The Peter Principle says, basically, that people are promoted until reaching a level of incompetence. I think the reverse of this can be true as well: An employee may not be promoted because he or she performs very well in a given role.
This is just me talking, but I think there are a few problems with the way we view employment hierarchies in the software engineering world:
- Managers never knew software development
- Managers who used to know software development have been away from it for so long that they no longer know it
- Developers don’t know management
- There is no clear promotional path for the motivated software engineer
I’ve known a number of software developers who have either turned down promotion or given up a management role because they preferred software development. I suspect then, that the people left to do software management are either people who didn’t like software development or were not very good at it. This isn’t to say that they aren’t great managers (they may be), but it does lead to the possibility that the people in charge of software decisions may not be the best equipped to make those decisions.
Managers Never Knew Software Development
These days many large companies like to assign a PMP to a software project. This is an individual whose job is only to “manage a project.” The individual contributors of the team (software developers, testers, writers, etc.) don’t actually report to this person. The project manager’s role is specifically to work on timelines, track progress and ask the people who are working diligently to report their status (presumably for input into the timelies). If the company doesn’t have a dedicated project manager, this set of tasks falls onto the shoulders of some other manager.
What ultimately happens is that a lead developer will be tapped for all this information anyway, since the project manager, who doesn’t know software development and isn’t writing software, isn’t equipped to provide a meaningful level of detail in this regard. Interrupting a software engineer to ask his “status.” achieves nothing that a good project plan and appropriately used ticketing and version control system cannot.
That said, a good project manager is an individual who knows and understands software development and can provide project status details to upper management without constantly interrupting a team. I’ll take it a step further: I don’t think there is ever a need to have a project manager on a team who isn’t in some way directly contributing to team goals. This doesn’t mean that the project manager must also be a software engineer, but the project manager should be a product contributor. Creating timelines, scheduling meetings and asking people, “When will you be done with that?” is not a full time job!
Yes, we may need a “project manager,” but only if the amount of work is so significant that project management activities are warranted. A better model, in my mind, is to have the group manager, that person who is responsible for the project, have a working team lead for each subgroup. In many cases I think a single team lead of all activities (software, QA, documentation) can suffice.
Managers Who USED TO Know Software Development
Here’s something that annoys me to no end: For a software engineer to take his or her career to the next level, moving into management, seems to require giving up on ever actually engineering software again (at least in the workplace). Ironically, the very people who are required to be hands-off are also expected to make major decisions about software, while their software expertise dwindles. Software engineering is a unique discipline in this regard. As a friend of mine recently put it, it is one of the few careers in which those of us involved with it essentially learn all new stuff every 5 year years.
I find this strange because, in my experience, there very best software leader is not the MBA or the person who has never been a software engineer, rather, it is someone who is STILL a software engineer; Its someone who knows what is going on in the world of Ruby, Rails, Grails, Hibernate, Spring, JQuery, Clojure, , Git, Maven, etc. because he/she is someone who uses such things regularly. The manager whose most recent software engineering experience is a string as a Cobol developer on an AS400 years ago isn’t very well equipped to make assumptions about the effort involded with a web application, for example. 20 years from now I don’t want to be telling some junior developer how easy a project should be because “I wrote the same thing in Java in 2 days back in 2010.”
No Clear Career Path
What I’m getting at is this: A software engineer NOT have to give up writing software in order to move into management (even beyond the lead engineer role). On the contrary–I think it would be better if software management, from director on down, included actual software engineering.