I was listening to a podcast where the host was interviewing Dan Heath, the author of Upstream: the Quest to Solve Problems Before They Happen.
The author tells a story about Jeff and Marta, who are standing by the river. They see a child drowning, so they rescue him. As they’re drying off, they see another child drowning, so they jump in and rescue her. As they get her to shore, they notice two more kids in the water, flailing around. After getting the two of them out of the water, Marta starts walking upstream. Jeff says, “where are you going, we’ve got to rescue these kids!” And Marta says, “I’m going to go find who’s throwing them in the water.”
Our daily work obstructs upstream thinking
In our daily jobs, there are a lot of factors that prevent this type of Upstream thinking. For example, when you’re the person that is responsible for answering support issues from customers, or when you’re handling lots of incidents, it is often rational to do what you need to to satisfy the current situation. You answer the ticket, you fix the bug, you tune the alert.
Three reasons transactional approaches don’t solve things deeply
Far too often, this type of transactional approach doesn’t really get at the heart of the problem, and prevent it from happening again. The author outlines a couple of things that prevent us from doing deeper work:
- The first is “tunnel thinking”. This is when you’re focused on solving things in a transactional way.
- The second is distributed responsibilities — when it’s not clear who is responsible for something, or nobody really owns it.
- And finally, an issue is when you don’t have the time or space to stop and contemplate the situation and understand it deeply.
When should you engage “upstream thinking”?
We always have to use our best judgment on how to invest our time, but a good rule of thumb is to weigh the costs and benefits of addressing things more deeply. If you see something happen more than a time or two, solve it more thoroughly.
Some approaches to build the habit of upstream thinking
Here are some things to consider that can help you get better at upstream approaches:
- Reply with documentation. When someone asks you something, document the response in a place that a future person can look it up, and send them the link.
- Automated testing. Prove that the bug can’t reoccur, which prevents it from happening again.
- Identify “do not repeat incidents” work after an incident. Make sure you identify the minimum possible thing that would prevent or mitigate future examples of this problem.
- Turn off an alert, or rethink how we monitor something. Rather than just bumping up the threshold, think about whether the alert is something we even act on. Move the channel of the alert to an information channel instead of alerting channel, or rework it to be actionable.
- Automate the steps into a script. Instead of going through a list of things, put it in a script, which is a step towards automating it.
If nothing else, it can be valuable to take a few moments when you’re working on something to look at the big picture, and not let the rush prevent you from looking upstream to where the source of the problem may lie.
Questions to ask yourself
To come up with your own upstream thinking, here are a couple of prompts to ask yourself:
- What is the trend I’m seeing? If it continues, will it be unsustainable over time?
- Is there a way I could make the impact of this decrease over time?
- Are there any simple ways I could make this situation go away?
- What would happen if we ignored this problem?
Beware solving everything deeply
Occasionally I see people so in love with upstream thinking that they only embark on huge efforts to solve every problem completely. This is misguided.
For many problems, solving things completely is too large of an investment. It may be fine to solve things incompletely if it requires significantly less effort.
Comments powered by Talkyard.