Case Study · Design Systems
Design systems practice from scratch inside a hyper-growth startup during the remote work revolution — without ideal conditions. No dedicated PM. High turnover. A product growing faster than documentation could follow.
I joined Calendly in June 2021 to establish a design systems practice from scratch and provide system-level strategy as the company moved from hyper-growth startup into its next stage. When I arrived, Calendly was simultaneously rebranding, launching a new marketing site, and aggressively expanding its enterprise offerings. The company doubled its headcount during my time there. The design org was moving fast, building on patterns that had never been formally consolidated, and desperately needed a shared language.
My role was to build that language — and to do it inside a company that was changing faster than any system could be cleanly documented.
I had built an ambitious roadmap anchored on a six-person pilot team — designers and content strategists who would serve as both subject matter experts and early adopters, helping me rapidly document patterns and establish process across the design org.
Within that first quarter, four of the six left for new opportunities. The remote work revolution was in full swing; the talent market was wide open in a way none of us had anticipated. The pilot team dissolved before it had a chance to function.
The pivot was to stop trying to build a standalone design systems practice and start embedding design systems work inside initiatives that were already well-resourced. I found an existing interdisciplinary working group with a project manager already attached and used it as a makeshift design system partner. Design system goals got aligned to project goals. Decisions that would have gone undocumented got captured in flight.
This wasn't the plan. It was more useful than the plan would have been.
The Calendly engagement required three capabilities working in concert: systems thinking to see the structural problem across teams and products, organizational design instinct to find viable paths when the original plan dissolved, and design craft to build components, standards, and documentation that the team could actually use.
The constraint framing matters here — not as an excuse, but as evidence. High turnover, shifting priorities, no dedicated support, a product growing faster than documentation could follow. A system built under ideal conditions wouldn't have been tested the way this one was. The system that came out the other side was shaped by all of it, which is precisely why it held.
