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