DEV Community: Daniel Holt

What Happens to Engineers When the Culture Shifts

Daniel Holt — Tue, 22 Sep 2026 13:10:23 +0000

Building a culture of ownership takes a long time. Longer than most managers expect. You spend months creating the conditions — the outcome orientation, the closed feedback loops, the refinement sessions where engineers show up prepared and ask why before asking how. And then one day you look around and realize something has changed. The engineers who were hunting are starting to wait again.

This is what I am watching happen right now.

Not because the engineers changed. Because the environment changed around them.

What Happened

Last week our leader left the bank. She was one of the people pushing hardest for Lean Six Sigma as a replacement for the way our product teams work. Her departure did not resolve the uncertainty she created — it deepened it.

Part of the organization is now defining new ways of working but has not communicated them. The work our team was doing under her direction is in limbo. Nobody knows what the new direction is, who is making the decisions, or what the expectations are going to look like when the dust settles.

So everyone is waiting. And questioning. And wondering whether what they were doing still matters.

This is the moment I want to write about — not the governance creep or the methodology debate, but what happens to engineers when the ground shifts underneath them. What regression looks like. And what the manager’s job is when it starts.

What Regression Looks Like

The engineers who were hunting do not immediately become passive when the culture shifts. The regression is gradual and it starts with something subtle: they stop trusting that the environment will reward initiative.

They have been here before. Not necessarily at this organization — but in their careers, in previous environments, they learned what happens when they invest in something and then the organization changes direction. The feature they championed gets deprioritized. The process they improved gets replaced. The work they were proud of gets painted over by a broad brush that decided the whole approach was wrong even if their specific contribution was working.

That history lives in their bodies. And when the environment starts sending the same signals — uncertainty about direction, silence from leadership, the sense that decisions are being made somewhere above them without their input — the history activates. The learned helplessness that was dormant starts to stir.

The first sign is usually in refinement. The engineer who was asking questions starts going quiet. Not dramatically — they still participate, still contribute, but the energy is different. They are hedging. They are waiting to see what the new environment rewards before they invest fully again.

The Two Engineers I Am Watching

I have two engineers right now whose situations illustrate the two ends of this.

One has always carried a baseline anxiety about his job that surfaces whenever the environment is uncertain. The confusion we are in right now is feeding that anxiety in ways I can see clearly. He is not asking questions in refinement. He is waiting to be told what to do. The progress we made — getting him to show up prepared, to speak up, to trust that his judgment mattered — is at risk because the environment stopped sending the signals that made it safe to engage.

The other is a hunter. He has been the person our team relies on — the one with the answers, the one who surfaces problems nobody assigned him to find, the one who shows up to every meeting having already thought about the problem. His contract ends in a couple of months. The bank has decided not to extend most contractors.

He keeps doing his job. Every day. Fully present, fully engaged, still hunting. But the situation is what it is, and the team knows it. Watching the person who most embodies ownership culture get let go — not because of performance, not because of anything he did, but because of a broad organizational decision — teaches everyone around him something about what the environment actually values.

That lesson is being taught right now whether I want it to be or not.

The Broad Brush Problem

The thing that makes this particular moment so hard is that what we built was working.

There are teams in this organization for whom the product team approach was not producing results. The Agile ceremonies were not translating into delivery. The outcome orientation was not taking hold. Those teams had real problems.

But the response to those real problems has been to paint with a broad brush — to treat the approach itself as the failure rather than the implementation, to throw out what was working alongside what was not. The teams that were delivering get caught in the same sweep as the teams that were not.

This is how organizations lose the things worth keeping. Not through deliberate decisions to eliminate them. Through decisions made at a level where the nuance is not visible — where the teams that worked look the same on the org chart as the teams that did not, and the intervention that gets applied is the same for both.

My engineers know what we built. They know it was working. And they are watching it get questioned by people who are not in our refinement sessions, who have not seen the metrics move, who are making decisions based on a category rather than a result.

That is demoralizing in a specific and legitimate way. It is not weakness or passivity. It is a rational response to watching good work get dismissed.

What the Manager’s Job Is Right Now

When the culture starts to shift — when the uncertainty rises and the engineers start hedging and the environment stops sending the signals that made ownership feel safe — the manager’s job is to provide stability.

Not false reassurance. Not pretending the uncertainty is not real. Stability.

Stability means keeping the work as consistent as possible while everything around it shifts. The refinement sessions still happen. The sprint goals still get named. The outcomes still get measured. The team still shows up on Tuesday morning and does the thing that needs doing — not because the organization has provided clarity, but because this team has not stopped being this team.

Stability also means helping people navigate what they cannot control. The engineer who is anxious about his job needs honest conversations about his career — not in the context of the current chaos, but in the longer context of what he is building and where he is going. The hunter whose contract is ending needs acknowledgment that what he built here was real and that it will travel with him wherever he goes next.

These are not management techniques. They are the things you do for people who are scared and who trusted you with the work.

What Holds

Here is what I keep coming back to when I look at the situation honestly.

The culture we built did not disappear because a leader left or because a contract is ending or because the organization is in confusion. It is under pressure. It is at risk. But the engineers who became hunters did not become passive the moment the environment shifted. They are still showing up. Still doing the work. Still bringing what they learned to every sprint.

The engineer who was making progress is not back to zero. He is anxious and hedging, but he remembers what it felt like to show up prepared and have his preparation matter. That experience does not erase.

What I am trying to do right now is hold the conditions as steady as I can while the organization figures out what it wants to be. Keep running the refinement sessions the same way. Keep closing the feedback loop. Keep naming the outcomes. Keep showing that the work matters even when the organization is not sure what it values.

The culture is not a finished thing. It never was. It requires ongoing attention and it is especially fragile when the environment shifts.

But fragile is not the same as gone.

Hold the line. Keep the work moving. And trust that the engineers who learned to hunt have not forgotten how — even if they are waiting, right now, to see whether the new environment is going to be worth investing in.

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

What Lean Six Sigma Gets Wrong About Knowledge Work

Daniel Holt — Tue, 15 Sep 2026 13:15:05 +0000

Lean Six Sigma is having a moment in large organizations right now. After years of Agile dominance, some leadership teams are rediscovering process improvement methodologies from manufacturing and wondering if they might solve the problems that Agile did not.

They might — in the right context. Lean Six Sigma is a serious methodology with real applications and a track record of genuine results. The problem is not the methodology. The problem is what happens when it gets applied to work it was not designed for.

This post is about that mismatch — what Lean Six Sigma is, what it does well, and why applying it to software engineering teams usually produces the wrong outcome even when everyone involved has good intentions.

What Lean Six Sigma Was Built For

Lean Six Sigma comes from factory line work.

The core idea is straightforward: find a repeatable process, map it carefully, identify the waste and variation within it, eliminate what does not add value, and standardize what remains. Do this consistently and you get a process that is faster, cheaper, and more predictable than the one you started with.

This works extraordinarily well when the work is genuinely repeatable. A manufacturing line that produces the same part hundreds of times a day is the ideal Lean Six Sigma candidate. The process exists. It can be observed. It can be measured. The waste is visible — unnecessary steps, defects, idle time, excess inventory. Remove the waste and the line gets better.

Lean Six Sigma is not a bad methodology. It is a methodology that was built for a specific kind of work and works best when that kind of work is what you are actually doing.

The Factory Line Problem

Here is what happens when you try to apply Lean Six Sigma to software engineering.

The methodology assumes there is a repeatable process to optimize. But software engineering teams are not running the same process over and over. They are standing up new factory lines — building new systems, solving new problems, navigating new constraints — every time they take on significant work.

You cannot optimize a process that does not exist yet. You cannot find waste in a factory line that is still being designed.

The work that does repeat in software engineering — routine maintenance, standard deployments, predictable support requests — can benefit from Lean Six Sigma thinking. If your team has a consistent intake process for business-as-usual requests, if the first request in is the first request out, if the work is genuinely predictable and repeatable, then looking for waste in that process makes sense.

But that is not the majority of what engineering teams do. The majority of what engineering teams do is build new things in response to new problems. Each project has different requirements. Each solution requires different thinking. The factory line is not optimized — it is invented.

Applying Lean Six Sigma to that work does not find waste. It finds novelty and calls it inefficiency.

What Leadership Is Actually Looking For

When leadership proposes Lean Six Sigma for engineering teams, they are usually not thinking carefully about the methodology’s origins or its design constraints. They are thinking about control.

Leadership wants to be able to say “jump” and have everyone jump. They want to know when the jumping will be completed. They want the jumping to look the same every time so they can predict it, report on it, and hold people accountable for it.

Lean Six Sigma, in theory, offers that. It promises repeatable processes, measurable outcomes, and continuous improvement toward a defined standard. For a leader who is frustrated by the unpredictability of software delivery, that promise is appealing.

The problem is that the work requires more than jumping. Sometimes it requires running. Sometimes turning around. Sometimes stopping entirely to reassess. The right movement depends on the problem — and the problem changes every time.

A framework that treats every situation as the same jump produces the wrong movement at the wrong time. The process gets followed. The jumping happens on schedule. And the team arrives at the wrong place because jumping was not actually what the situation required.

Leadership gets the control they asked for. They do not get the delivery they wanted.

What Gets Lost

When Lean Six Sigma thinking takes over in an engineering organization, something specific gets lost: the judgment of the engineers.

A Lean Six Sigma process, properly implemented, does not need engineers who think. It needs engineers who follow the process. Variation is the enemy — and judgment is a source of variation. The engineer who looks at a requirement and asks “is this actually the right approach?” is introducing variation into a process that is supposed to be standardized.

This is exactly the opposite of what builds ownership and engagement. The engineers who care about their work — who ask why before asking how, who surface problems nobody assigned them to find, who have opinions about the best way to solve a problem — are the ones who make product teams work.

They are also the ones who introduce the most variation from a Lean Six Sigma perspective.

The methodology that was supposed to improve the process ends up optimizing the people out of it.

What to Do If Your Organization Is Mandating It

If your organization is requiring Lean Six Sigma certification or implementing Lean Six Sigma processes for engineering teams, here is the honest advice: take the class. It is not worth fighting.

Not because Lean Six Sigma is right for your team. Because the fight costs more than the certification. Leadership has made a decision. The energy you spend arguing against the methodology is energy you are not spending protecting your team’s ability to deliver.

Take the class. Learn the language. Understand the framework well enough to speak to leadership in terms they recognize.

And then — this is the part worth doing with some genuine care — look for the actual waste in your actual processes. Not the waste that Lean Six Sigma predicts based on manufacturing assumptions. The waste that actually exists in how your team works: the meetings that produce nothing, the approval gates that add weeks without adding value, the handoffs that create delays, the rework that happens because requirements were not clear enough before work began.

Some of that waste is real and worth eliminating. The Lean Six Sigma vocabulary gives you a way to talk about it that leadership will hear. Use the language even if you are skeptical of the framework.

The most useful thing about learning Lean Six Sigma in an organization that has mandated it is that you can now find the waste in the Lean Six Sigma process itself — and name it in terms leadership understands.

The Longer View

Methodologies come and go in large organizations. Lean Six Sigma was the dominant framework before Agile. Agile displaced it. Now, in some organizations, the pendulum is swinging back.

The engineering teams that survive these swings are not the ones that fight each new methodology. They are the ones that keep delivering — that maintain the outcomes orientation, the short feedback loops, the culture of ownership — regardless of what the methodology is called this week.

The sprint review where a metric moved is still the sprint review where a metric moved, whether the meeting is called a sprint review or a process improvement checkpoint or something else entirely. The engineer who shows up prepared and asks why before asking how is still that engineer, regardless of whether the organization is running Agile or Lean Six Sigma or some hybrid that has not been named yet.

The methodology is the container. The delivery is what matters.

Keep delivering. Learn enough of the new language to have the conversations you need to have. And protect your team’s ability to do the work that actually moves the numbers — whatever framework is currently wrapped around 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

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.