Case study · Design org · Sprinto 2024–26
Designing a design org that works without me in the room
I treat the design function like a product: it has users, a roadmap, a quality bar, and metrics it's accountable for. Most of my leverage now comes from what the team can do without me.
Results
What changed, labelled by how it was verified.
The real problem
Design didn't have an execution problem. It had an ownership and visibility problem. Partners in product and engineering saw a team delivering tasks rather than owning outcomes, and designers weren't in enough customer conversations. Good work existed, but the rest of the company couldn't see it.
Four decisions
Gather evidence before changing anything
Before any calibration, I ran one-to-one retros with product and engineering leaders and asked what they needed from design. I acknowledged my own gaps in that process too. Then I wrote a response to each concern, with a named signal we'd watch for each one.
Trade-off: a few weeks slower to start, in exchange for a plan the partners had already shaped.
Three streams with deliberately different definitions of good
A team that ships fast and a team that builds foundations can't be held to one bar without one of them quietly losing. So the streams aren't specialisms. They're different mandates, and they're meant to pull against each other.
| Stream | Mandate | The bar | The non-negotiable |
|---|---|---|---|
| Core product | Customer-facing workflows, adoption, friction | L2, moving to L3 | Every designer leads at least one customer conversation a month. Leads, not observes. |
| New products and AI | SprintoX, AI-first products, AI governance, future bets | L3 and L4 for seniors | Seniors multiply others. Thinking that doesn't transfer is the growth gap. |
| Simplification | Navigation, information architecture, UX debt | Ship visibly, ship fast | Owned directly by me. Fewer committees, bounded scope. |
Each stream has a written brief. The part that matters most isn't the mandate. It's the section on what the stream gets back from leadership. A brief that only assigns obligations is a task list.
Trade-off: designers in core product moved closer to their PMs, which gives up some design-org control for clearer accountability.
Level people by the size of the question they own
Most levelling frameworks describe craft quality, which nobody can disprove in a review. This ladder describes the scope of the question you're trusted to answer, which you can observe. Each rung contains the one below it.
| Level | What you own | In practice |
|---|---|---|
| L1 | The solution | Given a problem, design the right solution |
| L2 | The workflow | Define how the whole workflow works, across screens and states |
| L3 | The problem | Find the right problem instead of solving what was handed over |
| L4 | The business outcome | Connect the work to adoption, retention or activation, and defend the choice |
Trade-off: it's uncomfortable on purpose. That discomfort is what makes it useful.
Ask for the baseline before the work, not after
Before significant work begins, three answers are required: what metric will move, what's the baseline today, and how will we measure it. Ask for a baseline after launch and you get an argument. Ask during scoping and you get a number.
Simplification gets one more filter: will a customer or a CX teammate notice this changed, and feel relief? It rules out a surprising amount of work that's genuinely better and genuinely invisible.
Builder OS
Builder OS is an R&D initiative I co-created and orchestrated. It lets designers and PMs, not just engineers, ship features with AI coding tools. It included a GitHub agent for small fixes (copy, typography, mappings, regressions), the design system exposed inside the coding tool so builds use real components, and a repeatable builder workflow.
It produced the most surprising lessons of my year:
- Review cost goes up, not down. AI speeds up production and inflates documentation. The domain expert who has to read three times as much became the new bottleneck.
- Traditional PRDs are the wrong format for AI. A flow of requirements, then plan, then tasks hallucinated far less.
- Small features aren't simple. Without tight scoping you get code bloat, test bloat and review overhead.
- Full local setups are mostly unnecessary for well-scoped builds, and cost hours.
What changed
The streams, owners and four-week plans were live within a week of the decision. 83% of everyday stories are now owned independently by designers, and the research loop runs on its own: monthly NPS analysis, five conversations a month with low-scoring customers, quarterly ticket themes, and at least ten user tests per flow.
We didn't have proper agendas before. Now every weekly meeting has purpose and clarity.
Ranjan PaiDesigner on the team
He enabled me to move from IC work to leading pods. That space to grow was created by him.
Utkarsh BhandariDesigner on the team
What didn't work yet
Builder OS first read to leadership as activity without an outcome. "We launched it" isn't a result; "it cut workflow time by X%" is. That taught me to frame every initiative by its outcome from day one.
The ladder also got pushback. Some designers felt it made the job "basically a PM role." That was partly the point, since the gap between PM and designer was costing us. But it showed I needed to explain what designers get back, not just what they're asked to own.
And the honest gap: the streams, the ladder and the baseline rule are running, but their outcomes aren't yet measured as a system. Next I want to know how many designers moved up a rung and on what evidence, and whether simplification releases show up in support-ticket volume.