In 1969, a guy named Dr. Laurence Peter wrote a book in which he described a consequence of promoting on merit within a hierarchical organization. The consequence was that people get promoted because they are competent at their jobs, and eventually reach a position in which they are no longer competent. In a fit of creativity, he called this the Peter Principle.
There are a few obvious and not so obvious consequences to this. One is that, in a company which has had managerial turnover, any person who has been in the same position for an extended period of time is probably not competent to do the job. There are obvious caveats to this, and the evaluation must be made on a case by case basis … for instance, a person in charge of every absolutely critical project a company has produced over a period of years probably handles that effort very well.
A not so obvious consequence is that creative upper management has identified this problem, and has invented the idea of a “sideways promotion” in which they give the no-longer-competent person a set of duties that is more in line with his previously displayed level of competence, but at a hierarchical level equivalent to his most recent promotion. This, of course, results in upper management bloat, because someone has to do the job that is being vacated by the “sideways promotion”, so another manager is promoted to that position.
Upper management bloat as a result of “sideways promotion” also frequently changes the focus of a company from developing products to developing process (since those managers can not be put back in charge of the product development they previously controlled, but are only competent within that context and must do something to give the perception of productivity.) Companies that become predominantly process generators rather than product producers are in trouble, and this is what happened to many small consulting companies toward the end of the Internet bubble. Although this cause paled in comparison to one I will mention momentarily.
In 1990, Scott Adams (creator of Dilbert) made the satirical observation that companies promote their least competent employees to management to limit the amount of damage they can do to the company (similar to my frequent desire to have different political parties control each of the Legislative and Executive branches of the US government.) Unfortunately, this observation had its root in fact. And, as Scott Adams intended his Dilbert Principle to be satirical, I choose to slap my own name on my interpretation of it … therefore, the Render Principle:
The problem is that, in an environment in which the fundamental production requires a high level of education or training and a creative and disciplined mind, the number of competent, not to mention talented, employees is fairly constrained. In a tight market, they become absolutely rare. So, while the traditional promotional methods require that these talented individuals be promoted into positions of management, in, for instance, the IT field, a company that did so would find itself unable to produce quality products (this effect can be mitigated by putting in procedural checks, like formalized unit, integration, regression, and user testing.)
But these companies need management that is familiar with the development requirements and techniques … therefore, they must promote from the same pool of employees. If it would be suicidal to promote their competent employees, they have no choice but to promote their less capable counterparts, evading the fact that inability to perform the minutiae of product development probably indicates a lack of understanding of the entire process. This is usually not suicidal because the competent developers frequently have such a strong work ethic that they will save seemingly doomed projects from the ineptitude of project managers, but this results in very long hours, poor home life, poor health, and general job dissatisfaction (the only reason they don’t leave for a better position is how pervasive the situation is in the industry.)
There are features of bad managers that complicate the issue and put more work on the remaining developers (for instance, interpreting their inability to manage as a lack of control of the development process, forcing them to impose unnecessary layers of process and documentation on an already burdened development team), but I will address those at another time.
Knowing this is the situation, all competent IT professionals, when interviewing for new jobs, should ask questions that will identify if they will be working under one of these types of managers. Think about what kinds of questions those would have to be.