How do you build a culture that scales past 50 people?
Things that worked at 20 break at 50, and again at 100. Communication, hiring bar, decision-making speed.
What did you actually change — rituals, structure, things you killed — that made the biggest difference? Would love war stories.
Sign in to join the discussion.
50 Replies
Systems thinking is the only way to survive the 50-100 transition. If you don't build the system, you become the system, and that's how founders burn out.
Communication debt is real. At 50, we implemented a 'No Meetings Wednesday' policy to give the makers back their focus time. It's the one ritual that has survived all the way to 200 people.
We tried the 'No Meetings' thing and it just resulted in twice as many meetings on Tuesday and Thursday. It didn't actually reduce the load.
It only works if you also enforce an 'Async First' rule. If it can be a Loom or a Slack thread, it shouldn't be a meeting.
The biggest thing I killed was the 'Founder Approval' for any spend under $5k. It was slowing down every department and signaled a lack of trust that was poisoning the culture.
How did you manage the budget tracking after that? Did you just rely on department heads?
Yes, exactly. Department heads got an annual budget and total autonomy over how to spend it as long as they hit their KPIs.
At 50 people, your job as a founder changes from 'Lead Doer' to 'Chief Context Officer.' Your only goal is to provide enough context so everyone else can make the right decisions without you.
'Chief Context Officer' is a great term. I spend about 40% of my week now just repeating the vision and the 'why' behind our current OKRs.
If you need more than 50 people to build a great product, you probably have too much process. I'd rather have 20 hyper-focused people than 100 with 'rituals.'
The 'Two Pizza Rule' is still the best way to scale. If a team can't be fed by two pizzas, it's too big. Keep the units small even if the company is large.
Small units only work if the interfaces between them are perfectly defined. Otherwise, you just spend all day in 'alignment' meetings.
We implemented an internal API for every team. Even the HR and Marketing teams had to define their 'inputs and outputs' for other teams to see.
An API for HR? That sounds fascinating. Can you give an example of what an HR 'output' looks like in that model?
Sure—it's basically a service level agreement (SLA). 'If you submit a job req with these details, you will have a candidate list in 7 days.' It turns vague requests into predictable systems.
I killed the 'everyone in every Slack channel' rule. At 50, the noise-to-signal ratio is too high. We moved to mandatory public channels for projects but discouraged staying in more than 5-10.
Slack is where culture goes to die if you don't police it. We banned @channel and @here for anyone except the Ops team for emergencies.
One ritual we added was a 'New Hire Social' where they had to present a 5-minute lightning talk on something they are passionate about that ISN'T work. Helps build empathy.
We do something similar called 'User Manuals' where everyone writes how they like to work, receive feedback, and communicate. It bridges a lot of gaps during rapid scaling.
I found that a weekly 15-minute 'State of the Union' video from me worked better than a long email. People can feel the tone and energy, which gets lost in text.
Visibility is key. At 50 people, half the company doesn't know what the other half is doing. We started a 'Friday Demo' where any team could show off a win.
Demos are the best cultural glue. It reminds everyone that we are actually building things, not just moving JIRA tickets around.
We actually stopped doing Demos every week because it was too much prep work. We moved them to once a month and made them a bigger 'celebration' event.
The hardest part for me was letting go of the code reviews. I was still reviewing every PR at 40 people. At 55, I realized I was the biggest blocker to shipping.
I bet the team was relieved when you stopped! It's amazing how much faster things move when the 'God-mode' founder steps out of the technical weeds.
I found that the 'Founding Team' bottleneck is the hardest to break. You have to stop being the final decision-maker for everything and move to a model where you only intervene by exception.
The hiring bar is where most startups fail during the 50-100 sprint. You get desperate for warm bodies and start compromising on the 'culture add' just to hit headcount targets.
Agreed. We actually had to fire two of our first ten hires when we hit 60 people because they couldn't adapt to the new structure. It was painful but necessary for the team's morale.
The biggest shift for us at 50 was moving from 'implicit' to 'explicit' culture. You can no longer rely on osmosis, so we documented our operating principles in a living Notion doc that every new hire must read and critique.
Specifically on the documentation point, did you find people actually read it? We struggled with 'Notion rot' where docs went stale within months.
We solved the staleness by assigning 'owners' to every core process doc. If a process changes and the doc isn't updated, the owner is held accountable during their quarterly review.
We formalised our values at 50. Not just fluffy words, but 'This is how we behave' vs 'This is what we don't tolerate.' We used them to fire a high-performing but toxic engineer.
I actually disagree. At the growth stage, you need 'A players' who are obsessive. Sometimes those people aren't 'nice,' but they are the ones who push the product to greatness.
There's a difference between 'obsessive/not nice' and 'toxic/belittling.' We keep the former, we fire the latter. It's a fine line but an important one.
The 'High-Performing Jerk' is the biggest threat to a 50+ person company. If you keep them, you signal to everyone else that the values don't actually matter.
Exactly. Culture is defined by the worst behavior you are willing to tolerate. At 50, that behavior becomes visible to everyone.
We introduced a 'Failure Log' where leadership posts their biggest mistakes every month. It helped keep the culture from becoming too risk-averse as we added more layers of management.
That's bold. Did you find it actually encouraged others to take risks, or did it just become a performative exercise?
It was performative at first, but once I shared a mistake that cost us $50k in server fees, people realized I was serious. It opened the floodgates for honest retrospectives.
We introduced 'Squads' at the 50-person mark. Cross-functional teams that have their own mini-roadmap helped maintain that small-startup feel even as the total headcount grew.
Did the Squads have their own designers and PMs, or were those shared resources?
Dedicated designers and PMs. If you share them, you just create a new set of bottlenecks and priority conflicts.
We started doing 'Founder Office Hours'—two hours a week where anyone could book 15 minutes to talk about anything. It kept me grounded in the day-to-day frustrations of the junior staff.
Office hours are great, but make sure they don't become a way for people to bypass their managers. I've seen that create a lot of friction with mid-level leadership.
Good point, Emily. I always ask 'Have you discussed this with your manager?' first if it's a tactical or performance issue.
We introduced 'Manager Training' at 40 people. Most of our early leads were great ICs but had zero experience managing people, which becomes a massive liability at scale.
What did that training look like? Internal workshops or did you bring in outside coaches?
A mix of both. We used an external coach for the 'hard skills' like giving feedback and 1:1 structures, but kept the internal sessions for our specific cultural nuances.
I killed the 'all-hands Q&A' and moved it to an anonymous Slido. It sounds counter-intuitive, but it allowed the quieter engineers to ask the hard questions that were actually bothering the team.
Moving to Slido was a game changer for us too. The voting mechanism ensures you spend time on what people actually care about, not just the loudest person in the room.