Building around generalists
To build around generalists or around specialists is a core architectural decision for a team. I've worked on teams that have done both, and I now lean towards building around generalists when possible.
By a specialist function, I'm referring to something that one person or only a small number of people can handle. On past teams, we've had an Oracle specialist, a front-end specialist, and a test automation specialist.
These sorts of specialization leads to queues. That is, because there's a function that only a small number can serve, work requests queue up for those people.
Queues are really expensive. Read The Principles of Product Development Flow for a detailed discussion. The quick summary: when work sits in a queue, it isn't delivering any benefits to you. Reducing the time your work spends in a queue reduces your delay cost. That is, it earns you money by hastening the point at which you can realize benefits.
When a team is built around generalists, there are many people who are capable of handling any particular queue. You can use the same strategy that Whole Foods uses in many stores: all requests can go in one queue, served by multiple generalist checkstands. When that line gets big, you can get it under control by temporarily adding someone to checkout duty. This adjustment is possible because checkout duty isn't a specialist function. Generalists lead to shorter queues and fewer delay costs.
Credit: Matt Baume via Flickr
Specialist queues are different. They're something like the line at a pharmacy counter. Not every supermarket employee can work at the pharmacy. When that line gets big, it's harder to get it under control. Specialists can lead to longer queues and higher delay costs.
In product development, specialties tend to form somewhat naturally. This isn't necessarily bad, but it becomes a bad thing when queues consistently build and when delay costs pile up. I've seen a few examples that led to this pattern:
- The person who builds it owns it. When someone rolls out a new feature, that person can end up as the de facto specialist for that feature for years.
- Early adopters become specialists. When someone rolls out a new tool or programming language, they can become the team's sole repository of knowledge for that tool.
- Some people want to specialize. I've worked with people who want to carve out a niche that makes them special. This is hardly a bad ambition for someone to have, but it can lead to queues and delay costs.
As I said, I lean towards building around generalists even though all of these pressures to specialize exist. I've seen a few ways of handling these pressures:
- Outsource specialities when possible. Consultants and vendors are often better equipped to handle specialist functions. We're likely to replace our hand-rolled queueing system, understood by only a couple of people, with Amazon's SQS. Amazon employs enough specialists to keep delay costs under control. We don't have to hire or develop those specialists ourselves.
- Despecialize. Not every specialty needs to be a specialty. The best specialists are great at making their specialty accessible to others, both by teaching and by actively simplifying areas that require deep expertise. Jerry Hsu, our most experienced iOS developer, excels here. There used to be a set of problems that only Jerry could handle, and, during the busiest times of year, Jerry would be inundated with work. Now he's trained several other developers, and his workload has naturally redistributed itself across the team. He remains our most knowledgeable iOS developer, but he's used that knowledge to enable others.
- Challenge someone. Some developers revel in taking complex special-purpose work and making it accessible to a broader group of developers. We try to hire people with this mindset and to give them opportunities.
- Staff up. Sometimes, it's essential to your business to get good at a particular specialty. In that case, the only way to avoid delay costs to staff up — not by hiring one specialist but by building a team of specialists. At GameChanger, we've gained several iOS specialists through a combination of external hiring and internal development.
Conflicts and misalignments can happen. Sometimes people on the team will want to staff up a specialty when I think we should outsource or despecialize it. These situations are tricky, and I've learned that it's best to manage them by being both honest and compassionate. At times, it may be best to help someone find a job at another company that seeks to invest in their chosen specialty.
The decision to build around generalists has been a fundamental architectural decision for our team. It attracts certain kinds of people and it demands certain types of behaviors. I find that I need to evangelize the benefits of generalists and to advocate constantly for a generalist culture.