People are without a shadow of a doubt a software organization’s most important asset.
So how should you organize your people and teams to make them flourish and deliver great software?
Organize around Products (not Projects)
ThoughtWorks, a major agile consulting firm, recently encouraged its clients to think in terms of products over projects. The commercial reason is that a software product is never done, but needs to be improved and extended for as long as the software is used. This is even more true today when businesses need to adopt faster than ever before. You simply cannot deliver a project and think that you’re done.
But beside the commercial benefits, you also get a productivity boost by using product teams.
Software veteran Robert Martin (i.e. “Uncle Bob”) wrote in The Clean Coder that the banks and insurance companies, which he consulted for over the years, formed temporary teams around projects. The drawback of this approach is that a team never works long enough together to “gel” (meaning: become a true team and work super-effective together). So he recommends that you keep stable teams, so they can continue to work together after they have gelled and then you feed new projects to these existing teams.
Another benefit of product teams is that it takes time to understand the core domain of the business, to learn the in’s and out’s of the product itself, and to master the technology stack that the product uses.
How do You Organize a Product Team?
So if product teams are this good, how do you organize them? My idea of a great product team is heavily inspired by how they work at Spotify:
Each team is an autonomous team in pursuit of a mission. It acts like a mini-startup, and the organization around the team acts as a startup accelerator that helps the team with advices and knowledge to create and nurture a successful product. The team is a team of peers, where nobody has authority over anybody else, but where the best idea is expected to win.
The Product Owner is an entrepreneurial type who wants to create a great product that the customers love. The product owner guides the team on “what” to build next, but is not involved with how the team members do their work (i.e. should we use Test-driven Development?)
The Competency Leader is the technical leader who sets the standard for good software craftsmanship. The competency leader guides the team on “how” to build it well. The role is focused on technical mastery, and is not involved in coordination or other traditional tech lead activities. The competency leader role is an add-on role, and the person who fulfills this role also works as part of a team to avoid becoming stuck in an ivory tower.
A healthy tension is to be expected between the Product Owner and the Competency Leader. If they were working alone, the Product Owner might compromise the craftsmanship to meet optimistic deadlines, and the Competency Leader might be so focused on perfecting the product that nothing would ever be shipped.
So why do I think that this product team would be effective? Because it fulfills the three basic needs that science tells us must be satisfied to light the inner fire in people (i.e. competence, autonomy, relatedness). The team is autonomous, the competency leader helps the team members pursue mastery, and the product owner creates a compelling mission that the team rally around.