Comment by PragmaticPulp | Hacker News Reader

Comment by PragmaticPulp | Hacker News Reader

My worst job ever was at a big company whose CEO believed that small teams and low headcount were the answer to everything. I was attracted to the company because I had enjoyed working in small teams at startups before.

It was awful in a big company, though. We were always short-staffed on everything we did. The CEO chronically underestimated how much work went into maintaining existing products or even just extending them. He wanted to treat every new initiative like a mini-startup that could move fast with small headcount, which led to tens of isolated teams building products that were incompatible with each other and not communicating about it. Coordinating with other teams would slow you down, so it was basically forbidden. But then our customers expected things to work together, so we had to scramble to re-integrate everything before it shipped.

Taking vacation was difficult because it could mean 20% of the team was gone, which would have measurable effects on delivery. Every time someone left it was a scramble to re-hire and re-train because it left such a huge hole in the team.

Hiring too many people is a problem, but trying to keep teams artificially small is also a problem. The hard part is knowing how close you are to "too big" or "too small", which is rarely obvious at the time.

> treat every new initiative like a mini-startup

> Coordinating with other teams would slow you down, so it was basically forbidden.

Are you sure team size was actually a factor? I've seen rules/cultures like these before and they always end in disaster, regardless of team size.

Small teams that actually coordinate, on the other hand, seem to do just fine in my experience. In fact, one of the biggest problems with oversized teams is the combinatorial explosion of communication channels https://project-management.info/number-of-communication-chan...

Heh, I used to have so many opinions on how to run software companies. Ideal team sizes, methodologies, remote vs office.

Now I'm seasoned with enough experience to know that no matter what the "best practice", some companies out there will screw it up.

Whatever past successes I experienced in teams I was a part of, I was wrongly attributing to these various rules of thumb (such as team size).

There's a great quote in the XP book that boils down to, "Never follow any rule or practice thoughtlessly. The important thing is understanding WHY you pair program, or TDD, or use CI/CD." If you have a Jenkins pipeline but are getting none of the benefits of CI, then there's really no point in having it. Same goes for any practice or tool.

Team Topologies provides some good info around team size, and how to split teams when they get too large: https://teamtopologies.com/

I recall someone talking, possibly here, about how they limited this a bit.

One of the expected outcomes of Agile is that the business has to acknowledge some of the realities (logistics) instead of just living in a fantasy word where how they think things works is real and if things aren't happening then it must be someone else's fault.

Anyway what they said is they had about 8 projects and 3 teams, some of which worked on the same projects, some which only worked on a subset. Rather than trying to juggle all 8 products, each sprint was about one product, and the product owners had to thumbwrestle over whether the next cycle was one (or possibly two) of theirs. Pretty much you could only count on 1-2 sprints a month, unless you were involved in some high visibility mandate.

But at the same time, old projects still existed as an ongoing concern, just with intermittent attention.

Thanks for your insightful comments. You're right; the hardest part is to find the balance between too big and too small headcount. It's challenging and it differs a lot per department, company size etc

Well, to be clear, it was great for the CEO

Reply on news.ycombinator.com