What Does it Mean to Have an Open Mindset?

Here are four ways that thinking openly can help us curb bureaucracy.

Huiren WooSuccessful companies are those that grow and expand. But bigger companies often need more managers. Excessive layers of management can instill cumbersome bureaucracy in a company, and bureaucracy can become a significant problem for companies when it can causes wasteful resource allocation, decreases productivity, and decelerates innovation.

We can observe that open thinking can challenge or overcome potential problems of bureaucracy. Even if your company isn't a software company, it's still possible to adopt the mindset prevalent in free and open source software communities and instill openness within your company's culture.

Distributing knowledge

We know organizations work best when people inside them sufficiently understand how all the parts of those organizations are working. Achieving this kind of knowledge is easier on a small scale where only a few people need to achieve complete understanding of the entire system. As time passes, however, and experienced employees get promoted to managerial positions, layers of bureaucracy form—and slowly but surely, the company grows into a top-down bureaucratic system in which certain members embody only the knowledge necessary to oversee their specific parts. They carry that knowledge with them wherever they go, and imparting it is often a one-to-one (or one-to-few) activity. This ensures the bureaucracy is slow to to change.

We can fight this tendency by following the example that open source software communities have set for us. In these communities, people often must work with others who are located around the world (and thus in different timezones). If someone from, say, another timezone does not understand the code for a particular project, he or she would have to wait for several hours for a response. This situation tends to compel everyone in the organization to write modular and readable code. It ensures decentralization of knowledge (through copious documentation and the establishment of knowledge commons) and makes it easy for new contributors to understand and participate.

This situation also forces people to be responsible for their own actions and adopt decentralized decision making practices. Having a culture of accountability, which forces people to be responsible for themselves, allows managers to relax and let go of many trivial decisions. In the long run, managers will also be able to trust the employees more, allowing them to participate in major decision makings and listen to their trusted opinions. Slowly but surely, people will start to assume the best intentions of everyone, and this would significantly reduce the effects of politics. Overall, the company would become a productive and respectful place to innovate and work in.

User-initiated effort

Imagine yourself as a business software customer. The software you pay for is unstable and always crashes. You visit the vendor's site to look for a feedback form. It doesn't exist. So you try emailing the company's support team. Days later, you have yet to receive a reply. You are angry and upset, so you go to a software review site and give the software a bad rating.

Here's what was happening on the other side of the screen. Behind closed doors, the company was forwarding your feedback to several people. It only reached the appropriate management team after several days of this—that is, if the feedback did not get lost through the chain of command. In the meantime, employees who saw your negative review were not allowed to respond, as doing so would not be compliant with the company's public relations protocol.

In open software development teams, maintainers and users maintain open communication. Users take initiative in giving feedback and suggesting possible solutions, typically through filing issues or pull requests. They don't just file complaints; they also offer solutions (which they're able to do because they're working with open code). On the other hand, open software maintainers tend to listen to users' feedback and review the solutions they submit as pull requests. The open nature of the code—and the open nature of the attitude between the users and the developers—leads to more user-driven initiatives and a more responsive development process.

Here's one example of of this process in action. A Digital Ocean user recently faced some trouble navigating through the user-facing menu system. He tried sending feedback to Digital Ocean, but he received no response. So he took the initiative of developing a Google Chome plugin to make the system easier to navigate. He made his code open source, then shared his experience on HackerNews. Some time later, the Digital Ocean staff noticed his feedback. In just a few hours, Digital Ocean implemented some of the user's proposed changes and offered to make the remaining changes within a few months. Both the user and the staff members embody an open mindset, and this shows how powerful that mindset can be. Staff listened to feedback. The user felt respected. And outside observers likely felt encouraged to continue giving constructive feedback. The accelerated development process perpetuates itself.

Stirring competition, boosting innovation

Large bureaucracies tend to be risk-averse, but innovation requires risk. In order for even a small innovation to become a fully grown product, that innovation must go through several processes of experimentation—processes that are likely to fail and yield a net loss for the company.

Having an open mindset means constantly asking, "Can this be improved?" and "Is there a better approach to this problem that we have yet to discover?" Questions like these are critical motivators for innovation. Open source communities encourage experimental thinking, discussions, and debates; members tend to collaborate by default and listen to each other's opinions, always understanding and never immediately trying to dismiss an idea as "too crazy." This kind of thinking has already led to the rise of innovative solutions from several places— Hadoop, for example, or CockroachDB.

The healthcare industry might provide another example. Here, companies of all sizes need enterprise software that complies with certain standards and regulations. Even small, family clinics must purchase software (or they might get fined for not doing so). Only a few software companies that specialize in this area and offer certified, compliant products. As regulations are complicated and compliance is expensive, this increases the barrier of entry—making it easy for those giants to maintain their oligopoly and charge high prices. And since there's no competition, there are no incentives for them to take risks and innovate.

However, open source communities are beginning to make waves in this field and disrupt these giants through innovative (for example, consider OpenEMR, OpenMRS and LibreHealth, which are helping to disrupt this space in different specialized areas of healthcare). These FLOSS communities see the need to stirr competition to benefit everyone whilst constantly coming up with new ways to approach problems that the giants have refused to address.

Adopting an open mindset

So how can you and your teams begin thinking and acting more like an open source community? You can immediately begin adapting some of your company policies to achieve an open source mindset.

First (and on a personal level) you should actually get involved in these communities, observe their discussions, and see how they operate. You'll definitely need to get your hands dirty for a few months to understand what it is like being in an open community. Think about a field you're passionate about or a particular problem you'd like to help solve. Getting started might sound daunting, but these communities are usually filled with friendly people willing to help you get involved. Ask how you can contribute with your skills and they would tell you about a few minor things they need a hand with. You'll need to start small and gain the community's trust before you'll be able to work on even bigger things on hand.

Second, allow your employees to work remotely if they'd like. Doing this will have a few benefits. At first, it will enhance levels of trust on the team. More often than not, managers and other leaders do not allow employees to work remotely because they don't trust their employees. Managers can learn to work more like open source community managers, respecting and trusting their employees, and expecting to interact with them remotely. Fostering a more open, remote work environment will also force people to change the way a team needs to communicate. When you you observe how open source projects work, you'll see people are almost all working together from different timezones. Surprisingly, these contributors are still able to communicate well with each other. They do so by being honest and upfront with each other through mailing lists and the respective project's repository issues section. In this way, communication is open and people are able to participate and contribute useful information whenever they wish—leading to a culture of distributed knowledge and decentralized decision-making, as I described earlier.

Lastly, do something crazy—even if it might not make business sense. Innovation means doing things outside the norm and challenging certain existing ideologies. Few people expected open source models (and the communities that power them) to work either, especially during the early 1990s when skeptics were everywhere. But if Linus Torvalds hadn't dared to start a free software project like Linux, where would the world be right now? Cultivate a culture for your team in which your employees will be motivated to experiment new ideas and occasionally. Let them feel okay doing fun but "meaningless" projects. For example, I've seen teams build an Internet of Things (IoT) sensor that lets them know when someone is using the toilet—and allows employees to book the toilet using the Slack messaging platform. It was somewhat useful, but doesn't really justify (economically) the time they spent doing it. But their purpose was to have fun and experiment with IoT, which I believe they certainly did.

In the end, remember: One should definitely tread carefully and manage cultural change properly. Context matters; what works for others does not necessarily work for your company. Remember to listen to your employees' opinions before treating your organization like an open source community.