27 May 2016

Why Every Team Needs a Decider

When I was in college and offered a job, I thought decision-making by consensus, as is practiced in the company I was joining, is great. It’s open and democratic and egalitarian. Everyone gets to be heard, vote for what they think is important, and the best ideas from everyone are recognised and incorporated into the final decision. Or so I thought.

Now, with the benefit of hindsight, I find that decisions take weeks or months or quarters to get made, you have endless discussions, you end up rehashing the same points with different people in different meetings or email threads, and so on. If you have a great idea, getting it adopted is hard or impossible because you need to convince many people. Consensus-based decision making strongly favours the status quo, and has a high inertia. Which is a problem because the status quo may not be the right decision. Or may have been when it was made, but no longer is. Even when you make a change, you make an incremental change, a slight difference from the status quo, rather than doing something completely different. As Larry Page puts it, incrementalism leads to irrelevance.

It would be better for every team to have a Decider, a person who has ultimate authority. The decider is formally identified and announced, say in an email, and there’s no confusion who he is. Everyone is free to speak up, either in private with the decider or with the team. They say whether they agree or disagree with the proposed course of action, and, if not, what we should be doing instead, and why. The decider listens to everyone, discusses and debates with the proposer as appropriate, and then makes a final decision. People can still disagree with the decider, either in private or in a team meeting, and that’s welcome and encouraged, but there’s no question who has final word.

This lets bold decisions be made. The product that gets built reflects a consistent vision, rather than a least-common-denominator among many participants. Teams will stop blindly doing what they have been doing all these years, and instead feel free to try something different. If the team succeeds, the decider is recognised for it, and if the team fails, the decider is again recognised for it.

One problem I’ve noticed with consensus-based decision making is that no one takes responsibility when things go wrong, because no one really owns the final decision. It’s important for people to recognise when something they did didn’t work, so that they try to understand why it failed, what they could have done instead, with the benefit of hindsight, and what the takeaway is for the next time.

The above formula needs to be tweaked a bit when you have different skills involved. For example, in a software team, you have engineers, a product manager, and a UX designer. In such a situation, perhaps you can have the PM be the decider for all product and UX decisions.

The PM has either consult with or outsource certain decisions to the designer, but at the end of the day, it’s the PM’s responsibility to ensure that the right decision is made and the UX is right, the flows are straightforward, that users are not asked questions they shouldn’t be asked, that choices users are presented with are intelligible and appropriate, and so on.

If a decision has no product or UX implications at all (whether to use a hash table or an array list), sure, engineering can make whatever decisions they want. But many engineering decisions have a product or a UX implication. For example, say you’re printing a spreadsheet and a certain font couldn’t be loaded, for some reason. Should the printing fail, or should it fall back to a default font? Would the user prefer a spreadsheet with the wrong font, or insist on it being printed right and are willing to try again? That’s a product or UX decision, so should be signed off by the PM. Engineering can and should give estimates like, “If you want this, it will take 2-3 weeks”. The PM then decides whether spending that time on that task is worth it.

In one sentence, the PM is god.

Any and all decisions that have a product or UX implication should be either taken or signed off by the PM. The PM, in this system, is much more closely involved with the product than a traditional PM would be, say in Google. Rather than overseeing and co-ordinating and guiding a half-dozen projects, they would be intimately involved in one or two.

In summary, every team needs a decider, so that the team can run with a consistent vision, rather than a least-common-denominator mishmash between what different people like. Teams can take bold decisions, rather than timid, incremental, neither-here-nor-there ones. Decisions will get taken faster and better, everyone will waste less time discussing and co-ordinating. People will take responsibility for and learn from their decisions.

Every team needs a decider. In a software team, the PM could play that role.

No comments:

Post a Comment