Leatherback sea turtles have a top speed of about 6 miles per hour in any direction. I am pretty sure their navigation skills have more to more to do with successful migrations across the vast ocean than top speed.
Many teams face a lot of pressure to “go fast” and “get things done.”
These are often pitched with dramatic language like “it’s do or die!” Or worse.
What if you don’t understand what the problem is? What if you don’t have the tools and processes to do that safely? What if the things you’re working on are the wrong things?
When I observe this happening, I like to say:
Slower is Faster
I say this to myself, my team, and anyone shouting dramatically so that we focus our efforts on the most important problems with tractable solutions that can be executed by the team using the skills and resources that are available to them.
I absolutely understand urgency.
When a business critical complex system is operating chaotically, those problems should be addressed with urgency. There may be actual immovable dates involved such as Cyber Monday. In these times, it is especially important to focus on the most important problems and promising solutions. It may be all you have time for, so let’s not waste it.
The Theory of Constraints tells us that working on improving anything but the system’s bottleneck is wasted effort. So we need to have a broad enough view to pull the problem(s) contributing to the system’s bottleneck into scope. And then we need to protect or expand the bottleneck.
Buckle up and get ready to focus.
Here’s how I try to help teams kick off a focused effort solving Big Urgent Problems derived from the 8D process:
First, create a prioritized, ordered list of the current suspected and confirmed problems. The problems often end up being prioritized by risk to the organization and its customers. The problem description should include if and how it relates to the system’s bottleneck. It’s very useful to capture problems that aren’t the current bottleneck, but might be once the current bottleneck is addressed or is bottleneck under certain conditions. This list must be written down in a place that is visible and modifiable by all team members. There is a universe of ‘productivity’ tools out there that you probably already have at your disposal. Pick a small set. Group chat tools are not sufficient for these use cases.
Second, use the list of problems to generate a set of to guide discrete tasks that help you clarify high-priority problems that are ‘fuzzy’ and implement containment measures for confirmed problems related to the system’s bottleneck. Again, write them down.
Your team has a bottleneck, too.
The team’s execution bottleneck is the number of capable people available to focus on investigating problems and implementing containment measures. If you don’t protect the people who need to do this urgent work distractions and forays into work on problems that aren’t the bottleneck, the system won’t get improved.
Third, clearly define the team’s membership, responsibilities, work prioritization process, and the mechanisms for communicating within the team and outside of the team. One of the primary responsibilities of the team should be to capture the problems, solutions, and most critical context in written form. Make the work visible. When in urgent problem solving mode, the team should examine the priority of work daily and adjust to new information and progress. What you’re capturing in written form will help make discussions efficient, distinguish and remind people of nuanced information, facilitate sharing outside of the team, and even provide a history of “what were we thinking and why.”
Yes, “write things down” is one of my big pro tips. You don’t even need to trust me on this. Try it out the next time things are on fire; I’d love to hear how it goes.
I understand that this may seem like a tautological statement of problem management 101. But I see teams struggle with this all over the place. This is especially true when an ad-hoc cross-functional team has been brought together to address urgent scalability and reliability problems of a large system. The team is trying to figure out how to work together, people have different communication styles and personalities (especially under pressure), lots of things are in motion and changing rapidly.
Do not import the chaos from the system into your problem solving approach because you need to look like you’re doing something, anything. If you do, you run the very real risk of running from symptom to symptom, thrashing people on the hot topic of the day and losing track of what is most important.
Recognize there are two bottlenecks: one in your computer systems and another in your team. Both need protection when the going gets rough.
Slower is Faster, especially when it’s urgent.
#NoDrama
