The mushroom management anti-pattern is one that appears everywhere. While it can be simplified to keeping employees in the dark, there is more to it. The side effects of this anti-pattern can cause long-lasting problems and even prevent a company from success. Let's look at it from the software development point-of-view.
The simple definition provided by Wikipedia gives us an excellent starting point for discussing this anti-pattern. [Click Here to See The Page]
"Mushroom management is a style of management in which the personnel are not familiar with the ideas or the general state of the company, and are given work without knowing the purpose of this work, in contrast with open-book management. "
I love this definition because it highlights one of our favorite topics. This implies the value of knowing the "why" for your work, even at an enterprise level. Confusingly, this is not a surprise to anyone. The reason behind things like vision and mission statements is communicating a corporate "why" to employees and customers. Why stop there? It only makes sense to carry that sharing of why things are done down to the lowest levels. When it is then you by definition are building the culture into everything a company does.
If you have ever talked to people that work in highly secretive situations, then you have heard about the challenges those environments create. This approach can even lead to the left hand, not knowing what the right is doing. While that may be required to protect some projects, it should be avoided where possible. There may be a sense of power in being able to keep knowledge from the staff, but that is detrimental to a team approach. It implies that team members or staff are somehow not worthy or capable of knowing completely the problems they are solving. I can not see how trust and loyalty will ever grow in such an environment.
While there are many problems this anti-pattern creates, the most damaging is the lack of using your team. A lack of information about a problem prevents team members from using their experience and skills to address the problem fully. They do not have the context to bring all of their abilities to bear.
For example, we can look at the idea of driving a nail into a board. When all the worker is told is to hit the nail with a hammer, then they will hit it once and maybe without the best amount of power. There is no context to allow them to use their nail driving skills. Now, let them know they are to drive the nail into a board and that it is best to do so until the nail head is flush with the surface. In this case, the worker can use previous hammering experience to take the best number of swings and proper force to complete the job. Better yet, they will not just finish it, but do so faster and better than if you have to talk them through it blow-by-blow.