The History of the Software Management Industry

I am often baffled when managers in the software industry assume a role of superiority over developers on the same project.  I am referring to people who are strictly managers.  Not lead developers or architects or the principle investigators or other types of visionaries who are crucial to the project.  I refer here only to people who were hired only to manage.

Any team of more than three people on a {set of} substantial project{s} is necessarily going to incur some overhead.  Some idea of progress needs to be tracked and communicated to customers (be they internal, higher level people or funders, or traditional customers, or whatever else), communication among developers needs to happen at the right time for maximal efficiency, goals and priorities need to be communicated from big picture visionaries to heads down developers.  Someone has to do the general PITA work so that developers are not distracted by it and can focus on writing code.  These things clearly need to be done.  But these things are also, clearly, shit work.

Other than the art of people-ese (and it is an art, and one that the rare good manager has in spades) there is little to no creativity in these tasks, and in far too many implementations, there is little to no skill.  The true task of the job is to eliminate all obstacles so that the people doing the heavy lifting can be maximally efficient.  The managers true and immediate customer, is the developer.  If the developers job is made easier by the manager, then the manager has done a good job.  If the developers is instead forced to jump through hoops at the managers whim with no regard for that workers natural resonant work cycle (which is too often the case) or the worker is left unmotivated (for whatever reason) then the manager has failed.

To me this is very obvious and logical.  So why is it that in almost all cases the manager is seen as the developers superior?  Why is the manager schedule dominate?  Why, on earth, is it that the manager evaluates the performance of the developer?   Isn’t this backwards?

I have a theory on how this evolved which I will illustrate below using my sub-par narrative skills.

A long time ago, before the advent of the ‘Project Management’ section at Border’s Books, there was a fabulous developer named Bob.  Bob had it all, vision, skills, personality, ambition, and he was a mountain dew slamming espresso drinking code machine.  The small project Bob was working on became very successful and thus hired more developers.  Because of this influx of people there was a bit of chaos and it was obvious that some coordination of effort was needed.  The progress of developers needed to be tracked so that commitments could be made and fulfilled, developers needed to know how to properly divide up work and integrate it once complete, and general bit of communication and paper work had to be done to ensure that progress was being made efficiently.

Because Bob had proven himself as able in the technological arena, the company leaders asked him to take on this role.  Bob had fabulous foresight and little use for perceived power and therefore he was able to recognize that these new responsibilities were shit work.  However Bob also was devoted to the effort and wanted to see the project succeed, so he said to the Big Bosses: ‘I will do this shit work, but since my job satisfaction will go down, my salary will need to go up’.  (It is like that time in college after a party we had at my apartment when we noticed that someone took a dump in our shower.  My roommate Andy was willing to clean it up, but only if the rest of us pooled together enough money to make the task tolerable).

So Bob took on the new role and, of course, he hated it.  Bob wanted to create, not track.  Bob wanted to build, not coordinate.  Bob didn’t want to be a secretary for the real moving parts of the project.  Bob felt like nothing more than lubricant in machinery, so he quit to find a new outlet for his creativity.

Naturally the Big Bosses were very sad that Bob left.  He was a valuable developer and co-founder of the project.  The Big Bosses recognized that being a manager is what made Bob quit.   They thusly figured that perhaps being a manager would make all good developers unhappy so they decided not to replace Bob with another developer, but rather to find someone who was just a manager.  The precedent had been set by Bob that this position must be more highly paid to compensate for the pains that it entails.  Early on everyone still understood that this existed to make the developers job easier.  It was there to organize developers, redirect them to the common cause, do paper work for them, eliminate distracting meetings and other overheads, and at times, in the case of the truly talented manager, motivate them.

Unfortunately this changed.  The manager was the liaison to the Big Bosses, because in general dumping state for the Big Bosses is just a distraction away from the developers true work.  Also the manager made more money, and as it tends to go, this implied they were more important.  Further, the manager had communication channels with the Big Bosses, and thus had their ears.   So as time when on organization and overhead and coordination gave way to scheduling.  And scheduling gave way to prioritizing, and then to demanding and reviewing.  Soon the manager was seen as the superior of the developer.

From this an entire industry emerged which sold books and seminars on synergy and extreme programming and scrum and agile and software products to help you un-myth the man month.  Bob ran off to start a utopian society with Eve and Alice.