What It Looks Like When It’s Working
Or: The Engineer Who Brings You Problems You Didn’t Know You Had
It was a Tuesday afternoon — the quiet part, after lunch, when the open floor settles into that particular rhythm of keyboards and Thai iced tea and the low hum of people who are actually thinking rather than performing thinking. Somchai appeared at the side of my desk the way engineers do when they have something real to say — laptop open, not waiting to be invited. He had his laptop. He had a Grafana dashboard. He had a slide with three numbers on it and a very specific ask.
He didn’t have a Jira ticket. He didn’t have a complaint. He had a proposal.
I’ve spent three posts describing a problem and its causes. This one is about what the other side looks like — not as a theoretical destination, but as a specific, recognisable moment that you’ll know when you see it, if you know what you’re looking for.
That moment is an engineer walking in with a proposal nobody asked for, built on data they gathered themselves, describing a problem the organisation didn’t know it had — and telling you how they’re going to fix it.
That’s Station 4. And the reason it’s worth writing a whole post about is that it doesn’t announce itself. It arrives looking like a regular Tuesday afternoon conversation, and if you don’t recognise it for what it is — and respond to it correctly — you’ll handle it like a routine request and miss the signal entirely.
The VP Definition
A VP I worked with was once asked what a principal engineer actually looks like. He didn’t reach for a job level framework or a competency matrix. He said, without pausing:
“He’s the guy who brings me the problems I didn’t know I had and tells me how he’s going to solve them.”
That one sentence contains everything. Not “executes assigned work exceptionally well” — though they do. Not “flags problems when asked” — though they do that too. Surfaces problems the organisation didn’t know to look for, and arrives with a solution already forming. Both halves matter equally. The first half is about system understanding deep enough to see what’s invisible from above. The second half is ownership: treating the invisible problem as yours to solve, not yours to report.
Most teams have people capable of getting there. Most of those people never do — not because of ability, but because nobody ever made the gradient visible or told them which direction to move. The first three posts in this series were about removing the obstacles. This one is about what you’re removing them for.
What Station 4 Actually Requires
The leap from Station 3 to Station 4 isn’t just more of the same initiative. It requires a specific skill that most engineers were never taught and most managers never explicitly offer to teach: how to make a case.
Not a complaint. Not a gut feeling with a slide deck. A case — with a diagnosis, a quantified impact, a proposed solution, and an honest estimate of the cost. The kind of argument that could convince someone who doesn’t share your intuition about the system, because it’s built on evidence rather than authority.
This skill doesn’t develop through osmosis. It develops through a specific conversation, in a one-on-one, that goes roughly like this: “You’re at the point where you should be bringing me proposals for larger investments. Here’s what a good one looks like.” Then you show them. Not the slide template — the reasoning. What a well-framed problem looks like. What evidence is actually evidence versus noise. How to express the value of a technical improvement in terms a business can act on.
The engineers who never receive that conversation either never make the leap, or make it messily — arriving with proposals that are too vague to approve, getting knocked back, and concluding that advocacy doesn’t work here. The skill wasn’t missing. The scaffolding was.
The Metrics Question
Somchai’s three numbers were deployment frequency, mean time to recovery, and a third metric his team had built themselves — a composite score tracking how often engineers had to work around a known issue in the service rather than through it. Call it friction rate, for want of a better name.
The first two came from the DORA framework — the research documented in Accelerate by Forsgren, Humble, and Kim, which established deployment frequency, lead time for changes, change failure rate, and time to restore service as the four metrics that most reliably predict both engineering performance and organisational outcomes. If you haven’t read it, it’s worth your time. The evidence base is unusually solid for this domain, and it gives teams a common language for talking about engineering health that doesn’t require everyone to already agree on what good looks like.
But the third metric — the one his team invented — is the one worth paying attention to. Because DORA is a starting point, not a destination. It’s scaffolding for building the habit of measurement: the discipline of diagnosis, quantification, and evidence-based argument. Mature teams eventually develop metrics that are genuinely theirs — calibrated to their specific system, their specific failure modes, the business outcomes they’re actually accountable for.
An engineer who learns to make a case using DORA metrics has learned the skill. An engineer who looks at their system, decides DORA doesn’t capture the thing that actually matters here, instruments something new, and uses that to make a case — that’s a principal engineer. The framework taught them to measure. The judgment is theirs.
The proposal format that works, in my experience, has four parts. What’s the problem, stated precisely enough that someone who doesn’t work in the system could understand it. What’s the evidence that it’s actually a problem and not just an annoyance. What’s the proposed solution and its cost, in honest terms — not a best case, a realistic range. And what does success look like, specifically enough to know when you’ve achieved it. That’s it. Four parts, one page, fifteen minutes.
Somchai’s had all four. He was asking for six weeks.
How to Respond When It Happens
This is the part that matters most and gets written about least.
When an engineer walks in with a Station 4 proposal — unsolicited, evidence-based, specific — the correct response is not to immediately approve or reject it. The correct response is to engage with it seriously, in the room, in a way that makes visible that this is exactly the behaviour you were hoping for.
That means asking questions about the evidence, not the premise. Pushing back on the solution if you have concerns, but treating the problem framing as sound until proven otherwise. Being honest about constraints — other priorities, timing, resourcing — without those constraints becoming a reason to dismiss the proposal itself. And, regardless of the outcome, naming what just happened: “This is exactly the kind of thing I want you bringing me.”
That last piece is not optional. The engineer who brought a Station 4 proposal and had it handled like a routine request — processed, filed, responded to in three days via Teams — has received a calibration signal whether you intended to send one or not. The signal is: this behaviour is normal. It isn’t. It took years to develop and it’s fragile in ways that aren’t obvious until it’s gone.
If you approve the proposal: say why, and say it in a way that reinforces the quality of the case, not just the idea. If you decline or defer: be specific about what would make it approvable, so the engineer leaves with something to work toward rather than a door closed. Either way, the conversation itself is the reward — being taken seriously as someone whose judgment about the system is trusted enough to act on.
Closing the Loop on School
In the first post, I argued that the waiting instinct comes from education — from twelve-plus years of a system that trained engineers to execute within defined parameters and never once asked them to define the parameters themselves. That School, in the broadest sense, produced people who are exceptionally good at completing assignments and genuinely unprepared for the moment when nobody is assigning them.
Ralph Waldo Emerson wrote that “the chief want in life is someone who will make us do what we can.” Not allow. Not permit. Make — by creating conditions that stretch people toward what they’re actually capable of, rather than just clearing the path and hoping they find their way there.
The ownership ladder is that. The process flex from Post 2 creates the space. The cultural conditions from Post 3 make it safe. This post is what you’re building toward: engineers who have internalised the gradient, understand where they are on it, and are actively moving.
You don’t manufacture that. But you can make it possible — by naming the stations, giving explicit permission at each transition, responding correctly when someone moves, and building the kind of environment where a Tuesday afternoon conversation with a Grafana dashboard and a very specific ask is the most normal thing in the world.
That’s what it looks like when it’s working. You’ll know it when you see it.
The Bottom Line
The series started with a reflex — an engineer reaching for a browser tab to write a Jira ticket for something that would take twenty minutes to fix. It ends with an engineer who walks in on a Tuesday with three numbers, a proposal, and the confidence that the problem they found is worth someone’s attention.
The distance between those two moments isn’t talent. It’s the accumulated effect of a process that has enough flex to absorb initiative, a culture where failure is a question rather than a verdict, a manager who gave explicit permission at every rung of the ladder, and enough repetition of all three that acting became the reflex instead of waiting.
None of it is complicated. Very little of it is easy.
Now, if you’ll excuse me — Somchai got his six weeks. I should go find out what he’s built.