Managers attempt to solve this problem by asking people to “think out of the box,” but without a culture that supports a diversity of ideas, and without the platform to have those ideas heard and prototyped, eventually they get marginalized before they’ve been given the chance to succeed. Employees become complacent and execute management’s ideas, regardless of whether a better idea might exist.
We want to address this problem to help management bridge the gap between simply asking for creative ideas—and establishing a platform where divergent, even dissenting, ideas can be heard, and employees can be empowered to prototype and build support for them.
For any project protected under one of the popular open source licenses there is always the freedom to "fork" the software. This means that anyone can take the code, move it under a new name, change the code (and possibly the direction the project was moving) and re-release it. In the early days of open source, forks would happen when there was disagreement over the direction of the software, or the code-base was to be used in a new and innovative way. This, of course, has given the idea of a fork a very negative undertones for the people who have experienced it under these circumstances. Despite that negative reaction stemming from disagreement, often we would see forks rejoining their root after some time, as either the forkers have convinced the originators of their ideas, or the innovations that took place from the fork became greater than the debate.
Recently in the open source world, forking has taken on a new meaning as it is slowly being defined as the space where one works on their own ideas with the intention of merging it back in when it is ready. Thanks to modern version control tools the idea of the fork has gone from being fairly negative to being a more standard way to work. The fork is now a tool for collaboration that helps make merging easier and less likely to produce conflicts. The fork is becoming a safe place to work on one’s own ideas.
This hack takes the idea of the fork from the open source software world (borrowing from both its older and newer meanings) and applies it to management.
The “Management Fork” would allow employees to take decisions and ideas from leadership and rework them from their perspective. By allowing everyone in the organization to work on decisions and idea we can create an environment where the diversity of ideas allows those ideas to survive. Ideas are then protected until they have the chance to survive on their own.
Imagine a situation where a decision is made by management and communicated to the company. This is perhaps on an internal website or in a meeting. At this point a group of employees decides they want to tweak this decision by adding new ideas and taking away ideas they feel would not work. They let the leadership know (perhaps on the same internal website) that they are forking the decision and go off on their own to make the changes they think make it a better decision. When complete, they then give this new re-worked decision back to the leadership who either implement it as newly written or perhaps iterate on it even more.
Within this scenario the employees have a voice in the decision making process and the idea (decision) is given more thought by people with different perspectives. With these perspectives comes a mutation of the decision which gives it more buy-in across the organization, and thus, more chance of stability.
Were this hack to be implemented successfully, employees would have a different attitude to completed decisions because they would have some ownership of them. In addition, when a new decision was presented, they would view it not just as an edict, but as the starting point for finding a solution to the problem the decision attempts to solve. This hack would allow for the diversity of thinking that we so often pay lip-service to.
- Allow any employee to take an idea, work on it on their own or with others, and submit that work to the organization.
- There must be a platform to support forking. Communication is key. Interested employees must know that they can fork an idea and everyone else must be able to see and join in on those forks.
- To that end, these "forkable ideas" can even be shared on an online resource which includes a "fork" button to show the multiple variations of the idea side-by-side. This would allow everyone to see them and decide for themselves on the different directions.
- Decide who gets to accept and reject forks for each project or task. If a software system is used, include this sort of "decision maker" assignment in the setup. This may be one or many people depending on the size of the project. If a project benefits from a collective decision making process, make sure all members can see the forks and assign one member to be the front-person for accepting and rejecting.
- Implementing a forking system takes time and money. To try it, there must be some level of commitment. As previously mentioned, some system using software tools would help immensely in keeping this organized. Software costs money, and takes time to learn and use. Decision-makers must also be allowed the time it would take to review and decide on incoming forks. Still, with the proper level of commitment comes great pay-offs in collaboration as well as a change to the way everyone works.
- Encourage everyone to merge their ideas when feasible.
- Establish rules around what is “forkable,” and timeframes. Decisions that are time-sensitive for reasons of competitive advantage, decisions that have complex project plans behind them, or decisions that are nested within other decisions will either be out-of-bounds or on a very short time frame. For example, the decision to open a new plant nests with where the plant will be opened. Having an extended forking period against the proposal that a new plant be opened puts at-risk the ability to purchase the optimal site.
- Encourage as much openness and sharing as possible during the process. Without transparency, parallel developments of an idea can’t learn from each other and merge.
- “Release” decisions and ideas early. If a decision doesn’t have enough time to be forked before being implemented, this exercise is for naught. Certainly this can’t be the process for every decision, as so many are time-sensitive. Learn to recognize when it can be most useful and make sure forking is possible within the timeframe.
- Start small! There may be a group within the company which could benefit from collaboration and serve as a test-bed for forking. This is a great way to see if its right for your organization. If it works, spread it to a larger group to ensure that it scales.
- Be willing to fork a decision even after it has been made! This can be a very good exercise for a “post mortem” when a decision has been implemented and realized.
In addition to these first steps the climate to favor the fork is similar to those things that allow for the collaboration in the open source software world. Among them are:
* An environment where content is shared and all information is available to anyone.
If those who might create the fork don’t have access to the same information as everyone else, it will become very difficult for the fork to succeed, much less get off the ground. Transparency levels the playing field. Without it, forks fail.
* An environment where divergent thinking and failure are celebrated.
A fork will likely be seen as a challenge to the existing solution, and those who champion and protect them. People in organizations can become entrenched and territorial. The organizational culture has to be comfortable with allowing experiments like these to happen, and to allow the old way to fall away if the fork proves successful. Don’t be afraid of people changing your ideas.
* An environment where people have enough autonomy in their schedule and priorities to experiment. If people in the organization don’t have time and are fully allocated, they won’t have the time to consider solutions that are outside the existing solution. Perhaps the most well-known example is Google’s 20% time where Google sets aside engineer time to work on projects beneficial to the company and of the engineer’s choosing.
* An environment where the criteria for success are well understood and applied universally. If people don’t have 20%, they at least want to fail fast, and ideally fail forward. This not only keeps resources focused on critical day-to-day tasks, but it also allows for a positive feedback loop where learning occurs. Communities of Passion are by their nature learning environments.
* An environment where everyone has a shared purpose and understanding of the overall mission. Communities thrive because of a shared purpose. People need to know that everyone has the same interests and ultimate goals in mind—that they’re not acting out of their own best interests, but in the interest of the organization and the project. People may take different routes to solve a problem, but ultimately they all want to arrive at the same destination.
* An environment where the culture tolerates friction in the course of collaboration. People need a common understanding of the mission, but they also need a common understanding of each other. They need to build internal relationships and have a social structure that makes a truly open dialog possible. Challenges are directed at the validity of solutions, but not at people. People should feel a shared ownership of the problem, but not a protective ownership of one particular way to solve it.
* An environment where the management is open to, and even welcomes, contradictory thinking. They accept that they don’t always have the answers and that sometimes the best experts are the ones closest to the problem. The first requirement for this is making sure there is an open channel for communication that allows many voices to be heard--whether email mailing list or similar company forum.
Jonathan Opp
Gunther Brinkman
This Hack was collaborated on in the Hackathon Pilot and is based on David Mason's "mini hack" also completed during the Pilot.
This is a great image that I can use in my MBA classes (especially as so many of them have software backgrounds). I'm always looking for images that will help people see that they already know some of what they need to do to make an organization better. This is a great example of that and seems to come from a similar mindset to the Lead by Negotiating hack I proposed. I expect that the two images will be more or less helpful depending on the audience you have -- we need to speak their language and you're giving me another dialect.
Would like to know more about the merging process.
- Log in to post comments
You need to register in order to submit a comment.