No Straight Lines
Scaling
Read time: 5 minutes
I told my leader directly: I need help, I can't do this alone. That's how I got my first dedicated contractor.
I didn't get to interview him individually — we vet through the staffing partner, not the person — but I coached him on the strategy from day one: no custom-building every native component, use the platform's own patterns where users already expect them, aim for feature parity instead of design parity. If Apple or Google had their own way of doing something, that was fine — we only needed the user to have the same capabilities. Southwest branding layered on top, customized only where it mattered. I was also deliberate about keeping the platforms from blurring together, following the same "system of systems" model I'd seen larger companies use for their own multi-platform work, rather than one system pretending to be everything at once.
Native engineering buy-in didn't come from a single meeting — it came from staying consistent. Everything the team was building before this was effectively custom, one-off components, and I watched us lose good engineering talent to companies working in a more modern way. My leader was hearing the same feedback from a different angle — why doesn't the app feel like an app. I kept offering the same answer to both problems, and once we defined real design tokens for the first time during that native work, the idea stopped being abstract to our technology partners. That's when it started to spread on its own.
He showed up just ahead of one of the biggest shifts in how we worked. A few months into 2023, we finally replaced our old design-tooling patchwork with Figma — we dubbed it "Figma Day" internally — and having him already helping me plan what we'd need to rebuild made the move faster than doing it solo would have. I attended Config that same year, the conference where they announced the features (variables, modes, Dev Mode) that made everything we'd been arguing for actually practical. I came back a different kind of energized.
That's when the team started to take real shape. A foundation pod on the technology side became a consistent crew. A couple of native allies came aboard. I had my first dedicated contractor. What had been a grassroots effort run on conviction and borrowed time started to look, for the first time, like an actual program.
Scaling a design system is hard. Scaling one without a dedicated team, across two departments, four different teams, and reporting lines that stretch up to two directors and a VP — while the company around you is navigating one of the most turbulent stretches in its history — is a different kind of hard. That's where I've been living for the past few years.
I've made calls here I'm not fully certain about, and I'd rather say so than pretend otherwise. When resourcing didn't stretch far enough to unify naming conventions across every platform the system now touches, I let our technology partners make that call on their own rather than hold up the work waiting for a version of me that had time to do it "right." It didn't fully pan out — the inconsistency it created has since been called out as one of the things slowing us down. I'd make the same call again given the same resourcing, but I own that it's an open problem, not a solved one.
What needs rethinking next isn't the system-of-systems approach itself — letting each platform's out-of-the-box components do the heavy lifting is still the right call, and I'd make it again. It's the seams between them: unifying naming conventions and UI kits across iOS, Android, and web so the same small team can move across all three without holding three separate vocabularies in their heads. That matters more given the math. Our UX team, not counting me or my contractor, is about 12 designers with two to three contractors at any given time, working opposite a front-end engineering org of roughly 250 — something like one designer for every 17 or 18 engineers. That ratio isn't getting more forgiving, and the pressure to deliver faster only compounds it. Unifying naming and kits doesn't fix the ratio, but it's the lever I actually control, and it buys the team back real time.
A design system isn't just a technical challenge. It's an organizational one.
None of this is fully solved. I want to be honest about that. What's changed is that I now have a leader who's spent real time understanding what this work actually is and why it matters to the business, rather than a leader who inherited design systems as one line item among many. That's given me room to plan seriously — bringing in outside design-systems specialists to assess where the system actually stands (not to tell us anything we didn't already suspect, but to give it outside authority), and to start building a real case for the team this needs, rather than the team it's had to survive on.
The system survived things it probably shouldn't have. What it needs next isn't more conviction. It needs resourcing to match the scope it's already grown into.