Individual vs Team Ownership

 

Team ownership is tough. Organizations (and people) struggle with the concept. It’s a challenge to separate the idea of sharing responsibility for an outcome, and owning something outright.

Individual ownership = mine

Teams that focus on individual ownership have a lot of processes. There is a process for getting each piece of information to the right person at the right time, and each person fills a role and has certain responsibilities. Each person owns the documentation and process for their own role, and other team members should work through the owner if they have recommendations, questions, or any updates.

This can be efficient if everyone fully understands and supports the process, and everything is running smoothly. However it can be a challenge if the document/phase owner is unavailable, or the communication is unclear (without a clear call to action), or technology fails in some way.

Team ownership = ours

Teams that focus on team accountability have a lot of conversations rather than processes. They don’t just hand things off by throwing work over some mystical wall that separates functional silos.

Instead these teams share responsibility, knowing that each individual on the team is responsible for each task and deliverable. These teams hold themselves, and each other, accountable for the team’s overall success. This doesn’t mean that everyone does every role all the time – that’s unmanageable and impractical. We all have different skillsets and strengths.

Accountability means that:

• A handoff is more than sending an email, or assigning an issue or ticket to the next group. Perhaps the handoff is a conversation to confirm that all of the relevant information is included, and that the next steps are clear. Perhaps the handoff happens in a working session in which all team members accomplish the team’s needs together.
• Every member of the team shares both the responsibility and the ability to impact each step. A BA may create requirements, but also has a clear idea of what the developer will need in order to best follow those requirements with minimal roadblocks. Questions and assumptions are discussed to be sure that everyone has a common understanding. (In my case, I even contribute to code quality, mostly by never ever touching the code – but that doesn’t make me any less accountable for the overall results that the team produces.)
• Each team member speaks up with any concerns or questions. Everyone speaks up, ask questions, and contributes to the success of the team. This can include addressing requirements that may be unclear or missing, discussing points of confusion, confirming that the team has common understanding about the topic, and more.
• The team is based on trust and communication. As a project manager, I’m responsible for creating and maintaining the project plan, but I don’t create it in a vacuum. A project manager should get input from the team every step of the way. Other team members can make updates to the project plan – the team owns it as part of the project. The team should communicate so everyone is aware of any updates, and to discuss any questions or differing opinions as a team. In the same way, a PM may contribute to requirements, assist with testing, etc., which doesn’t mean they’re trying to take over the roles of BA or QA… it just means that every team member is there to help, and should welcome the same help from the team.

I’m not advocating a full re-organization of all teams – there’s enough of that sort of thing in many of our industries. I simply ask that as project managers, we help our teams and lead by example, focusing on open communication, trust, and a commitment to hold ourselves and our teams accountable to the shared goals of the team.