When Engineers Stop Arguing, Metrics Stop Moving

The whole point of backlog grooming, the way I run it, is for the engineers to tell me where I failed. Where I didn't think a ticket through deeply enough, couldn't explain it clearly, or didn't write down enough for them to take it forward. My job as the product person in that room is to support them, and if I'm failing at that, I need to know, so grooming is where I ask.

That's not the usual view of grooming. In a lot of companies it's a review the product side runs and the engineering side sits through, and a session that goes by with no pushback counts as a good one. The tickets were clear, everyone nodded, the sprint is planned. Leadership reads that as alignment.

Sometimes it is. Sometimes it's a team that has decided arguing isn't worth it, and from the outside the two look exactly the same.

Critique lands on the person, not just the work

Every hard conversation is really three at once. There's what happened, there's how everyone feels about it, and there's what it says about who they are. That third layer comes from Difficult Conversations, the book by Douglas Stone, Bruce Patton and Sheila Heen, and it's the one that's always in play and almost always ignored.

You point out that some code isn't working the way it should, or you critique a design, and what the person on the other side can hear is: am I not good enough at this job? Am I bad at this career? Designers feel it especially, because so much of their identity is having good taste and a real sense of the user's experience, and a critique of the design can land as a critique of them. I've watched that spiral into withdrawal and anxiety, and I've watched it turn into anger. Neither one shows up on a sprint report.

None of this means the critique was wrong, and it doesn't mean the person was right, either. A designer who made something other people dislike may well have made the better call. The trouble is that, from inside the identity layer, being critiqued feels like having done the wrong thing, and it hurts, so people find ways not to get hurt again.

Ticket-takers are what's left when nobody handles that layer

When nobody addresses the identity layer, people become ticket-takers. They do what they're told and nothing else, because that's easier and safer than engaging in a conflict or sticking up for their own judgment. The designer implements the layout someone else sketched. The engineer builds the feature as written, even when they can see a simpler version or a reason it won't work.

From a distance, that looks like a team running smoothly. Up close, it's expensive. Implementing other people's ideas instead of bringing your own takes more time, because every decision has to travel up and back down. It takes more oversight, because nobody below the person writing the tickets is thinking about the outcome anymore. And it produces worse work, because the whole point of hiring a specialist is that they bring their discipline to the table – design, systems architecture, whatever it is – not that they put it away to stay safe.

That's where the metrics come in. If you're shipping steadily and the numbers aren't moving, the people best placed to tell you why are usually the ones building it. They can see the ticket that won't change behavior, the edge case nobody planned for, the feature that duplicates something customers already ignore. A team that's stopped arguing has stopped telling you those things.

The org chart can produce the same silence

Marty Cagan draws a distinction between product teams and feature teams that describes the same outcome at the level of structure. A product team is given a problem and judged on whether it solves it. A feature team is given what he calls "a prioritized list that is called the roadmap" and judged on output, while whether a feature creates any value is the responsibility of the stakeholder who asked for it.

He also names what that feels like from inside the team. When the hoped-for results don't show up, the stakeholder will still find a way to blame the team, and, as he puts it, "your team was probably never convinced this was worth building in the first place."

I'd put the two together this way. A feature-team structure tells people their judgment isn't wanted. Critique that lands on identity, with nobody tending to it, teaches them it isn't safe. Either one alone can produce a quiet team, and plenty of companies have both.

The research on teams that speak up

The best-known evidence here comes from Google, which studied what made its own teams effective and found that who was on the team mattered less than how the team worked together. Of the five dynamics it identified, psychological safety came first: people "feel confident that no one on the team will embarrass or punish anyone else for admitting a mistake, asking a question, or offering a new idea." Google reported that people on teams with a stronger team culture were rated effective by executives twice as often.

The idea itself comes from Amy Edmondson at Harvard, who defined team psychological safety as "a shared belief held by members of a team that the team is safe for interpersonal risk taking." In her 1999 study of 51 work teams, psychological safety was associated with learning behavior – asking questions, seeking feedback, talking about mistakes – and that learning behavior was what connected it to team performance.

That's the mechanism in plain terms. Teams get better by surfacing problems. Teams that don't feel safe stop surfacing them, so they stop getting better, and from the outside they look calm.

Make the first critique about your own work

I don't think you can tell a team to feel safe. What you can do is go first.

That's why I run grooming the way I do. When the person who wrote the tickets treats the session as the place to hear where they fell short, the engineers aren't critiquing a colleague, they're answering a direct request. And being that open about my own work is what makes it safe for them to say the same kind of thing to each other.

Retrospectives work the same way. Mine happen every two weeks and they're always forward-facing: we're not there to complain, we're there to figure out how to work better together. We look at what happened over the last two weeks and use it to decide what to change in the next two. There are at least two columns, what went well and what could have gone better, and making room for the positives first loosens people up to share the negatives, like acceptance criteria that weren't good enough. Sometimes I skip the structure and just ask everyone to write down the things I could be doing better for them.

There's still a place for the leader to step in directly. When someone is causing drama, or giving feedback that's harsh or mean, that's mine to handle, and often there's something else going on in that person's life that's worth understanding before deciding what to do about it. But that's the exception. Most of the work is modeling, and the model starts with the leader being the first one critiqued.

If your grooming sessions have been quiet for a while, the next one is a good place to start, by asking the room where your tickets failed them.