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 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.
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.
There’s a common scaling heuristic, related to Greiner’s growth model, that organizations need to fundamentally change how they operate as they grow. I recall numbers that every time your organization triples you need to change how you do things.
Part of this is communication overheads, and as op points out, the need, and ability, to specialise in a larger organisation.
Indeed, with a big BUT: you don't want to overvalue loyalty in respect of competence. You don't want to have a boss that is not good but "is here since forever".
Instead, reward them economically. Everytime the company takes a leap forward, make clear to them that they were important for the process, and share some profit.
And make clear that being important in a moment doesn't automatically mean they will be important in the future: they will have to compete on results, like everyone else.
Not everyone is great at the level above and even if they are, sometimes it is not always a good fit for them. I've had more a good few engineers ask to go backwards when they've been promoted - each for their own reasons but nearly always around the theme of being in a position of leadership / seniority.
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...).
Done this. Good question but I don't think it's the most helpful way of thinking about it.
Every new recruit brings their own assumptions about how organizations / employment / etc. work and many of those assumptions won't be visible until after a while. This is especially true for managers.
I found Charles Handy's thinking about four types of organisational culture very helpful and I wish I'd found it earlier in the process.
AI summary: Charles Handy identified four types of organizational cultures: Power Culture, where decision-making is centralized among a few; Role Culture, which is based on defined roles and responsibilities; Task Culture, focused on teamwork to achieve specific goals; and Person Culture, where individual interests take precedence over the organization.
Basically, 15>50 is very likely to involve a shift from one of these to another one and making that open and explicit could help you a lot (including understanding how the role of senior managers needs to change).
The book is Understanding Organisations from 1976 but still valuable.
From my personal experience, if I take your categorization as a guideline, 15-50 headcount is where "Power Culture" is going be a huge issue like 80% of the time. It can very quickly devolve into brown nosing and putting off high performing new hires.
I've been in that situation. What broke was that nobody had the skills to coordinate and to ramp up all these new joiners. And the hiring didn't anticipate that this would be a problem.
Eventually, things went better when they found the right persons to help with the organization, but it was chaotic and frustrating for a while.
Growing companies from ~10 to ~200+ has been my bread and butter for almost 20yrs now. A few relatively universal observations:
1. As sloaken said, your documentation of processes and procedures is NOT adequate. This applies to everything. From your code commit process to how to book vacation days. Document everything early. Notion is your friend.
2. Like it or not, your work culture is going to change. New people obviously means new personalities but it also means new ways of working, some good, some bad. It really is worth spending some time with the first 15 people that helped get your company to where it is today and define some operating principles (otherwise known as 'company values'). This blog post (not mine) is an incredible insight into why this stuff actually matters at your stage of growth: https://lowercaseopinions.com/post/useful-values
3. Hiring gets expensive and laborious. You're reaching a point where it just isn't practical for you to be involved in every hiring decision. That being said, don't let go of it until you are confident that everyone involved in hiring for your company is aligned on what 'good' looks like both in terms of candidates and hiring process.
4. More people means more individual questions, problems, and ultimately admin. More people getting paid means more payroll issues and questions and adjustments. More people interacting with each other means more disagreements, arguments, and issues. Someone needs to be able to handle all of these issues. Usually the challenges are distributed across different teams but again, without some rigour around how you want your company to approach these issues means that different managers/teams will take different approaches which in turn will amplify the problems rather than solve them.
5. Reconsider the financial impact of hiring experienced people. Bringing in strong leaders early can enormously mitigate the operational costs of scaling. Hiring a highly experienced person at your stage will have a big impact on your budget but long-term, that investment will pay dividends both in terms of the quality of work but also in sharing the burden of handling these scaling challenges.
on point 5, that person may be highly experienced, but its important to know that this highly experienced person must be a good fit for your company size. Often times we assume that hiring an L8 at faang is perfect for a startup and thats usually not the case: they know how to play the big company game, not how to take you from 15 to 100 employees.
Docs help, but they don't save you from a team that treats Slack as the source of truth. At 50 people the bigger failure is ownership: nobody knows which page is current, nobody gets time to fix stale docs after the process changes, and after a few rounds of that the wiki becomes a museum piece new hires learn to ignore.
Most of my time working with startups was dealing with these repetitive things that nobody had time to do. Humans somehow have the time to work two jobs and then update the wiki on MMOs they play, but never the time to do it on that one day job.
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.
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.
Art is knowing what to document. And how to organize it. This is probably not a solved problem and needs constant care and refactoring like the code itself.
Giving people additional documented responsibilities helps. Lucy is responsible for API docs and swagger up to date and for building that out as business needs. Varun is responsible for coding practices docs. And so on. If something is out of date they update it. Use Confluence or Notion or something else good.
The hardest part of the 10-to-50 jump is the identity crisis for early hires. In the beginning, they were the product, the support, and the sales team all at once. If you hired juniors then, "organized chaos" is the only environment they know.
When you start adding structure—dedicated QA, CX, or PMs—those early employees often feel like they’re being demoted. They go from "defining the vision" to "owning a single feature." It’s a hard pill to swallow, and some never stop resenting the new boundaries. The real management challenge isn't just hiring the next 40; it's helping the first 10 realize that a smaller scope is the only way the company actually scales.
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.
Communication broke first. Information theory fundamentals. The space of possible conversations grows quadratically with the number of participants.
The only solution I can come up with is something approximating a benevolent dictator model where the person at the top tries to remain as curious as possible about the details in their business, but is otherwise god when it comes time to make decisions. Allowing leadership to become diffuse through committees and boards of directors is where most companies go to die.
Keeping the head count small as a primary defense measure is probably the simplest thing. If you aren't comfortable with the idea of a CTO, CIO and CEO being 3 different people, then you should keep it in the low double digits. It might be better to create a wholly separate company than to grow the existing one. Outsourcing doesn't necessarily mean to another party you've never interacted with before.
The first is that you had a system with a given set of ownership and now lines need to be drawn between groups to grant each sub-team their own piece of the larger pie. This is where Conway's law comes to bite you because your code is likely structured around your existing team and practices. Deciding how to draw that boundary is a challenge (API-based? Separate services?). Do not skip this part, otherwise you'll have an awful mix of old and new and everyone suffers.
The second is how work is structured. With a small team, anyone can edit anything (ownership again). With multiple teams you need to accept that changes will require multiple stages of development and the rate of change can take a hit due to scheduling and prioritisation for each team. In the small team a single sprint (assuming this is your working practice) may have been sufficient, but with multiple teams those changes will need scheduling.
I know about 2 big discontinuities in group dynamics, which are based on the limits of human cognition at specific sizes:
1) ~7 people. This is when each member cannot participate in the whole context and all important decisions. "2 pizza teams", limits of the working memory. Decisions cannot be done all together anymore. This results in hierarchies forming and people worrying about their positions in them.
2) ~150 people (Dunbar's number). This is when group members cannot all know each other anymore and have meaningful relationships. Max sizes of family-based tribes, an important unit size in the army. This results in inability to observe each other's actions well, so understanding who contributes a lot vs not shifts to indirect stories. Group members start building narratives instead of demonstrating contributions directly.
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.
In a team of 10, you have 10 x (10 - 1) / 2 = 45 communication channels
In a team of 15, you have 15 x (15 - 1) / 2 = 105 communication channels
Which implies that the time you need to spend communicating would be around double. So if you need 1 hour meeting per day in a 10 person team, you will need 2 hours of meetings in a 15 person team.
The only solution that I know, however impopular, is to form a hierarchy of information, just like you would organize a growing code base in a hierarchy of abstractions.
Onboarding was our canary. At 12 people the setup doc was a wiki page someone maintained as a hobby. By 30 it was a graveyard of broken links.
We gave up on documenting the environment and just made it cloneable. Snapshot a working setup, hand it over, done. First-commit time went from ~2 weeks to a day. (fwiw I work on https://cyqle.in partly because of this)
What I’d be most worried about is an “us vs them” mentality developing. It doesn’t break first but it can develop almost naturally. 10 -> 50 people tends to mean “team of teams” rather than “a team”.
Once this dynamic takes root, it’s much harder to stomp out. I’d be more worried about systemic issues like this than the short term pain from growth.
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)
I think what breaks first is team / org dependent but ime: alignment & quality standards
I found a mixture of shoehorning the vision into as many conversations as possible and occasional in person meetups (we die roughly yearly) helped with vision. I dont have measurements but my concern for teams decision making dropped a lot and disagreements in smaller discussion settings also dropped.
Standards dropping was secretly alignment too but more around why than what. I found building a culture of excellence helped e.g. "we're here to build software we're proud of, from the code to the experience, and you are the right people do it, so lets build something we're proud of.". You or who ever has to actually believe they are the people to so it though.
Im sure people have more concrete and technical examples.
What breaks is always the weakest link, this will vary based on your own organization structure, it may be ops, it may be engineering, it may be culture, it may be management, but most certainly all of it will be tightly coupled to your communication.
Try and identify what is the weakest link, then avoid over correcting a symptom, double down on communication and ensure that your values, principles, and alignment are well understood across the org.
I really like 37signals as a reference guideline, build your variation of that and talk about it every day[1]
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.
Entirely 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.
Docs. Load-bearing implicit authority. Attribution of sales. Implicit assumptions about humor / topicality in group chats. Office kitchen standards & practices.
It’s up to the CEO to fix all of it, directly or indirectly. Except perhaps the chat one. You need someone with community-manager DNA and a light touch, lest the CEO come off as control freak. (Which is ironic bc they have to be one in many areas but this is one where it will alienate people)
Culture. 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.
At 15 people, you can rely on 'tribal knowledge', where there is enough interaction between individuals that everyone is on the same page on most key points (company mission, coding standards, release processes, etc.)
As you grow, that stops being the case; to echo what @Peroni and @sloaken said - a good first step is good documentation and clear, repeatable and where possible automated processes. A second, related challenge is company culture - as you grow and interactions between each & every individual become less & less possible, getting everyone aligned on what it means to work at your company (and how to achieve company goals) is harder. You'll need to make a conscious effort to maintain that (see below).
The core team will need to start delegating more, which can be a hard if you're not used to it (some may also want to remain ICs), and will change the shape of your organisation. This is particularly hard to do gradually, as you'll need to work out the right point at which to transition different areas of the business. This comes with the risk of silos developing - a good way to work around that at mid-size is to continue arranging teams by project, but make sure that there are both opportunities to gather across functions (e.g. dev, qa, project management etc.) and more widely (e.g. company events, social events etc.). The main thing here is making sure people talk to each other, exchange information, getting good at collaborating with each other and know who to reach out to in case of issue. Again, you are going to have to dedicate time to this which will seem strange coming from 15 people (but will pay off handsomely in increased efficiency).
There are many good other points in this thread (on hiring experienced people even though they cost more, the importance of good hiring, clear ownership, us vs them), but a last one is the need more generally for the leadership team to adapt. They will have less visibility and control; the company will become less efficient which might be frustrating (it will still be able to do more overall); changes of direction will become harder and slower. This applies to all 15 people working there now, but particularly for the founders/leaders. Having some thoughts on how to handle this ahead of time (established reporting structures, clear goals and reporting metrics) will help minimise growing pains. It's always easier to say this than to do of course.
Source: did something similar a couple of times (4->25 people, 600->1000 people).
- Are you able to get people to buy in on the need for consistency?
- Are you micro-managing it or are you delegating?
Usually the problems start at the top, so that's where I would start looking for solutions. A really good coach for your CTO if they're not very experienced would be a nice start.
It 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.
The big discontinuity is Dunbar's number. When you get to ~200 you stop being a single company and divide into fiefs. There's a reason militaries have always had the smallest maneuver unit be a little more than 100 people.
In 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.
Manager of managers. Some engineers get promoted to first-line managemen t and some outsiders are brought in as the team grows. And some of each of those don't succeed.
Each sub-team (about 4 or 5 people?) must create and fully document the interfaces to their product(s). Otherwise you just have a big pile of something steaming.
Communication infrastructure breaks first. When you're 10 people, context lives in people's heads and Slack threads. At 50, that stops working entirely. The fix isn't more meetings, it's written decision logs. Every significant decision needs a one-paragraph record: what was decided, why, and who owns it. Took us longer than it should have to figure that out.
Having taken a startup from 2 to 100 a lot of the comments here resonate, but now that I'm in a company of 10,000 and trying to get things down across wide areas, I would say efficiency and communication overhead are all relative and make sure you're solving the problems in front of you and not "playing house" on problems you anticipate having down the line.
You will need more structure than you had before. For instance at 15 the idea of managers is silly, everyone still needs to be contributing individually, the only thing is that you do need to minimally subdivide work so that everyone isn't doing everything. Be wary of process for processes sake, you will start to need some but you really want to stay focused on concrete progress; is everyone doing the most important thing possible at every given moment? How fast are you shipping changes, closing sales, etc? Also make sure you have the right people, don't get starstruck by big tech vets. They have many skills that will be useful—if you are phenomenally successful—but if they don't have startup experience they likely will overengineer things by default, and a significant percentage of them can not wipe their own ass without the best-in-class tooling and infra support teams that allowed them to focus purely on one domain at BigCo. Basically you need pragmatic hustlers, veterans are good so long as they aren't cathedral or empire builders. Also watch out for weird team dynamics and nip any toxic interactions in the bud, one bad apple really can spoil the barrel; that's probably the most important thing to watch out for in the 15-100 range.
In my experience: ego. With few people you often have to keep things balanced and thus picking people that can work well with others. With 50, you are practically guaranteed to have at least several people that are absolutely insufferable(which can also happen in small teams in some cases - the reason why I resorted to "I quit, 1 month notice is best I can do, not 3, else I'll be doing the bare minimum for 3 months" at my old job). The truth is, more often than not, no one is willing to actively do anything about problematic people and hope that the problem will solve itself magically. Spoilers: it doesn't and it's not a question of if but when people will start quitting in swarms and usually that happens at the worst time for each company: heavy load, unreasonable deadlines, stress, etc. That's when you know the total collapse might be right around the corner.
People need to transition from 100% code* to 80-90% code and 10-20% do things that are good for the company and team's productivity (using that word in the broadest sense). You want all hands to spot the cracks and fix them. You probably want to create a culture where people do that.
*code = code, design, discuss code, write tickets, test etc. i.e. get the shit done on the plan
You may need to transition to making willingness and ability to do that (i.e. be an owner) a hiring criteria and performance criteria.
You're in the hardest phase - 15 until about 60 people. Right now, you are transitioning from needing generalists to needing to hire specialists, but you don't have the infrastructure for specialists. You are likely to start hiring managers now.
Compounding the difficulty, people are going to expect all the services of a 60 person company but you haven't built them, and probably don't know exactly what you want. Have you started getting requests for "HR" to do something yet? Requests for "policies"? In the thread here, people mention documentation. This will be a theme. And your vision for what you want that to look like is important; in my experience if you leave this up to a new hire that's "bigger company" experienced - they will generally rebuild what they have experienced without a lot of thought about adapting it to your company and the size you're at.
Like a lot of startup problems, a) this is a good problem, so don't be mad, and b) there is no magic bullet, you just have to get through it.
My two cents, having mentored a number of companies through this and done it a few times myself, here are my non-negotiables:
1. Keep hiring managers that can execute. It's too early for corporate VP types at your size. And you're probably not ready to manage the political and management skills and needs of corporate VPs just yet.
2. Double down on engaging with hiring - you're likely to be hiring new people with organizational leverage (managers) - you need to be able to explicate the values and make CERTAIN they are being carried out and improved on and broadcast by new management hires; they will be doing things you don't know anything about, so you need to be totally in sync with them. I've read a few startup CEOs that say they stayed personally involved in their first 1,000 hires. That sounds incredible to me, but I like the aspiration.
3. Build reporting process - could be digital could be soft, e.g. periodic standup meetings where numbers are reported - but you're going to need this as you get a bit bigger, and it's culturally easier if it's embedded in the org as you recruit and hire and grow than if you impose it as a "founder/CEO project" later on.
Anyway - what breaks first is your old methods of alignment. A lot of people talk documentation here, which makes sense. Culture is more important than docs IMO.
The way I would say it is: communication becomes exponentially more important. Basically every doubling in size means you will need to say things twice as simply and four times as often for them to get through the org. You will need partners in the org as it grows to help with all this, but you will not be able to give up the responsibility of communicating vision, standards, direction, and to the extent you don't build that skill, you'll send an org spinning, or lose it to someone who is doing this.
Enjoy the ride! It will be fun. Also, things do get easier in many ways as you grow - you get some money to invest inside the company - you'll get to work with great people - it's a lot of fun.
Eventually it all becomes about communication between teams of people.
"We just talk to each other" doesn't work well enough when you no longer know who to talk to. Email aliases for teams can help, so that you don't need to know who the right person is for your question, you just need to know the right team.
Things can't live in peoples' heads anymore. Task lists need to live somewhere. Tribal knowledge needs to live somewhere. Priorities need to live somewhere. Some tools may help. You probably eventually will need a bug database. Depending on what world you're in, you may need a requirements database.
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 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.
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.
There’s a common scaling heuristic, related to Greiner’s growth model, that organizations need to fundamentally change how they operate as they grow. I recall numbers that every time your organization triples you need to change how you do things.
Part of this is communication overheads, and as op points out, the need, and ability, to specialise in a larger organisation.
That’s something I’ve never thought about. It’s a valid point and somewhat understandable.
The obvious solution is to promote them. If you don't reward loyalty don't expect loyalty.
Indeed, with a big BUT: you don't want to overvalue loyalty in respect of competence. You don't want to have a boss that is not good but "is here since forever".
Instead, reward them economically. Everytime the company takes a leap forward, make clear to them that they were important for the process, and share some profit.
And make clear that being important in a moment doesn't automatically mean they will be important in the future: they will have to compete on results, like everyone else.
Not everyone is great at the level above and even if they are, sometimes it is not always a good fit for them. I've had more a good few engineers ask to go backwards when they've been promoted - each for their own reasons but nearly always around the theme of being in a position of leadership / seniority.
That's peter principle 101
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...).
Done this. Good question but I don't think it's the most helpful way of thinking about it.
Every new recruit brings their own assumptions about how organizations / employment / etc. work and many of those assumptions won't be visible until after a while. This is especially true for managers.
I found Charles Handy's thinking about four types of organisational culture very helpful and I wish I'd found it earlier in the process.
AI summary: Charles Handy identified four types of organizational cultures: Power Culture, where decision-making is centralized among a few; Role Culture, which is based on defined roles and responsibilities; Task Culture, focused on teamwork to achieve specific goals; and Person Culture, where individual interests take precedence over the organization.
Basically, 15>50 is very likely to involve a shift from one of these to another one and making that open and explicit could help you a lot (including understanding how the role of senior managers needs to change).
The book is Understanding Organisations from 1976 but still valuable.
Good luck!
From my personal experience, if I take your categorization as a guideline, 15-50 headcount is where "Power Culture" is going be a huge issue like 80% of the time. It can very quickly devolve into brown nosing and putting off high performing new hires.
I've been in that situation. What broke was that nobody had the skills to coordinate and to ramp up all these new joiners. And the hiring didn't anticipate that this would be a problem.
Eventually, things went better when they found the right persons to help with the organization, but it was chaotic and frustrating for a while.
Growing companies from ~10 to ~200+ has been my bread and butter for almost 20yrs now. A few relatively universal observations:
1. As sloaken said, your documentation of processes and procedures is NOT adequate. This applies to everything. From your code commit process to how to book vacation days. Document everything early. Notion is your friend.
2. Like it or not, your work culture is going to change. New people obviously means new personalities but it also means new ways of working, some good, some bad. It really is worth spending some time with the first 15 people that helped get your company to where it is today and define some operating principles (otherwise known as 'company values'). This blog post (not mine) is an incredible insight into why this stuff actually matters at your stage of growth: https://lowercaseopinions.com/post/useful-values
3. Hiring gets expensive and laborious. You're reaching a point where it just isn't practical for you to be involved in every hiring decision. That being said, don't let go of it until you are confident that everyone involved in hiring for your company is aligned on what 'good' looks like both in terms of candidates and hiring process.
4. More people means more individual questions, problems, and ultimately admin. More people getting paid means more payroll issues and questions and adjustments. More people interacting with each other means more disagreements, arguments, and issues. Someone needs to be able to handle all of these issues. Usually the challenges are distributed across different teams but again, without some rigour around how you want your company to approach these issues means that different managers/teams will take different approaches which in turn will amplify the problems rather than solve them.
5. Reconsider the financial impact of hiring experienced people. Bringing in strong leaders early can enormously mitigate the operational costs of scaling. Hiring a highly experienced person at your stage will have a big impact on your budget but long-term, that investment will pay dividends both in terms of the quality of work but also in sharing the burden of handling these scaling challenges.
on point 5, that person may be highly experienced, but its important to know that this highly experienced person must be a good fit for your company size. Often times we assume that hiring an L8 at faang is perfect for a startup and thats usually not the case: they know how to play the big company game, not how to take you from 15 to 100 employees.
Well said. Second all of this.
This 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, because it is obviously their fault.
'building on different assumptions' - oh good, your old assumptions are clearly documented, because it is obviously their fault.
So their is your self focus, please do good, and document well.
Docs help, but they don't save you from a team that treats Slack as the source of truth. At 50 people the bigger failure is ownership: nobody knows which page is current, nobody gets time to fix stale docs after the process changes, and after a few rounds of that the wiki becomes a museum piece new hires learn to ignore.
Slack is communication, not documentation.
It should be, but I’ve also seen few teams having everything on slack. Better ones at least pinned stuff
So, documentation is the solution? But do people have time to document everything?
Anything not documented is throw away.
Any given day someone can win the lottery, inherit a lot of money, or need to leave for some other reason.
Every complaint they had was a direct effect of failure to document. Well that or the other people are just complete idiots ... you decide.
Most of my time working with startups was dealing with these repetitive things that nobody had time to do. Humans somehow have the time to work two jobs and then update the wiki on MMOs they play, but never the time to do it on that one day job.
My laws of existence:
Business. If the customer can’t feel it it doesn’t exist.
Ops. If it isn’t automated it doesn’t exist.
Product. If it isn’t documented it doesn’t exist.
Engineering. If it isn’t in code it doesn’t exist.
You have an opinion about security? Have you written a linter? Is it documented? Is it in the deployment pipeline? Do customers care?
If it’s only in your brain I don’t accept it and refer you back to the existence rules.
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.
> 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.
It’s 2026. Reading is not the problem any more. Culling obsolence is the problem.
Art is knowing what to document. And how to organize it. This is probably not a solved problem and needs constant care and refactoring like the code itself.
Giving people additional documented responsibilities helps. Lucy is responsible for API docs and swagger up to date and for building that out as business needs. Varun is responsible for coding practices docs. And so on. If something is out of date they update it. Use Confluence or Notion or something else good.
Agreed in principle, but I think the real art is to keep it up to date over the longer term.
Are you saying there's too much undocumented tribal knowledge? If so, I agree
* 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.
The hardest part of the 10-to-50 jump is the identity crisis for early hires. In the beginning, they were the product, the support, and the sales team all at once. If you hired juniors then, "organized chaos" is the only environment they know.
When you start adding structure—dedicated QA, CX, or PMs—those early employees often feel like they’re being demoted. They go from "defining the vision" to "owning a single feature." It’s a hard pill to swallow, and some never stop resenting the new boundaries. The real management challenge isn't just hiring the next 40; it's helping the first 10 realize that a smaller scope is the only way the company actually scales.
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.
Communication broke first. Information theory fundamentals. The space of possible conversations grows quadratically with the number of participants.
The only solution I can come up with is something approximating a benevolent dictator model where the person at the top tries to remain as curious as possible about the details in their business, but is otherwise god when it comes time to make decisions. Allowing leadership to become diffuse through committees and boards of directors is where most companies go to die.
Keeping the head count small as a primary defense measure is probably the simplest thing. If you aren't comfortable with the idea of a CTO, CIO and CEO being 3 different people, then you should keep it in the low double digits. It might be better to create a wholly separate company than to grow the existing one. Outsourcing doesn't necessarily mean to another party you've never interacted with before.
Two major issues in my experience seem to occur.
The first is that you had a system with a given set of ownership and now lines need to be drawn between groups to grant each sub-team their own piece of the larger pie. This is where Conway's law comes to bite you because your code is likely structured around your existing team and practices. Deciding how to draw that boundary is a challenge (API-based? Separate services?). Do not skip this part, otherwise you'll have an awful mix of old and new and everyone suffers.
The second is how work is structured. With a small team, anyone can edit anything (ownership again). With multiple teams you need to accept that changes will require multiple stages of development and the rate of change can take a hit due to scheduling and prioritisation for each team. In the small team a single sprint (assuming this is your working practice) may have been sufficient, but with multiple teams those changes will need scheduling.
I know about 2 big discontinuities in group dynamics, which are based on the limits of human cognition at specific sizes:
1) ~7 people. This is when each member cannot participate in the whole context and all important decisions. "2 pizza teams", limits of the working memory. Decisions cannot be done all together anymore. This results in hierarchies forming and people worrying about their positions in them.
2) ~150 people (Dunbar's number). This is when group members cannot all know each other anymore and have meaningful relationships. Max sizes of family-based tribes, an important unit size in the army. This results in inability to observe each other's actions well, so understanding who contributes a lot vs not shifts to indirect stories. Group members start building narratives instead of demonstrating contributions directly.
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.
In a team of 10, you have 10 x (10 - 1) / 2 = 45 communication channels
In a team of 15, you have 15 x (15 - 1) / 2 = 105 communication channels
Which implies that the time you need to spend communicating would be around double. So if you need 1 hour meeting per day in a 10 person team, you will need 2 hours of meetings in a 15 person team.
The only solution that I know, however impopular, is to form a hierarchy of information, just like you would organize a growing code base in a hierarchy of abstractions.
Onboarding was our canary. At 12 people the setup doc was a wiki page someone maintained as a hobby. By 30 it was a graveyard of broken links.
We gave up on documenting the environment and just made it cloneable. Snapshot a working setup, hand it over, done. First-commit time went from ~2 weeks to a day. (fwiw I work on https://cyqle.in partly because of this)
What I’d be most worried about is an “us vs them” mentality developing. It doesn’t break first but it can develop almost naturally. 10 -> 50 people tends to mean “team of teams” rather than “a team”.
Once this dynamic takes root, it’s much harder to stomp out. I’d be more worried about systemic issues like this than the short term pain from growth.
Slow, inefficient hiring process and desperate to close roles
Adding culturally non-fit team members
Setting process and system to accelerate the speed of execution not to slow down
Finding the harmony with process and speed
Finding the harmony with quality and quantity
My book suggestion is "The One Minute Manager" for team management
Reinforcing Vision and Mission statement of why your startup exists
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
I think what breaks first is team / org dependent but ime: alignment & quality standards
I found a mixture of shoehorning the vision into as many conversations as possible and occasional in person meetups (we die roughly yearly) helped with vision. I dont have measurements but my concern for teams decision making dropped a lot and disagreements in smaller discussion settings also dropped.
Standards dropping was secretly alignment too but more around why than what. I found building a culture of excellence helped e.g. "we're here to build software we're proud of, from the code to the experience, and you are the right people do it, so lets build something we're proud of.". You or who ever has to actually believe they are the people to so it though.
Im sure people have more concrete and technical examples.
What breaks is always the weakest link, this will vary based on your own organization structure, it may be ops, it may be engineering, it may be culture, it may be management, but most certainly all of it will be tightly coupled to your communication.
Try and identify what is the weakest link, then avoid over correcting a symptom, double down on communication and ensure that your values, principles, and alignment are well understood across the org.
I really like 37signals as a reference guideline, build your variation of that and talk about it every day[1]
[1] https://37signals.com/
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.
Entirely 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.
Nine women can't deliver a baby in a month.
Docs. Load-bearing implicit authority. Attribution of sales. Implicit assumptions about humor / topicality in group chats. Office kitchen standards & practices.
It’s up to the CEO to fix all of it, directly or indirectly. Except perhaps the chat one. You need someone with community-manager DNA and a light touch, lest the CEO come off as control freak. (Which is ironic bc they have to be one in many areas but this is one where it will alienate people)
Culture. 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.
At 15 people, you can rely on 'tribal knowledge', where there is enough interaction between individuals that everyone is on the same page on most key points (company mission, coding standards, release processes, etc.)
As you grow, that stops being the case; to echo what @Peroni and @sloaken said - a good first step is good documentation and clear, repeatable and where possible automated processes. A second, related challenge is company culture - as you grow and interactions between each & every individual become less & less possible, getting everyone aligned on what it means to work at your company (and how to achieve company goals) is harder. You'll need to make a conscious effort to maintain that (see below).
The core team will need to start delegating more, which can be a hard if you're not used to it (some may also want to remain ICs), and will change the shape of your organisation. This is particularly hard to do gradually, as you'll need to work out the right point at which to transition different areas of the business. This comes with the risk of silos developing - a good way to work around that at mid-size is to continue arranging teams by project, but make sure that there are both opportunities to gather across functions (e.g. dev, qa, project management etc.) and more widely (e.g. company events, social events etc.). The main thing here is making sure people talk to each other, exchange information, getting good at collaborating with each other and know who to reach out to in case of issue. Again, you are going to have to dedicate time to this which will seem strange coming from 15 people (but will pay off handsomely in increased efficiency).
There are many good other points in this thread (on hiring experienced people even though they cost more, the importance of good hiring, clear ownership, us vs them), but a last one is the need more generally for the leadership team to adapt. They will have less visibility and control; the company will become less efficient which might be frustrating (it will still be able to do more overall); changes of direction will become harder and slower. This applies to all 15 people working there now, but particularly for the founders/leaders. Having some thoughts on how to handle this ahead of time (established reporting structures, clear goals and reporting metrics) will help minimise growing pains. It's always easier to say this than to do of course.
Source: did something similar a couple of times (4->25 people, 600->1000 people).
Depends on the root cause.
- Are you hiring senior people or juniors?
- How good are the managers?
- Are you able to get people to buy in on the need for consistency?
- Are you micro-managing it or are you delegating?
Usually the problems start at the top, so that's where I would start looking for solutions. A really good coach for your CTO if they're not very experienced would be a nice start.
Note the military has a fractal structure such that you still have smaller units inside a bigger operation. I think that’s part of the solution.
A different kind of military, but cells were popular in startups here. The smallest stable unit is three people, aka a cell.
Arguably it can be two people, but buddy cop movies are popular precisely because of how dysfunctional this can be.
It 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.
The big discontinuity is Dunbar's number. When you get to ~200 you stop being a single company and divide into fiefs. There's a reason militaries have always had the smallest maneuver unit be a little more than 100 people.
In 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.
Manager of managers. Some engineers get promoted to first-line managemen t and some outsiders are brought in as the team grows. And some of each of those don't succeed.
I’m interested in hearing how AI tools fix (or don’t fix) this problem.
Each sub-team (about 4 or 5 people?) must create and fully document the interfaces to their product(s). Otherwise you just have a big pile of something steaming.
Communication infrastructure breaks first. When you're 10 people, context lives in people's heads and Slack threads. At 50, that stops working entirely. The fix isn't more meetings, it's written decision logs. Every significant decision needs a one-paragraph record: what was decided, why, and who owns it. Took us longer than it should have to figure that out.
Having taken a startup from 2 to 100 a lot of the comments here resonate, but now that I'm in a company of 10,000 and trying to get things down across wide areas, I would say efficiency and communication overhead are all relative and make sure you're solving the problems in front of you and not "playing house" on problems you anticipate having down the line.
You will need more structure than you had before. For instance at 15 the idea of managers is silly, everyone still needs to be contributing individually, the only thing is that you do need to minimally subdivide work so that everyone isn't doing everything. Be wary of process for processes sake, you will start to need some but you really want to stay focused on concrete progress; is everyone doing the most important thing possible at every given moment? How fast are you shipping changes, closing sales, etc? Also make sure you have the right people, don't get starstruck by big tech vets. They have many skills that will be useful—if you are phenomenally successful—but if they don't have startup experience they likely will overengineer things by default, and a significant percentage of them can not wipe their own ass without the best-in-class tooling and infra support teams that allowed them to focus purely on one domain at BigCo. Basically you need pragmatic hustlers, veterans are good so long as they aren't cathedral or empire builders. Also watch out for weird team dynamics and nip any toxic interactions in the bud, one bad apple really can spoil the barrel; that's probably the most important thing to watch out for in the 15-100 range.
In my experience: ego. With few people you often have to keep things balanced and thus picking people that can work well with others. With 50, you are practically guaranteed to have at least several people that are absolutely insufferable(which can also happen in small teams in some cases - the reason why I resorted to "I quit, 1 month notice is best I can do, not 3, else I'll be doing the bare minimum for 3 months" at my old job). The truth is, more often than not, no one is willing to actively do anything about problematic people and hope that the problem will solve itself magically. Spoilers: it doesn't and it's not a question of if but when people will start quitting in swarms and usually that happens at the worst time for each company: heavy load, unreasonable deadlines, stress, etc. That's when you know the total collapse might be right around the corner.
People need to transition from 100% code* to 80-90% code and 10-20% do things that are good for the company and team's productivity (using that word in the broadest sense). You want all hands to spot the cracks and fix them. You probably want to create a culture where people do that.
*code = code, design, discuss code, write tickets, test etc. i.e. get the shit done on the plan
You may need to transition to making willingness and ability to do that (i.e. be an owner) a hiring criteria and performance criteria.
Culture
Some good advice in here!
You're in the hardest phase - 15 until about 60 people. Right now, you are transitioning from needing generalists to needing to hire specialists, but you don't have the infrastructure for specialists. You are likely to start hiring managers now.
Compounding the difficulty, people are going to expect all the services of a 60 person company but you haven't built them, and probably don't know exactly what you want. Have you started getting requests for "HR" to do something yet? Requests for "policies"? In the thread here, people mention documentation. This will be a theme. And your vision for what you want that to look like is important; in my experience if you leave this up to a new hire that's "bigger company" experienced - they will generally rebuild what they have experienced without a lot of thought about adapting it to your company and the size you're at.
Like a lot of startup problems, a) this is a good problem, so don't be mad, and b) there is no magic bullet, you just have to get through it.
My two cents, having mentored a number of companies through this and done it a few times myself, here are my non-negotiables:
1. Keep hiring managers that can execute. It's too early for corporate VP types at your size. And you're probably not ready to manage the political and management skills and needs of corporate VPs just yet.
2. Double down on engaging with hiring - you're likely to be hiring new people with organizational leverage (managers) - you need to be able to explicate the values and make CERTAIN they are being carried out and improved on and broadcast by new management hires; they will be doing things you don't know anything about, so you need to be totally in sync with them. I've read a few startup CEOs that say they stayed personally involved in their first 1,000 hires. That sounds incredible to me, but I like the aspiration.
3. Build reporting process - could be digital could be soft, e.g. periodic standup meetings where numbers are reported - but you're going to need this as you get a bit bigger, and it's culturally easier if it's embedded in the org as you recruit and hire and grow than if you impose it as a "founder/CEO project" later on.
Anyway - what breaks first is your old methods of alignment. A lot of people talk documentation here, which makes sense. Culture is more important than docs IMO.
The way I would say it is: communication becomes exponentially more important. Basically every doubling in size means you will need to say things twice as simply and four times as often for them to get through the org. You will need partners in the org as it grows to help with all this, but you will not be able to give up the responsibility of communicating vision, standards, direction, and to the extent you don't build that skill, you'll send an org spinning, or lose it to someone who is doing this.
Enjoy the ride! It will be fun. Also, things do get easier in many ways as you grow - you get some money to invest inside the company - you'll get to work with great people - it's a lot of fun.
Eventually it all becomes about communication between teams of people.
"We just talk to each other" doesn't work well enough when you no longer know who to talk to. Email aliases for teams can help, so that you don't need to know who the right person is for your question, you just need to know the right team.
Things can't live in peoples' heads anymore. Task lists need to live somewhere. Tribal knowledge needs to live somewhere. Priorities need to live somewhere. Some tools may help. You probably eventually will need a bug database. Depending on what world you're in, you may need a requirements database.
dns