When Everyone Agrees, Who Challenges the Plan?

In one team, the person who asks whether we can skip another round of approvals is treated as a troublemaker. In another, it’s the person asking why nobody has written down a process in the first place.

Both are questioning the status quo. Yet, depending on the kind of company you work in, one may be praised for taking initiative while the other is labelled difficult.

When we talk about dissent, we tend to picture somebody breaking a rule. But in a team where nobody follows a process, the person insisting on some structure is also questioning the status quo.

There’s another situation where dissent is useful: when everybody in the room is convinced the plan will work.

The tenth man

World War Z is an odd place to find a useful management question. In the film, an Israeli official explains the “tenth man” approach. If nine people agree on an explanation, the tenth must investigate the possibility that they are wrong.

The movie uses that idea to explain why a warning about an outbreak was taken seriously when it sounded impossible to everyone else. Quite convenient when your problem involves zombies.

If nine people agree with a product plan, I’d want to know whether they reached that conclusion independently, or whether everybody simply took the same assumption for granted.

The tenth person may end up agreeing with the other nine. At least the team has examined an alternative before going ahead with the plan.

When engineering leads the conversation

Consider a product company where the default is to let engineering lead. The team figures out what the technology can do, works through the technical challenges and builds the solution. Only then does it begin a serious conversation about who wants it and why they would pay.

That approach may work when the team is exploring a new technical capability. But if the question is whether customers need the product, someone from marketing asking for early customer conversations has a rather sensible objection.

Of course, engineering may say that customers cannot tell you what is technically possible. Fair point. I’d still want somebody to put the market assumption next to the technical assumption before committing the next development cycle.

Things look rather different in a team that lives on hustle. Decisions happen over phone calls, people move quickly, and a customer request can reach development the same day. When there are only a handful of people, everyone knows what’s going on.

As the business grows, that becomes difficult. Sales and engineering may have different versions of what was promised. Product priorities change without anyone recording why. Suddenly the person asking for a change-control process is the one creating friction.

I don’t see much point in a twenty-page approval document for every customer request. I’d want to know who made the decision, what was promised and what it means for the rest of the roadmap.

I have trouble with the idea that a dissenter must always be a rule breaker. Sometimes the useful challenge is asking the team to stop improvising.

Healthy tension in a strategy meeting

Strategy meetings should be uncomfortable at times. A salesperson looking at a potential deal and an engineer looking at the cost of building for one customer are dealing with different concerns. Product has to work out whether the request belongs on the roadmap. Finance has to consider what it would cost.

I would be concerned if nobody raised those differences. We might call it alignment, but we’d still have to deal with the consequences later.

When people participate in the decisions being made dissent based innovation occurs. The participation part matters. You can’t ask people to challenge a plan and then make it clear that objections are unwelcome.

Still, I wouldn’t reward disagreement for its own sake. Somebody can object to a plan because it affects their budget or gives their team more work. And an endless debate can stall a sensible decision.

So when somebody disagrees, I’d ask them to explain which assumption they are challenging and what information might change the decision.

What do we do with the objection?

For a computer-vision product installed in a warehouse, an engineer may worry about poor lighting. Sales may worry that the customer will refuse to change an existing workflow. Both are things worth testing, but the solutions are different. Moving a camera won’t help with the customer’s operating process, and a discussion about adoption won’t fix a bad image.

I’d rather hear these concerns while the team can still change its plans. Once the budget is spent or deployment is under way, the same conversation becomes rather expensive.

Of course, we cannot debate everything forever. Hear the objection, work out what can be tested within the time and money available, and then somebody has to make a decision. Keep a record of what remains uncertain. You may need to come back to it.

There’s also the manager’s role in all this. It’s easy to say “My door is always open” and rather harder to remain interested when the person walking through it is questioning your decision.

Before calling the next strategy meeting a success because everyone agreed, we need to know what was challenged and what we learnt from it.

If the answer is nothing, perhaps we need to have that discussion before signing off on the plan.