The simple thinking techniques that would’ve saved us $500,000

For engineering leaders to avoid shallow decisions.

Three years ago, I made a decision I was proud of.
We cut scope on a project we were working on to hit our OKRs. Quite a normal thing to do.
Another team relied on it for next quarter.
We talked it through with my manager, PM, my team, and the other team and just went for it.
And we delivered it on time! Big win.

Or so I thought.

What followed wasn’t just small cleanup we needed to do.
It was chaos.
Sales had promised the whole thing so we missed deals. What we delivered was unstable so we had to very quickly rewrite a big part of it.
We spent a whole quarter “fixing” it and our roadmap was out the window.

When we finally added it all up:
That "quick win" must have cost the company $500,000.
(We actually calculated it.)

Am I proud of this? No.

The execution was fine. Can’t blame the team at all.
My thinking and decision at the time… clearly wasn’t.

Why…

Like most engineering leaders, I made a decision based on what was directly in front of me.

That’s first-level thinking.
It looks like:
→ “What’s the fastest way to fix this?”
→ “What’s the obvious win?”
→ “How do we get this done and move on?”

But of course…
Every decision has a ripple effect.

How I think now

It starts with one simple question:

“What happens after what happens, happens?”

1. Cascade mapping

I use this every time I’m about to commit to something big.

It’s stupid simple.
But very effective.

Draw this on a whiteboard:

Decision → First-Order → Second-Order → Third-Order Effects

Next time you have a big decision to make,
work with your team and important stakeholders to fill it out.
Not just engineers. Get Support, Marketing, Sales and anyone else who might care about it in “the room”.
Why? Because they’ll have context you might not have.

Try it.

Fictional Cascade Map for increasing mobile release rate

2. Stakeholder experience forecast

Here’s the rule:
If you forget your stakeholders, they’ll remind you with angry emails or slack messages.

I learned this during a rushed dashboard redesign.

Marketing would benefit immediately from it, but our customer support team would potentially face a three-month nightmare of increased ticket volumes and complex troubleshooting. Don’t even get me started with this story.

Now I use a simple Stakeholder Forecast Table before every major launch.

Fictional stakeholder experience forecast for increasing mobile release rate

3. The Counter-Decision Protocol

Every leader has bias. Especially when the decision feels exciting.

This will keep you honest:

1. Write out your preferred decision

2. Ask people you trust to assess it or even argue the exact opposite

3. Find the gaps in your logic

4. Update your decision before committing to it

When we debated whether to build a custom workflow engine or use an open-source solution, this method exposed a scaling issue we hadn’t even thought about.

It’s basically like ADRs.

4. The Second-Level Decision Matrix

Use this whenever you face a high-impact choice.
Here are 5 real examples from my journey:

1. Team scaling

• First-level thinking: “We need to hire 8 more engineers to meet our roadmap commitments”

• Second-level thinking: “Adding 8 engineers means onboarding overhead, knowledge dilution, and communication complexity that will temporarily decrease team velocity before improving it. We should hire 4 engineers now, improve documentation and onboarding, then evaluate if we need the remaining 4.”

• Result: When scaling our team using this approach, we achieved our roadmap goals with 40% less hiring than originally planned, while maintaining better team cohesion and code quality metrics.

2. Technical debt prioritization

• First-level thinking: "We'll dedicate one sprint per quarter to addressing technical debt."

• Second-level thinking: "Batching technical debt work creates boom-bust cycles of motivation and increases regression risk. We should instead identify the highest-impact debt items, divide them into 2-day packages, and distribute them throughout regular sprint work."

• Result: Our platform stability team reduced incidents by 60% over 6 months using this approach, compared to minimal improvements under the previous batch method.

3. Architectural evolution

• First-level thinking: "Let's rewrite our monolith as microservices to improve scalability."

• Second-level thinking: "A full microservices migration will create immediate chaos before eventual benefits. We should identify the 3 most performance-critical components, extract only those as services while strengthening the monolith's internal boundaries, then reassess."

• Result: By using this incremental approach, we achieved 80% of our performance goals with only 30% of the effort a full rewrite would have required.

4. Process improvements

• First-level thinking: "Our stand-ups are inefficient. Let's switch to asynchronous updates."

• Second-level thinking: "Asynchronous updates will improve efficiency but reduce spontaneous problem-solving and relationship building. We should implement async updates 2 days per week, keep 3 days for synchronous meetings, and create explicit virtual spaces for the spontaneous interactions we'll lose."

• Result: Our distributed team improved sprint completion rates while maintaining team cohesion scores above baseline.

5. Career development

• First-level thinking: "We need to promote our strongest individual contributors but they’re at the company’s top IC tier so the logical next role is in management."

• Second-level thinking: "Promoting ICs to management creates two risks: we lose strong technical contributors and gain inexperienced managers. We should create parallel technical leadership tracks, identify management aptitude separately from technical skill, and develop transition plans that ensure knowledge transfer."

• Result: After implementing dual-ladder progression, our two-year retention rate for senior+ engineers improved.

Final thought

Most bad decisions aren’t bad because they’re wrong.
They’re bad because they’re shallow.

Did you like this post?

Consider supporting my work and subscribing to this newsletter.
Here’s what you get as a subscriber:

Free:

• ✉️ 1 high value post per week

Paid:

• 🔒 50 Engineering Manager templates and playbooks (worth $79)

• 🔒 The Engineering Manager’s Field Guide (worth $29)

• 🔒 A weekly "What would you do?" scenario & breakdown from real challenges EMs face

• 🔒 The complete archive

Some useful links from me

• 📂 Get 50 Engineering Manager Notion Templates to streamline your workflow.

• 📕 Read The Engineering Manager’s Field Guide for practical leadership insights.

• 👨‍💻 Become a better Software Engineer with CodeCrafters – build Redis, Git & more from scratch (40% off with my partner link).

• 🎯 Book a mock System Design or Behavioral interview with me to prep for your next interview.

• 👋 Connect with me on LinkedIn for more Engineering Management tips.

Love or Scared of System Design?

I just launched System Design, but Simple a weekly newsletter where I will be breaking down system design concepts in a way that actually makes sense.

If you're preparing for interviews or just want to sharpen your architecture skills, this is for you.

🎁 Bonus for all subscribers: System Design Interview Preparation Cheat Sheet