Discussion

boombapoom: dns

sloaken: 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.

hariprasadr: So, documentation is the solution? But do people have time to document everything?

iso1631: > But do people have time to document everythingAnd 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.

trollbridge: I’m interested in hearing how AI tools fix (or don’t fix) this problem.

axegon_: 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.

le-mark: 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.

astatine: 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.

varispeed: Nine women can't deliver a baby in a month.

Apreche: 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.

AnimalMuppet: 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.

tech2: 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.

bsjshshsb: 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.

jacquesm: Agreed in principle, but I think the real art is to keep it up to date over the longer term.

AnimalMuppet: 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.

zcrar70: 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).

prateeksi: 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.

hrmtst93837: 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.

jacquesm: Slack is communication, not documentation.

bandrami: 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.

jraines: 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)

jacquesm: 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.

joexo: In a team of 10, you have 10 x (10 - 1) / 2 = 45 communication channelsIn a team of 15, you have 15 x (15 - 1) / 2 = 105 communication channelsWhich 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.

pwagland: 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.

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

ax3726: 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.

mikpanko: 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.