Comment by jillesvangurp | Hacker News Reader

Comment by jillesvangurp | Hacker News Reader

Parent Full thread

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.

> 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.

My team is 3 right now and 33% time oncall is still pretty bad.

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.

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.

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.

That's exactly the situation with my two teams now. Make teams of 4.

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.

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.

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.

This is the inverse of Metcalf's 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.

Metcalfe's law succinctly explains why communication becomes more fraught as teams and organizations grow. Good managers minimize this quadratically rising cost.

LOC = n(n - 1)/2

This is the same as the number of undirected edges in a N clique graph with no self edges.

+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.

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

Reply on news.ycombinator.com