Evan King joined Meta in 2017 as a new grad engineer working on suicide prevention. His team had ML PhDs building models to detect suicides in live videos. Brilliant people. Cutting-edge work.
Their model caught 9% of actual crisis situations.
While the PhDs kept improving their video analysis, Evan noticed something. By the time the model finished processing frames, people in the comments had already spotted the crisis. “Don’t do it.” “It’s not worth it.” Comments appeared within seconds.
He suggested using comments as input.
Accuracy jumped from 9% to 50%. Then above 90%.
That—plus a few more wins like it—got Evan promoted from new grad to Staff Engineer in three years.
Here’s the lesson: the fastest path up isn’t solving the hardest problems. It’s solving the problems that matter.
Why We Work on the Wrong Things
We see a slow database query. Messy code. An architecture that could be cleaner.
Real problems. But here’s what we miss.
Companies promote us for solving business problems, not technical ones.
Spend six months optimizing a service that gets 100 requests per day? Nobody notices. Spend six weeks building audit logging that unblocks three $500K deals? That’s a promotion conversation.
Same skills. Different problem.
Look, technical excellence matters. But technical difficulty and business impact are different things.
This doesn’t mean we should only work on what leadership talks about in meetings. Sometimes you need to fix infrastructure. Sometimes you need to pay down technical debt. Sometimes the most important work is invisible.
But here’s the thing: even invisible work has business impact if you look for it.
That infrastructure fix? It prevents outages that would cost customers and trust.
That technical debt? It’s slowing down every feature the team ships.
That refactor? It means new engineers can contribute in days instead of weeks.
Four Questions Before You Start
Before you work on anything, ask these:
1. Who cares if this gets fixed?
Low impact: “The code would be cleaner”
Medium impact: “Our team would save time”
High impact: “The business could do something it can’t do today”
2. What happens if we ignore it?
Low impact: “Nothing really”
Medium impact: “We’ll be slower eventually”
High impact: “We’ll lose customers or money”
3. How sure are we this matters?
Low certainty: “I think this might help”
Medium certainty: “We have some signals”
High certainty: “Customers are asking for this, or the data shows it’s costing us”
4. Can we measure if it worked?
No measure: “The system will be better”
Soft measure: “Developers will be happier”
Hard measure: “API response time drops 50%” or “We close 3 blocked deals”
If a problem scores high on three or more questions, it’s worth your time.
One note: if you’re early in your career, it’s okay to work on hard technical stuff just to learn. This framework matters more once you have solid skills and want to move up.
Try This Week
Pick one:
Talk to support
Most companies have a Slack channel where support tickets show up. Join it. Read for 15 minutes once a week. Write down patterns.
If the same issue appears five times, that’s a signal.
Ask your team
Next standup: “What’s one thing that’s working but annoying?”
Nobody will answer the first time. That’s fine. Ask again next week. By the third time, someone will mention the thing that’s been bugging them for months.
Pick one thing. Spend an hour seeing if you could fix it.
Ask your manager
“What are the top three things leadership is measuring our team on this quarter?”
Write it down. Look at what you’re working on. Ask yourself: does this connect to any of those three things?
If yes, great. If no, you might be working on the wrong stuff.
Where to Look
Once that feels comfortable, look here:
Sales and customer success
Pick someone who seems approachable. Message them:
“Hey [name], I’m [your name] on the [team] team. I’m trying to understand what customers actually need. Do you have 15 minutes this week to chat?”
Most people will say yes. They like when engineers care about customers.
When you talk, ask:
“What’s one technical thing that keeps you from closing deals?”
“What do customers keep asking for that we have to say no to?”
Then listen. Don’t defend why things are the way they are. Don’t explain the technical reasons. Just write it down.
Do this with three different people.
If you hear the same thing three times, that’s a real signal. Look into it.
All-hands meetings
What does leadership talk about? What numbers do they show?
CEO mentions infrastructure costs three times? Saving $50K/month gets noticed. Leadership talks about retention? Look at why customers leave.
Your skip-level
Once a quarter, get 15 minutes with your manager’s manager. Ask one thing:
“What would make your job easier over the next three months?”
You’ll learn what matters two levels up.
Write It Down First
Before you build anything, fill this out:
Problem: [What’s broken]
Who it affects: [Which teams, how many customers]
What it costs: [Time? Money? Opportunity?]
Your solution: [What you’d build]
How you’d measure success: [Specific numbers]
Timeline: [How long it takes]
What you need: [Resources, approvals]Takes 10 minutes. If you can’t fill it out, you don’t understand the problem yet.
How to Pitch It
Found something. Wrote it down. Now what?
Try this:
Hey [Manager], I noticed [Problem] is affecting [Impact]. I think I could fix it by [Approach] in about [Time]. What do you think?”
Send it in Slack. If they say yes, schedule 15 minutes. Bring your writeup.
Why this works: you’re talking about business impact, not technical beauty. You’ve done the work already. You’re connecting it to what they care about. And you’re asking, not demanding.
When It Doesn’t Work
You found a problem. Wrote it up. Pitched it.
Nothing.
Your manager says no, or maybe later, or just... nothing happens.
That’s normal. Here’s what to do:
Get specific
Don’t guess why they said no. Ask:
“I want to make sure I’m focused on the right stuff. Can you help me understand why this wasn’t a priority? What should I be looking for instead?”
Maybe timing is off. Maybe priorities just changed. Maybe they see something you don’t.
Look for patterns
One rejection? Normal. Three in a row? That’s a pattern.
Ask yourself:
Same reason each time?
Is it timing or “this doesn’t matter”?
Did I talk to the right people first?
Check your sources
Go back to basics. Watch the next all-hands more carefully. Ask your manager what leadership actually cares about this quarter.
Then compare: are you proposing solutions to those things, or to different things?
Consider the environment
Some teams don’t have room for this:
Teams maintaining old products nobody cares about
Teams in the middle of reorgs
Teams where all priorities come from above
Some companies say they reward impact but actually reward politics or tenure.
Try for six months. If nothing lands, you might need a different team. That’s not failure. That’s information.
The point: don’t spiral into “I’m bad at this.” Treat rejection like missing information.
Sometimes you’re wrong. Sometimes timing is wrong. Sometimes the company is broken.
Figure out which one it is.
What If You Just Love Technical Problems?
Maybe you love compilers or distributed systems and don’t care about promotions.
That’s fine. Some of the best engineers I know stay at senior level forever because they love the work.
But if you want to move up, understand the game. Technical excellence gets you to senior. Business impact gets you past it.
You don’t have to love this. You just have to know how it works.
And here’s the thing: you can do both. Building a caching layer can be technically interesting and save $200K a year. The difference is whether you frame it as “this is elegant” or “this cuts our costs.”
The Pattern
Go back to Evan.
His solution worked because he asked: what’s the actual problem?
The problem wasn’t “build the best video analysis model.” It was “catch crises before it’s too late.”
Once he saw that, the answer was obvious. Use the signals already there.
You can do this too:
Figure out what success looks like
Notice what’s not working
Look for simpler solutions people missed
Propose it with numbers
Ship it and measure
That’s it.
Evan did this several times over three years. Not one big heroic project. A series of wins that built credibility.
P.S. If you want my help with the tech lead transition, I’m opening up a private community for senior engineers.
Video courses. Expert workshops. Q&A calls. 1:1 support.
👉 Join waitlist