I have been thinking about the shape of teams. I have built software products in teams as small as 1, and as large as “I don’t actually know everyone who is involved in this project”. You are probably not shocked that I prefer closer to 1 than infinity (ignoring the fact that we all build on the shoulder of computing giants!)
What is the ideal size for a team? It obviously depends on the problem, but I have changed my view over time. For awhile I would see the skills that I lack, and think of the roles that need to fill in the gaps.
- You need a developer to write code (and then there is front end vs. backend)
- You need a visual designer to create assets
- You need a UX person to get the right experience
- You need a product manager to define what we are building and garden the backlog
- You need a QA person to test the application
- You need a project manager to keep everything moving and unblock blockers
- … and you can keep going …
For some projects this can make sense, but for many…. maybe it is overkill?
The other extreme is the team of 1. There are some real advantages to a team of 1:
- Easy to build consensus :)
- The entire team thinks the same way.
You often here the “Linus was able to do the core of Linux by himself” (even though it grew into a case study for distributed collaboration). Solving a narrow problem can be ideal for 1, especially when they can collaborate in a loose way with others. We have been doing this in academia for a long time.
In the modern time I look to folks like Joe Hewitt as people who can go off and do something brilliant in a short time with their style. If you look back at the early Firebug your hair may curl when you see his with()y style. Pairing him up with the wrong person would not be productive. He also happens to be solid at all of the other skills (not just a great developer). He is a perfect “Product Engineer”.
Two heads are better than one
I am often a fan of pairing up on problems. There is a reason that I love working with Ben for example. The advantages here are:
- You have a built-in sounding board / reviewer
- If you complement each others skills, the match can be golden.
One of the pairings that I really enjoy is that of a product focused designer and a product focused engineer. I have seen more and more companies with job openings that they call “Product Designer”, but I have only just started to see the “Product Engineer” term. I have changed the view of myself and my roles over the years (developer, engineering manager, advocate, technologist) and I often have conversations with myself (bicameral mind and all) about what I want to be when I grow up. I find this hard because I like each of those roles. When I am in the mood to be a “maker” I find myself much more interested in the software product than the pure technology that gets me there.
Thus, I enjoy being a “Product Engineer”. Someone who doesn’t sit in the corner hacking up some code, but someone who loves building products with software, and programming is the tool at hand.
One of the reasons I am so impressed with the GitHub team is that they tend to hire product engineers. It helps greatly that the product they are engineering is something for a developer, so they don’t have to dig deep to see how their user base would want something to work.
Every team is different. If the engineer on your team is an amazing hacker but just wants to be told what to build? get a strong UX/PM to cover that role. There is no “right structure” for all projects with all types of people.
When I think of developer super heroes though? I will be day dreaming of the “Product Engineer”, “Product Designer” duo. And, at the very least, I will make sure that my engineers are as invested in the product as they want to be, and that my teams are as small as possible (but not smaller).
