I worked at a company where a DevOps team was 5 to support a team of 35. They hired someone incredibly talented, knowledgeable and driven for change. They shrunk in size and are still over capacity and could now be 2 only.

Don't look at headcount to gauge complexity, difficulty, etc.

What I've experienced is the larger the team the more likely to have dilution of ownership. The less ownership the less likely each person will spend the energy or fully understand solving root causes.

Oddly, I'd say headcount can often be a driver of complexity.

In two ways, one being that more people legit need a more complicated system. You want that so that they interact with the system, not with each other.

The other being a bit of a Parkinson's Law. That is specifically that you will expand work to fit the allocated time; but I posit that you will also expand work to fit the people doing it. So, more people pushing ideas into the codebase will keep more ideas in the codebase. Even if fewer would work.

Any build system is a nightmare when you don't understand it. I don't know what that team moved to Bazel from. I suppose it was Makefiles, and I'm sure if that's what the team was using, almost all of those 25 people did not understand them either.

What parts of Bazel were a nightmare? What problems were fixed by these 4-5 people that were previously impacting all 25 people routinely?