The catch-22 of software management is that the ones who want it most are usually the worst at it ...First, kill all the managers, eh, Steve?
Software companies that prize managers above engineers are guided by their own Invisible Hand to become a henhouse of clucky managers pecking viciously at harried engineers. Sadly, most software companies fall into this trap, because they're borrowing traditional ideas about management from non-tech industries ...
I don't think anyone's figured out how to make a no-management structure work for an org with hundreds or thousands of engineers. I do know one great company that's come really close ...
Unfortunately I have neither time, nor space, nor in all likelihood permission to explain their recipe for success with almost no management. You'll just have to take my word for it: if you take all the managers away, great engineers will still build great things. Maybe even faster.
If you have seen the harm middle managers can create, it is hard not to be sympathetic with this view. I do think Steve is right that a software engineering company can do very well with almost no management.
Mentoring and program management are probably better off being independent of technical management. Forming a unified vision for an organization, an important part of leading a group, does not require layers and layers of middle management.
Steve may not be willing to talk about Google's recipe for success, but, to the limited extent that I know it, I can.
Google has almost no management. In 2003, managers were at the director level or higher and had 50 or so reports. More managers have been added since then, but I believe that 20+ reports is the norm.
Program management is done in a separate organization. The PMs have no power over the engineers, not even an appeal to engineering managers, since there are none. The PMs try to bring order to the chaos, but they must do so by convincing people, not by commanding them.
Mentoring is done by other engineers. People learn by doing. You want people to dive into the code and learn from those who are closest to the problem.
Parts of the vision emerge from everywhere, brought together, clarified, and unified by the few managers that exist. Despite a few people wandering up other peaks, most are guided up the same hill.
Communication is direct through informal networks, not through the management hierarchy. Transparency and pressure from peers provide for accountability and limit free riding.
Titles are unimportant. A "software engineer" could be a former tenured professor or a recent college graduate. A "program manager" could be a former CTO.
To imitate Google, it is important to realize that there is more to do here than just suddenly sending your middle managers out to sleep with the fishes.
Tasks often done by managers need to be moved out of a management hierarchy. Informal networks and a culture of transparency need to be encouraged. Hierarchies must be destroyed, titles made irrelevant, and compensation and rewards redesigned.
If you can do all those things, then let's bring out the cement shoes.
