The one framework every engineer should know

Production-Ready Backend Templates (Sponsor)

Stop losing hours to backend boilerplate ❌

Start your next project with a production-ready template built on Directus, the open-source backend + CMS.

• Automatic REST & GraphQL APIs — zero code required

• Built-in auth, roles, and permissions

• Visual data modeling + content management

Directus powers projects for Domino’s, Red Bull, US Space Force, Apple and thousands more.

Explore Our Templates

Hi fellow High Growth Engineer, Jordan here 👋

Today’s article features a special guest, Torsten Walbaum, ex Director at Rippling and manager at Uber and Meta. He’s also the author of The Operator’s Handbook. I’ve been incredibly impressed with Torsten’s writing. He provides insanely in-depth, actionable advice and has a ton of experience and examples to back it up. So strap in.

In this article, you’ll learn a single, hugely applicable framework that takes your communication and problem-solving to a whole new level.

Without further ado, I’ll pass the mic 🎤 to Torsten 👏

I’ve interviewed hundreds of candidates as a hiring manager at Uber, Meta, and Rippling.

The most common reason I rejected candidates, by far, was a lack of structured problem-solving and communication.

If they make a mistake, I can help them correct it. Or if they spend too much time on an unimportant part of the question, I can redirect the conversation.

But if the candidate doesn’t show a structured thought process and I can’t follow their reasoning, that’s a huge problem–even if they get to the right answer.

Why? Because I need to make sure that they didn’t get lucky during the interview and “stumbled upon” the right answer. In other words, I want to know they can repeat that success on the job.

Over time, I realized that the best responses all have a similar structure. They sound somewhat like this:

✅ “There are generally four ways we can improve the performance of the system: A, B, C and D. We can eliminate A and B because they are not feasible under the constraints. Between the remaining options, C is the most promising because of [reason], so I’ll focus my answer on this option.”

What makes this a good answer? Instead of diving straight into the technical details, the candidate first gives an overview of possible solutions. As the interviewer, that shows me they analyzed the problem, evaluated tradeoffs, and intentionally chose their approach.

☝ But there’s one key requirement for this to work: The way the candidate structures the problem needs to be MECE (Mutually Exclusive and Collectively Exhaustive). Let’s take a look at what that means:

Let’s say we’re trying to segment our users based on which search engine they use.

We first need to make the user buckets mutually exclusive, i.e. not overlapping:

Since we removed the overlap between the segments, there’s no risk of double counting.

🚫 But there’s another issue: Some people aren’t captured by any of these buckets!

To fix this, we need to make the buckets collectively exhaustive:

👉 Now, our segmentation is crystal clear. These buckets capture everyone, and nobody falls into more than one.

The MECE framework was developed by the management consulting firm McKinsey, but its central ideas go back to the philosopher Aristotle. It can be applied to almost anything, including Engineering use cases, to sharpen your thinking and problem-solving.

⭐ What you’ll learn

In this article, you’ll learn how to apply this principle in 5 real-life use cases with actionable examples:

1. Acing interviews (we just covered this)

2. Diagnosing problems

3. Giving investigation updates

4. Explaining something to your colleagues

5. Deciding what to work on

Let’s get into it.

Use case #2: Diagnosing problems

You’re checking some dashboards and notice new signups dropped by 50%. When you flag this, everyone is freaking out and an incident is created.

This has been my life for years. It felt like every week I was in a war room dealing with an investigation, and the MECE principle has been a lifesaver during those chaotic periods.

Here’s what usually happens at the beginning of an incident. People throw out some hypotheses for what could be going on, and start investigating those:

❌ “I think I know what’s happening. The signup page might be down again; didn’t that happen last quarter? Or it could be related to that iOS update we shipped. But it’s also December, and it could just be a weak time for signups. Maybe it will go away on its own…”

What’s the problem with this? This set of random hypotheses doesn’t have a structure and is not collectively exhaustive. If you get lucky, you find the problem; but if you’re not lucky, you might spend the entire day chasing down dead ends.

And if you don’t finish the investigation quickly, you’ll likely start going in circles since you lose track of what you already looked into.

🎯 The solution: Break the problem into an issue tree that follows the MECE principle.

How? You start by dividing the possible root causes into high-level groups. Then, you break these groups down further, ensuring every possibility is captured and none of the buckets overlap.

✅ After: “There are two options for what could be happening: Either something is broken, or the data only makes it look like there’s a problem. If something’s broken, it could be isolated to a specific OS, or affect all devices. And the issue could be at any of the three steps of the signup process, so we’ll check them one by one.”

Don’t rely on luck to find the root cause. The MECE framework gives you a structure that ensures you will find it, and makes it easy to…

1. get everyone on the same page on what’s being investigated, and

2. divide the work between different people or teams.

One added benefit of using a structure like this: Since you have an overview of all possible things you need to check, you can prioritize what to investigate first.

For example, you can see that checking for a data issue or seasonality first can potentially save you a lengthy investigation.

Use case #3: Giving investigation updates

Continuing the example from above: Imagine you’re in a Slack channel for the incident you’re investigating, and you need to give regular status updates.

Given the severity of the issue, a lot of people are paying attention to how things are progressing.

This is what a lot of incident updates look like:

What’s the problem? The update lacks a MECE structure and jumps between seemingly random issues. It’s unclear how close you are to finding the root cause.

Using a MECE issue tree instead, we can make it easy for stakeholders to follow along – you can literally cross out possible root causes one by one as you rule them out.

✅ After: “We’re confident we will find the root cause by the end of the week. First, we have ruled out that it’s a data issue or seasonality; in other words, we know there is a real problem with signups. Next, we have narrowed down the issue to iOS users only; as a final step, we just need to figure out which step of the iOS flow is broken.”

This approach lets you highlight your progress and give people confidence that you’ll find the issue soon.

If you were in the shoes of your manager or a Tech Lead watching, which one would give you more confidence?

Use case #4: Explaining a process or part of the system

Imagine you’re trying to explain to another team how your lead enrichment pipeline works. It often goes something like this:

What’s the problem with this? This overview is a stream of consciousness that goes in a zigzag line and makes it hard to follow.

I guarantee you, if you asked the other person at the end to draw the lead enrichment flow based on your description, they’d get it wrong.

That’s where the MECE principle comes in:

Why is this better? Your audience is trying to build a mental diagram of the system. Even if you don’t draw an issue tree for them, you can still use the MECE principle to structure your communication. By first giving a high-level overview before going deeper on any individual component, you make it easy to follow along.

But we can make our audience’s life even easier:

✅ Expert: “Leads are added from four sources to our system: They’re either ingested from one of three data vendors, or added manually via CSV upload. Since 95% of the volume comes from data vendor A, I am mainly going to focus on this flow…”

Why is this even better? The “expert” example takes the structured information from “better” and focuses only on the most relevant pieces.

Remember: You should always create a complete picture in your head, but you don’t have to communicate everything.

Use case #5: Deciding what to work on during planning

The more senior you get as an engineer, the more you will have to evaluate different options to drive impact and present your recommendation.

Unfortunately, brainstorming ideas during planning often looks like this:

❌ “Last week, I realized we’re not allowing video ads on Android; they work well on iOS and Desktop, though. I think we can enable that pretty quickly, and it should drive higher CPMs and therefore revenue.”

This might be a good idea, but something else might have a higher impact, and presenting this way makes it look like you’re not considering that.

Instead, you can frame your proposal using the MECE principle:

Stating the goal first, then (MECE) options, and finally a recommendation, makes it more likely your idea convinces your manager. Why? Because you already compared it against alternatives, which is what they would otherwise do.

There’s no better way to prove that you’re ready to move up than making your manager’s life easier and showing that you can think like a leader.

📖 TL;DR

MECE structures your thinking, writing, and communication. Use it to solve problems in a systematic and repeatable way, and ensure others can easily follow along.

1. Use MECE in interviews
   
   ✅ Example: “There are generally four ways we can improve the performance of the system: A, B, C and D. We can eliminate A and B because they are not feasible under the constraints. Between the remaining options, C is the most promising because of [reason], so I’ll focus my answer on this option.”
   

2. Use MECE when diagnosing problems
   
   ✅ Example: “There are two options for what could be happening: Either something is broken, or the data only makes it look like there’s a problem. If something’s broken, it could be isolated to a specific OS, or affect all devices. And the issue could be at any of the three steps of the signup process, so we’ll check them one by one.”
   

3. Use MECE when giving investigation updates
   
   ✅ Example: “We’re confident we will find the root cause by the end of the week. First, we have ruled out that it’s a data issue or seasonality; in other words, we know there is a real problem with signups. Next, we have narrowed down the issue to iOS users only; as a final step, we just need to figure out which step of the iOS flow is broken.”

4. Use MECE when explaining a process or part of a system
   
   ✅ Example: “Leads are added from four sources to our system: They’re either ingested from one of three data vendors, or added manually via CSV upload. Since 95% of the volume comes from data vendor A, I am mainly going to focus on this flow…”

5. Use MECE when proposing ideas, like during planning
   
   ✅ Example: "If we want to drive ad revenue, we have three options as a company: We can either grow user engagement, increase ad load or improve CPMs. Engagement is owned by another team and we've increased ad load pretty aggressively last quarter, so I recommend we focus on CPMs. One quick win could be enabling video ads on Android.."

🙏 Thank you to Torsten

Wow, I think this guest post beats the record for most examples of any High Growth Engineer article 😄. On top of that, it’s crazy how this framework can be applied to practically every communication use case.

Since initially working on this post with Torsten, I’ve been using MECE and I can 100% attest to the difference it makes. I was even complimented recently and can’t help but wonder if it’s related. The only framework that made this big of a difference was BLUF (Bottom Line Up Front).

Thanks again to Torsten for such a valuable post. If you liked this post, check out Torsten’s Substack, The Operator’s Handbook. He provides actionable advice like this every week. I haven’t missed a post of his yet. They’ve all been phenomenal.

👏 Shout-outs of the week

• Lenny Rachitsky had an awesome AI-based guest post that showed how you can level up your team with reusable, shared prompts and custom GPTs. Credit to Hilary Gridley for the great post.

• 28 Year Old Staff Engineer @ Google on The Developing Dev — Ryan hosted a podcast + gave takeaways with an engineer who reached Staff Engineer by 28.

• A Practical Guide to Earning Respect on Stay SaaSy — Things execs do to earn respect that you can do and think about too. I particularly resonate with “not taking things too literally” as it’s something I’d like to work on more.

Thank you for being a continued supporter, reader, and for your help in growing to 80k+ subscribers 🙏

You can also hit the like ❤️ button at the bottom of this email to help support me or share this with a friend to get referral rewards. It helps me a ton!