There is a Season

In most modern organizations, it's fine for everyone to challenge everything. While this is very empowering, it also brings a new responsibility: to determine when it is the right time to challenge something.

We all met these colleagues, that tend to challenge anything and everything. While they can be infuriating, they are also absolutely crucial to every successful team. But with the right approach, we can support them in how and when to best make their challenges.

Let's make up a colleague and call him Andy. Andy is very critical and analytical, with strong opinions and loves discussions. He's also very experienced and there is usually a lot of merit to his comments. Still he drives the team up the walls at every corner. Here's how.

In a typical software project, there are 5 phases that offer a lot of things to challenge: ideas, plans, data, work items, user value. And challenge Andy does: Inconsistencies in the plan; gaps in logical reasoning; incomplete data; approaches he doesn't agree with. Andy insists on discussing his concerns with all parties involved and thereby derails the team's progress again and again.

Since he's not involved in all phases, he's naturally lacking context and crucial details. For example, when the PM does the sifting and cataloging, they aren't consulting with him. Usually, Andy doesn't learn about the project until phase 3 and will not be spending the majority of his work on this particular project until phase 4. By then PM and stakeholders of course expect to see some value created and not to have to go back to negotiating buy-in to the initial idea.

The problem is, he's still right some of the time. Just not about his timing.

So when is the best time to challenge something?

When it's in focus. Within those five project phases, each phase has a different focus and a different output it aims to deliver.

  1. Focus: data; output: ideas
  2. Focus: idea; output: plan
  3. Focus: plan; output: work items
  4. Focus: work items; output: user value
  5. Focus: user value; output: data

What if you challenge it at a different time?

You force all thinking and focus back into that phase.

What does that mean?

When you are in implementation phase, but you start challenging the plan, you force the project back into the planning phase, possibly rendering all work done so far obsolete.

Is that a bad thing?

Well, depends. If you found something that major that will render all work obsolete, then forcing the project back into planning phase makes a lot of sense. If it's only a minor disagreement with the approach that does not really invalidate anything, making this move can cause anything from frustration among colleagues to lost time-to-market to impending financial doom for the company.

Andy is frustrating the people he works with by forcing the focus on discussions that others don't deem relevant at the time and those discussions often end up with no changes at all, just another encore to the discussions that already happened. But every now and then, he finds a real blocker. A detail that has slipped through so far but is a huge obstacle to the value the team is trying to create. And that's why the Andys of the world are crucial for any team.

So, by allowing anything to be challenged any time, managers also invest their organization with the trust that they will make the right choice about when to challenge what. Of course people can always pass this trust back by sharing their concerns with managers and asking for advice about whether to raise this with the team at this point or not.

When we can coach Andy to challenge the right things at the right time (including when it's not in focus, but should be because it's such a big deal), that's when things really can take off.

There is a season to everything.