Team Composition

I’ve only been working for a 3 years, so I don’t think that I’m anywhere near the best person to ask about building strong performing teams. I actually think I’m not a good person to ask about building good team. In my short career, I have built opinions about the types of teams I like to work in.

Senior vs Junior

When I first started working, I found myself on a team with 3 staff engineers. This was a really lucky situation for me. During the first year and a half that I was on that team, I learned more than I would in any other situation. The stronger engineers on the team understood that it wasn’t the job of senior engineers to crank out the most features or write the most tech specs. It was their job to mentor and unblock other engineers. This is one of the highest leverage (impact/time spent) task they could spend their time on.

When I first started working, I was pretty useless on my own. As the more senior engineers spent more time mentoring me, and as I spent more time working, I could be more effective and lead bigger projects. When I think about strong team composition, I don’t just think about how many Senior vs Junior engineers are on the team, I think more about who is a strong mentor/mentee pair and how do the two grow from each other. Too many mentees, and junior engineers aren’t growing. They don’t feel productive, then they don’t get to own as much, then they feel unhappy and leave. Too many mentors, and you’re wasting resources.

Han Solo and Chewbacca

I read Radical Candor by Kim Scott last year because it was recommended to me by my company. While I was reading it, there was a section that talked briefly about team composition. She talked about “Rockstars” and “Superstars”.

Rockstars were strong contributors that pushed clean code and were productive members on the team, but didn’t need the “spotlight” anymore. They generally weren’t looking to lead the entire org into the next phase of development. Their contributions are local to the team and they spend their time mentoring new engineers, writing tech specs, etc etc. Now, this just sounds like a strong engineer until I introduce the “Superstar”.

Superstars are still on the way up. They look to attach their name onto high profile OKRs. They try to lead multi team efforts and direct the org from a higher level. They’re concerned with promotions, visibility, and execution.

Now, why did I name this section Han Solo and Chewbacca. In my experience, the Superstars are like Han Solo and Rockstars are like Chewbacca. You need both, but Han Solo causes much more controversy. People either like him, or want to kill him. Likewise, I’ve found that Superstars are controversial within an org. Some people will rave about Senior Engineer X, but others will say they’re a dick. On the other hand, everyone loves the solid contributor. The loveable Chewbacca is a rockstar. Chewbacca doesn’t make large, cross-team projects, so they don’t have a chance to make bad impressions. Chewbaccas generally just work with their immediate team, who they have a strong rapport with.

Size

Amazon has something called the “2 Pizza Rule.” The basic idea is, pick a team such that two pizzas could feed them. Don’t over index on the pizzas. I’ve found myself on a “team” that got divided into smaller “sub-teams” where each “sub-team” is led by an IC, then all of us report to our actual manager. There are 3-4 people in a “sub-team” and 3 “sub-teams” in the “team”. It’s confusing, but there are pros and cons.

Meetings can be a lot smaller, so that’s nice, but it generally feels like the IC leaders on each “sub-team” are managers and we just turned a team of 1 manager and 14 engineers to a team of 4 managers and 11 engineers.