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.
