Until recently, each new project I had worked on had a bigger team than the last, culminating a year ago with a team of eight to relaunch RadioTimes.com (an architect, three devs, one UI dev, a tester, a technical project manager and me, the product owner). This was in addition to a third party tech supplier and design agency. That’s a lot of people to create something together.
After we launched, the team got smaller and became four (two devs, one UI dev and me). I performed the role of product owner and our UI dev and I picked up design tweaks between us. Al, one of our devs acted as our scrum master.
Recently I’ve been building iPad apps where we use only one developer who has absolute ownership of the product from a tech perspective. They work in a (slightly) bigger team, pair programming when they get stuck, but they have their own projects.
I’ve been surprised at how productive this form of working is. Although the iPad projects have had little in the way of backend heavy lifting, which is clearly in part responsible, I would put it down to two things.
1. Ownership
The more ownership somebody feels of a project, the more enthusiastic, committed, responsible and proud they become. This leads to more, high-quality work being done. The more people covering the same discipline, the more diluted is this sense of ownership, the more compromises are made, the more creative tension there is (some is good, lots slows you down). The best people, like to own something. And ownership leads to products with character, passion and soul.
2. Communication
A small team working closely together are constantly communicating, aligning their views and know what each other are doing. Project management becomes easy if everyone is talking to each other. The more people are in a team the more talking is required and the less doing gets done. It also leads to overheads like code branching and merging that takes time.
Smallest and biggest
My experience tells me that three is probably the smallest team that can practically deliver a high quality product. And this can feel tight if you have lots of stakeholder/client management to do. But also that eight is the biggest team that can move quickly and feel real ownership. Beyond that speed, productivity and passion drops.
(Note, you can have more people building a bigger thing, but divide them into cross discipline teams that have ownership of specific areas.)
Band vs orchestra
Having played in bands in the past, I firmly believe a dev team is like a band. You get the same creative battles, the same camaraderie, the same collective sense of pride over something you made together. They’re self organising and require little formal project managing.
The smallest band is generally a power trio (treating The White Stripes as the exception that proves the rule). A band that has more than eight becomes an orchestra. And an orchestra is a very different thing and requires a different way of managing things with a band leader/conductor. At that point, it stops being self organising, communication is top down and you lose the sense of ownership. Most bands have between three and six members.
So when building your team my advice would be to think, do I want a band or an orchestra? Can we do with less people? Is there skills cross over that could lead to a dilution in the sense of ownership or worse, conflict? (Some band have two drummers but it’s unusual and generally they have very different styles).
Having got to the point in my career where I was conducting an orchestra, I discovered what I really wanted to do was play in a band.
