DEV Community: Daniel Holt

What I’ve Learned in 90 Days of Writing About Engineering Management

Daniel Holt — Tue, 21 Jul 2026 13:11:25 +0000

I started this publication because I had something to say and no good place to say it.

Not a complaint. Not a rant. A real observation about a real problem that I had spent nearly two decades watching play out across two organizations, two Agile transformations, and more refinement sessions than I can count. The observation was this: engineers are not passive by nature. They are made passive by the systems they work inside. And most of the people in a position to change that don’t understand what they’re actually looking at.

I wrote a book about it. Then I started writing here. And ninety days in, here is what I have learned.

The Response Surprised Me

I expected indifference. What I got was recognition.

Not from everyone. Reddit, where I posted early on, has a particular kind of reader who engages primarily to challenge, dismiss, or score points. I learned quickly that the communities most likely to respond to my content were also the communities most likely to detect AI assistance in the writing and use that as a reason not to engage with the ideas. That was frustrating in ways I did not fully anticipate.

But underneath the noise, something else was happening. The comments that mattered — the ones from managers and engineers who said “this is exactly what I’ve been trying to articulate” — told me something important. The problem I’m writing about is not niche. It is widespread. The engineers sitting silently in refinement sessions, the Agile transformations that produced ceremonies without conditions, the passive behavior that gets blamed on individuals rather than systems — these are not edge cases. They are the norm in large organizations across the industry.

People recognized the problem immediately because they are living it.

I Am Writing From the Inside

One thing I want to name directly, because I think it matters for how you read what I write here.

I was an engineer before I was a manager. I have sat in the refinement sessions on both sides of the table. I have been the engineer who stayed quiet because the environment taught me that initiative was risky. I have been the engineer who finally spoke up because I realized that if I didn’t say something, nobody was going to. I have written the user stories, run the standups, navigated the change control processes, and lived through the transformations.

I am not writing about engineers from the outside. I am writing from inside the experience — as someone who became a manager without losing the engineer’s perspective, and who manages teams today the way I wish I had been managed when I was an individual contributor.

That is a different vantage point than a people manager who learned about engineering culture from a framework. I do not say that to dismiss people managers — I say it because I think it explains why some of what I write lands differently than the typical management content you might read elsewhere.

Building the Audience Has Been Harder Than Expected

I am someone who reads. A lot. I consume writing about engineering management, product thinking, organizational culture — and I assumed that because I read actively, others would too.

What I found is that the people most likely to engage with writing online are not always the people most likely to benefit from it. The Reddit communities where I posted early had high visibility and low signal. The managers who are quietly struggling — who are sitting in broken refinement sessions and wondering why their engineers won’t engage — are not the ones leaving comments. They are reading and moving on, if they find the content at all.

Getting writing in front of the right people is harder than writing the content itself. I underestimated that.

What I have learned is that the audience builds slowly and then compounds. The subscribers who find this publication and stay are the ones who recognized something real in the first post they read. They are not casual browsers. They are managers who are already in the fight and looking for language for what they are experiencing.

Those readers are worth more than ten times their number in passive visitors. I would rather have thirteen subscribers who actually read every Tuesday than a thousand who subscribed and forgot.

Writing Has Been an Outlet During a Stressful Time

I did not plan this, but it has turned out to be true.

I started this publication during a period of real organizational uncertainty. New leadership. Questions about how a product team fits into the current structure. Conversations about Lean Six Sigma. Engineers who are anxious about losing the way they work.

Writing about these things — turning the frustration and the uncertainty into something structured and shareable — has given me a way to process what is happening that I did not have before. The act of articulating the problem clearly enough that a stranger could understand it has helped me understand it better myself.

That is not why I started writing. But it is one of the things I have gotten from it.

The Frustration Is Real and It Is Widespread

The most important thing I have learned in ninety days is something I suspected but did not fully understand until I saw the response.

People are frustrated because leaders are not listening.

Not in a vague, general sense. In a specific, daily sense. The engineers who have been through Agile transformations that produced ceremonies without autonomy. The managers who have built something real and watched the organization try to standardize it into something hollow. The practitioners who know exactly what is wrong and have no language that their leadership will hear.

They are reading this because it gives them words for what they already know. And they are frustrated because the people who need to hear it are not the ones reading it.

That gap — between the practitioners who understand the problem and the leaders who have the power to address it — is the real problem underneath everything I write about. It is why passive engineers stay passive. It is why Agile transformations fail. It is why the conditions that produce ownership are so rare inside large organizations.

I do not have a solution to that gap. But I think naming it clearly, consistently, and from inside the experience — is worth doing.

That is why I am still writing.

What Comes Next

The content calendar runs through the end of August. There are more posts coming about refinement sessions, leadership conversations, what good actually looks like in practice, and how to sustain a culture of ownership when the organization is always, in some way, working against it.

If you have been reading and finding it useful — thank you. If you have been reading and have a situation you want me to write about, reply to this email and tell me. The best posts come from real problems, and the real problems are the ones you are actually dealing with.

If you have been on the fence about a paid subscription — the practical posts, the templates, the diagnostic tools — use code JULY20 for 20% off the book through July 31. The link is below.

The fight is worth having. Keep having it.

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

The Engineer Who Stopped Waiting

Daniel Holt — Tue, 14 Jul 2026 13:15:19 +0000

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 →

The Question Nobody Asks Before Writing a User Story

Daniel Holt — Wed, 08 Jul 2026 18:59:49 +0000

There is a question that almost never gets asked before a team writes a user story. It is not a technical question. It is not a product question. It is not even a difficult question.

It is this: how does this story fit into where the system is going?

That question sounds simple. In most teams it never gets asked — because most teams have learned to treat each story as a discrete unit of work with a beginning, a middle, and an end. The ticket arrives. The acceptance criteria get written. The story gets estimated. The work begins. And somewhere in that process, the connection between this specific piece of work and the larger thing the team is trying to build quietly disappears.

The result is a backlog full of stories that each make sense individually and don’t quite add up to anything together. Features that work but don’t compound. Improvements that land but don’t move the number. A team that is busy and not building anything.

The Template That Hides the Problem

The “As a user, I want... so that I can...” format was designed to keep stories connected to user value. The “so that” clause is supposed to answer the why — not just what the feature does, but what it enables.

In practice, the “so that” clause almost never does that work.

Watch what happens in a real refinement session. Someone reads the story aloud. The “so that” clause gets recited — so that I can view my account balance — and nobody asks whether that clause actually explains why this story matters, whether it connects to anything the team has agreed they are trying to accomplish, or whether building this thing moves the system closer to where it needs to go.

The template creates the appearance of a why without requiring anyone to think about one. And because the appearance is there, the question doesn’t get asked.

The North Star

The question that changes this is not about the individual story. It is about the system.

Every team should be able to answer: where is this system going? Not in terms of the roadmap — roadmaps change. Not in terms of the next release — releases come and go. But in terms of the fundamental thing this system is supposed to become, the problem it is supposed to solve at its best, the user it is supposed to serve when everything is working the way it should.

That is the North Star. And it is what makes individual stories meaningful or meaningless.

A story written without reference to the North Star is a ticket. It describes a change to the system. It has acceptance criteria. Someone can build it. But it does not answer the question of whether building it moves anything that matters.

A story written with the North Star in mind is something different. The engineer who writes it knows not just what it does but why it belongs in the sequence. They can explain how this piece connects to the larger thing. They can make decisions during implementation when something unexpected comes up — because they understand what they are trying to build, not just what the ticket says.

That engineer does not need to ask their manager what to do when the edge case appears that the story didn’t account for. They already know what direction the system is supposed to move. They make the call that gets it there.

What This Looks Like in Practice

Here is the difference between a story written in isolation and a story written with the North Star in mind.

Without the North Star:

As a user, I want to see my recent transactions on the dashboard so that I can review my account activity.

That story is not wrong. It describes a real feature that a real user might want. But it contains no information about why this feature belongs in the sprint, what it connects to in the larger system, or what success looks like beyond “the feature exists.”

An engineer who builds this story has completed a ticket. They have added a feature. They have no way of knowing whether what they built moved anything that matters — because nothing in the story told them what matters.

With the North Star:

As a user, I want to see my recent transactions on the dashboard so that I can identify unexpected charges without navigating away from the main view — reducing the friction that currently causes users to abandon the session before completing their intended action.

Now the story has a why that connects to something real. The engineer building it understands that the goal is not just to display transactions — it is to reduce session abandonment at a specific point in the flow. They know what success looks like. They can make decisions during implementation that serve that goal. And when they present it in the sprint review, they have something to show beyond a feature — they have a hypothesis about what this change will do to the number.

The Question to Ask in Refinement

The simplest way to introduce the North Star into your refinement sessions is to ask one question before every story gets written or reviewed:

“How does this fit into where the system is going?”

That question will be uncomfortable the first few times. Engineers who have been writing stories in isolation for years will not have an immediate answer. Product owners who have been focused on the immediate roadmap will have to think about it. The scrum master will look at you like you’ve added something to the process.

Let the discomfort sit. The answer to that question is what separates a story from a ticket.

If nobody in the room can answer it — if the team cannot articulate how this piece of work connects to the larger thing they are building — that is information. It means the story is not ready to be written yet. It means there is a conversation that needs to happen before the acceptance criteria get defined.

That conversation is not overhead. It is the work.

What Changes When the Team Has a North Star

When engineers understand where the system is going — when they can see the connection between this ticket and the outcome the team is working toward — three things change.

They make better decisions during implementation. The unexpected edge case, the design choice that the story didn’t specify, the tradeoff between two valid approaches — all of these get resolved faster and better when the engineer knows what direction the system is supposed to move. They are not guessing. They are navigating.

They ask better questions in refinement. The engineer who understands the North Star does not just ask clarifying questions about the acceptance criteria. They ask questions about fit — does this approach get us closer to where we’re going, or does it solve the immediate problem in a way that creates friction later? Those questions change the conversation from execution planning to problem solving.

They write stories that compound. A backlog built around a North Star has a shape. Each story moves the system in a direction. The features accumulate into something rather than just accumulating. And over time the team develops a mental model of the problem space that makes them genuinely difficult to replace — because they understand not just what the system does but what it is becoming.

That is the difference between a team that is closing tickets and a team that is building something.

The Question Worth Asking

Before your next refinement session, try this.

Pull up the first story on the agenda. Before anyone talks about acceptance criteria or estimation or implementation approach, ask the room: how does this fit into where the system is going?

See what happens.

If the room can answer it clearly and quickly, you have a team that is already thinking in terms of the North Star. The refinement session that follows will be more focused, the stories will be better, and the sprint review at the end will have something real to show.

If the room goes quiet — if people look at each other and reach for the template instead of the answer — you have found the gap. And you have found the conversation that needs to happen before the story gets written.

That conversation is where product thinking starts. It is also where the most engaged engineers begin to separate themselves from the ones who are just closing tickets.

The question nobody asks is the one worth asking first.

If this resonated, the thinking behind it goes deeper in my book — Getting Engineers to Give a Damn: A Manager’s Guide to Building Ownership Inside Broken Systems. Written for managers inside large, constrained organizations who are tired of backlogs that don’t add up to anything.

What Psychological Safety Actually Looks Like in Practice

Daniel Holt — Wed, 08 Jul 2026 18:56:53 +0000

Psychological safety has become one of those phrases that gets used so often it has stopped meaning anything specific. Teams talk about it in retrospectives. Managers put it in their leadership principles. Consultants build frameworks around it.

Most of what gets said about it focuses on the same thing: are people willing to speak up? Will they admit mistakes? Will they disagree with someone senior in a meeting without fear of consequences?

Those things matter. But they are not the most useful signal.

The most useful signal of psychological safety on an engineering team has nothing to do with what happens in the meeting. It has to do with what happens before it.

The Thing That Tells You Everything

Pull up a story in refinement. Watch what happens.

In a team without psychological safety, the story appears on the screen and the room waits. Nobody has seen it before. The scrum master reads it aloud. Silence. A clarifying question gets asked. Another one. The conversation starts from zero because everyone is starting from zero — nobody looked at it before they walked in.

In a team with psychological safety, something different happens. Someone has a question ready. Someone else has already identified a dependency. A third person has a concern about the approach that they formed before the meeting started. The conversation begins in the middle rather than at the beginning because people came prepared to have it.

That preparation is the signal.

An engineer who looks at the sprint board before a refinement session has made a bet. They invested time and mental energy before anyone asked them to. That investment only makes sense if they believe it will pay off — if they believe the meeting is going to be a real conversation, that their preparation will matter, that showing up ready is going to be worth something.

That belief is psychological safety expressed as behavior.

It is not “I feel safe to speak up.” It is something more fundamental: “I believe this environment is worth investing in.”

The Misconception Worth Naming

Most managers think psychological safety means being nice. No conflict, no critical feedback, no hard conversations. A team where everyone feels comfortable and nothing is ever uncomfortable.

That is not psychological safety. That is conflict avoidance dressed up in better language.

Real psychological safety is not the absence of discomfort. It is the presence of trust — trust that the discomfort is worth it, that engaging with a hard problem will produce something useful, that a mistake will be treated as information rather than evidence of failure.

A team with genuine psychological safety can have a sharp disagreement in refinement about the right approach and leave the meeting aligned and energized. A team without it will have no disagreement at all — and leave the meeting having agreed to something nobody actually believed in, because the cost of saying so felt too high.

The silence that looks like harmony is often the most dangerous thing in the room.

How Preparation Becomes Self-Reinforcing

Engineers do not show up prepared because you tell them to. They show up prepared because they have seen that preparation works.

Here is what that looks like in practice.

A refinement session with five stories on the agenda. Everyone has looked at the board before the meeting. The first story gets pulled up and someone already has a question. The question gets answered. The next story. Someone has identified a dependency. It gets discussed. The story gets refined. Third story, fourth story, fifth story — the meeting moves.

With twenty minutes left on the clock, you are done.

That twenty minutes is the return on investment. It is immediate, tangible, and felt by everyone in the room. Not in the abstract — in their calendar. They have twenty minutes back in their day that they did not expect to have.

Engineers are rational. When preparation produces time back, they prepare. Not because it is the professional thing to do. Because it works.

The next refinement session, a few more people show up having looked at the board. The session moves faster. More time back. The session after that, a few more people. The behavior compounds because the reward is real and it is immediate.

You do not have to manufacture the incentive. The meeting itself is the incentive. Your job is to make sure the meeting is worth preparing for.

What Makes a Meeting Worth Preparing For

An engineer will look at the stories before a refinement session if they believe the following things are true:

Their preparation will be used. If they come in with a question and nobody engages with it — if the scrum master plows through the agenda and the questions get deferred or dismissed — they will not prepare next time. Preparation has to produce something in the room.

The meeting will be a real conversation. If refinement is a walkthrough where the scrum master reads stories and engineers nod, there is nothing to prepare for. The meeting is not asking anything of them. Preparation only matters if the meeting requires thinking.

The stories will be ready to refine. If the team consistently pulls up stories that are not ready — vague requirements, missing context, no clear definition of done — preparation becomes frustrating rather than rewarding. You can think about a story all you want before the meeting and still not be able to do anything useful with it in the room.

All three of these conditions are in your control. The stories you bring to refinement, the way you run the meeting, the way you respond to preparation when you see it — these are the conditions that make preparation rational or irrational for your engineers.

How to Signal That It Matters Without Making It Weird

You do not need to call out preparation explicitly. You do not need to praise the engineer who had a question ready or single out the one who clearly looked at the board. Making it feel like a gold star undermines the point — preparation should be the norm, not a performance.

What you do instead is let the meeting speak for itself.

When refinement moves well — when stories get refined efficiently, when the conversation is substantive, when the team gets out early — that outcome is its own signal. Everyone in the room knows why it happened. They felt the difference. The engineer who prepared knows their preparation contributed to that. The engineer who did not prepare knows it too.

The meeting that finishes early because everyone was ready feels completely different from the meeting that drags because nobody was. The energy is different. People leave with momentum instead of exhaustion. That feeling is more powerful than any recognition you could give.

And then — simply, genuinely, without ceremony — you tell the team you appreciate getting the time back.

Not “great job preparing everyone.” Not a performance review moment. Just: I noticed, I appreciated it, thank you.

That is enough. It lands because it is real. Engineers can tell the difference between a manager performing gratitude and a person acknowledging something that actually mattered to them.

The Environment That Produces This

Preparation before a meeting is a downstream effect. It does not happen because you ask for it. It happens because the environment has taught engineers that engagement is worth it.

That environment has a few consistent characteristics.

Stories arrive at refinement ready to be discussed — not vague, not missing context, not half-formed ideas that need another meeting before they can be refined.

Questions get real answers. When an engineer asks something in refinement, the answer is substantive — not “we’ll figure that out in the sprint” or “let’s take that offline.” The question gets engaged with in the room.

The meeting requires something from the engineers. Not passively watching a scrum master read stories — actively thinking, asking, proposing, deciding. The meeting asks for their judgment and uses it.

And when the meeting goes well because everyone showed up ready — when the team gets time back because the preparation paid off — that outcome is acknowledged. Not effusively. Just honestly.

Build that environment consistently and the preparation will follow. It is not a culture initiative. It is not a values exercise. It is a rational response to a meeting that is worth preparing for.

That is what psychological safety actually looks like in practice. Not the absence of fear. The presence of a belief that the work is worth investing in.

Why Your Sprint Review Is a Waste of Everyone’s Time

Daniel Holt — Wed, 08 Jul 2026 18:52:48 +0000

There is a meeting that happens at the end of every sprint in almost every engineering organization that runs Agile. It is called the sprint review. It is supposed to be where the team demonstrates what they built, gets feedback from stakeholders, and connects the work to the outcomes the business cares about.

In practice, it is usually a show-and-tell where engineers describe their tickets to people who would rather be somewhere else.

You can tell within the first two minutes whether a sprint review is going to be useful. If the person presenting hasn’t planned what they’re going to say, the meeting spirals quickly into narration. Someone opens a ticket. They explain what it does. They show a screenshot. They move to the next ticket. Words accumulate. Time passes. Nobody in the room — including the people who built the thing — can clearly articulate what value was just delivered.

The business partners sitting across the table learn something from that meeting. They learn that sprint reviews are where you go to watch engineers describe their work. Not where the needle moves. Not where decisions get made. Just a ceremony they have to attend.

That is not a sprint review problem. It is a preparation problem. And the preparation problem is actually a thinking problem — because a team that cannot prepare a clear sprint review is a team that has not clearly defined what value they were trying to deliver in the first place.

Start With the Hypothesis

The most important thing that happens in a well-run sprint review happens before the meeting starts.

Someone on the team — ideally the engineer who did the work, supported by the PM — should be able to complete this sentence before the review begins:

“We believed that if we did X, we would see Y — and here is why we believed that.”

That sentence is the spine of the entire presentation. Everything else hangs off it.

Here is a concrete example of what this looks like in practice. A team working on API reliability identifies that a significant number of failed requests are transient — the kind of failure that would succeed if tried again. They form a hypothesis: if we retry failed API requests up to three times within a ten-second window, we will increase the number of successful responses by at least 25%.

That hypothesis does several things at once. It tells the stakeholder what problem the team was solving. It gives them a number to react to — 25% is either meaningful or it isn’t, and the stakeholder probably knows which. It sets up the rest of the presentation as a test of a specific claim rather than a tour of completed work.

Start here. Every sprint review should open with the hypothesis. What did we believe, what were we trying to prove, and why did we think it mattered?

Then Show What You Observed

After the hypothesis comes the evidence.

What did you actually find? Did the metric move the way you expected? More? Less? In a direction you didn’t anticipate?

This is where the sprint review becomes a real conversation rather than a presentation. A number that moved the way you expected is a confirmation — the hypothesis held, the approach worked, here is what we want to try next. A number that moved less than expected is a signal — something about the assumption was wrong, and now you have real data to figure out what. A number that moved in an unexpected direction is the most interesting outcome of all — it means you learned something you didn’t know you were going to learn.

Business partners do not come to sprint reviews to watch engineers demonstrate features. They come because they care about outcomes — whether the product is moving in the right direction, whether the investment is producing results, whether the decisions they made six weeks ago are holding up. The evidence section is the only part of the sprint review that speaks directly to those questions.

Name the number. Show where it was at the start of the sprint. Show where it is now. Let the room react.

Then Explain the How

Only after the hypothesis and the evidence do you show what you built.

This is the inversion most sprint reviews get wrong. They start with the how — here is what we built, here is how it works, here is a demo — and treat the outcome as an afterthought, if it gets mentioned at all. The result is a presentation that answers a question nobody was asking: how does this work? Instead of the question everyone in the room actually has: did it work?

When you lead with the hypothesis and the evidence, the how becomes the explanation of the method rather than the point of the meeting. You built the retry logic because you believed transient failures were recoverable. Here is how it works. Here is what the implementation looks like. Here is what we had to navigate to get it there.

The how section is where the engineers get to show their craft. But it lands differently when the audience already knows the outcome. They are not watching a demo and wondering whether it matters. They already know it matters — they just saw the number — and now they are watching to understand how you got there.

Name the Caveats Before Someone Else Does

There is a moment in almost every sprint review demo that derails the conversation. It is not a technical problem. It is a test data problem.

A stakeholder notices something on the screen that looks wrong. Account X has a negative balance. The timestamp is from 2019. The user’s name is “Test User 47.” They raise it. The engineer explains it. Five minutes disappear. The thread of the presentation is lost and it takes another five minutes to get it back.

This is entirely preventable.

Before the demo, identify everything in the test environment that might look wrong to someone who doesn’t know your data setup. Name it explicitly at the start of the demo section, before anyone has a chance to notice it themselves:

“You’ll notice that some accounts in this environment have negative balances — that’s an artifact of how our test data is structured, not a bug in the feature we’re showing. I wanted to flag it so it doesn’t distract from what we’re demonstrating.”

That one sentence does three things. It shows you prepared. It preempts the distraction. And it signals to the stakeholder that you have thought carefully about what they are going to see — which is exactly the kind of attention to detail that builds trust over time.

Name the caveats before someone else finds them for you.

The Structure That Works

A sprint review that does its job follows a simple four-part structure:

The hypothesis What did we believe, what were we trying to prove, and why did we think it mattered? One or two sentences. This is where you orient the room before anything else happens.
The evidence What did we observe? Show the number. Show where it was, show where it is, let the room react. This is the most important part of the meeting and it should happen early.
The how What did we build? How does it work? This is the demo section — but it comes after the outcome, not before it.
The caveats What might look wrong in the demo that isn’t actually wrong? Name it before someone finds it.

That structure takes no more time than the narration format most teams default to. It takes more preparation — someone has to think carefully about the hypothesis before the meeting, and someone has to know the evidence before they walk into the room. But that preparation is the point. A team that cannot prepare a sprint review in this format is a team that has not done the thinking that should precede the demo.

The sprint review is not the problem. It is the diagnostic.

What to Do Before Your Next One

Before your next sprint review, ask the team one question:

“What did we believe at the start of this sprint, and what did we learn?”

If nobody can answer it, the review is going to be a narration. The work may have been done well. The value is invisible.

If someone can answer it — if there is a hypothesis and a result and a team that understands the connection between the two — you have a sprint review worth running.

The preparation takes fifteen minutes. The difference in the room is everything.

If this resonated, the thinking behind it goes deeper in my book — Getting Engineers to Give a Damn: A Manager's Guide to Building Ownership Inside Broken Systems. Written for managers inside large, constrained organizations who are tired of sprint reviews that go nowhere.

Why I Wrote This Book

Daniel Holt — Wed, 08 Jul 2026 18:48:18 +0000

I am writing this from inside the problem.

Not as someone who figured it out, left, and wrote a book about what they learned on the way out. As someone who is still managing teams, still navigating the constraints, still watching the same patterns play out that I have watched play out for the better part of two decades — and still believing that something can be done about them from inside, even when the organization is working against it.

Here is what is happening right now, at my current job, as I write this.

My teams have been successful. We work as a product team — oriented toward outcomes, thinking in problems rather than tasks, delivering consistently and showing the results. The kind of culture this book describes. And the reward for that success is that leadership is considering reassigning some of my engineers to help teams that cannot get their projects done.

The logic is rational from the outside: your team gets things done, these other teams are struggling, redistribute the talent.

What gets missed is the reason my team gets things done. It is not the engineers themselves — it is how we work. The conditions we built. The way requirements get framed as problems, the way outcomes get named before work begins, the way engineers are expected to think rather than just execute. Move those engineers into a project-thinking environment and the conditions disappear. The engineers adapt to their new environment, the way people always adapt to their environments. The thing that made them effective stops being possible.

And here is the part that makes it worse: the engineers who are most likely to get reassigned are the ones who look most compatible with a project-thinking team. The passive ones. The ones who are still in the process of becoming hunters. The ones who need the conditions most.

I have watched this happen before. It is the same mistake, made again, by people who see the output and not the journey.

I started my career as a mainframe developer at a national bank. I spent nineteen years there, working on teams across the full stack — mainframe, internal applications, customer-facing web, partner APIs. I watched the organization go through an Agile transformation. I watched the pilot work because it was set up to work — cross-functional, empowered, given a real problem to solve. I watched the organization scale the rituals instead of the conditions, forcing mainframe teams to run two-week sprints on quarterly release cycles, layering Agile ceremonies on top of waterfall budgets.

I watched engineers learn to perform Agile rather than practice it. To write user stories for work that had no user. To run retrospectives where nobody said what they were actually thinking. To wait to be told what to build because initiative had become dangerous in an environment that said it valued initiative.

Then I joined a second bank and watched it happen again.

Not because the people were different. Because the system was the same.

The thing I hear most often from engineering managers is some version of this: “Agile works — just not the way our organization implemented it.”

They are right. And they are more alone than they should be.

Agile was designed to give engineers autonomy, fast feedback loops, and the ability to adjust based on what they learn. It was designed by practitioners who understood what good engineering work actually requires. What gets implemented at most large organizations is something else entirely — the ceremonies without the conditions, the vocabulary without the values, the appearance of agility without any of the substance.

And the people who pay for that gap are the engineers. They get all the overhead of Agile — the standups, the story points, the retrospectives — with none of the autonomy that makes it meaningful. They get trained, slowly and systematically, to wait. To stay in their lane. To do what they’re told and survive.

The transformation gets designed by people who don’t deliver. It gets forced on the people who do. And then the people who designed it wonder why the engineers aren’t more engaged.

I wrote this book because I wanted engineering managers to have something I did not have when I needed it most.

Not a framework. Not a methodology. Not another set of ceremonies to layer on top of the ones that aren’t working.

A map. Written by someone who has been inside the machine long enough to know where the walls are — and where the doors are, if you know how to find them.

The book is called Getting Engineers to Give a Damn. It is for engineering managers inside large, constrained organizations — banks, regulated industries, anywhere that adopted the rituals of Agile while keeping the infrastructure of waterfall. It is practical and it is honest and it does not pretend the system is going to change.

What it does say is this: the system does not have to change for your team to work differently inside it. You can build a culture of ownership even when the organization is working against you. It takes longer than you want and it is never finished and the organization will always be trying to undo it.

But it is possible. I know because I am doing it right now, in the middle of a reorganization that is trying to take it apart.

The engineers on my teams are not beaten down. They show up to refinement having thought about the problems. They ask why before they ask how. They help each other without being asked because they understand that the sprint goal belongs to all of them. They are proud of what they build.

That did not happen because of a transformation initiative. It happened because someone decided to create conditions where it was possible — and kept creating them, sprint after sprint, even when the organization pushed back.

I wrote this book for the managers who are making that same decision. The ones who know the ceiling is higher than the organization believes, and who show up every day committed to proving it.

If that is you — the book is here.

The Engineer Who Waits and the Engineer Who Hunts

Daniel Holt — Wed, 08 Jul 2026 14:22:07 +0000

I manage two teams. They are structured almost identically — same size, same roles, same tools, same access to leadership, same business domain. They receive the same inputs and operate under the same constraints.

One of those teams has a conversation. The other one waits.

I have watched this contrast play out week after week for long enough to be certain it is not about talent, intelligence, or motivation. The engineers on both teams are capable. The difference is something else entirely — something in how they relate to the work, how they think about their role, and what they believe their job actually is.

I call it the difference between project thinking and product thinking. And it shows up most clearly when something goes wrong.

Imagine a message comes in from a user: the app feels slow.

Two engineers receive the same information at the same time.

The first engineer — the one who waits — reads the message and opens their task manager. There is no ticket. They check Slack to see if anyone is discussing it. There is some noise but no clear direction. They wait for someone to file a ticket, assign it, and tell them where to look. When the ticket arrives, it says “investigate performance issue.” They start there and not a moment before.

The second engineer — the one who hunts — reads the same message and opens a dashboard. They start looking. Where is the slowness? Is it one endpoint or many? Is it consistent or intermittent? When did it start? Is there a deployment in the last 24 hours that correlates with it? Before anyone has filed a ticket, they have a hypothesis. By the time the ticket arrives, they have already narrowed the problem to two possible causes and ruled out four others.

Same message. Same information. Completely different response.

The waiting engineer is not lazy. They are not indifferent. They have simply learned, somewhere along the way, that moving without a ticket is risky. That if you investigate something nobody asked you to investigate, you might spend time on the wrong thing, or surface a problem that creates more work, or step on someone else’s territory. The safest move is to wait for explicit direction and then execute within it.

The hunting engineer has learned something different. They have learned that the ticket is not the starting gun — it is a lagging indicator. By the time a performance problem becomes a ticket, it has already been slow for a while. Users have already been frustrated. The engineer who waited for the ticket is always solving yesterday’s problem. The engineer who started looking is solving today’s.

The difference between these two engineers goes deeper than work style. It is a difference in mental model.

The waiting engineer treats each task as a discrete, isolated unit. A message comes in, a ticket gets created, the ticket gets worked, the ticket gets closed. There is no accumulated context, no growing understanding of the system, no pattern recognition that carries from one problem to the next. Each problem arrives fresh and gets handled in isolation.

The hunting engineer is building something different — a mental model of the product, the users, and the system that grows more accurate with every sprint. When the “app feels slow” message arrives, they are not starting from zero. They know which parts of the system have been under stress lately. They know which recent changes touched performance-sensitive code. They know which users tend to report problems first and what their usage patterns look like. The new problem lands in a context that makes it immediately interpretable.

This is what product thinking actually means in practice. Not enthusiasm. Not initiative as a personality trait. A mental model of the problem space that compounds over time.

The question I get asked most often when I describe this contrast is: can a waiting engineer become a hunting engineer?

The answer is yes. But not through explanation.

You cannot tell an engineer to think differently. Telling someone to “think like an owner” or “take more initiative” lands in the same environment that produced the waiting behavior in the first place. If that environment has not changed, the instruction will not change the behavior. They will nod and wait for the next ticket.

What changes the behavior is changing what the environment rewards.

When an engineer investigates a performance problem before being asked and their investigation turns out to be useful — when that initiative is recognized, attributed to them specifically, and treated as exactly the kind of thing the team does — they learn something. The model updates. Looking is safe here. Looking is valued here. Looking is what this team does.

That learning does not happen from a conversation. It happens from experience. Your job as a manager is to create the conditions where the experience is possible.

There is a moment I have seen happen more than once that I think of as the turning point.

An engineer ships a small change. It is not a big feature — a query optimization, a caching adjustment, something that took a day. The metric moves. Response times drop. User complaints stop. And the engineer who wrote the change watches it happen in real time on a dashboard the team built together.

Something shifts in how they hold themselves after that moment. Not dramatically. But visibly.

They built something small and watched it matter. The connection between what they did and what it caused was immediate and undeniable. And that experience — not a conversation, not a performance review, not a values statement on a wall — is what starts turning a waiting engineer into a hunting one.

The engineer who hunts is not a different kind of person. They are the same engineer, having had a different experience of what their work can produce.

Your job is to create the conditions where that experience is possible. Everything else follows from there.

Getting Engineers to Give a Damn: A Manager’s Guide to Building Ownership Inside Broken Systems goes deeper on how to build those conditions — inside large, constrained organizations where the system is working against you.

The Agile Lie

Daniel Holt — Tue, 07 Jul 2026 14:27:26 +0000

Most large organizations did not adopt Agile. They adopted the appearance of Agile.

There is a difference, and it matters enormously — because the engineers sitting in your standups, writing user stories, and estimating in story points can feel it. They feel it every single day. And it is a significant part of why they stop caring.

Here is what actually happened at most large companies that went through an “Agile transformation.”

Leadership decided the organization needed to move faster. Competitors were ahead. Something had to change. The answer, almost universally, was Agile. A consulting firm was brought in. There was a presentation. There was enthusiasm about “ways of working.”

Then came the pilot.

The pilot team was set up carefully — cross-functional, empowered, given an actual problem to solve rather than a list of requirements handed down from a business analyst. They had access to the people they needed. Obstacles were removed in real time.

Of course it worked.

A self-contained team with every skill it needs, empowered to solve a real problem, with obstacles actively removed — that team is going to deliver. That is not a controversial statement. That is just what happens when you create the conditions for good work.

The problem came next. When the pilot succeeded, leadership decided to scale it. But what they chose to scale was not the conditions that made the pilot work.

It was the rituals.

The two-week sprints. The story points. The standups. The retrospectives. Every team in the organization was going to do Scrum — including the teams for whom Scrum made no sense whatsoever.

I watched this happen firsthand at a national bank. The mainframe engineering teams — disciplined, careful teams doing procedural work with quarterly release cycles and months-long testing processes — were told they were going to run two-week sprints.

At the end of each sprint, they were expected to demonstrate “working software” and deliver “value.” But the software was not going to reach production for another two and a half months, minimum. The feedback loop that makes Agile meaningful — build something, ship it, watch it perform, learn, adjust — simply did not exist for these teams.

So what did they do? They did what rational people do when forced to perform in a system that doesn’t fit their reality: they performed. They learned to write stories that demonstrated “value” on paper. They crafted “As a user, I want...” statements for backend infrastructure work that no user would ever directly touch. They held ceremonies that felt meaningless because they were meaningless in that context.

Meanwhile, I was on a team building APIs for the bank’s credit card partners. Two-week sprints made sense for us. We could build quickly. Pipelines existed. The consulting firm’s playbook fit our work.

But we had our own version of the trap.

All of our credit card data lived on the mainframe. Any change touching that data required a deployment from the mainframe team — the team that released quarterly. We could build in two-week sprints. We just couldn’t always release.

What this produced was not a failure of process. It was a new and exhausting form of project management that nobody had planned for. Before anyone could begin a piece of work, the first question was always: does this change touch the mainframe? If yes, it had to be scheduled around a quarterly release window. If no, it could proceed — but carefully, because releasing the wrong thing at the wrong time meant shipping something incomplete or breaking a dependency that hadn’t landed yet.

So the team’s energy — the energy that was supposed to go into building and solving problems — went instead into dependency mapping. Sorting changes into buckets: mainframe or not, ready or waiting, safe to release or hold. The cognitive overhead of managing that inventory was invisible work. It never showed up in a velocity chart. It never surfaced in a retrospective.

It was just the constant background hum of a team doing Agile ceremonies on top of a waterfall dependency structure.

This is what I mean by the Agile lie. Not that Agile is wrong. Not that the consultants were frauds. But that most large organizations import the ceremonies of Agile while preserving the infrastructure of waterfall.

And the most important piece of waterfall infrastructure is the budget.

Finance departments at large companies have not figured out how to budget for true Agile development. They budget for projects. They have deadlines. They have annual planning cycles that define what gets funded, for how long, and with what expected deliverable. These constraints do not disappear because engineering teams start calling their work “sprints” instead of “phases.”

What you end up with is teams working in two-week sprints, running standups, estimating in story points — and implementing projects that were defined by leadership six months ago, with fixed scope and fixed deadlines.

The engineers are doing Scrum. The organization is still doing waterfall. These two things are in direct conflict. And the engineers feel that conflict every single day.

There is a layoff that happened during that first transformation that I think about often.

The Agile rollout happened at the same time as a significant restructuring. Engineers had to bid for their own jobs. There was a day where people sat at their desks and waited. You would watch a colleague get tapped on the shoulder and escorted to HR. By the end of the day, you would find out whether you still had a position.

That day taught every engineer in the building exactly what kind of environment they were now working in.

Stay quiet. Don’t stand out. Do what you’re told and survive.

This is the opposite of ownership. And it happened on the same week everyone was being told to embrace Agile’s values of self-organization, autonomy, and continuous improvement.

The colleagues who were let go were often the ones who had carried the unglamorous work — production support, regulatory maintenance, the labor of keeping systems running. That work did not disappear because the people doing it did. The remaining engineers were expected to deliver new features in two-week sprints and manage the production support burden with reduced headcount.

Retrospectives became performative. Engineers learned that the path of least resistance was to write the story, attend the ceremony, and wait to be told what to build next.

The passivity was not a personality trait. It was a rational adaptation to an irrational system.

One of the consultants from that transformation said something to me that I have never forgotten.

He said: “If your team is doing everything the same way in a year, then we have failed in understanding what Agile’s real benefit is.”

He was right. The real benefit of Agile is not sprints or story points or any ceremony. It is quick feedback loops. Continuous improvement. The discipline of testing things out, watching what happens, and adjusting based on what you learn. It is delivering value to real customers and using their response to guide what you build next.

The organization had looked at his framework and seen a process to install. He had meant it as a mindset to cultivate.

That gap — between Agile as a set of rituals and Agile as a philosophy of learning — is where passive engineers are made.

If you manage engineers inside a large organization and you recognize what I’m describing, the passivity you’re seeing in your team is not a character flaw. It is a message. The system produced the behavior.

The system can be changed — not all of it, but enough. That is what my first post was about, and it is what the book I wrote goes into in depth.

The ceremonies are not the point. The conditions are.

The Passive Engineer Isn't the Problem

Daniel Holt — Tue, 07 Jul 2026 14:25:16 +0000

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.

The Uncertainty Is the Point

Daniel Holt — Tue, 07 Jul 2026 14:14:21 +0000

There is a particular kind of organizational anxiety that doesn’t come from bad news. It comes from no news — from the sense that something is shifting underneath you without anyone saying clearly what it is or where it’s going.

That is where my teams are right now.

New leadership has arrived. There are questions about how a product team fits into the current organization. Lean Six Sigma is being discussed — a methodology that hasn’t been prominent in software engineering conversations for a long time, and one that signals something specific about how the people asking the questions think about engineering work. There are suggestions about getting certified. There is no clear direction.

And my engineers — the ones who show up to refinement having already thought about the problem, who ask why before asking how, who help each other without being asked because they understand the sprint goal belongs to all of them — are afraid.

Not of the work. Not of change in general. Of going back.

What They Are Actually Afraid Of
When I have one-on-ones with my engineers right now, the fear is specific.

They are afraid of not having a backlog. Of losing the product team identity they have built over time and grown into. Of becoming a project team again — receiving requirements, executing tickets, waiting to be told what to build next.

They have been hunters. They know what that feels like. And they can feel the possibility of becoming cogs again, not because they have done anything wrong but because the organization around them is asking different questions than it was before.

That fear is rational. They are not catastrophizing. They have seen enough of how large organizations work to know that the signals matter. When leadership starts talking about Lean Six Sigma and certification programs, they are telling you something about how they think about engineering — as a process to be optimized, not a capability to be developed.

Lean Six Sigma is a serious methodology with real applications. It was built to eliminate waste and reduce variation in repeatable processes. It works well in manufacturing, in supply chains, in contexts where the goal is to do the same thing more efficiently every time.

It is not built for the kind of work a product team does — iterating toward an outcome, forming hypotheses, running experiments, adjusting based on what you learn. Product thinking requires variation. It requires the ability to change direction when the data tells you to. Applying a reduce-variation framework to a learn-and-adapt team is not just a mismatch. It is a direct contradiction.

My engineers can feel that contradiction. They do not have the language for it yet. But they feel it.

What I Am Telling Them
Keep going.

Not as a platitude. Not as false reassurance that everything is going to be fine. But as a strategy.

The work does not stop because the organizational questions are unresolved. The sprint goal is still the sprint goal. The metric we are trying to move is still the metric we are trying to move. The engineer who shows up prepared, asks the right questions, and delivers something measurable is still the most valuable person in the room regardless of what the methodology is called.

And here is the thing that is hard to argue with: positive results.

Numbers do not care about organizational politics. A team that consistently moves the metrics that matter to the business — that reduces fraud losses, increases successful evaluations, improves response times, delivers measurable outcomes sprint after sprint — is a team that is difficult to dismantle. Not impossible. But difficult.

The case for a product team is not made in a meeting about methodology. It is made in every sprint review where a number moved and the team can explain why. It is made in every one-on-one where an engineer surfaces a problem nobody assigned them to find. It is made in the data, accumulated over time, that shows what this way of working actually produces.

That is the evidence that is hard to argue with. And building more of it — right now, in the middle of the uncertainty — is the most important thing the team can do.

What the Uncertainty Is Actually Doing
Uncertainty is not neutral. It teaches people things.

An engineer who watches leadership signal a shift toward process and certification without clear direction learns something. They learn that the environment may be changing. That the things that were valued before may not be valued the same way going forward. That the safest move, until clarity arrives, might be to pull back.

That is the passive engineer being rebuilt in real time. Not because the engineer chose it. Because the environment started teaching the old lesson again.

This is why the manager’s job in a period of uncertainty is not to wait for clarity before acting. It is to keep creating the conditions that produce hunters — to keep naming the outcome before the sprint begins, to keep closing the feedback loop, to keep pressing engineers to lead and playing dumb when they bring problems — so that the team’s identity stays intact while the organizational questions get sorted out.

The culture you built is not a finished thing. It was never a finished thing. It requires ongoing attention and ongoing protection — especially when the organization is shifting underneath it.

The uncertainty is the point. This is exactly when the work matters most.

What Comes Next
I do not know how the reorganization will resolve. I do not know whether Lean Six Sigma will arrive in full, in part, or not at all. I do not know whether my product teams will stay intact or whether engineers will be redistributed to teams that work differently.

What I know is that the results are real. The numbers have moved. The engineers on my teams have become something different than what they were — and that difference is visible in every sprint review, every refinement session, every moment when someone surfaces a problem nobody assigned them to find.

That evidence exists. It is documented. It travels in ways that stories do not.

And when the questions get answered — when the organizational direction becomes clear — a team that kept delivering through the uncertainty is in a much stronger position than one that went quiet and waited.

Keep going. Positive results are hard to argue with.

The fight is worth having.