Friday, November 4, 2016

Priority Inversion in Organizational Decision Making and How to Avoid It

“If you're not prepared to be wrong, you'll never come up with anything original.”
Sir Ken Robinson. The Element: How Finding Your Passion Changes Everything.

"I do not know what I may appear to the world; but to myself I seem to have been only like a boy playing on the seashore, and diverting myself in now and then finding a smoother pebble or a prettier shell than ordinary, whilst the great ocean of truth lay all undiscovered before me."
Sir Isaac Newton. 1643-1727.

"But in all my experience, I have never been in any accident… of any sort worth speaking about. I have seen but one vessel in distress in all my years at sea. I never saw a wreck and never have been wrecked, nor was I ever in any predicament that threatened to end in disaster of any sort."
EJ Smith. Captain of RMS Titanic. 1907.

A colleague from my Microsoft days had this to say in a recent email exchange: “BTW - someday [you should write] a piece on 'what's actually important vs what is perceived to be important' would be timely! folks get caught up in take your pick - org, title, level, doing a re-org, what product MVP is etc...so much time wasted on not improving a customer's experience one bit.”

So I figured I'd write a few words on the topic. Let me start by saying that I'm the last person who should be giving this kind of advice, having personally broken every single one of the rules multiple times over my career. Many of my bad decisions can, in retrospect, be attributed to priority inversion - one way or another. Then again, I suspect that is true for most people.

The rules will perhaps come across as simplistic, cliche, or even naive. In my defense, I have this to say:

1. Simplistic. One of the reasons I love science is Occam’s razor: “As a logical principle, Occam's razor would demand that scientists accept the simplest possible theoretical explanation for existing data.” Simple rules are good rules. Simple rules are easier to follow and adhere to. Simple motives are easier to defend and, more importantly, to reason about.

2. Cliche. There's a reason some sayings become cliches. They apply to a lot of scenarios and a lot of people - because they are based on thousands of years of experience. As James Madison said: “Experience is the oracle of truth and where its responses are unequivocal, they ought to be conclusive and sacred.”

So, if I tell you to "never put an individual team member above the team" or "put the customer first", most of you will roll your eyes and say that's obvious. That's just a cliche. Well, think about why it has become a cliche before you knock it.

3. Naive. Yeah, what Madison said. I have only my experience to fall back on. I'd be glad to show you all the scars on my back if you don't believe me. Over the years, I've managed thousands of people and hundreds of projects at dozens of companies. I hope I have learned a few things even if they seem, well, a bit naive in the retelling.

So, then, with that preamble, let me add 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 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, to be delivered as part of a product. The next release of iOS. A new website. A network driver.

Customer: the customer is the guy that uses your product. For the purposes of our discussion, the customer is usually outside the company but the same logic can apply when your customer is just another group within the corporation.

Product: what you sell to the customer. Usually comprises of multiple projects. Maybe delivered as a service.

So, now, based on that vocabulary, here is my strict top to bottom prioritization when trying to make any decision, be it technical or organizational.

1. Customer
2. Company
3. Product
4. Group
5. Project
6. Team
7. IC

If you follow this prioritization, you will almost always make the right call. I guarantee it. The only problem is that most of us invert the priorities most of the time - for one reason or another.

Always put the customer first. Yup, it's a cliche. But 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. He/She is almost never in the room or even on the mail trails or chat channels when we are making our decisions.

The rest of the prioritization should be obvious. Put the company second. Not only the survival but also the ultimate success of the company depends on all the other items being lower priority. Every time we make a decision that favors a specific project above the overall strategy of the company, we are inverting priorities.

A similar recursive logic applies to the next four priorities. Always put the team ahead of the individual. Every time we make a decision that favors a single individual over a team, we are inverting priorities. 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! Yeah, right. It's obvious. But every time we postpone a release because we “absolutely need” one more project/deliverable in the release, 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, in general, 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. How many of the following statements resonate?

"Of course, I (the ultimate IC) am more important than this stupid project. Fuck, it. I'm outta here. They screwed me on the performance review last week, so I'm going across the street for an extra 10% compensation. Screw them." [aka God complex]

"Those guys in the storage 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]

"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. My manager told me it was a strategic priority for the company".
“We gotta give Jack/John/Jane a huge raise and some stock. He just walked in the door with an offer from Google/Facebook/Amazon/Apple/Microsoft/Uber/insert your favorite rival company].”

“Our product is saving the company’s ass. Those losers over there in [insert your favorite group name] are just wasting time and money.”

Now go apply the strict priority list above to these statements and see how they look. As I said, the problem is not that we don’t intrinsically understand or agree with the priorities I’ve listed. It’s just that we tend to act irrationally in the heat of the moment, based on emotions, based on incomplete data, based on inverted priorities.

As for solving the problem, my only advice to you is this:

1. Leave emotion at the door. Most priority inversions are a result of emotion overriding logic and reason.

2. Make sure you hear both (or all) sides of the story. Another common cause of priority inversion is incomplete data.

3. Think about the priority list above every time you make a decision. If you still feel strongly about the decision, 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 will admit that 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. As I said earlier, I'm personally guilty of committing pretty much every one of these priority inversions. Let the ones who haven't sinned cast the first stone.

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 give Joe a raise just because you feel bad about giving Jack a raise. Don't build feature X because Competitor Y has it and you are losing deals because of it. If I had to use a cliche, it would be: “Don't follow someone else’s tail lights.”

Note that the title of this blog is not “... and how to fix it” but rather “... and how to avoid it”. 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, acknowledge it, so we can avoid it - as a team.

No comments:

Post a Comment