The Engineer Who Stopped Waiting
I want to tell you about one engineer. Not a composite. Not a hypothetical. A real person on one of my current teams whose transformation from passive to engaged took about a year and happened entirely on his own terms.
I am telling this story because most writing about engineering culture talks about what managers do to change their teams. This story is about what happens when an engineer finds his own reason to change — and what that looks like from the inside.
How He Started
When he joined the bank, he received his work the way a contractor receives a statement of work.
Here is what I mean by that. A contractor comes in, reads the scope, executes the scope, and waits for the next scope. They do not ask why the scope was defined that way. They do not propose alternatives. They do not question whether the scope solves the right problem. That is not what they were hired to do — or so they believe.
He was not a contractor. He was a full-time engineer joining an established team. But he came in with the contractor mindset, and for a specific reason: he did not want to rock the boat.
The team already had its dynamics. The senior engineers had their way of doing things. The processes were established. He was new and he did not yet know enough to have opinions worth sharing — or so he believed. So he kept his head down, took the tickets, did the work, and waited.
For about a year, that is how it went.
The Moment the Calculus Changed
Somewhere in that first year something shifted. Not dramatically. Not in a single meeting where everything changed at once. Gradually, and then clearly.
He started noticing that when he stayed quiet, the decisions that got made were not always the right ones. Not because the people making them were incompetent. Because he had context they did not have — knowledge of how the system actually worked, awareness of a dependency that was being overlooked, a question that nobody was asking that would have changed the direction of the conversation.
And he was not asking it. So it did not get asked. And the decision went the wrong way.
This happened enough times that he could no longer ignore it. The silence he had been maintaining to avoid rocking the boat was itself causing problems. The cost of staying quiet had become higher than the cost of speaking up.
That realization — if I don’t say something, nobody is going to — is one of the most important things an engineer can understand about their role. It is the moment they stop thinking of themselves as a resource executing tasks and start thinking of themselves as someone whose judgment matters. Not because they were told their judgment matters. Because they watched what happened when they withheld it.
What Changed in the Room
The place where the transformation became most visible was refinement.
Refinement sessions are where you can see most clearly who has come prepared and who has not. Most engineers on most teams come in cold — they have not looked at the stories, they do not have questions ready, they are waiting to be walked through the material and told what to do. The scrum master carries the meeting. The silence fills the space between items on the agenda.
He started coming prepared.
Not because anyone asked him to. Because he had started to understand that if he did not come prepared, the conversation would happen without his input — and he had seen enough times what that produced. So he looked at the board before the meeting. He formed questions. He thought about the dependencies and the edge cases and the things that might go wrong. And when the meeting started, he had something to say.
In a room where most people are waiting to be told what to do, the engineer who shows up having already thought about the problem is immediately noticeable. Not because they are performing. Because everyone else can feel the difference between a conversation and a briefing, and this engineer was turning the briefing into a conversation.
What He Looks Like Now
About a year after the transformation started, here is what it looks like from the outside.
Questions get directed to him. Not just questions about his own work — questions about the system, about historical decisions, about why something was built a certain way, about what the right approach is for something new. People go to him because they know he will either have the answer or go find it in a timely manner. That reliability — knowing, finding, following through — is rare and it compounds. Each time he delivers, the next question comes faster.
He has become the team’s institutional knowledge in the best sense. Not the person who hoards information to protect their position. The person who has paid enough attention, for long enough, that they have built a model of the system that is more complete than anyone else’s.
He is not the loudest person in the room. He is the most prepared. And in a room full of people waiting to be told what to do, preparation is the most powerful thing you can bring.
What This Means for Managers
I did not coach him into this transformation. I did not use a technique or apply a framework. I did not manufacture an opportunity or play dumb or point toward a problem.
He got there on his own. And that is actually the point.
The conditions on the team were already there — the outcome orientation, the closed feedback loop, the expectation that refinement was a conversation rather than a briefing. He was surrounded by those conditions for a year before they started to take hold. And then something clicked, and he started using them.
This is what the slow version of the transformation looks like. Not a dramatic moment of intervention. An engineer who gradually realizes that his silence has consequences, and then gradually stops being silent, and then gradually becomes the person the team relies on.
The manager’s job is not always to intervene. Sometimes it is to build the conditions and wait. To hold the environment steady while the engineer finds their own reason to engage. To not give up on someone who is still in the waiting phase because they have not yet found the reason that will move them.
He found his reason. If I don’t say something, nobody is going to.
That is enough. That is everything, actually.
The Broader Pattern
I have seen this pattern more than once. The engineer who comes in quiet, takes the tickets, stays in their lane — and then, at some point, realizes that staying in their lane is itself a choice with consequences.
The transformation is never instant. It is measured in months, not weeks. And it is rarely triggered by a manager intervention. It is triggered by the engineer themselves noticing something — a decision that went wrong, a question that did not get asked, a moment where they could see clearly what their absence was costing.
What the manager can control is the environment that makes that noticing possible. An environment where initiative is rewarded rather than punished. Where speaking up in refinement produces something rather than nothing. Where the feedback loop closes and engineers can see what their work causes.
Build that environment and hold it steady. The engineers who are ready to find their reason will find it.
The ones who are not ready yet are still watching. Give them time.
Getting Engineers to Give a Damn: A Manager’s Guide to Building Ownership Inside Broken Systems is available now. Use code JULY20 for 20% off through July 31. Get it here →
I publish every Tuesday at danielholt.substack.com