I’m interested in hearing how AI tools fix (or don’t fix) this problem.
Ask HN: What breaks first when your team grows from 10 to 50 people?
21–30 of 85 posts
Re: Ask HN: What breaks first when your team grows from 10 to 50 people?
#22This might not be the first to break, but it will eventually, and if corrected NOW will make things much smoother: Your documentation of processes and procedures is NOT adequate. 'everyone used to know about are getting lost' - oh good thing your documentation makes this clear, because it is obviously their fault. 'New hires take forever to ramp up' - oh good thing you have complete ramp up plan and documentation, be…
So, documentation is the solution? But do people have time to document everything?
> But do people have time to document everything
And to read everything. And to find it.
I find documentation is often meaningless or worse -- in networks you find people documenting IP addresses on static pages like confluence pages or powerpoint presentations. That isn't important. Sure it should be in a single source of truth -- emphasis on the single -- but if isn't, it's not the end of the world.
A new employee can see that router 1 is connected to router 2 by looking at the config. What they can't do is tell you why its connected. And why the route filters are the way they are. The how is easy to reverse engineer, but documentation should start with the why. Anyone changing something can then make an informed decision about whether the new solution still meets the why, or if the why isn't relevant any more.
Why are we using this architecture, why are we using an ec2 vs lambdas (or vice versa), why are we putting this infront of cloudfront and this direct, why is this in us-east-2 and this in eu-west-1.
A quick look at the teraform, or even manual things like "ec2 describe instances" tells you what's deployed, what the IP addresses are, what vpcs are connected.
It doesn't tell you why, that's where documentation comes in.
Re: Ask HN: What breaks first when your team grows from 10 to 50 people?
#23Culture. I don't really know what you can do about it other than considering it in hiring, especially for roles that will influence it (i.e. leadership and any sort of internal function as opposed to revenue-generating) and being aware of the impact they might have, whether intentionally/philosophically or just as a byproduct of their experience in other (larger? Tech-first? Same country? Similar vibe?) firms.
Re: Ask HN: What breaks first when your team grows from 10 to 50 people?
#24In my experience, business started to slow down. More and more interactions gradually became chat-only, and I found myself being more careful than before, which made it harder to work at the same speed I used to.
Re: Ask HN: What breaks first when your team grows from 10 to 50 people?
#25Entirely my opinion, but I believe that there are breakpoints at multiples of 1,2,5. So, changes in org structure are needed to adapt at 10,20,50 (and further at 100,200,500) counts. More formality, more processes, more tools, more variety of roles.
If someone is doing a task which takes 4 hours a week, in a team of 10, on scaling to 50 it likely becomes a half FTE level work. Not everything scales that way, obviously, but it's a good way to model new roles needed.
Re: Ask HN: What breaks first when your team grows from 10 to 50 people?
#26This might not be the first to break, but it will eventually, and if corrected NOW will make things much smoother: Your documentation of processes and procedures is NOT adequate. 'everyone used to know about are getting lost' - oh good thing your documentation makes this clear, because it is obviously their fault. 'New hires take forever to ramp up' - oh good thing you have complete ramp up plan and documentation, be…
So, documentation is the solution? But do people have time to document everything?
You don't have time for people to not document everything.
Documentation has to be done once. (Well, it has to keep being updated. But for any change, the documentation only needs updated once.) But new people need to know about it over and over, because as you grow, you keep getting new people. You don't have time for each new person to have to go exploring to find the answer to each question. It's far less time to have one experienced person write down the answer... if you have each new person read all the relevant documents, and if you have people update the documents every time anything changes.
The last point is important. It has to become part of the culture. It should also become part of the code review/commit process.
At my last job, I was on the wrong end of this. Much of the initial code was written by two people. One was now a director; the other was incredibly busy. The code was extremely object oriented, to the point that it was very hard to figure out where anything happened and therefore where changes should be made. The documentation was a number of UML diagrams.
The result was that new people (including yours truly) wasted huge amounts of time trying to find their way around in the code. Even after being there for three years (and with over 35 years of experience), I still found the code very hard to work with.
What that code needed was someone (one particular someone) to take a solid month and work on writing good beginner-to-intermediate documentation for the code base. It would have saved literally man-years of time for new people.
Re: Ask HN: What breaks first when your team grows from 10 to 50 people?
#27It really depends on the speed. I went through it in the past few years, and it was too fast. One day I knew everybody in the whole organization, what their responsibilities are, and what they are working on. I turn around and there are more employees than I can ever know.
Re: Ask HN: What breaks first when your team grows from 10 to 50 people?
#28Entirely my opinion, but I believe that there are breakpoints at multiples of 1,2,5. So, changes in org structure are needed to adapt at 10,20,50 (and further at 100,200,500) counts. More formality, more processes, more tools, more variety of roles. If someone is doing a task which takes 4 hours a week, in a team of 10, on scaling to 50 it likely becomes a half FTE level work. Not everything scales that way, obviousl…
Nine women can't deliver a baby in a month.
Re: Ask HN: What breaks first when your team grows from 10 to 50 people?
#29Early 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 early employees perceive the decrease in scope as a demotion. They’re no longer defining the product, they’re no longer helping land the sale, at least not directly. For some that’s a hard pill to swallow and they resent it. Managing these so they can grow within the organization can be the right path, or not depending on the person.
Re: Ask HN: What breaks first when your team grows from 10 to 50 people?
#30This might not be the first to break, but it will eventually, and if corrected NOW will make things much smoother: Your documentation of processes and procedures is NOT adequate. 'everyone used to know about are getting lost' - oh good thing your documentation makes this clear, because it is obviously their fault. 'New hires take forever to ramp up' - oh good thing you have complete ramp up plan and documentation, be…
[flagged]