Peter Principle and Software Architects

It's time to address an uncomfortable truth within IT: technology professionals have a tough time finding, retaining, and promoting people with leadership ability. Instead, technology professionals, especially in consulting, tend to promote people based on their ability to do their current jobs and their knowledge of technology. This type of promotion leads to the Peter Principle, which is the idea that people get promoted until they cannot do their job anymore, which leads to them failing and getting fired. It also leads to business leaders losing their faith that IT can manage themselves, causing IT to lose their place at the executive table.

The problem is that typically people aren't promoted to a job that requires the same skills. Managing people well requires the ability to understand people so they can be motivated to do their best work, which only rarely requires a manager to be able to do a job better than the employees can. A leader (CIO, CTO, etc.) must understand their industry and know how to react to industry trends, and must be able to create plans for the managers to execute. But instead of promoting people based on their ability to do their new job, they're too often promoted based on their ability to do the job that they have. This makes sense to a certain extent - if you have a team member who clearly excels at their job more than any of their peers, would you promote one of the lesser skilled team members?

Within technology departments and companies there is another issue that is contributing to the problem. As I mentioned earlier, promotions within technology areas tend to occur based on a candidate's knowledge of technology. I would argue that knowledge of technology has surprisingly little bearing on how well a software product is built (though a detailed explanation of why that is the case will need to wait for another day), and it certainly has no bearing on turning around an underperforming employee's performance.

Let's examine a fairly common example of the Peter Principle at work: promoting a good software developer to a software architect. Many companies treat a software architect as a senior software developer, but if done correctly, the positions are quite different.

	Developer	Architect
New Technologies	Must understand the details of new and emerging technologies and how they can solve a particular problem	Must understand at a high level how new and emerging technologies can solve a particular business problem
Business Requirements	Must take a micro-level business requirement and anticipate end-user needs (such as form field validation)	Must take a business need and envision how that could be solved (with or without software)
Return On Investment (ROI)	Does not need to understand ROI	Needs to find the right balance between the best software solution and keeping costs appropriately low
People Management	Needs to be able to communicate with peers about the specifics of technology decisions	Needs to be able to communicate with and persuade people with a wide range of experience, from developers to project managers to business stakeholders
Code	Must write clean, clear, understandable, and maintainable code	Must understand why developers focus on code quality and must be able to communicate these reasons to business stakeholders
Debugging	Must be able to find and fix problems on a micro-level	Must be able to look for macro-level logical fallacies in business and technical requirements

Looking at this list, it's not hard to see why people promote their best developers to be architects. On the surface, it appears as though the architect must do everything that the developer does, except have a higher-level understanding and have better communication skills. And I will be the first to admit that having developer skills would help an architect do their job well. But here are some problems that occur when you assume that the best developer can be an architect:

• A good developer needs to be extremely detailed. They must understand where a user might make a mistake on a single form field, and understand how one line of code might cause problems several hundred lines later. If an architect tried to think at this level of detail, he/she would be extremely slow to make decisions as he/she gathered all the information needed to understand the problem.
• Similarly, a developer must be able to communicate very small issues to other developers and to the architect. To contrast, an architect must understand his/her audience and provide the level of detail necessary for that person to understand the issue at hand. Just because a developer can communicate well does not mean that he/she can communicate as an architect should.
• A good developer should spend time on their own learning about new and emerging technologies so they can work with them on a moment's notice. An architect must instead have at least some knowledge over a much wider array of subjects, both technology- and business-related.

In other words, the detail orientation that is needed to be a truly fantastic developer can at times be a hindrance for an architect. Instead of promoting the best developer on your team to be an architect, focus on finding the big-picture developers on your team and training them to be architects. To make this work, you'll also need to build a company structure where there are multiple means for advancement and build a culture where being excellent at a career without being promoted is okay.

You should also take the same approach when promoting people to leadership and management positions within your organization. Promote people based on their ability to do their new position rather than their old. Your company will be better for it.

Other posts in this series

June: An introduction to Leadership vs. Management

July: Is a project manager the right person to put in charge of your software project?

August: How do you manage an Agile software project?

September: How to leverage a project administrator effectively

October: Getting programmers to see the value in management

November: The Peter Principle and software architects

December: Creating a leadership team to make your software project a success