Collective Accountability and Quality

There was a point in my life when I loved being the hero. I would pull all-nighters working on a technical problem. The thrill of finding the solution muted the sheer terror I felt at 3:00 AM, knowing that I had nowhere to turn for help. The problem with being the hero is that you soon become the bottleneck, and the praise for the initial solution is lost due to the frustration of stalled progress.
At some point, I decided this was no way to live. The stress of the hero going on vacation, quitting, or being so overloaded that nothing could get done drained everyone and greatly informed how I structure and manage teams. It turns out that the simple idea of having no heroes was a stepping stone to profound changes in accountability and quality. In most organizations, each team or system has a hero—the person who is always called upon for anything related to the need. Removing the hero helps move beyond individual accountability to collective (shared) accountability. In hindsight, the connection is obvious, but I came to this understanding organically.

The examples below for removing the hero are from an engineering team I managed, but these concepts still apply to any creative team (see Cultivating Self-Managing Teams). Here is the sequence of tactical changes I made:

• If the same person always picked up a particular type of work, I encouraged (and later directed) others to do it, even if it took longer. This was moderately successful but quickly broke down when something was urgent, or the team was overloaded.
• I stopped going only to the most senior person on the team when there was a production issue. I posted the problem in a team forum. Every single person rose to the challenge.
• We adopted mob programming (slowly). Mob programming is basically group design and initial coding, then often (not always) moving to individuals to complete the implementation.

Mob Programming (Group Work)

Mob programming was the turning point. After a lot of trial and error, the following ended up happening:
​

• The person who knew the system the best shared everything they knew. The team asked questions and collaborated on the change. Later, this led to organic refactoring (making old stuff better).
• Everyone understood what design decisions were made and why they were made. This made pull requests (code reviews) a formality that took virtually no time.
• The engineers regularly pulled in Product Management during design, which eliminated implementation surprises that needed to be changed late in the process.
• Within a year, anyone on the team could handle any technical issue or task. This is not hyperbole. Everyone on the team was genuinely interchangeable.
• All of this upfront communication increased the team's throughput by 25% simply because they caught most changes before the final implementation.
• What did it do for quality? We basically eliminated all production regressions (breaking things that used to work). Every substantive design was discussed from multiple perspectives. Rework was dramatically reduced.

​Why Did This Work?

​

• We continually gave the team space to learn and make mistakes. They learned to trust each other and their management (see Foundation of Trust).
• The team created their own working agreement and continually updated it as we evolved. This codified what collective accountability looks like.
• We made transparency paramount (see Foundation of Trust).
• Everything they did was viewed through the lens of a team, not an individual. It quickly grew to include Product Management, UX, and IT as actual team members.

​The necessary elements to make mob programming (or any team creative endeavor) work lead to accountability and higher quality. Both grew organically from a sense of safety. Always do everything possible to resist a hyper-focus on accountability without an established trust/psychological safety baseline. In addition, the team should establish what accountability (working agreement) looks like to them. That base level of ownership will permeate everything and turn into collective accountability.

What Is a Working Agreement?
​
Contrary to what an initial impression might be, a working agreement isn’t a draft contract. It is an agreement on how to work together. It might include specifics for the following areas:

• Communication Protocols
• Meeting Guidelines
• Decision-Making Process
• Code and Quality Standards
• Work Hours and Availability
• Conflict Resolution
• Learning and Improvement
• Respect and Inclusivity

Working agreements are continually in flux but rigorously followed. After any lessons-learned session, they are updated. They exist everywhere, but we may not always think of them from this perspective. Some common examples include parent/teacher communication, sports team conduct, and meeting ground rules in community organizations. Even Robert’s Rules of Order is a working agreement!

In Conclusion

​Despite the glut of collaboration tools and frameworks today, fostering an intrinsically collaborative mindset takes tremendous work to make it part of your team's core identity. It is worth it.​

<< ​Foundation of Trust

Teaching Autonomy >>