The Level 3 Trap: Eight Levels of Product-Minded Engineering
A fintech team shipped 40+ tickets a sprint while activation stayed flat for three quarters. An eight-level framework for assessing where engineers actually operate – and why Level 3 feels like mastery but isn't.
They were the most productive team I’d ever seen building the wrong things.
I worked with a fintech team of eight engineers running 40+ tickets a sprint.
Velocity was healthy. PRs merged daily. Standups were efficient. Nobody was slacking.
Their core activation metric had been flat for three quarters.
The team wasn’t broken. They were stuck – at a level nobody had a name for.
I’ve since developed an eight-level framework I use to assess every engineer I work with. Not as a hierarchy of seniority titles, but as a map of where someone’s instincts actually fire when they get a new task.
Most teams stall at Level 3. It feels like mastery. It isn’t. It’s the edge of the map.
Level 1 – Problem DiscoveryLink to section: Level 1 – Problem Discovery
Junior instinct: “The user wants X.”
Product-minded instinct: “Why do they want X?”
The gap between these two sentences is the entire career of most engineers who never cross into product thinking.
Artifact of mastery: you threw away a feature you already built because one user conversation revealed the wrong assumption underneath it.
This level isn’t about saying no to stakeholders. It’s about holding the problem loosely enough that evidence can change it. The engineers who struggle here treat requirements as immutable. The ones who’ve internalized Level 1 treat them as hypotheses with an expiration date.
Level 2 – Outcome ThinkingLink to section: Level 2 – Outcome Thinking
Average engineer: “I closed the ticket.”
Product-minded engineer: “What changed after we shipped?”
The release isn’t the end of the work. It’s the beginning of measurement.
I’ve watched teams celebrate sprint completions while the metric they were supposed to move didn’t budge. The ticket system recorded success. The product recorded nothing.
Level 2 engineers ask what signal they’re waiting for before they merge. They know the difference between shipped and worked. They’ll reopen their own PR if the instrumentation was wrong.
Level 3 – User EmpathyLink to section: Level 3 – User Empathy
The most underrated level. Almost every team stalls here permanently.
You’ve earned it when you can complete this sentence in under five seconds:
“The user is frustrated because…“
Not from reading a ticket. From watching sessions. From reading the angry emails. From taking one support shift.
Level 3 feels like mastery. It isn’t.
I see this constantly: engineers who can articulate user pain with genuine specificity, who’ve done the research, who care – and still can’t connect that empathy to business tradeoffs, experiment design, or the courage to kill their own work. They’ve reached the edge of the map and mistaken it for the destination.
The fintech team I mentioned? They were here. Deeply. Genuinely. They could describe user frustration in detail. They just couldn’t translate it into what we should stop building.
That’s the trap.
Level 4 – EconomicsLink to section: Level 4 – Economics
This is where Staff-level engineering actually begins.
You’ve canceled a technically elegant solution because the ROI wasn’t there.
You’ve defended an ugly fix through business impact, not code elegance.
Impact / Effort appears in your mental stack before Code Quality.
Level 4 is uncomfortable because it requires saying “this isn’t worth doing” when the technical solution is beautiful. It requires advocating for the hack that ships this week over the refactor that ships next quarter – when the data supports it.
Engineers who operate here stop optimizing for elegance in isolation. They optimize for leverage.
Level 5 – Fast ExperimentationLink to section: Level 5 – Fast Experimentation
You validated a hypothesis before writing a single line of production code.
You threw away a week of work without drama.
You were publicly wrong and adjusted.
Most teams optimize for delivery. Discovery exists precisely to avoid building the wrong thing.
Level 5 engineers treat code as one of several tools – not the default tool. They’ll run a concierge test, a fake-door experiment, a prototype in a spreadsheet, a shadow deployment. They measure the cost of being wrong in days, not quarters.
The fintech team shipped constantly but experimented rarely. Every ticket was production code. Every hypothesis was a feature. That’s expensive discovery.
Level 6 – Product CommunicationLink to section: Level 6 – Product Communication
The underrated career multiplier. Almost nobody develops it intentionally.
You’re here when people use your framing to describe a problem. Not because you’re the most senior, but because you articulated it most clearly.
Level 6 isn’t about being loud in meetings. It’s about making the invisible visible – turning a vague product tension into a decision frame that others can act on. The best Level 6 engineers I know write better than most PMs. They draw the system. They name the tradeoff. They make the meeting shorter.
This skill compounds across an entire organization. One engineer who can frame problems well changes how ten other people think about them.
Level 7 – OwnershipLink to section: Level 7 – Ownership
Nearly impossible to fake.
- Woken up at 3am for a prod incident you caused
- Fixed your own release under pressure, not someone else’s
- Felt shame about a decision from six months ago
- Felt pride about one from two years ago
I’ve been paged at 3am for a migration I wrote that took down a payments queue. That incident is the reason I can identify Level 7 engineers in a twenty-minute conversation.
You’ve stopped saying: “That’s not my responsibility.”
You’re saying: “This affects the product.”
Ownership isn’t heroics. It’s the accumulated weight of decisions you made, outcomes you tracked, and failures you didn’t outsource. Engineers at this level don’t need permission to care.
Level 8 – AI OrchestrationLink to section: Level 8 – AI Orchestration
The 2026 separator.
You’ve delegated to an AI agent, gotten a bad output, and understood the problem was your context, not the model.
Now you spend more time on:
- Problem definition
- Context creation
- Output validation
…than on writing code.
Level 8 isn’t about using Copilot. Everyone does that. It’s about treating AI as a collaborator whose output quality is a function of how well you defined the task. The engineers who’ve internalized this don’t chase model benchmarks – they chase context architecture. (I wrote more about this in The AI Model Is No Longer The Bottleneck.)
Building got cheap. Choosing what to build got expensive. Level 8 engineers know which side of that equation they’re paid for.
The Final TestLink to section: The Final Test
When you get a new task, what fires first?
| Instinct | First question |
|---|---|
| Engineer | “How do we build this?” |
| Senior | “What’s the architecture?” |
| Product-minded | “Why does this matter?” |
| Product-minded in the AI era | “Is this even the highest-leverage problem we could be solving right now?” |
That last question is the most valuable engineering skill of this decade.
AI makes building cheap. Choosing the right problem is getting more expensive.
What I See in the FieldLink to section: What I See in the Field
At a workshop I ran for 60+ senior Ruby engineers last year, the pattern was consistent.
The engineers asking that last question were mostly already in leadership roles or actively moving into one. The ones shipping the most code were often building the least impactful things.
The Level 3 trap is real. It’s just invisible until the metric doesn’t move.
You can have high velocity, strong empathy, clean code, and a flat activation curve – all at the same time. The dashboard won’t tell you you’re stuck. Only the outcome will.
Where Does Your Team Actually Operate?Link to section: Where Does Your Team Actually Operate?
This framework isn’t a grading rubric for performance reviews. It’s a diagnostic.
When I work with founders and CTOs on fractional engagements, the first thing I map isn’t the org chart – it’s where the senior engineers actually sit on this scale. The gap between perceived seniority and operational level is often the reason metrics don’t move despite healthy sprint velocity.
If you can’t tell where your team operates, that’s the gap worth closing before you hire another engineer.
What level does your team actually operate at – and what broke because of it?
Scaling a technical team and can’t tell where your senior engineers sit on this map? Connect on LinkedIn. Fractional CTO engagements, limited to a few teams per quarter.
Comments powered by Disqus.