How Rippling builds fast: small teams, deep expertise, and designing for complexity

Executive overview

Most product orgs slow down as they scale — too many people, too much process, too little clarity. At Rippling, velocity is a deliberate cultural artifact, not a byproduct of headcount.

The approach: small founding teams, product leaders who become domain experts, decisions made in real time, and systems designed for the hardest use case first — not the easiest.

The core insight is that speed comes from clarity, not fewer constraints — and that designing for simplicity early creates compounding technical debt that kills long-term velocity.

Maintaining velocity at scale

• Small teams with clear, singular missions minimise cross-team communication overhead
• A strong platform reduces decision-making complexity for every team building on top of it
• Leaders must go deep into the hardest problems, not delegate and float above them
• Teams need the right skill distribution for their lifecycle stage — zero-to-one builders often aren't the right people to scale
• Product leadership must be precise about what the priorities are and, crucially, what they are not

Rippling's model for launching new products

• Start with one entrepreneurial engineer and one designer — typically a team of four or fewer
• New team members spend months absorbing the platform before writing a line of product code
• Every few weeks, founders or senior leadership review designs and pressure-test decisions
• Teams grow only when the product demands it — sometimes a team of five is sufficient long-term
• The model has been replicated a dozen times; it is not dependent on the CEO unblocking things

Why Rippling doesn't build MVPs

• MVPs optimise for speed at the cost of deeper product thinking and architectural integrity
• Building only for simple cases leads engineers to make assumptions that become impossible to unwind
• Designing for the most complex use case first ensures the architecture can accommodate growth
• Global payroll example: launching across six countries simultaneously, not just the UK, meant 80% of the system is shared infrastructure — adding a new country is far easier as a result
• This approach takes more time upfront but saves significant time in the long run

The compound startup model

• Rippling is many businesses — payroll, benefits, IT, device management, time and attendance — each a multi-billion dollar industry on its own
• The founding insight: a single system of record makes all of these products continuously better than any standalone alternative
• A unified data layer enables things competitors literally cannot do — e.g., always-current org charts, cross-product permissioning, instant manager lookups
• The activation energy to build this platform is extremely high, but once built, each new product benefits from it

Decision-making speed as a cultural principle

• Decisions are made in the meeting, not scheduled for later — if the right person isn't present, they're called in immediately
• Quarterly planning has hard deadlines; missing them means the train leaves without you
• Product managers are expected to be the world's foremost expert in their domain — this is what enables instant, confident answers
• Go and see is a core leadership principle: walk all the way to ground, talk to the engineer writing the code
• The CEO models this behaviour constantly; it cascades through the organisation

Product leadership and domain expertise

• Rippling keeps the product org deliberately thin — one senior leader is expected to know the full product scope
• Becoming a world expert takes roughly half the job — but there is no point writing documents about things you don't understand
• Don't delegate the learning to a domain specialist; the PM must get into the weeds first, then hire the specialist
• Global payroll required the head of payroll to personally study tax laws country by country before any specialist was hired

What to look for when hiring PMs

• Give case studies that are deliberately too complex to fully solve upfront — watch how candidates react when an assumption changes
• The most important interview question: "What questions do you have for me?" — asked before the product discussion
• The best candidates ask insightful questions about the business, not just the product role
• Mental agility and humility matter more than having the right answer in the room
• Early-career PMs: humility is the biggest differentiator — the job is always about discovery

Frameworks and process

• Process is useful as a frame; it becomes dangerous when it substitutes for deep product thinking
• Different teams at different lifecycle stages need different processes — no universal framework applies
• The only unification requirement is quarterly planning and Jira visibility across the organisation
• Imperatives — a force-ranked, cross-team priority list — have created more focus than anything else recently; typically around 10 at any given time