Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ask HN: What breaks first when your team grows from 10 to 50 people?

news.ycombinator.com

Post reply on HN
Print view View original

61–70 of 85 posts

Re: Ask HN: What breaks first when your team grows from 10 to 50 people?

#61

Post by hennell »

The more people you have the more processes you need. With 5 people the same person usually does the same things or they've seen the person who usually does it do it. So they do it in the same way, know the tricks or who to ask if it goes wrong. Your working environment is usually small, communication fluid, so people just know what goes on and how it works.

As you get larger you see what you're seeing - not everyone is in on the meetings, knowledge in one person's head isn't shared and people don't know who to ask.

I worked on a simple barcode database setup years ago. Originally it was just a spreadsheet one person 'owned'. Then I made it into a webapp that I and original owner could both add items to - enforcing unique entries and validating checksums (plus an API I could querry). More process, but still a lot was in our heads. When a 3rd person started using it, they added something in lower-case (we always wrote refs in caps) and a variety of case sensitive bugs were found. I had to fix the DB manually and started adding hints and validation.

The more people you have using something the more problems you will have and the less feasible it is to walk everyone through the system in person!

Documentation, make process, make efforts to share knowledge. No way around it.

Re: Ask HN: What breaks first when your team grows from 10 to 50 people?

#62

Post by juancn »

Not a lot, over 100 it's a different game.

At 50 it start showing signs of stress as people that knew everything no longer do so. High performers suffer and start feeling left out, because they lose some autonomy.

It particularly impact those whose scope narrows and they liked the broad scope. Those types thrive in startups, but suffer as more structure is added.

Make sure they are fully utilized and don't get bored or you'll lose them, they like to pick what's important for them to work on.

Re: Ask HN: What breaks first when your team grows from 10 to 50 people?

#64

Post by agcat »

I have been at this stage and failed at it. So i can tell you things not to do:

- It also matters at what PMF quality stage you are, like we were at a weak PMF when we started scaling from roughly 12 to 25.. and i hired leaders who used to report to me. So i lost touch with people on field. ( I should have kept things flat)

- Hired too many managers instead of IC.

- Focussed more on growth v/s retention

Re: Ask HN: What breaks first when your team grows from 10 to 50 people?

#65

Post by necovek »

paulcole wrote: post #45
RobotToaster wrote: post #42

Earlier quoted context omitted.

The obvious solution is to promote them. If you don't reward loyalty don't expect loyalty.

But if you reward loyalty over skill then don’t expect skill to stick around. Some people have 5 years of experience and some people have 1 year of experience 5 times.

Since we are a bit nitpicking here, I'd also say don't reward skill, but actual value instead. You can have someone very skilled who is all smarty-pants and derails anyone wanting to actually, you know, do something.

Thus I'd give the previous poster some leeway too, and read their (but also your message) as: there is an implied basis of skill and value you expect early employees to continue bringing to the table, but when that is satisfied, reward their loyalty too (either with promotions or money or status or stock or...).

Re: Ask HN: What breaks first when your team grows from 10 to 50 people?

#67

Post by h4kunamata »

* Communications: It is the first one to go, people are always "busy" to listen

* Ownership: "this is my project and nobody touches it without me"

* Too many meetings: This happens even with small teams. Hours wasted for nothing

* Hiring people very good at telling history rather than having actual skills

Put them all together and you have the perfect storm.

Re: Ask HN: What breaks first when your team grows from 10 to 50 people?

#68

Post by kirubakaran »

Team knowledge is the first thing to succumb to chaos, in my experience. This is the reason I'm building https://hyperclast.com/ When everything you used to take for granted to be in everyone's "L1 cache" is no longer there, things slow down real quick.

Re: Ask HN: What breaks first when your team grows from 10 to 50 people?

#69

Post by kohexo »

le-mark wrote: post #29

Early employees often have difficulty with the new reality. In the early days everyone is involved in making product decisions, helping with sales by implementing features, doing support for customers. If you hired juniors this is all they know. Everyone doing everything is exactly what you don’t want in a larger organization. You need structure, you need dedicated teams for CX, product, development, QA, etc. Often e…

That’s something I’ve never thought about. It’s a valid point and somewhat understandable.

Re: Ask HN: What breaks first when your team grows from 10 to 50 people?

#70

Post by dwd »

le-mark wrote: post #29

Early employees often have difficulty with the new reality. In the early days everyone is involved in making product decisions, helping with sales by implementing features, doing support for customers. If you hired juniors this is all they know. Everyone doing everything is exactly what you don’t want in a larger organization. You need structure, you need dedicated teams for CX, product, development, QA, etc. Often e…

A hard change is the required skills mix.

Early stage you want the generalists who can do everything, move fast and probably break things.

There's an inflection point where you want to stop breaking things and for that you need specialists. Experts in scaling, security, optimisation and code purists.

Finding new roles for your generalists at this point could be hard, even harder will be having to let them go. It's possibly something you should consider at the start and give them the ability to vest and leave for a new greenfield. Alternatively find them a role as an architect/lead where it's their responsibility to be across everything and able to bridge between teams because they have your domain and institutional knowledge.

Post reply on HN