“Everything finds its level” is an old adage and while not actually true, is nevertheless a useful proposition.
The best performers in life and in organizations are those operating at their natural level of abstraction. Unfortunately most people and most organizations have no idea what this means, so let’s take a look at some examples.
More than two decades ago I was working for a large database company as part of a group that was supposed to be helping chart the company’s future strategy. One of my colleagues was tasked with participating in the SQL standards group. Ideally he’d have been thinking about how each proposed addition or alteration to the standards would impact our company’s users.
His level of abstraction, however, was at the detailed technical level. He knew everything there was to be known about current standards, proposed future standards, and their deep technical implications. But he had no concept of why any of this would matter to people buying and using databases and so he was incapable of providing either strategic analysis of potential impact nor was he able to steer the new standards in a direction that would help customers. His level of abstraction was too low to be of use in the role he’d been placed in.
It’s surprisingly common for organizations to assume that if someone is competent at one level then after promotion they’ll be equally competent at their new level. The fallacy of this belief was pointed out back in 1969 by Laurence Peter, who explained that in most organizations “people rise to their level of incompetence.” We can illustration what became known as the Peter Principle by looking at the career of a software developer whom we’ll arbitrarily call Mary.
Mary emerges from coding school as a reasonably competent programmer in a couple of well-known software languages. She gets hired by a large organization and becomes a reliable worker, quite good at her job, liked by her peers, and trusted by her manager to deliver good code on time. After a couple of years her manager is promoted and Mary is selected to move up into his place. Although she has no formal management training she basically emulates what she saw him do and becomes an average manger, though at times she feels like she’s floundering. As far as her superior in the organization is concerned, however, she’s likeable and performs just well enough to be judged successful in her new role.
A couple of years later she receives another promotion. In this new role she’s managing a series of managers who in turn manage teams such as the one she was originally part of when she joined the organization. Now Mary is frankly out of her depth. After a while it becomes obvious to her superiors that she’s not really cut out for higher management. So for the rest of her time in that organization, Mary stays where she is. Her next promotion is really just a sideways move, though she gets a slightly more impressive title and a small pay increase. This is as far as Mary will rise. She’s reached her level of incompetence.
Why does this happen in nearly every organization that’s ever existed?
Partly it’s because few companies have adequate guidelines for promotion and on-the-job skills enhancement. Mostly it’s because few organizations realize that if someone is good at their job they should be able to benefit from remaining in that job rather than aspiring to move up the career ladder in order to secure the benefits accruing to seniority. If they’re good at their job, chances are they’ve found their level of abstraction. The organization can benefit from letting them do a good job where they are instead of promoting them to do a bad job higher up the ladder.
Great organizations have parallel career paths. For example, a really good software engineer should be able to progress from junior engineer to principal engineer without ever having to step sideways onto a management track. More shares, more prestige, more salary should all accompany each step along the developer path so that a great developer can earn more salary, have more stock, and have more prestige within the organization, than a just-average Vice President. This way the organization can continue to benefit from the engineer’s excellence rather than turning them into a mediocre manager.
Sometimes organizations unintentionally self-sabotage by listing job requirements that are actually the opposite of what they really need. A classic example of this is the insistence on only hiring project managers with PMI certification. Anyone who’s actually gone through the Project Manager’s Institute course will understand why this is a very poor requirement. The PMI course is akin to believing you can train F22 fighter pilots by making them learn every detail of how to assemble a Sopwith Camel. It is so out-of-date and so wedded to failed approaches that anyone holding a PMI certification must discard everything they were forced to learn or else they will wreck every project they’re asked to manage.
Why do some organizations make this mistake? Sometimes it’s because they let Human Resources get involved in the hiring process, which is always and without exception a grave error. As HR personnel know nothing about the jobs they’re being asked to help fill, naturally they look around to see what indicators are out in the world that may provide some guidance. Stumbling upon the fact that there is such a thing as the PMI certification, HR people will often throw it in as a requirement because they have no idea how antiquated and irrelevant it is.
At other times the hiring manager themselves makes precisely the same error. Worst of all is when a manager who’s done the PMI course and doesn’t understand how unhelpful it is asks for the same certification because they believe that only people with the certification can be “real” project managers like them.
While we’re using the PMI certification for this example it’s important to realize there are plenty of similarly unhelpful certifications and qualifications out there, ranging across nearly every functional area.
Agile certification is another example of how well-meaning managers can end up with unhelpful requirements when hiring to fill a role. I’ve used Agile in several software projects and it can be very useful. I’ve also intentionally not used Agile in a couple of projects because in these cases it would have been catastrophically unfit for purpose. Unfortunately people often follow trends without realizing that one-size-fits-all is never possible.
It’s essential to use the appropriate methodology for a given type of development if you want the optimal outcome.
Let’s consider two very different approaches to handling a problem in order to illustrate what we mean:
Our first problem-handlers are a team of special forces operators. They’ve been tasked with neutralizing a potentially dangerous individual and ensuring that the hostages he’s taken are moved out of the conflict zone. Their methodology is based on the tactics originally developed by the British Army’s Special Air Service back in the 1970s and refined continuously ever since.
They breach the wall of the building using plastic explosives, storm the room, shoot the target, aggressively take control of the hostages, zip-tie their wrists, and bundle them out of the building to a holding area where they can be searched for hidden weapons before being debriefed. This procedure is to prevent one or more targets pretending to be a hostage in order to escape detection and potentially cause problems as the operation unfolds.
The second group of problem-handlers is a team of management consultants. Their tasking is to neutralize a potentially disruptive senior manager and ensure that the other employees who’ve been stuck in the conference room watching endless PowerPoint slides for the last six hours get out of the meeting and return to more productive activities.
They enter the conference room reasonably discretely and take positions around the sides of the room. One of them interrupts the verbose senior manager who’s now on slide 93. Another consultant follows up the interruption by asking how long the meeting has already run. A third wonders aloud why it wasn’t possible to make the salient points in far fewer than the 93 slides already displayed. A fourth proposes the meeting be adjourned so people can get back to their real jobs. Two other consultants encourage the seated captives to rise and leave the conference room, mentioning that there is fresh coffee and cake in the nearby break room.
While this contrast is intentionally humorous it is nevertheless clear how disastrous it would be for these two very different methodologies to be applied outside of the appropriate circumstances. Sending in special forces to close down an overly long business meeting could result in death and destruction, while sending in a group of management consultants to deal with a terrorist would most probably not end with the mission objectives being accomplished.
So rather than blindly applying criteria that may be unhelpful, or automatically trying to apply a particular methodology du jour to every project, it’s important to understand the nature of the challenge being addressed and select the most appropriate way to manage that challenge. Key to this is understanding the requisite level of abstraction and proceeding from there.