Why Your Engineers Are Still Waiting
Or: The Ownership Problem Nobody Admits They Created
Beer and Servers Don't Mix — Microservices Workshop Series, Part 1 of 4
He'd been staring at it for eleven minutes. You could tell by the way his cursor had stopped moving — hovering somewhere in the middle of the screen, that specific stillness that isn't thinking, it's deciding whether to think. The standup had finished, the vinyl floor outside still humming with the footsteps of people heading back to their desks, and Somchai was looking at a bug that was going to take him about forty minutes to fix. He knew it. The team knew it. Everyone had just agreed, out loud, that it was the kind of thing that should probably get done soon.
He opened a browser tab and started writing a Jira ticket.
You've seen this. You may have done this. The instinct to ticket a small, fixable problem rather than fix it is so deeply embedded in most engineering teams that it doesn't even register as a decision anymore — it just happens, like reaching for your phone when a conversation goes quiet. And if you're an engineering leader watching it happen, the right response probably isn't frustration. It's curiosity. Because that reflex didn't come from nowhere, and it didn't come from laziness.
It came from twelve-plus years of school.
The Education You Didn't Know You Were Getting
Here's the thing nobody puts in a job description: most engineers arrive at their first role exceptionally well-trained to wait for instructions.
Not because they're passive. Not because they lack ambition. Because school — from the first day of primary school to the last exam of university — is a long, carefully structured sequence of assigned work assessed by authority figures. Every task has an owner, and that owner isn't you. Your job is to complete what's been defined, meet the deadline that's been set, and wait for the next assignment. The system is optimised to produce people who execute well within defined parameters. It is not optimised to produce people who walk up to an unsolved problem and say "that's mine."
Then those people join your team. You hand them a system to own. And for the first several months — sometimes longer — they treat it exactly like a school assignment. They do what's asked of them. They do it well. They're responsive, technically sharp, diligent. But they wouldn't dream of stopping a sprint to fix something nobody told them to fix. The system is assigned to them. They haven't made the leap to owning it.
Those are different things. And the gap between them is almost entirely invisible until you know what to look for.
What "Waiting" Actually Looks Like
The Jira ticket is the tell, but it's not the only one.
Waiting looks like a standup where every update is about tasks on the board — never about things adjacent to the board that are quietly on fire. It looks like an engineer who flags a problem in a one-on-one but wouldn't raise it in planning, because planning is where the Product Owner decides what matters. It looks like a pull request that fixes exactly what was asked, no more, even when the author clearly noticed three related things that would have taken ten minutes each to address.
None of this is incompetence. It's calibration — the kind of calibration that happens when people learn, through observation, what the environment actually rewards. And most engineering environments, without meaning to, reward completion of assigned work over initiative. They reward staying in your lane. They reward asking before acting.
The economist Milton Friedman once observed that "one of the great mistakes is to judge policies and programs by their intentions rather than their results." He was talking about government, but the mechanism is identical in engineering organisations. You can intend to build an ownership culture. You can say "we want engineers who treat their systems as genuinely theirs." And then you can build, entirely by accident, an environment that teaches them the opposite — and wonder why nothing changes.
The Spectrum Nobody Tells You About
Ownership isn't a switch you flip. It's a gradient, and most engineers spend their entire careers at one end of it without ever being told there's another end to move toward.
The gradient has four recognisable stations — and they matter because the manager's job is genuinely different at each one.
Station 1: Waiting. Executes what's asked. Good work, no initiative. This is where almost everyone starts, and it looks fine until you realise nothing is happening that you didn't specifically request.
Station 2: Reacting. Flags problems they notice. Raises things in standups that weren't on the agenda. Advocates — once, maybe twice — for fixing something that's bothering them. This is the first real signal that something is shifting. They're paying attention to the health of the system, not just the tasks on the board.
Station 3: Initiating. Stops a sprint for a couple of days to fix the thing they've been flagging for three weeks. Makes a call and tells you about it afterward. Doesn't ask permission for every small decision because they've worked out they don't need to. This is where "assigned responsibility" actually becomes ownership — and, as we'll explore in the next post, it's also where most organisational systems inadvertently punish them for it.
Station 4: Advocating. Comes to you with a proposal. Not a complaint dressed as a suggestion — a real case. They've looked at the data, framed the problem in terms the business can act on, estimated the impact, and asked for two sprints of investment. This is principal engineer behaviour. It requires seeing problems the organisation didn't know to look for, and treating those problems as yours to solve.
A VP I worked with once described a principal engineer in one sentence. "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's Station 4. Most teams have a handful of people capable of getting there. Most never do — not because of ability, but because nobody ever made the gradient visible, let alone told them they were supposed to be climbing it.
Back to the Ticket
So. Somchai's ticket.
My response, when I see this happen, is to fix it myself. Open a pull request. Then make the time visible.
The critical detail is the timestamp. When I paste the PR link in Slack — sometimes less than twenty minutes after the Jira tab opened — I'm not making a point about Somchai. I'm collapsing an assumption the whole team shares: that fixing it yourself is the slow path, the risky path, the path that requires clearance. The time to write the ticket and the time to fix the thing are roughly the same. Often less. The ticket isn't efficiency — it's the appearance of efficiency, wrapped around an instinct to defer.
Then I show up at standup. Say it out loud. Not as a reprimand — as a demonstration. "This isn't a Jira ticket. It's a twenty-minute fix. The ticket takes longer to write than the problem takes to solve." I reply in the Slack thread with the same message. I make the pattern visible and name it as a pattern, because that's the only way to interrupt an automatic response: show the alternative, repeatedly, until the alternative becomes the reflex.
It takes longer than you'd think. The instinct runs deep.
What This Series Is About
This is the first of four posts on the ownership ladder — how engineers move from waiting to initiating to advocating, and what actually gets in the way.
Post 1 (this one) is about the wound: what waiting looks like, where it comes from, and why handing someone ownership rarely produces the ownership you were hoping for.
Post 2 is about the trap: the structural reasons — Scrum, sprint metrics, product alignment — that punish Station 3 behaviour before it even has a chance to become a habit.
Post 3 is about the fix: the cultural conditions, and the specific manager behaviours, that make taking ownership safe. There's a story in that post about a CEO in a room full of people watching him respond to three consecutive quarters of failure. It's worth the wait.
Post 4 is about the proof: what it looks like when it's working, how to measure it, and the specific conversation you need to have when someone is ready to move from Station 3 to Station 4.
For now: next time someone on your team tells you they're going to create a Jira ticket for something — check your watch. Then open your IDE.