Nate Clark's Musings

Back in 2019, I went from managing a team of ~30 people to a team of ~300. This was a pretty drastic change that required learning all sorts of different skills and ways of operating. One of the questions that bothered me most at the time was, what is the best way to structure an organization? How many people should be on each team? What should the reporting structure look like? That sort of thing.

Finding answers to those questions was surprisingly tricky. There were many anecdotal answers from people who had experimented on their teams, but little in the way of peer reviewed academic work with statistically significant sample sets. There are certainly tradeoffs to be made as well with different designs, but I was curious if there’s any broadly applicable truths. Below is a summary of the best resource I came across at the time.

Get on with it already!

Ok, according to the best science available…

• Smaller teams are more effective at sharing information, reaching decisions, and generally show improved employee motivation since it’s easier for individuals to see their direct contribution toward goals. But if a team is too small, their target scope must decrease, and it creates friction when projects cross team boundaries. (Insert obligatory reference to Conway’s Law and the inefficiencies that can arise here). A lot of other research points to the optimal software team size being in the 3-8 person range.
  
  
• Teams should be organized around a clear scope of responsibility. This scope should be as broad as is reasonable, as broad scope enables greater agency, meaning teams have control over as many aspects of their responsibilities as possible.
  
  
• Teams should have clear goals. This should go without saying, but as the organization grows the importance of being explicit increases dramatically.
  
  
• Teams should interact with other teams to share best practices in order to make each other more effective. This communication ideally should be horizontal rather than hierarchical (up and down the org chart).
  
  
• Effective hierarchy helps facilitate information sharing across teams, helps empower teams if they need assistance from other parts of the organization, provides useful advice, and to holds the teams accountable for delivering on their goals. To the extent the hierarchy does not do this, it only provides friction. You can see much of this reflected in my post about Expectations for Managers.
  
  
• Mentorship and professional development are very important, but they don’t necessarily need to come from a formal manager. That’s an orthogonal concern.
  Similarly technical leadership doesn’t necessarily need to come from a formal manager. There are many examples of people with very strong technical skills that are less effective at, say, communicating goals or getting help from a different team.
  

Looking back on these points, a bunch of them seem obvious, and possibly a little vague. Given the natural tradeoffs in organizational design it shouldn’t be surprising that there are few maxims applicable to every organization. Seeing these points is still useful as a checklist to ensure people are hitting the basics though. I’ve personally incorporated these points and feel like they worked well for my team (caveat being, again, sample size of one), and they closely align with many of the best anecdotal answers I’ve come across later as well.