Making the Right Decision Every Time
Priority Inversions in Organizational Decision Making and How to Avoid Them
The deliberate application of reason [is] necessary precisely because our common habits of thought are not particularly reasonable. — Steven Pinker. Enlightenment now: The Case for Reason, Science, Humanism, and Progress.
In the world of computer science, “priority inversion” refers to a condition where a low priority task gets to run instead of a higher priority one, potentially resulting in a system deadlock. Applied to the world of human beings, I’m using the term to signify a bad (low priority) choice on a prioritized list of items.
If I tell you to “never put an individual team member above the team” or to “put the customer first”, most of you will roll your eyes and say those are obvious rules. But think about some recent decisions in your organization and I bet you’ll find plenty of examples where the opposite took place. In each of those cases, I claim, the problem is priority inversion.
How many of the following statements resonate with you?
- “We gotta give Joe a huge raise and some stock. He just walked in the door with an offer from [insert your favorite rival].” [putting the individual ahead of the team]
- “Those guys in the xyz team are never going to make the deadline. Let me check in my code. I promise it’s in better shape than theirs.” [aka schedule chicken, putting my team ahead of yours and ahead of the overall project]
- “They screwed me on the performance review last week, so I’m going to screw them. I’m outta here. I’m going across the street for an extra 10% compensation.” [Putting the individual ahead of the team, project, and company]
- “Yeah, I know 10% of customers are crashing daily with that bug but I gotta work on this cool new feature for the next release. Performance reviews are next month and I want to make sure it’s done by then. Besides, my manager told me it was a strategic priority for the whole company.” [putting the individual and the project ahead of the customer]
With those scenarios in mind, here’s a brief glossary to make sure we are talking the same language.
- Individual contributor (IC). Team member. Can be as junior as a kid right out of school or as senior as any executive in the company.
- Team. A small collection of individuals usually working on a single project — usually less than fifteen people. Two pizza rule applies.
- Group: Several teams working on multiple projects simultaneously, for example “Engineering Division” or “The Operations Group”.
- Project: A multi-disciplinary cross-group deliverable, usually to offered as part of a product. The next release of iOS. A new website. A network driver.
- Customer: The guy that uses your product. For the purposes of our discussion, the customer is usually outside the company but the same logic applies if your customer is just another team within the corporation.
- Product: what you sell to the customer. Usually comprised of multiple projects. Maybe delivered as a service.
Based on that vocabulary, here is my strict top to bottom prioritization when trying to make any decision, be it technical or organizational.
- Customer
- Company
- Product
- Group
- Project
- Team
- Individual Contributor
Mine is a very utilitarian view of the corporate world, I suppose. The greater good for the greatest number. If you follow this prioritization, I claim, you will almost always make the right call. Guaranteed. The problem is that most of us invert the priorities some of the time — for one reason or another.
Always put the customer first. Seems like such a cliche but, somehow, we seem to forget this truism almost every single time we make a decision. We are so caught up in the internal politics and cross-group prioritization conflicts that we forget about the customer. It’s so easy to lose sight of the customer given that she is almost never in the room or on the mail trails where we make our decisions.
Put the company second. Not only the survival but also the ultimate success of the company depends on all the other items on the list having lower priorities. Every time we make a decision that favors a specific project or team above the overall company strategy, we are inverting priorities.
A similar recursive logic applies to the next four items. Always put the team ahead of the individual. Every time we make a decision that favors a single individual over a team, we are almost certainly making a bad decision. I’m not saying it should never happen. There are clearly brilliant ICs out there that add more value than an entire team of B-players but they are not the norm. We are talking about best practices here, not outliers.
Never put any specific project or deliverable ahead of the product. Well, duh! It’s obvious. But every time we postpone a release because we “absolutely need” one more deliverable included, we are inverting priorities. Another way of saying this is: The train leaves the station on time. Don’t even bother talking to me [the release manager] about postponing it for your deliverable.
I think you will find that experience will agree with this prioritization scheme. And I think it’s all obvious and you will all agree with it. Why, then, do we all make decisions every day based on inverted priorities? I suspect that’s due to us not stopping long enough to understand that we are actively inverting the priority.
As for solving the problem, my advice to you is this:
- Leave emotion at the door. Most priority inversions are a result of emotion overruling logic and reason.
- Make sure you hear both (or all) sides of the story. Another common cause of priority inversion is incomplete data.
- Think about the above list every time you make a decision. If you still feel strongly, go ahead and press your case. Otherwise, let’s get back to work. After all, we are all supposed to be on the same team, aren’t we?
I’ve mostly managed engineering teams but I’ve also managed product management, marketing, and operations teams. The rules above are pretty universal and can be applied to those teams as well. I’m personally guilty of committing pretty much every one of these priority inversions. Hindsight is 20/20.
Some will fault me for not including competitors in that prioritization list. Competitors actually appear at every level of the list — individuals competing with each other, teams competing with other teams, companies competing with other companies. My only advice to you on that topic is: Be aware of them but do not include them in your decision making process. Don’t build feature x because Competitor y has it. Don’t give Joe a raise just because you feel bad about giving Jack a raise. If I had to use a cliche, it would be: “Don’t follow someone else’s tail lights.”
As long as humans are involved in the decision making process, we’re not going to solve the priority inversion problem. The best we can do is be aware of it and acknowledge it, so we can avoid it — as a team.
