Paired Leadership: Good Things Come in Pairs
December 16, 2011
December 16, 2011
Written by David Williams
Paired leadership was something we stumbled upon at Fishbowl while investigating XP development methodologies. A few years ago we were struggling through a growth period. Our quest was to figure out how to build high-quality software quickly and sustainably. We found an invaluable book by James Shore and Shane Warden called "The Art of Agile Development." As we went about the process of building our product management team for the future, we wanted to fix some problems we had.
For example, we had one person in charge of setting the scope of the projects and the release dates. This led to unachievable goals, which invariably led to one of two problems: the scope of the projects was too large and the teams missed their release dates, or, even worse, the product was released too soon and ended up having bugs. Assigning one person to both tasks removed the checks and balances, especially when that person was the programmer’s boss.
Secondly, our development department was lopsided. Our chief engineer/product manager had been a computer programmer for most of his career. Consequently, our product releases were driven by engineering--not by customer values or needs.
Finally, our chief engineer/product manager was out of touch with the programmers. They were not friends, they didn't trust each other, and they didn't share ideas.
To fix these problems, we did the following things:
1. We created two roles for each programming team. The first is the product manager and the second is the team lead. These two leaders are equally yoked in guiding the team. The product manager is now in charge of what we build, and the team lead is in charge of how we build it. This means the team lead and programmers determine the scope, and the product managers and customer teams determine the feature set. This builds checks and balances into the design process. No new team is created without the paired leaders in place.
2. Product managers, team leads and team members share the same space. This solves many problems in modern technology teams. It improves relationships, builds trust and removes communication barriers. We also choose the product managers carefully to ensure we balance their personalities and contributions. Teams sit together, eat together and play together. From the vice presidents to the interns, there are no private offices. People who genuinely like each other work much more efficiently together.
3) The department is led by one product manager and one technical lead. These two individuals have different skills: one is customer oriented, and the other is technology oriented. The product managers on each team report to the vice president of product development, and the programmers report to the vice president of technology. These two individuals are from one of the existing development teams. In reality, each team is a self-sufficient, working ecosystem, and the development department has very little management overhead.
The results are a work in progress, but they have been very positive so far. We build better and more customer-centric products, which I attribute to happy, autonomous teams. The team players have more trust in each other and in the leadership. When you walk into a team space, it is difficult to tell who is in charge; you see people simply working together. We are much more consistent at hitting our release dates and delivering bug-free products.
We have moved this methodology into all other departments of the company, as well. Every division has paired leaders. Neither is senior to the other. The teams work in harmony just like our programmers and testers. Our leaders work in an agile fashion, making decisions, challenging each others' assumptions, and truly creating a whole that is greater than the sum of its parts.
This is how we have been able to create award-winning products for a customer audience that is becoming larger and more diverse with every product revision and is requiring us to grow our technology features at a faster pace.
When we talk about Extreme (XP) Development, we are referring to the full extent of the concept, applied to every single department and role in our firm.
David K. Williams is a national speaker and author on business leadership who has served as CEO of the award-winning software company Fishbowl since 2004. He also holds leadership roles at UVU and BYU and is a member of the Utah Technology Council.
Kevin Batchelor, Fishbowl's vice president of programming, and Heber Billings, vice president of technology, contributed to this article.