A veto killed the team
You’ve worked for several days on a complex problem with a couple of teammates. You are proud of your approach and your code, and the three of you high-five when the CI server and testing confirm everything works fine. But the guy shows up, has a look at your code, and tells you that this detail is not the way we work here. You ask him for detail, try to convince him your solution is OK, but he doesn’t agree, and he tells you how to rewrite that part of the code. You know he’s considered right, so you just do as he says. The consequences are huge. You get 2 additional days of refactoring to comply to the rules, and you end up with a code you’re not so proud of.
Next time, you know you will ask the guy first. You will wait for his approval up-front, take his instructions into account, and do as he says. As you ask him, he will tell you all the details about how he would have done it. You know you’d better take notes of every detail, cause you don’t want to rewrite your stuff next time. And if anything doesn’t work as expected, you know you’ll ask for his advice.
You got a veto.
Veto is a smell: it happens once something is somehow decided, discussed, or done. Which means waste.
Veto tends to prevent teams from empowerment. If you need the approval from someone who is likely to put a veto, the result is very quick: people wait for detailed specifications, or micro management, from this guy. He will be the only brain in the team, and the bottleneck.
Counter-measures:
- Allow mistakes. A team may be wrong when it decides something, which is OK. If you accept mistakes, you may have good surprises. What you consider as a mistake up-front might be a great solution.
- Limit batch size. Small batch size means lower risk. Lower risk means higher resilience to mistakes.
- Make sure vetoers coach before instead of using the card after. With great power comes great responsibility. Everybody’s job is to get useless. If you have the veto power, ask questions, like “what if”, “how will you know”, “how should we mitigate”… Get along with people, coach them.
- Make sure the vetoers put vetos on actual issues with high risk and high impact, not potential issues, not actual issues that will be detected right on, not actual issues with low impact, not actual issues with known counter-measures.
- Make sure your team is made up of opposite powers. This is the only guaranty to balance. If the vetoer shuts a silent minority, you have a smell. Only with attention can you detect it. If you have as much power as the vetoer, pay attention, so that veto only occurs in extreme situations.
- If alignment is needed between teams, explain why and discuss about it. Note that alignment is far less needed than you may think.
- Limit veto power.
- Include people with veto power from the start of decisions (which is rarely possible, as powerful enough people are not available).
- If nothing else can be done, remove the vetoer from the team. Every time I saw a necessary person get out of team, willingly or not, the outcome was surprisingly better. At least, you can run the experiment and see how it works.
The veto is a very dangerous tool. If you use it in your team, you must use it with extra care, only if all other tools failed, and only if the consequences of not using it are too serious. If you couldn’t convince people of your perspective before, or make sure they were able to take what you consider as the right decision on their own, you may consider it as a failure. But you shouldn’t use dictatorship to cheer up. Your team mates don’t have this tool.
Everybody has great ideas, and their own perspectives. Take benefit of that. Help the teams become autonomous, you’ll get great results.
AAAgile 