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:

1. Managers never knew software development
2. Managers who used to know software development have been away from it for so long that they no longer know it
3. Developers don’t know management
4. 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.

This is a somewhat old article (2006), but it eludes to something that I have found a bit bothersome about attitudes regarding software engineering career paths.

I recently interviewed for a Business Analyst position with the CIO of a large multi-national software development firm. This man was in charge of the company’s worldwide IT operations, including offshore development projects, for which he was searching for qualified Business Analysts. The interview quickly became a casual conversation about current trends within the IT service sector, how the company was planning to take advantage of those trends, and, most importantly, how I could fit into those plans. It was during his evaluation of my skills that I asked how I fit and whether it was technical or business skills that were most valuable to his projects. The CIO summed up his advice about my career path with one small sentence: “Stay on the business side.”

The author goes on to state:

My job searches have suggested that business and systems analysts with a good programming background and a high-level of “business savvy” are becoming the next hot ticket. More and more organizations are finally hiring business analysts to explore, record, and recommend systems that fit the business—as opposed to the other way around.

While I agree with what the author is trying to say here, I think he missed the point. And the CIO quoted above is severely mistaken… Sure, you can train anyone to “be technical” and write a program, but you cannot train those people to do it well. There is a big   huge critical difference between a software developer and a good software developer. I first observed this in college, when some of my classmates loved working on programming assignments and performed very well on such things, while others fumbled through the simplest assignments, unable to get their code to compile, much less work.

Why were such people majoring in computer science? I’m not sure, but its probably because they thought they liked computers and would therefor like programming, or maybe because they heard it would make for a good career.

I don’t mean to pat myself on the back, but I (like many others in my field) didn’t realize that software engineering may be a good career until I was well into my Computer Science major. I started writing simple programs in the 6th grade, going to the library and checking out every single computer and computer programming book I could find. Later, after I had read all of the books that the small local public library had on the subject, I discovered Nibble magazine (also available at the library). Every good/great programmer I know is someone who landed in the career because it was something that he was drawn to naturally, and most of these people began at a young age. These are the people who write software because they like it, and this is why they are good at it.

Anyway, at one point, after being frustrated that my library didn’t have any more computer programming books to read, I found a strangely titled book that had been misplaced next to a book about Applesoft BASIC: The Peter Principle.  I checked it out, if only because I thought the title was funny, and I took it home and read it–all of it! I was probably the only 7th grader in the world to ever read the book, which by that time was already very dated. The closest I had ever come to the corporate world by that point in my life was delivering newspapers. I was a fairly competent paperboy, and even if I wasn’t, failing as a paperboy doesn’t lend itself to a very clear path of promotion. That said, the wisdom of The Peter Principle was lost on me.

Little did I know that years later this strange book would be remembered much more vividly than the Applesoft BASIC book that I had checked out dozes of times.

The CIO, probably much older, wiser and richer than me, missed something major: Anyone can write code, but do you want just anyone making important technical decisions that can make or break your project, department or company? I didn’t think so either. Not just anyone can write good code. I’ve seen the results of software written by cheap labor… Indeed, I’ve rewritten code written by cheap labor!

I think there is a very obvious career path for software developers, and it doesn’t necessarily involve moving into a role that no longer includes hands-on software development. I disagree that upper management doesn’t realize this. I think in many organizations they do. I intend to write more on this subject…

[Career Paths for Programmers by John Bennett, Jr. - developer., Developer Dot Star]