In the world of collaborative teams, we love the idea of distributed ownership. It sounds fair, empowering, scalable. And it often is.

Until it isn’t.

Over the past few months, I’ve noticed something subtle but persistent happening in one of the platform efforts I’m part of. We have two squads working toward a shared goal. Responsibilities are clear enough, we have DRIs in place, and we all show up as one unified team to our stakeholders. But underneath that surface-level alignment, sometimes decisions are getting stuck.

Not because of conflict. Not because of apathy. But because of kindness.

The polite pause

When ownership is distributed but not tightly coordinated, you start to see a familiar pattern: people waiting. Waiting for others to chime in. Waiting not to overstep. Waiting for the product manager. Waiting for a consensus that never quite arrives.

It’s a polite pause. Everyone wants to do the right thing. No one wants to push too hard. But the result is the same: time slips away, decisions take their own time, and progress feels slower than it should.

I’ve been guilty of this too. As a manager, I try to practice servant leadership. I want the team to lead, to grow, to own. But that can quickly become a trap - you wait just a bit too long to intervene, trying not to be too directive, and then realize that everyone else was waiting too.

So the question becomes: how do we keep our culture kind and collaborative, while still moving forward with momentum?

Temporary DRI: making ownership lightweight

One simple practice to explire is the idea of a temporary DRI (Directly Responsible Individual) - someone who steps up to own just the next step or decision. Not the whole project. Not the full outcome. Just the moment that’s currently stuck.

It doesn’t have to be the manager. Or the product owner. Anyone can say: “I’ll take temporary DRI on this until we close the loop.”

That’s it. It gives the team a driver without creating hierarchy. It builds agency and it keeps momentum. And it reduces the ambiguity that often paralyzes distributed teams.

Escalation as a service

The second cultural shift you can try is to reframe how you think about escalation. Instead of treating it like a failure mode, you treat it as a service.

“I’m escalating this not because someone dropped the ball, but because I want us to decide and move on.”

Escalation as a service helps people feel safe surfacing blockers. It prevents things from quietly drifting. It respects people’s time and mental energy.

It also normalizes one of the hardest things in distributed systems - surfacing uncertainty early, rather than waiting for perfect clarity.

Deciding who decides

Sometimes we defer decisions too long by saying, “this is a product call.” And yes, sometimes it is. But more often than not, it’s a team call. And what’s missing is not clarity of responsibility - it’s clarity of decision authority.

One small but powerful change you can make is to add a section to design docs and RFCs:

**Decision Owner**: [Name here]
Responsible for reviewing input and making the final call. Consults with stakeholders, listens to feedback, then decides.

This removes ambiguity. It makes decisions feel real. And it avoids the quiet deferrals that otherwise accumulate in shared work.

Servant leadership is not indecision

What I’ve learned in all this is that kindness and clarity are not opposites. You can lead with care - and still make calls. You can empower others - and still frame the boundaries. You can stay quiet, but only until the pause becomes a drag on the team.

Distributed ownership works. But it needs small rituals to keep it moving. These aren’t heavy processes. They’re small tools to help us do what we already want to do: Work well together, move forward and stay kind along the way.