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.
 |
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.
 |
3. The Counter-Decision Protocol
Every leader has bias. Especially when the decision feels exciting.
This will keep you honest:
Write out your preferred decision
Ask people you trust to assess it or even argue the exact opposite
Find the gaps in your logic
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.
No comments:
Post a Comment