Most orgs deal with a daily deluge of problems.
When enough of them land at once, leadership tends to slip into react mode. Clearing the plate becomes more critical than what is on it. And the whole “bias for action”, normally great advice, starts to become reactivity under pressure.
What many forget is that a problem reacted to is often a problem either amplified or absorbed, not solved.
First, we have a type of leader we can call the amplifier. Amplifiers pass the problem to the team with their own alarm attached. Sometimes with a layer of judgment or a layer of doom, or both. Lots of accusations, how did this happen, who made the mistake. Or lots of catastrophizing, we can get sued, we will lose our customers.
Amplifiers will confess to clients, press the dev team for ongoing updates, and create a type of frenzy. The problem is often very real, but the legit problem is now saddled with a second problem: the leader’s own stress and sense of urgency.
Opposite to the amplifiers is the absorber, who will routinely take the weight of the world onto their shoulders. They will try to fix things personally, diving into the code or creating reports by hand. The absorbers are arguably more insidious than the amplifiers, because many times they only ask for help once the problem has grown larger. And even when they succeed and the trouble passes, the absorber becomes a bottleneck, because when the next instance of the same problem arrives, no one really remembers what the absorber did.
Unlike the amplifier or the absorber, the operator needs to not react to a problem, rather simply understand it first. Understand the seriousness of the issue, who is best positioned to investigate it, prepare a series of communications to assuage the clients while things are being investigated. Then structure the problem so the most critical things are addressed first. And when the problem is resolved, look for ways to anticipate and mitigate any root causes that led to the failure.
That last part is the one that compounds. The amplifier and the absorber both leave the team exactly where it was before, ready to meet the same problem again from scratch. Structure is what converts what happened into something the team keeps: a fix, a step added to the process, a check that catches it earlier next time. It is the only way a company gets better at problems instead of just surviving them one at a time.
Now any of us can be any of these archetypes depending on the day and how stressed out we are. But the operator mode requires being able to understand the problem fully.
When the founder or the c-suite is the amplifier or the absorber
When the founder or the c-suite is amplifying, the useful thing to know is that the volume is not information. You need your own read of what actually happened, arrived at independently, and then the rest can go by.
Acknowledge the noise if that is what the moment needs. But acknowledging something is not the same as actioning it, and the difference between those two is most of the discipline.
With absorbers you can stay involved and continually offer to help. Force the discussions if needed, so at a minimum the problems start to exist somewhere other than in one person’s head. Volunteer to take specific pieces rather than offering to help in general, because a general offer is easy to decline. Then supply the structure that is missing, such as a post-mortem once the crisis passes.
Let’s look at two situations and what the operator does in each.
When the problem is not yours to fix
At times a problem occurs that affects you but is not yours to fix, such as the infrastructure provider going down along with your platform.
When something like this happens, amplifiers can go into overdrive and spend the day on the phone with clients, team, partners, whoever, re-hashing the situation and asking for updates.
But operators, once they understand the solution is out of their hands, will anticipate the issues that might land on their lap once the system is back online, prepare things like communication or test cases, and focus on all the thousand things that still need to be done.
When the problem is yours
Sometimes the problem is ours. A bug reaches production at the worst possible moment, for example donations start failing around a crucial fundraiser.
The amplifier starts assigning blame and freaking out. The absorber quietly patches it, tells nobody, and changes nothing, so the next one arrives the same way it did the first time.
The operator goes into understanding mode. Validate the bug, replicate the bug, prioritize it for the dev team to investigate. Understand the scope of the damage, meaning who else has hit this and how far it goes. Help test the fix against the original case. Prepare the communication that might need to go out, including the version you may never send. Then, after it is closed, have the conversation about how it reached production and what changes, so the next one does not.
You must size it before you can structure it.
The reason understanding a problem must always come first is that how loud a problem is and how big it is are independent of each other. It’s easy to fall into the trap of sizing a problem based on the volume of the complaint.
The work is to size it to the magnitude of the cause, and you cannot know the magnitude until you have looked.
And most problems are never just one problem. The platform goes down, and that single event is really four or five questions stacked on top of each other. What are clients experiencing right now? What do they need to hear, and when? What caused the outage? What is the specific fix? And what keeps it from happening again? Each of those has a different owner, a different urgency, and a different answer.
What’s interesting is that at an operator level, existential problems and minor problems essentially have the same framework. Understand the scope of the problem, understand the point of failure, figure out who is best position to investigate and remedy, what type of communication is required, and once resolved, how to ensure it doesn’t happen again.
Problems are a daily reality in most high velocity orgs. As an operator, the imperative is always to understand and structure a problem rather than react to it. And too often teams can vacillate between chaos, everything is on fire all the time, or nonchalance, everything is on the shoulder of one person. But by consistently understanding and structuring problems, an operator can inject calm and accountability while over time reducing problems overall.
pvot40 