On most software teams, the work of running things falls to a few people. The engineering manager and product manager run standups and retros and a handful of engineers write most of the tickets. They're the ones who hold the context and drive the team forward. The rest of the team, often the majority, picks up tickets and executes them.
I was working as a software consultant on a team that had hit this wall and over time, but became one of the people advocating for change. Things were fine at the top level but there were friction points underneath that were affecting the team.
The symptoms
Engineers didn't have enough context on the projects they were working on. Tickets were often just titles, with no description or acceptance criteria to estimate against. That lack of context led to tickets taking longer to finish because engineers had to stop mid-implementation to chase down missing information.
Code reviews were also suffering. Without a shared understanding established early, business decisions were landing in pull request comments. Debates about scope and product direction happened at the code review stage, where they don't belong. Reviews dragged on, making PRs sit open longer and slowing shipping.
Sprint planning suffered too because people estimated without enough context, so estimates landed far from the actual time the work took. And the weight of keeping all of that organized fell to a small group of people who had accumulated enough context to be relied on.
The rest of the team hadn't been given a structure, or a reason, to get involved in how the work got shaped before it reached them.
Let the team diagnose the problem
The team ran three workshops across multiple sessions: a retrospective, a team charter session and a team process workshop. The sessions surfaced pain points and worked toward solutions that the team itself could own.
When a team participates in designing how they work, the changes are more likely to stick, because the people following the process are the same people who built it. The workshops were just the mechanism for getting there; the underlying idea was to give the team the space to name what wasn't working and decide how to fix it.
What the team actually changed
Product Requirements Documents (PRDs) as group kickoffs. Before medium and large projects began, the team reviewed the PRD together rather than leaving engineers to absorb context alone. This gave everyone visibility into the business goals and open questions before tickets were written. Implementation concerns surfaced earlier and engineers entered refinement with enough background to flag risks they'd otherwise have missed.
The project anchor role. Each project was assigned an engineer as its project anchor whose responsibilities were to prepare the Technical Design Document, ensure tickets were well-defined before estimation and serve as the technical point of contact throughout. This meant that the context about a project lived more closely with the person closest to implementation.
Technical Design Documents (TDDs) as shared decisions. The anchor prepared the TDD, but technical direction wasn't finalized until the team discussed it. One person did the research and drafted the design efficiently but did not lock the technical decisions. Engineers who would implement the work had a say in the tradeoffs before the design locked. That shared understanding made estimation grounded and reduced mid-sprint surprises.
Ticket completeness as a team standard. Incomplete tickets became ineligible for refinement. The idea was not to have lengthy documentation in tickets but just enough context and acceptance criteria for any engineer to pick it up confidently. The anchor got tickets to that state before refinement; the team then estimated together from a shared foundation.
Distributed team rituals. Running standups, retros and other ceremonies did not fall solely on the shoulders of EM or PM. Such responsibilities rotated across all team members. Ownership of how the team functioned became a shared expectation. People were no longer just participants in someone else's process.
Where the team landed two months in
Within two months, the team started noticing shifts across delivery and team health.
Estimation improved noticeably. With tickets refined and ready before sprint planning, engineers estimated as a group with confidence rather than hedging individually. Refinement stopped turning into discovery sessions. Everyone was working from the same context, which meant fewer surprises mid-sprint and more honest commitments upfront. Sprint commitments started closely matching actual delivery and occasionally the team finished more than they'd committed to.
Code reviews moved faster. With business context established earlier during PRD and TDD kickoffs, PR reviews stayed focused on the code itself. The back-and-forth over scope and product decisions in review comments largely disappeared and PRs shipped more quickly as a result.
Self-service became possible. Engineers could pick work directly from the backlog without tracking someone down for context first. Because the project anchor had done the preparation work, the information was in the ticket, not locked in someone's head. Onboarding onto a new piece of work became significantly less friction-heavy.
Overall team velocity increased. That was never the goal behind distributing responsibilities, though. Engineers spent less time asking whys and whats on tickets, and no longer had to chase people for context, which freed up time for the actual implementation.
The engineering manager and product manager had less to carry. When the people responsible for team health are buried in administrative work, their capacity to do the harder, higher-value parts of their jobs shrinks. Redistributing process ownership gave them that capacity back.
Why ownership distribution works
When context is spread across the team, less of it gets lost between people and delivery improves as a result.
Teams that centralize process ownership often do it for understandable reasons. It's faster and more consistent, and it doesn't require buy-in from people who have other things to focus on. But that efficiency comes at a cost: the team becomes dependent on a small number of people to hold everything together. And those people eventually become bottlenecks or burn out.
Spreading ownership took the team's dependence on a few key people and turned it into something the whole group carried. Friction drops when people understand the why behind a decision and context doesn't depend on any single person.
The gains were better estimations and faster code reviews with fewer surprises mid-sprint. Engineers could own their own work without constantly asking for context. Managers also had capacity to do the work that actually required management.
All of this was the result of a system that was built to distribute responsibilities and motivate people to care more about how work flows.
Sukhraj Singh is a Senior Software Consultant at Test Double, and has experience in Ruby on Rails, from modernizing legacy systems to building greenfield applications while learning alongside the peers he works with.
