There are a number of times in any given project or product development cycle where you might have to consider stopping work. I want to explore some of those ideas and share a story.

$15 turns into $250k

I was working with a team who was building a product that would use various messaging services to engage their customers. I took it upon myself to know the rules and regulations for such things and help them set up a small spend limit.

By the end of the month they had run out of money which prompted an obvious request to increase the limit. I refused asking instead for information about how we hit the limit.

Another interesting detail was that messages were going all over the world, which was a troubling.

After several days of investigation the team uncovered a bug that resulted in all these abnormal messages. The problem was that the bug resulted in potentially illegal messaging all over the world. The potential fines reached $250,000.

When the money ran out, I stopped all work until we could understand this.

Task Force

Quite regularly the approach many leaders take is to assign a sub-group to investigate while the rest of the team makes progress. This approach has some benefits and some drawbacks.

The obvious benefit is that progress continues on the other work that was previously identified. It also protects the rest of the group from information overload as they would have to switch contexts and modes of working.

Now, the drawbacks are that quite regularly the task force will investigate something related to the progress the rest of the group is making, slowing progress of both groups. Often this appears as the group tries to modify and investigate logs while the other is creating new entries from their work.

Also, there is another risk that the task force may not find the answers they need quickly enough, and the bet that the few that were selected could pull this off was not the right bet to make.

Last, and this is a strange one, the team now lives with competing priorities. One group’s priority is making progress and the other’s is something different. Were these two isolated groups there might not be much to worry about, but often it is one team with two priorities and this winds up confusing the team. They now don’t know how to make decisions about what they should do since there are two urgent things. The competing priorities will pollute information flow and impede decision making

Full Stop

The more extreme approach is to stop all progress until the urgent issue is resolved. I can say that in ten years of doing this work the full-stop is very infrequently used.

When we call a full stop, that’s it. No more work happens. We re-allocate everything to a new priority and wait. This can often feel very inefficient as not everyone can be fully productive. Or so it seems.

Ironically every place I’ve been has experienced an all-hands-on-deck period that comes after a rough release. Everyone is together swarming around issues as they come up. I’ve never seen someone pause then to split the groups down further by task in hopes of optimizing productivity. Instead we have every good idea, every body ready to contribute, and plenty of capacity to absorb change.

If you’re doing something like Scrum they have this built in as well by cancelling a sprint. The idea is that if priorities have changed so drastically that the purpose of the sprint isn’t valid, you stop all work by cancelling the sprint and start a new one.

In essence a full stop trades individual business for overall capacity gain in solving a problem.

Crisis or Inconvenience

A crisis by my definition exists when there is significant disruption to people, operation, or business. An inconvenience is everything else.

When a crises emerges I call for a full-stop. It feels terrible, but we now have all that we need to solve the issue and there are very few loose ends left over. There is never a need for telling someone else what happened because everyone was there. Everyone knows more about how this crises happened and is better equipped to avoid and solve it.

When there is an inconvenience, on the other hand, I source options. I don’t hurry into the task force style of things as I don’t care for the consequences of splitting a team. More often than not the inconveniences are easily resolved by one of the options, and it never turns into a crisis at all.