Collaborations within hierarchies

My further reading of The Firm as a Collaborative Community offered up some more insights I have previously rejected. I have assumed that bureaucratic hierarchies could only put on a show of collaboration, claim to be collaborating, but then not actually collaborate. This assumption of mine is based on decades of experience with observing bureaucrats who go through the motions of the latest management fad without realizing any of the benefits and who are forced to join teams that function "as a team in name only".

Chapter Five challenged this assumption. In Beyond Hacker Idiocy - The Changing Nature of Software Community and Identity, Paul S. Adler reveals how huge software development projects evolve into collaborative dynamics. Bureaucracies don't necessarily rule out the inefficient and serendipitous process of innovative collaborations.

In my own language, there is a process of acculturation of the "cowboy coders" to do both the "work and the paperwork". Once they see value of leaving a paper trail of their own thinking, work and changes to the project, they begin to value the required reporting process. They switch from complaining about so many "rules and regs" and think instead about how to improve them.

When collaborative dynamics emerge among the software coders, they work together to improve the processes, policies and design standards they work under. They get more buy-in to the imposed constraints because they have participated in their formulation and final selection. The outcomes of collaborative efforts yield less rework, cost overruns and schedule slippages. They realize some "best of both systems combined": top down controls and bottom up innovations.