It’s easy to think of problem solving as something that happens in a single sequence: I have a problem, and now I will sit down, think it through, and come up with a solution.
In reality, many problems are too complex to be solved in one pass. This means we have to go through any given problem multiple times, starting with a broad, undetailed pass to get a general understanding of what a solution looks like, and systematically progressing toward a detailed, nuanced set of action steps to solve the problem.
For the skimmers in the audience, problems need to be solved at multiple levels:
- High Level, Low Fidelity — no details, no concrete ideas; not even necessarily a plan. This is what you might hear referred to as “vision”.
- Mid Level, Medium Fidelity — this is where the high-level vision gets chopped up into goals. You may hear this called “strategy” or “roadmapping”.
- Low Level, High Fidelity — during this stage, things get tactical. Strategic goals get turned into time-bound projects with specific deliverables and metrics.
In general, problems need to be solved at all three levels, and things go a little smoother if you only try to solve at one level at a time. And on sufficiently complex problems, this sequence might happen multiple times at different levels of focus.1
The rest of this post will add context through an example, as well as provide some guidelines for keeping discussions at the right level.
The three levels of problem solving, as embodied by a meal.
Marisa and I bought a house in Portland this year, which is a huge shift from our previous lifestyle.2 A decent chunk of our extended family on both sides is within about an hour of us, which meant we were now part of the discussion around Thanksgiving.
Thanksgiving is complex to say the least. There are subtle family dynamics in play, a dozen or so dishes to plan, extra seating and utensils, and the relativity of Relative Time.3 Dozens of decisions need to be made to ensure the meal goes well.
Low-fidelity: “What are we doing for Thanksgiving this year?”
Before we could actually plan anything, we needed to make some low-fidelity decisions:
- Where are we having Thanksgiving?
- Are we going to try and pull our families together for a single meal, or have two different stops?
This is low-fidelity problem solving. The answers we come up with aren’t complete, and they’re not particularly actionable. This is the “vision” for what should be done.
And vision is important. If we don’t know where Thanksgiving dinner will be or whether or not it’s a one- or two-family affair, other plans are made without critical information:
- If we order a turkey, we might find out that someone else is hosting Thanksgiving and already ordered one.
- If we plan a long, slow meal, we might find out that we have to drive an hour to Silverton for a second Thanksgiving meal.
Without a vision, it’s extremely hard to know if the decisions and actions we’re carrying out are sending us in the right direction.
Mid-fidelity: “Who’s coming?”
Our vision is now in place: Marisa and I are hosting a two-family Thanksgiving this year.
In order to make the meal a success, we need to come up with a strategy. Mid-fidelity problem solving is where the vision turns into specific goals.
Some of the questions we needed to answer at this stage included:
- How many people will be there?
- Should we do just turkey, or another main?
- What dishes do we definitely want to include?
From this, we learned that we’d have 12–14 people, turkey two ways, and a few family favorite sides.
We were then able to create goals using the information:
- We need to have enough seating and place settings for 14 people.
- We need enough food to feed 14 people.
By setting goals, we get a clear idea of what “success” looks like.
High-fidelity: “Let’s make a Gantt chart.”
Marisa doesn’t take hosting lightly. Her first step was to create a spreadsheet for Thanksgiving, complete with all the dishes, who was responsible, and links to recipes.
Hosting Thanksgiving when you work in tech means spreadsheets, pajama party whiteboarding sessions, Gantt charts, and — of course — hand turkeys. 🦃 pic.twitter.com/vfH1XpRTIf
— Jason Lengstorf (@jlengstorf) November 18, 2018
Using the spreadsheet, we were able to turn each dish into a list of requirements: cooking equipment, serving dishes and utensils, oven time, and so on.
From there — stealing a trick from our friends, Ryan and Chelsea — we turned Thanksgiving into a Gantt chart: each dish, its oven time and equipment accounted for, is on a timeline so we know exactly what to do and when to ensure that Thanksgiving is as stress-free as something like Thanksgiving can be.
High-fidelity planning turns goals into actionable todo items.
The Pitfalls of Problem Solving
The challenge with problem solving is that it’s extremely tempting to start solving problems at the wrong level: a meeting intended to brainstorm about tasks for a new contractor becomes a detailed discussion about how to solve one of the proposed tasks; a progress check-in becomes a redesign; a goal-setting session falls down a rabbit hole on the first goal and everything else isn’t planned at all.4
This typically gets ignored, because planning is planning, right? But — remember Thanksgiving? — we’re going to waste a lot of time if we move to a tactical discussion before we’ve defined a vision and goals, and we’re never going to get anywhere if we rewrite the vision every time we start creating actual todo items.
Historically, I’m utterly terrible at choosing the appropriate level for discussion, because I’m what Mona Patel would describe as a “scaffolder”. At IBM, people would drop by my desk with a question like, “Where do you think this label should be aligned?” and — fast-forward to three hours later — I’ve cornered the architects for the project and I’m demanding an explanation of why labels were added to this design in the first place.
However, if we’re going to effectively solve problems, we need to be more intentional about what level we’re currently solving for.
How to Use Level Setting for Better Problem Solving
While far from a Complete Guide to Solving All Your Problems™, over time I’ve learned a few tricks that — when I actually follow them — go a long way toward keeping my problem solving efforts on track and effective.
1. Make sure you know what you don’t know.
On any problem, start by doing an assessment of what you know, and what you still need to learn.
If you ask me to cook dinner, I already know how to cook. But I don’t know how many people are coming over, or whether any of them has dietary requirements. If I go to high-fidelity planning before I have that information, I’m probably going to end up backtracking and wasting time.
2. Start with “Why?”
The vision needs to be in place before anything else can be done with confidence. I’ve talked about this before: we need to Find the Why to make sure we actually understand what we’re trying to accomplish.
3. Be clear about what you’re here to discuss — and what you’re not.
The biggest mistake I make — and the most common mistake I’ve seen in all the teams I’ve observed — is that meetings are held without agendas. There’s probably a whole post to write on this, but for context, there should never be a meeting that doesn’t have an agenda with, at minimum:
- What the purpose of the meeting is
- What deliverables the meeting will produce (e.g. answers, a design document, an unblocked project)
An additional feature of the agendas we send out on my team is this: “What are we not going to talk about?”
This helps us level set the meeting. For example, the agenda might look something like this:
- Topic: project roadmapping for Q1 2019
- Deliverables: a prioritized list of the projects we plan to complete in Q1 2019
- What we are going to discuss: projects at a high level, their impact, and their importance
- What we are not going to discuss: how to complete the projects, technical details, or ownership/staffing
4. Don’t revisit the vision or goals to avoid doing the work.
On an embarrassing number of occasions, I’ve hit a hard problem (or just gotten into The Slog), gotten frustrated, and decided it would be easier to redesign the entire project rather than push through it.
Don’t be like me. Be better than that.
If you’ve already thought through the vision and strategy, don’t try to convince yourself to start over when things get hard. Instead, CTFD and JFDI.
Multi-Level Problem Solving: A Recap
To solve problems properly, we need to solve them at three levels:
- Vision — understand the problem at a high level to understand why it’s worth solving in the first place
- Strategy — create concrete goals that will help us achieve our vision
- Implementation — turn the goals into actionable todo items so you can do the work
How do you solve problems? Let’s talk about it on Twitter.
For example, if you’re working on a book, you might start by creating a vision for the book, then defining a story arc as the roadmap, and finally breaking that down into chapters at the strategic level. Then, for each chapter, you’ll need to take the vision of the book and define a vision for the chapter, a story arc (or content requirements), and finally an outline.↩
I need to write a full post about the shift, but the short version is this:
- We missed having a community, and while we met a huge number of amazing people on the road, we never had enough time to get close with any of them.
- Our families are both in the Portland, OR area, and it’s really nice to have them around.
- We were sick of having to buy a new chef’s knife in every city to replace the dull IKEA knife in the Airbnb, of sleeping in uncomfortable beds, and of other small annoyances of constant travel.
Ultimately, the trade-offs of having ultimate mobility vs. a place we could really make our own finally tipped — for us — in favor of sticking in one place for a few years.↩
In every family, there’s one branch of the family tree that is convinced that they’re very punctual and organized. They always have specific times and well-formed plans. However, upon crossing the event horizon, an observer would describe the family’s activity as “lackadaisical”, “unhurried”, and “certainly not keeping to the fucking schedule they were so goddamn adamant about”.
This phenomenon has stumped physicists for years.↩
The rabbit holes hurt me the most, because this kind of derailment creates the perception that planning doesn’t solve problems. When a meeting like this goes sideways, a follow-up is rarely scheduled, which means the planning never actually happens. Later, when the project is lagging and things feel stressful and unclear, someone will bring up project planning, and they’re met with, “We had a planning meeting! It didn’t help!”↩