Hack

Hack: Free to Fork

by David Mason - Product Manager at Mozilla
Co-Authored by Jonathan Opp, gunther brinkman

September 6, 2011 at 7:36am

1 Comments

2 Ratings:

Overall 4.25
Innovative 4.5
Detail 4

Contribution Summary

Summary

This hack gives all employees the power to take management’s ideas and rework them to either replace the idea or merge the two together. Taking a cue from the open-source software world, the fork allows everyone to have a voice, and the best ideas to come to the fore.

Moonshot(s)

Problem

Organizations need to change fast to innovate fast. Innovation depends on a diversity of ideas. Yet over time many organizations suffer under a culture of groupthink where dissent is discouraged, diversity is weeded out, and employees are given neither the freedom nor the platform to seek better answers.

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.

Solution

In the open source software movement, an essential element to the power of open source (which leads to faster development, increased innovation, and greater stability) is the concept of forking.

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.

Practical Impact

Not all companies work like open source projects/companies do. Despite the origins of this hack coming from the open source world, in practice, that shouldn't matter. This is about collaboration at its heart. Were a company to implement a forking system, they would reap instant collaboration, not to mention, transparency.

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.

Challenges

Getting all of management to buy into the idea and allow it to happen at their level.
Convincing employees to not see it as just another exercise but to see it as a real forum for their voices to be heard.
Demonstrating that just because someone has the power to fork your idea, it can still be worth spending the time to work on it as it either sparks the a idea or can be merged back in to the new idea later.
Getting everyone to buy into sharing at all levels. For this to be successful, people must share their work. If one doesn't know all of the work and research that has gone into an idea, forking it is much harder and can simply be a waste of everyone's time. The organization must be committed to sharing work across the whole structure.
Keeping order in the chaos of forks. Were this to be successful, it could be overwhelming to have a good number of forks to keep up with. This is where software can play a role. If everyone's ideas are submitted in a system that can track the ideas and allow management to easily approve or reject ideas, the task of ordering would be easier to handle.
Ensuring action is not unduly delayed by teams forking ideas or constantly iterating on the original idea without reaching consensus. There can be too many cooks in the kitchen, collaboration is incredibly useful but there must be strong leaders who can quickly decide when its time to move.
While it possible that this hack could work in nearly every type of company across industry sectors (with some modifications to suit different business environments) it may not be suited for every type of decision. Financial decisions, M&A, personnel issues, sales visits, and the like may benefit from an altered form which is used more as a "post-mortem" with specific members rather than letting everyone in on tough decisions. Having said that, members of an M&A team may find that a smaller version works within their group when looking at something like a large merger than can not be shared with others.

First Steps

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.

Credits

David Mason
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.