There is a window in early-stage SaaS where everything moves at a speed that feels almost irrational. Features ship in days. Decisions happen in a hallway conversation. Everyone knows what is being built and why. Then headcount doubles, then doubles again, and suddenly nothing moves at all. Meetings multiply. Decisions require sign-off from people who were not around when the context was built. Velocity, which once felt effortless, becomes the thing leadership talks about trying to recover.
The irony is that the slowdown is almost never caused by hiring the wrong people. It is caused by applying the wrong systems to the right people.
What Actually Made You Fast at 10
At 10 people, speed came from a few specific conditions: shared context (everyone knew the whole system), high trust (no one needed to explain or justify their reasoning), and short feedback loops (you could talk to anyone in two minutes). None of these things scale automatically. Each requires intentional effort to preserve as the team grows.
Most companies respond to scale by adding process — approval gates, weekly syncs, project briefs. This is the wrong instinct. Process imposed on top of broken context does not fix the root problem. It just makes the brokenness more organized.
Context Is Infrastructure
At 50 people, shared context cannot live in people’s heads. It needs to be written down, kept current, and actually read. This means investing in decisions logs — short documents that record what was decided, who was involved, and crucially, what options were rejected and why. New hires who can read six months of decision history onboard in weeks instead of quarters. Engineers stop re-litigating settled debates. Trust scales because reasoning is visible.
In Pulse, teams build this habit by attaching a brief decision note to any task that results in a significant architectural or product choice. The task board becomes a searchable record of how the product got to where it is.
Keep Teams Small, Not Work Small
The fastest teams at any size are small, autonomous, and end-to-end. Going from 10 to 50 does not mean building one 50-person team — it means building five 10-person teams, each with clear ownership of a domain. Amazon’s two-pizza rule is not a catering guideline; it is an architecture principle.
Each team should be able to define, build, ship, and measure their area without requiring cross-team coordination for the majority of their work. When cross-team coordination is needed, treat it as a signal that team boundaries need adjustment — not that you need more meetings.
Replace Heroics With Defaults
At 10 people, heroics are a feature. Someone stays late, context-switches freely, and covers whatever needs covering. At 50, heroics are a bug. They mask broken systems, burn out your best people, and make capacity impossible to predict.
Replace heroics with defaults: standard templates for how work gets defined, standard tools for how decisions get communicated, standard cadences for how teams sync. Defaults feel boring. They are the thing that lets 50 people move as fast as 10.
The Culture You Want to Preserve Needs a Name
Speed, directness, low bureaucracy — these are values, and values drift under scale pressure unless they are named and defended explicitly. Write them down. Give specific examples of what they look like in practice. When a new hire joins, make the culture legible rather than hoping it is absorbed through osmosis.
The teams that successfully grow from 10 to 50 without losing their identity are not the ones who got lucky with culture fit. They are the ones who treated culture as a system that required maintenance, just like the product.