You've had the meeting.
Smart, well-paid engineers. A refinement session. Nobody saying anything. The scrum master carrying the entire conversation while the engineers watch. A requirement gets read aloud. Silence. Someone offers a point estimate — a 3, maybe a 5 — and everyone nods along. After the meeting, you get a message from one of your engineers: what should I pick up next?
You've tried talking to them about it. You've told them to speak up, to ask questions, to take ownership. They nodded. The next refinement session looked exactly the same.
Here is what most managers conclude at this point: the engineers are the problem. They're disengaged. They don't care. They're not the right people.
Here is what is actually true: the engineers are doing exactly what their environment has taught them to do.
Passivity in engineering teams is not a personality flaw. It is a rational adaptation.
Think about what the organization has been teaching these engineers, often for years. The engineer who speaks up and proposes a solution takes a risk. If the solution is wrong, they own the failure. If the solution is right but wasn't what was specified, they may still own the failure. The engineer who waits to be told exactly what to build, builds exactly that, and asks what to do next — that engineer is never wrong.
Waiting works. And so engineers learn to wait.
Something in their history — a failed initiative, a layoff, a project that got credited to someone else, a solution they proposed that was ignored — taught them that the safest move is to stay in their lane and execute their assignment. That lesson calcified. And now it runs automatically, below the level of conscious decision-making.
This is not laziness. This is learned helplessness — a self-preservation instinct that was once, in some environment, exactly the right response.
The implications for managers are significant.
You cannot talk engineers out of a lesson their environment taught them. Telling them to speak up, to think like owners, to take initiative — these instructions land in an environment that has not changed, delivered by a manager who may or may not still be there in six months. The rational response is to nod and wait to see if anything actually changes.
The manager who understands this does not start with the engineers. They start with the environment.
What would it look like if initiative were rewarded instead of risky? What would it look like if engineers could see the direct connection between what they built and what it caused — if the feedback loop actually closed? What would it look like if the work were framed as a problem to solve rather than a specification to execute?
Those are the conditions that produce a different kind of engineer. Not a different person — the same person, operating inside different conditions, having a different experience of what their work can produce.
The passive engineer is a message, not a verdict.
When you look at a team where nobody speaks in refinement, where every story is a 3 or a 5, where engineers message you to ask what to pick up next — you are not looking at people who cannot do better. You are looking at people who have learned, accurately, that doing better was not what was being asked of them.
The system produced the behavior. The system can be changed.
Not the whole system — you cannot fix how your organization budgets, how leadership sets scope, or how your release process works. But you can change how your team relates to those things. You can create conditions where asking why becomes the natural first response to an unclear situation. Where engineers develop the habit of thinking in problems instead of tasks.
That is the work. It is slow, it is unglamorous, and it is worth doing.
I wrote a book about how to do it.
Getting Engineers to Give a Damn: A Manager's Guide to Building Ownership Inside Broken Systems is a practical guide for engineering managers inside large, constrained organizations — banks, regulated industries, and anywhere that adopted the rituals of Agile while keeping the infrastructure of waterfall.
It covers why passivity happens, what product thinking actually looks like in practice, how to earn the credibility that precedes autonomy, and how to sustain a culture of ownership when the organization is always, in some way, working against it.
It was written by someone still inside the machine.
Top comments (0)