4 ms·

It's good, sound advice. Big teams are inefficient teams. They are harder to manage. They waste more time in meetings. And they lack focus. The easiest way to f

It's good, sound advice. Big teams are inefficient teams. They are harder to manage. They waste more time in meetings. And they lack focus. The easiest way to fix broken teams is to remove people from them. You don't have to fire them. Just put them in other teams or create some new teams. This does wonders for cutting down on the stress levels, heated debates, and other wasted energy that plague overstretched teams with too many captains on the ship. I would not even wait for problems to emerge. Just split big teams on principle. Minimum size of 3. Maximum size of 7. One eight person team then becomes two teams of 3,4,or 5 people. Make sure each team has a tech lead that knows what they are doing. Don't over-staff teams with managers/minders/scrum masters/whatever label you slap on junior management. This causes a big problem: managers like to hoard people to inflate their importance. You deflate their team and you deflate their ego and they'll be forever whining to "fix it" with more "resources". Simple solution: give them more than 1 team to manage and direct them to keep their teams small. Now they count teams instead of people. Or teams and people. And you can measure their success as a function of how well their teams are performing. Then if those teams get overloaded, you have a conversation about which new teams are going to be needed and who is going to manage them. Any new team should be bootstrapped with mostly existing people: you move people around and promote them. New people start out in existing teams. This accomplishes two important things: people have a perspective of getting promoted sideways and new people learn the ropes in a small well functioning team rather than being dumped in an overstretched team.

nine_k 4y ago
+100. When during a job interview they ask me what was the size of my team, I invariably say something between 2 and 5, and comment that a larger team cannot be efficient. At least, in my practice a larger team was never efficient as a team, and I helped split teams as they grew past this threshold.
tetromino_ 4y ago
> Minimum size of 3. 3 is risky. One person has a baby and goes on leave, or gets long Covid, or is poached by a FAANG. Until a substitute can be found, the team of 3 turns into a rather overwhelmed team of 2, each spending 50% time on call. And if either of them goes on vacation to recharge, the remaining one is left with an unbearable workload.
- martin_a 4y ago
  That's exactly the situation with my two teams now. Make teams of 4.
  - dmitriid 4y ago
    I've worked in a team of 4 (and later, of 5), and it was amazing: everything could still be communicated quickly, but you didn't feel overwhelmed if a team member was inaccessible.
- tpankaj 4y ago
  My team is 3 right now and 33% time oncall is still pretty bad.
  - ecshafer 4y ago
    The biggest source of relief for oncall for me is that even though my "team" is 8 people. We work on larger systems. We have ~5 teams working on a single code base, so around 30 people. Its not really a microservice, but its not really a monolith (since we have many other, and larger codebases). On call is much more bearable when its once every 3-4 months than once a month.
  - beberlei 4y ago
    Genuine question, Is the software not reliable? How often do you get paged? We have 33-50% on call and noone complains because not a lot is happening.
    - hn_go_brrrrr 4y ago
      Being on call requires being pageable and able to respond. This seriously curtails your ability to live your life. For instance, you can't decide to go hiking over the weekend on a whim, because you couldn't handle an incident, were one to occur.
- marcosdumay 4y ago
  I imagine those restrictions on team size only apply to pure development tasks. You certainly want more than one of those teams to be able to support each piece of your software. You also want to be able to move people quickly from a team to a close one, so from the training point of view you also want them to know both codebases.
brightball 4y ago
I saw a good chart that explains the issues as teams grow by showing the lines of communication between team members as the size of the team grows. If you draw a dot for each member of a team and then a line from each dot to each other dot, you can see the "lines of communication". With 3 members, there are 3 lines of communication (loc) 4 members, 6 loc 6 members, 15 loc 10 members, 45 loc 14 members, 91 loc Communication breaks down as more people are involved.
- bombcar 4y ago
  This is the inverse of Metcalf's law: https://en.wikipedia.org/wiki/Metcalfe%27s_law https://en.wikipedia.org/wiki/Metcalfe%27s_law As you get more and more lines of communication you end up having to break them and create a hierarchy.
- alexpetralia 4y ago
  Metcalfe's law succinctly explains why communication becomes more fraught as teams and organizations grow. Good managers minimize this quadratically rising cost.
- mateo411 4y ago
  LOC = n(n - 1)/2 This is the same as the number of undirected edges in a N clique graph with no self edges.
froh 4y ago
have you worked in set ups like this? what was the tricky thing to get right?

nine_k 4y ago

+100. When during a job interview they ask me what was the size of my team, I invariably say something between 2 and 5, and comment that a larger team cannot be efficient. At least, in my practice a larger team was never efficient as a team, and I helped split teams as they grew past this threshold.

tetromino_ 4y ago

> Minimum size of 3. 3 is risky. One person has a baby and goes on leave, or gets long Covid, or is poached by a FAANG. Until a substitute can be found, the team of 3 turns into a rather overwhelmed team of 2, each spending 50% time on call. And if either of them goes on vacation to recharge, the remaining one is left with an unbearable workload.

martin_a 4y ago
That's exactly the situation with my two teams now. Make teams of 4.
- dmitriid 4y ago
  I've worked in a team of 4 (and later, of 5), and it was amazing: everything could still be communicated quickly, but you didn't feel overwhelmed if a team member was inaccessible.
tpankaj 4y ago
My team is 3 right now and 33% time oncall is still pretty bad.
- ecshafer 4y ago
  The biggest source of relief for oncall for me is that even though my "team" is 8 people. We work on larger systems. We have ~5 teams working on a single code base, so around 30 people. Its not really a microservice, but its not really a monolith (since we have many other, and larger codebases). On call is much more bearable when its once every 3-4 months than once a month.
- beberlei 4y ago
  Genuine question, Is the software not reliable? How often do you get paged? We have 33-50% on call and noone complains because not a lot is happening.
  - hn_go_brrrrr 4y ago
    Being on call requires being pageable and able to respond. This seriously curtails your ability to live your life. For instance, you can't decide to go hiking over the weekend on a whim, because you couldn't handle an incident, were one to occur.
marcosdumay 4y ago
I imagine those restrictions on team size only apply to pure development tasks. You certainly want more than one of those teams to be able to support each piece of your software. You also want to be able to move people quickly from a team to a close one, so from the training point of view you also want them to know both codebases.

brightball 4y ago

I saw a good chart that explains the issues as teams grow by showing the lines of communication between team members as the size of the team grows. If you draw a dot for each member of a team and then a line from each dot to each other dot, you can see the "lines of communication". With 3 members, there are 3 lines of communication (loc) 4 members, 6 loc 6 members, 15 loc 10 members, 45 loc 14 members, 91 loc Communication breaks down as more people are involved.

bombcar 4y ago
This is the inverse of Metcalf's law: https://en.wikipedia.org/wiki/Metcalfe%27s_law https://en.wikipedia.org/wiki/Metcalfe%27s_law As you get more and more lines of communication you end up having to break them and create a hierarchy.
alexpetralia 4y ago
Metcalfe's law succinctly explains why communication becomes more fraught as teams and organizations grow. Good managers minimize this quadratically rising cost.
mateo411 4y ago
LOC = n(n - 1)/2 This is the same as the number of undirected edges in a N clique graph with no self edges.

froh 4y ago

have you worked in set ups like this? what was the tricky thing to get right?