Anit-pattern of February -- Mushroom Management- Keep them in the dark

Two weeks ago, I mentioned that I I attended "Hackathon” workshop at Microsoft office located at Polaris. During the workshop, a few speaker gave some presentations and demos on all kind fun and cool staff.   the organizer provided promotional items for the attendances. these promotional items including books, software etc. one of them caught my eyes, that is a 2014 calendar titled “Software Craftsmanship- Anit-patterns” from a company named Telerik.

it list one anit-pattern in each month and with photo and explanation elaborates what is the anti-pattern and why it is bad. I thought it is a fun way to address Software development issues..

Anti-pattern of January is Mushroom Management- Keep them in the dark

The elaboration says:

The practice of reducing or eliminating the development team’s contact with the end user and the reasons for the project requirements, thereby risking the creation of unwanted features

The link above provides some further reading on the anti-pattern ( including this interesting photo). for your convenience, I copied some here:

Mushroom Management refers to the practice of treating your developers like mushrooms - to wit, "keep them in the dark and feed them BS." By introducing barriers between those who develop the software and those who use it, feedback loops are extended (or destroyed) and the likelihood of mis-communication, invalid assumptions, and building the wrong thing skyrockets.
Ideally, the customer or their representative should be co-located with the developers, who themselves should be co-located. This minimized the communication friction involved in the development process, which should be a shared effort between all members of the team (yes, the customer should be a part of the team, along with the developers, designers, testers, etc. involved).
At the business level, ensure your employees feel like they know what is going on with the organization. Share as much as you can, especially about big picture items like the mission, goal, vision, or strategy that everyone should currently be following. Thus, even if the details of the plan aren't yet ready, or an individual department's plan hasn't been formulated, individual employees can make good decisions in the best interests of the company's internally expressed intent. Without sharing this information, employees are each left to their own devices, which causes stress in the best case and results in inefficiencies and possibly conflict with management (when the wrong decision has been made due to lack of information) in worse cases.

In my over  3 decades  of working experience in IT industry, my observation is that this anti-pattern happens when these in the projects felt less confident than they should be.  they felt more comfort when they withhold information to themselves; they felt they would be more indispensable  when they are the information hub for all parties. they like to be the decision makers for as many decisions as possible; they like the sense of being “in control”

The question would be asked is “how to break the pattern?” Well, the leadership is the key. The leadership is the crucial factor  in establishing positive culture in an organization or a project team… It is similar to a family, when the elder son wants to withhold his toy from his younger brother, it is the time for the daddy or mommy to step up and say “ no, you should share the toy with your brother!” For a leader in any team, if he or she is really put the project interest at his or her heart, he or she would never want to put his team in the dark…

At the bottom of the calendar of the month it quoted Edward Yourdon as as saying "If you think your management doesn't know what it's doing or that your organization turns out low-quality software crap that embarrasses you, then leave."