Case · Scaling · PandaDoc · 2021–2024
Three org designs through hypergrowth.
PandaDoc became a unicorn in 2021 and almost tripled its engineering teams in under two years, all through organic hiring. The structure had to change three times to keep up, and once more to undo what growth had built.
- 12 → 48
- teams, all organic hiring
- 8 → 3
- requirement areas after the maturation redesign
- 14.75
- working days for a team to switch to a new priority
- 2 weeks
- for a boot-camp cohort to ship to production, vs 2–3 months before
Context
Growth faster than any structure could keep up with.
The starting point
In late 2019 a LeSS flip turned a classic component structure into 8 feature teams on one product backlog, with the CTO and co-founder as Product Owner. He stayed in that role for years.
By September 2020 there were 12 teams and about 100 developers: too many for one backlog and one Product Owner. Then the unicorn round in May 2021 ignited hypergrowth: 150 → 800 people in 18 months, while the company went remote-first with hubs across Europe.
The question was never “which framework”. It was how to keep the organisation adaptive while it tripled.
Teams in R&D, 2019–2023
Requirement areas
What changed
Three blueprints, one principle each time.
Org design is a means, not a goal. Each blueprint kept the principles and changed the details.
1Late 2020 – early 2021 · Early growth
Areas around customer profiles
- Requirement areas defined by ideal customer profile
- Area Product Owners and a leadership group per area
- Teams as the smallest building block: stable and long-living
- Remote self-design on Miro: people chose an area, then formed teams
12 → 18 teams · 4 product areas + 1 platform area
2Mid 2021 – late 2022 · Hypergrowth
Product Owner at investment level
- The PO allocates investment per area instead of ranking every item
- An incubation area for new revenue streams
- Onboarding Sprint and engineering boot camp for every cohort of hires
- Anti-pattern: a new area for every new batch of hires
18 → 48 teams · 8 areas · ~320 developers
3Late 2022 – 2023 · Maturation
Fewer, larger areas
- 8 areas merged into 3
- Structures separated from people: managers no longer move with their teams
- Each area gets its own optimisation goal
- Pay down the fatigue in the product and in the organisation
No further growth planned until the fatigue was addressed
Maturation
Eight areas became three, each with its own goal.
Small areas had reduced visibility of overall priorities and increased local optimisation. Merging them, and letting areas optimise for different things, made the investment easy to rebalance.
Late 2022 · 8 areas, some with high walls2023 · 3 areas with dotted-line borders
Measuring adaptivity
Switching cost, measured for the first time.
How much adaptivity is enough?
The Product Owner wanted to move investment to the highest-value work and stop low-value work easily. Nobody had measured what a switch actually cost, so we did.
For every team switch we logged the decision, the first refinement of the new initiative, the first Sprint backlog item, the first commit in production and the first Sprint Goal met.
The average was 14.75 working days, and about 7 of them were the previous Sprint still running. The Product Owner's verdict: good enough.
- Priority first. When investment pivots, the team takes from the top of the backlog, not the familiar items.
- Team NorthStar. A self-assessment across 19 domains, at least every six months.
- Component mentors. Guidelines, self-paced material and consultations, so any team can work in any component.
Switching cost per team switch
Experiments
What worked, and what didn't.
- ✓Remote self-design workshopsPeople chose their area, then formed teams. Used again for every structural change.
- ✓Engineering boot campCohorts work as a temporary Scrum team on real backlog items. One cohort of 10 shipped 3 items to production in 2 weeks, with an NPS of 50.
- ✓Onboarding teamsExisting teams volunteer to host 1–2 newcomers for their first three months. One area grew from 1 to 4 teams in 7 months this way.
- ✕Small requirement areasAt least three areas started with a single team. Months of merging followed. “It's in the book for a reason.”
- ✕Copy-paste scalingA new area with its own leadership roles whenever enough teams were hired. It built walls that were hard to take down.
What I'd tell you
Org design is a means
It's fine to change it when it stops helping. Keep the principles, adapt the details.
Adaptivity needs investigation
There is no dashboard that shows “adaptivity = 5”. Measuring it starts better conversations.
It's a continuum
Not adaptive versus rigid. Find your “good enough” between the two.
Where does work wait in your organisation?
Book a short call, or start by email if you'd rather write first. Tell me what you're seeing, and I'll tell you whether I'm the right person to help.