DEV Community: Daniel Holt

How to Protect Your Team When the Organization Is Working Against You

Daniel Holt — Tue, 01 Sep 2026 13:07:04 +0000

Last week I wrote about what happens when governance creep turns a manager into a reporter — when the spreadsheets multiply and the capitalization language arrives and the job you took stops looking like the job you have.

The response I got, from managers who recognized themselves in that post, was some version of the same question: okay, but what do I actually do?

This post is my honest answer. Not a framework. Not a set of best practices. What I am actually doing right now, inside an organization that is figuring out what it wants to be, to keep my teams delivering while the swirl happens above them.

Your Job Is to Be the Filter

When an organization is in transition — when new governance is arriving, when leadership is asking questions that haven’t been answered yet, when processes are being proposed that may or may not become mandates — your primary job as a manager is to be the filter.

Not every piece of information that reaches your level needs to reach your team. Not every question that leadership is asking needs to become a concern the engineers are managing. Not every “we think we might” needs to be communicated as “here is what’s coming.”

The team needs to focus on delivery. That focus is fragile. Organizational uncertainty is one of the fastest ways to break it — because engineers who are worried about what’s coming next are not fully present in the sprint that’s happening now. They are managing their exposure, hedging their bets, waiting to see how things land before they invest fully in the work.

Your job is to hold that uncertainty at the boundary. To absorb it, process it, and only let clarity through.

That means managing the information that reaches the team. Massaging it. Working it into conversations carefully and at the right time. Preparing people for change as it becomes clear rather than as soon as you hear about it.

They will not be able to avoid all of it. But they do not need to deal with all of it now.

The Difference Between a Question and a Mandate

The most common mistake I see managers make when their organization is in chaos is treating everything as a mandate — even when leaders are asking questions.

A leader who asks “have you thought about how Lean Six Sigma might apply to your team?” is asking a question. They may be curious. They may be testing an idea. They may be floating something they read about. They may be genuinely exploring.

They are not mandating Lean Six Sigma.

The manager who goes back to the team and says “leadership is asking about Lean Six Sigma, we need to figure out how to comply” has turned a question into a directive. The team scrambles. Time gets spent on something that was never actually decided. Anxiety rises. Delivery slows.

The manager who sits in the question and says “noted, we’ll keep delivering” has done their job. They have filtered the noise. They have protected the team’s focus. And they have waited for the “we think” to become “we know” before acting on it.

There is always a lot of “we think” in a large organization. There is much less “we know.” The manager’s job is to know the difference — and to not pass the “we think” to the people who need to keep moving.

Until someone makes a decision that the organization will mandate, there are always opportunities to deliver and to show how things work. Use them.

Prepare, Don’t Surprise

When something does move from “we think” to “we know” — when a decision gets made and change is genuinely coming — the manager’s job shifts from filtering to preparing.

This does not mean announcing the change the moment you hear about it. It means working it into conversations over time. Planting seeds. Raising questions that help the team start thinking in the direction of where things are going, without triggering the anxiety of a formal announcement before you have answers.

“How do you think our team would handle more structured project tracking?” is a different conversation than “leadership has decided we’re moving to a project management framework and here’s the timeline.” Both are true eventually. The first one gives the team time to form their own thinking. The second one drops something on them they have no context for.

The manager who prepares their team for change before the change arrives makes the transition smoother for everyone — including the team members who will find it hardest. The manager who passes every piece of organizational news directly and immediately is not being transparent. They are passing their own anxiety along with the information.

Don’t Let Your Frustration Bleed Through

This is the hardest part and the most important part.

You are absorbing things that your team does not have to absorb. Governance overhead. Political maneuvering. Decisions made without engineering input that affect engineering directly. The exhaustion of filling out forms that produce nothing. The frustration of watching your job get smaller while the expectations stay the same.

That frustration is real and it is valid. And it cannot go to your team.

Not because your team cannot handle it. Because your job is to protect their ability to focus — and a manager who is visibly frustrated about the organization is a manager whose team starts spending energy managing the manager’s feelings rather than doing the work. They pick up on it. They worry about it. They adjust their behavior in response to it. None of that is useful.

Find somewhere else to put it.

I have a small group of peer managers who I meet with regularly specifically for this purpose. We vent. We help each other navigate. We remind each other that what we are experiencing is real and that we are not imagining it. Just having someone there to listen — someone who understands the same pressures and is not going to be affected by what you say — is more valuable than most management development programs.

If you do not have that group, build it. The filtering you are doing for your team is sustainable only if you have somewhere to process what you are filtering. Otherwise it accumulates. And eventually it bleeds through anyway — not in one conversation but in a hundred small ones, in the tone you take, in the energy you bring, in the way you answer a question about what’s happening above.

Find your people. Talk to them honestly. Come back to your team intact.

Show How to Deliver

The most powerful argument against governance creep is not a debate about governance. It is delivery.

Every time your team ships something meaningful and connects it to a result — every sprint review where a number moved and the team can explain why — you are making the case that this way of working produces something the governance framework does not. You are not arguing. You are demonstrating.

Leaders who are asking questions about Lean Six Sigma and capitalization and project governance are asking because they are not sure the current approach is working. The answer to that uncertainty is not to debate the methodology. It is to show that the methodology is working.

Keep the bus moving. Keep the results visible. Keep showing up to the conversations that matter with data rather than opinions.

If people want to jump in front of the bus, they get run over. Not because you did anything aggressive — because the momentum of consistent delivery is hard to stop once it is moving.

That is the protection. Not a shield against every organizational force that comes at your team. A record of results that makes it harder for those forces to justify themselves.

What to Do Today

If your organization is in swirl right now — if the governance is multiplying and the uncertainty is high and you are not sure what is coming next — here is what to do:

Keep the team focused on the sprint. Absorb the organizational noise at your level. Wait for questions to become decisions before you act on them. Prepare your team for change as it clarifies rather than as it swirls. Find your peer group and talk to them honestly. And keep delivering.

The organization will figure out what it wants. In the meantime, your job is to make sure your team’s answer to whatever comes next is a record of results that is hard to argue with.

That is how you protect your team when the organization is working against you. Not by fighting the organization. By keeping the work moving in spite of it.

Getting Engineers to Give a Damn: A Manager’s Guide to Building Ownership Inside Broken Systems is available now. Get it here →

Use code SEPTEMBER20 for 20% off the book or a paid subscription through September 30.

I publish every Tuesday at danielholt.substack.com

When You Become a Resource, Not a Manager

Daniel Holt — Tue, 25 Aug 2026 13:20:08 +0000

There is a particular kind of organizational shift that happens slowly and then all at once.

It starts with a new governance process. Then a reporting requirement. Then a capitalization framework that requires your time to be logged against specific project codes. Then a steering committee that needs to approve things that used to be decided at the team level. Then a program management layer that wants weekly status updates formatted a specific way.

None of these things are announced as a change to your job. They arrive as additions. Reasonable requests, each one. And then one day you look up from the spreadsheet you are filling out for the fourth time this week and you realize: this is the job now.

Not developing engineers. Not solving problems. Not building something worth building.

Filling out spreadsheets and playing politics.

What Leadership Actually Gets

The governance creep that produces this situation usually starts from a real concern. Leadership does not trust the delivery. Something went wrong — a project missed, a budget overran, a commitment that did not land — and the response is to add control. More oversight. More reporting. More approval gates. More visibility into what the teams are doing and when.

The logic is understandable. The outcome is the opposite of what they wanted.

Here is what actually happens when you layer governance and project thinking on top of a team that was functioning as a product team:

The engineers who were oriented toward outcomes start orienting toward process compliance. The sprint goal stops being about moving a number and starts being about satisfying the reporting requirements. The product owner who was defining problems starts defining deliverables — because deliverables are what the governance framework tracks. The manager who was coaching and developing starts reporting and shielding.

The delivery gets worse. Not because the people changed. Because the system changed what the people are rewarded for doing.

Leadership wanted control. What they got was the appearance of control and less actual delivery. The spreadsheets are full. The numbers are moving in the wrong direction.

The Manager Becomes a Reporter

When governance takes over, the engineering manager’s job transforms in a specific and demoralizing way.

You become a reporter. Your primary function is translating what the team is doing into the language the governance framework requires — project codes, capitalization percentages, milestone status, risk registers. You spend hours every week producing documentation that nobody reads carefully and that has no meaningful connection to whether the work is actually going well.

You also become a governance shield. Your job is to absorb the friction between the organization’s process requirements and the team’s ability to do actual work. You attend the meetings so the engineers do not have to. You fill out the forms so the team can keep moving. You manage upward so the people doing the work can keep doing it.

These are not nothing. In a heavily governed organization, protecting your team from process overhead is real and necessary work.

But it is not the job you signed up for. It is not the job that develops engineers or builds ownership or produces the kind of team that makes you proud to be a manager. It is the job of a human buffer between a broken system and the people trying to work inside it.

And it is exhausting in a specific way — not the exhaustion of hard work that produces something, but the exhaustion of hard work that produces nothing except the continuation of the process.

What Gets Lost

The thing that gets lost in governance creep is not efficiency. It is not velocity. It is not even delivery, though delivery suffers.

What gets lost is the human factor.

In the language of resource allocation and capitalization, engineers are line items. Their time is a cost to be managed. Their allocation is a variable to be optimized. The question is not “what does this engineer need to grow?” or “what problem is this engineer best positioned to solve?” The question is “what percentage of this resource’s time can be capitalized against this project code?”

That language is not accidental. It reflects a genuine belief — held by a lot of people in large organizations — that engineering is a production function. You put in requirements and time, you get out software. The quality of the output is a function of the specification, not the people.

This belief is wrong. But it is deeply embedded in the systems that governance frameworks are built on. And when it takes over, it teaches engineers the lesson that passive engineers have always been taught: you are not here to think. You are here to execute.

The hunters become cogs again. Not because they chose to. Because the environment stopped rewarding hunting.

The Only Defense

I am still in the middle of this. My organization is moving away from Agile and adding governance at every level. My time needs to be capitalized. My teams are being evaluated as resources to be allocated, not capabilities to be developed.

I have not figured out how to fix it. I am not sure it can be fixed from where I sit.

What I have figured out is the only thing that actually works as a defense: keep delivering.

Positive results are hard to argue with. A team that consistently moves the metrics that matter to the business — that reduces fraud, improves conversion, delivers measurable outcomes sprint after sprint — is a team that is difficult to dismantle even inside a heavily governed organization. The governance framework can add all the reporting requirements it wants. It cannot argue with the numbers.

Keep the bus moving forward. If people want to jump in front of it, they get run over.

That is not a satisfying answer. It is not a system change or a culture fix or a way to make the governance go away. It is just the thing that keeps the team intact and the work meaningful while the organization figures out what it actually wants.

Keep delivering. Keep the results visible. Keep the engineers oriented toward outcomes even when the system is trying to orient them toward compliance.

The fight is worth having. Even when you are not sure you are winning.

What This Means for You

If you are reading this and recognizing your own organization — the spreadsheets, the capitalization language, the governance layers multiplying — you are not alone. This is happening in large organizations everywhere. The pendulum that swings toward autonomy and product thinking eventually swings back toward control and project thinking. Sometimes it swings back hard.

The managers who survive it with their teams intact are the ones who kept their heads down and kept delivering. Not because delivery fixes the system. Because delivery is the only argument the system cannot dismiss.

Your engineers need you to protect their ability to do the work. Your stakeholders need you to keep showing them the results. Your leadership needs you to keep the bus moving even when they are adding obstacles to the road.

And you need to remember why you took this job — not to fill out spreadsheets, but to build something worth building. That purpose does not disappear because the governance framework arrived. It just gets harder to hold onto.

Hold onto it.

Getting Engineers to Give a Damn: A Manager’s Guide to Building Ownership Inside Broken Systems is available now. Get it here →

Use code AUGUST20 for 20% off the book or a paid subscription through August 31.

I publish every Tuesday at danielholt.substack.com

What Good Looks Like — The Team That Actually Works

Daniel Holt — Tue, 18 Aug 2026 13:22:37 +0000

Most writing about engineering teams focuses on what is broken. The passive engineers. The Agile transformation that missed the point. The sprint reviews that nobody prepared for. The requirements that arrive as instructions rather than problems.

This post is different. This post is about what the other side looks like.

Not the ideal. Not a framework for a team that does not exist yet. The real thing — what a fully functioning product team actually looks like in a refinement session, in a sprint review, in the daily rhythm of work when the culture is working the way it is supposed to.

I manage a team that looks like this most of the time. Here is what I see.

Everyone Is Doing Their Job

The clearest sign that a team is working is also the simplest: everyone is doing the job they are supposed to be doing, and nobody is doing someone else’s job for them.

In a refinement session on a team that is working, the roles are visible and distinct.

The product owner defines the problem. Not the solution — the problem. They bring the context, the customer need, the business constraint. They explain what is wrong with the current state and what the customer is trying to accomplish. They do not tell the engineers how to fix it. They trust that if the engineers understand the problem, they will figure out how to fix it.

The software engineers understand the problem and generate ideas for solving it. They ask questions that sharpen the definition. They surface dependencies the product owner did not know about. They propose approaches — not to get approval, but to think out loud, to test their understanding, to invite the expertise of the people next to them.

The quality engineers are thinking about how to put the solution through the rigor that guarantees it works. Not at the end, after the code is written — at the beginning, during refinement, before a line has been written. They are asking: how will we know this is right? What does failure look like? What edge cases need to be tested? They are building the quality into the definition of done rather than bolting it on afterward.

The scrum master is facilitating. Keeping the conversation on track. Making sure the right questions get asked. Noting what has been decided and what still needs resolution. Moving the meeting forward without driving it.

And the manager is watching. Not managing the conversation — watching how the people in it are interacting. Who is engaged. Who is holding back. Where the growth opportunities are. What the team needs that they do not yet know how to ask for.

When all of that is happening at once — when everyone is in their role and the roles are complementary rather than overlapping — the meeting has an energy that is immediately different from a session where one person is carrying everything.

The Role That Trust Plays

Here is the thing underneath all of it: none of this works without trust.

Trust is not a soft concept in this context. It has a specific, observable meaning. It means each person on the team believes the person in the next role is going to do their job — and because they believe that, they do not have to do it for them.

Watch what happens to a team without trust and you will see every role bleed into every other role.

The scrum master starts asking the questions that the engineers should be asking — because the engineers are not asking them, and the scrum master cannot let the silence sit.

The software engineers start specifying how the quality engineer should test the solution — because they do not trust that the quality engineer will catch what needs to be caught.

The quality engineer starts nitpicking what the scrum master wrote in the story — not because there is a real problem with it, but to prove that they can, to establish relevance, to fill a role that nobody has clearly defined for them.

Everyone is compensating for everyone else. Everyone is doing a version of someone else’s job. The conversation is louder than it needs to be and less focused than it should be. And everyone is working harder than they would have to work on a team where the trust was there.

The product team that works is not a team of better individuals. It is a team of individuals who trust each other enough to stay in their own lane — because they believe the person in the next lane is going to show up.

What the Product Owner Gets Back

On a team without trust, the product owner becomes a requirement machine. They specify everything because they have learned that if they do not specify it, it will not happen — or it will happen wrong. They write detailed acceptance criteria not because the engineers need them but because the engineers have shown, over time, that they will not ask the questions that would surface the details themselves.

This is exhausting for the product owner. And it makes the engineering worse, because engineers who receive fully specified requirements have no reason to think. The thinking has been done for them. Their job is to implement.

On a team that is working, the product owner gets something different back. They get to focus on the problem. They describe what needs to be different, why it matters to the customer, what success looks like at the outcome level. And then the engineers take it from there.

The product owner is still in the conversation. They answer questions, provide context, push back when the proposed solution seems to miss the point. But they are not the one generating the solution. They are the subject matter expert on the problem, and the engineers are the subject matter experts on the solution.

That division of labor is not a process decision. It is a trust decision. The product owner who trusts the engineering team to figure out the how can focus on the what and the why. The product owner who does not trust the engineering team has to do everything.

What the Manager Sees

When the team is working, the manager’s job in a refinement session is to watch.

Not to drive the conversation. Not to rescue the silence. Not to answer the questions that engineers should be answering. Just to watch how the people in the room are interacting — who is contributing, who is holding back, where the friction is, what each person needs to grow.

That shift — from participant to observer — is one of the clearest signals that the culture has taken hold. The manager who cannot step back from a refinement session without it falling apart has a team that depends on them. The manager who can sit quietly in a session that runs itself has built something real.

It does not mean the manager is passive. They are actively watching. They are forming observations that will shape the next one-on-one, the next coaching conversation, the next moment where they point toward a problem and give someone the space to find it. They are doing the long-term work of developing people, which requires seeing people clearly — and you cannot see people clearly when you are doing their job for them.

What the Engineers Feel

The engineers on a team that is working know something that engineers on other teams do not.

They know that their judgment matters. Not because someone told them it does — because they have experienced it. They have asked a question in refinement and watched the conversation change direction. They have proposed an approach and had it taken seriously. They have surfaced a problem nobody assigned them to find and watched it get addressed.

They show up to work knowing that what they think is relevant. That showing up prepared is worth the effort. That speaking up will produce something rather than nothing.

That knowledge changes everything about how they engage. Not because they are different people from the engineers on a passive team. Because they have had different experiences — and those experiences have taught them different things about what their work is for.

What It Takes to Get There

Nothing in this post happens by accident. The team that looks like this on a Tuesday afternoon in refinement was not always this team. At some point the product owner was handing down solutions. The engineers were waiting to be told what to build. The quality engineer was catching problems at the end instead of preventing them at the beginning. The trust was not there yet.

Getting from that team to this one is the work this publication is about. It is slow. It requires ongoing attention. It requires a manager who is willing to hold the environment steady while the culture builds — who does not rescue the silence, who asks why before asking how, who presses people to lead and plays dumb when they bring problems.

But it is possible. I know because I am watching it happen.

The team that actually works is not a fantasy. It is what you get when you build the conditions for it and hold them steady long enough for the trust to form.

That is what good looks like.

_Getting Engineers to Give a Damn: A Manager’s Guide to Building Ownership Inside Broken Systems is available now. Get it here →

Paid subscriptions are open at https://danielholt.substack.com.

Use code AUGUST20 for 20% off a paid subscription or the book through August 31._

The First Question to Ask When a Requirement Arrives

Daniel Holt — Tue, 04 Aug 2026 13:41:18 +0000

Every requirement that arrives in your team’s backlog contains a hidden assumption. The assumption is that the person who wrote the requirement already knows what the customer needs and how to deliver it. The team’s job is to implement what was specified.

That assumption is wrong more often than anyone admits. And the teams that never question it are the ones that ship features nobody uses, deliver projects on time that don’t produce results, and wonder why their product owner feels the need to specify every detail before the engineers can begin.

The fix is one question. Asked before anything else. Asked every time.

Who is the customer, and how do they get value out of this change?

What That Question Actually Does

Most requirement conversations start with the what. What needs to be built. What the acceptance criteria are. What the definition of done looks like. The engineers who ask good questions ask about edge cases, dependencies, technical constraints.

Nobody asks about the customer.

Not because they don’t care — because the format of the requirement doesn’t invite it. The ticket says build this. The story says as a user I want this. The implicit message is that the customer value question has already been answered upstream, and the team’s job starts where that answer ends.

But the customer value question has almost never been fully answered. It has been assumed. Leadership decided what to build based on what they believe the customer needs. The product owner translated that belief into a requirement. The requirement arrived at the team as a specification.

At no point did anyone ask the people closest to the system — the engineers who know how it actually works, what it can do, what it has done before — whether the specified solution is the best path to the customer value everyone claims to be working toward.

Asking who is the customer and how do they get value reopens that conversation at the point where it can still be acted on.

What Happens When Nobody Asks

When engineers skip the customer value question and go straight to implementation, a specific and predictable pattern emerges.

The team becomes order takers. Not because they chose to be. Because the format of the work trained them to be. A requirement arrives. It specifies what to build. The engineers figure out how to build it. Nobody asks why.

The product owner feels this and responds to it. When engineers never ask about customer value, the product owner concludes — reasonably — that the team cannot be trusted to make decisions about value. So they start specifying more. More detail in the requirements. More prescriptive acceptance criteria. More oversight during implementation. More review before anything ships.

This makes the order-taking worse. The more the product owner specifies, the less the engineers have to think. The less they think, the more the product owner has to specify. The cycle compounds.

The team that never asks the customer value question ends up in a relationship with their product owner that looks like a contractor relationship. Here is the statement of work. Build it exactly as specified. Come back when it is done.

That is not a product team. That is an outsourced development shop with the overhead of Agile ceremonies.

The Vendor and Tool Problem

The clearest version of this plays out when leadership decides on a tool or vendor without any input from the engineering team.

It happens constantly in large organizations. A business problem gets identified. Procurement gets involved. A vendor gets selected. A contract gets signed. And then the engineering team gets told: implement this tool.

Two ways of receiving that requirement produce completely different outcomes.

The first way: Tell me exactly what I need to build to implement this tool.

This approach treats the tool as the destination. The team maps out the full implementation, figures out all the dependencies, builds everything the tool requires, and ships it when the entire implementation is complete. Value arrives at the end — if it arrives at all. If the tool turns out not to solve the problem the way everyone hoped, that discovery comes after all the work is done.

The second way: How will this tool provide value to the customer, and what is the smallest thing we can build to start delivering that value?

This approach treats the tool as a means to an end. The team asks what the customer actually needs from this tool, identifies the piece of the implementation that delivers the most important part of that value first, and ships that. Then the next piece. Then the next.

Value starts arriving before the full implementation is complete. If the tool turns out to have problems — if it does not behave the way the vendor said it would, if the customer does not respond to it the way leadership expected — the team finds out early, while there is still time to adjust.

The requirement was the same in both cases. The question changed everything about how it was approached.

What the Product Owner’s Job Becomes

When engineers ask the customer value question consistently — when it becomes the first thing they do with every requirement — something changes in the team’s relationship with their product owner.

The product owner stops needing to specify everything.

Not because they decide to step back. Because the engineers are doing the thinking that the product owner was doing on their behalf. The engineers are asking about the customer. They are connecting the requirement to the outcome. They are making decisions about how to deliver value rather than waiting to be told.

The product owner’s job shifts from order-giver to subject matter expert. They stop writing requirements that contain all the answers and start having conversations that share all the context. The engineers take that context and figure out the best path forward.

That shift does not happen because someone announced a new process. It happens because the engineers started asking one question that changed the nature of every conversation that followed.

How to Introduce It

If your team is not currently asking this question, you cannot introduce it by announcing it. Telling engineers to ask about customer value in refinement is the same as telling passive engineers to speak up — it lands in an environment that has not changed, from a manager who may or may not still be there in six months, and produces a nod followed by the same behavior as before.

You introduce it by asking it yourself. Every time. In every refinement session. Out loud, so everyone can hear the question and the answer.

Who is the customer for this story, and how do they get value from this change?

Ask it before anyone talks about implementation. Ask it when a new epic gets broken down. Ask it when a vendor tool gets handed to the team. Ask it until the engineers start asking it before you do.

That is the moment the question has become part of how the team works — not a technique the manager uses, but a habit the team has internalized. The requirement arrives. Someone asks the customer value question. The conversation that follows is different from the one it would have been.

Everything that comes after that conversation is better for it.

Getting Engineers to Give a Damn: A Manager’s Guide to Building Ownership Inside Broken Systems is available now. Get it here →

Paid subscriptions are open at danielholt.substack.com.

Use code AUGUST20 for 20% off a paid subscription or the book through August 31.

The Refinement Session Playbook

Daniel Holt — Tue, 28 Jul 2026 13:07:38 +0000

Most refinement sessions are structured around a false assumption: that the goal of the meeting is to walk through the stories on the board.

It isn’t. The goal of refinement is to make sure every engineer understands the problem well enough to solve it independently — without needing to ask for approval on their approach, without needing to come back to a meeting for clarification, without needing the scrum master to tell them what the story means.

That is a fundamentally different goal than walking through stories. And running toward it requires a fundamentally different structure than most teams use.

This post is the playbook I use. Three sessions per sprint, specific roles, specific moves for the hardest moments, and the one thing that matters more than any of it.

This is the opening of a paid subscriber post at danielholt.substack.com. The full playbook — three-session structure, the silence problem, what the scrum master's job actually is, and the one thing that matters more than all of it — is available to paid subscribers.

danielholt.substack.com

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.

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. 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. 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.