Case study · Builder.ai
Building a design team from one
How I grew Builder.ai’s design team from just me to eight, kept everyone for two years, and helped a mostly junior team do work that mattered.
- Problem and role
- Builder.ai was building several products at once, and design started with just me. As Design Manager I hired the team, set how we worked, and stayed hands-on as a designer.
- Team and scale
- A team of 8. Four reported to me and I mentored the rest through influence, including 2 designers in London who reported to the Head of Design. Two mid-level, the rest junior. Sep 2022 to Sep 2024.
- The idea
- Give every designer clear ownership, then build the habits and guardrails that let a junior team do senior-level work.
Outcome
1→8
design team grown from just me
0
designers left in two years
5
of the team hired by me
I hired the rest together with the Head of Design.
Most of the team was junior. The work was not.
Context
Design started with one person
When I joined Builder.ai, the design team was me. The company was building several products at the same time, from Builder Studio to Builder Enterprise, and each one needed design across many product pods.
The question was not only who to hire. It was how a small team, most of it early in their careers, could cover that much ground without quality slipping.
01
Many pods, few people
Every product was split into pods, and each pod needed a designer who knew it well.
02
A mostly junior team
Two mid-level designers, the rest junior. Talented, but new to work at this level.
03
Real stakes
Builder Studio was heading to launch, and Builder Enterprise was moving from alpha towards beta.
Decision 01 · Hiring
Build the team one hire at a time
I hired five of the team myself, and the others together with the Head of Design. The team grew to eight: four reporting to me, and designers in London reporting to the Head of Design, whom I mentored through influence.
Hiring mostly junior designers had a clear trade-off. They would need more support, so the way we worked had to give it to them.
Decision 02 · Ownership
Two pods each, one owner each
Every designer owned two product pods. Each PM and engineering lead knew exactly who their designer was, and designers built deep context instead of jumping between projects. It also kept me from becoming the bottleneck.
Decision 03 · The hard part
Helping a junior team do senior work
This was the real challenge. I did not want to fix the gap by reviewing everything myself, so I used three things.
01
Hands-on beside them
I designed alongside the team on real work, so they could see the thinking, not just the result.
02
Critiques that teach
Critiques explained why a change mattered, not only what to change, so designers could apply it on their own next time.
03
The system as guardrails
The Block Design System gave everyone trusted components and rules, so juniors could move fast without breaking consistency.
Decision 04 · Rhythm
Habits the team could rely on
A predictable rhythm meant nobody had to guess when they would get help or feedback.
01
Weekly 1:1s
Time with each of my direct reports every week, for blockers, feedback and their own goals.
02
Design critiques
Work in progress shared early with the team, so problems surfaced while they were still cheap to fix.
03
Design reviews and sign-off
A clear quality bar before handoff, so engineering got work that was ready to build.
Decision 05 · Growth
Growing people without new titles
There were no promotions in my time, so growth had to come from ownership. Designers took on their own pods, then work across the team, like the core group of four who built the Block Design System with me.
I used Rose, Bud and Thorn to help each designer look back and plan their growth. I shaped mentoring around what each person wanted to get better at, and kept giving more scope as they earned it.
01
Rose
What went well, and why, so a strength could be repeated on purpose.
02
Bud
What was starting to grow: a new skill or a chance to stretch next.
03
Thorn
What was hard or blocking, so we could work through it together.
He doesn’t micromanage; he truly empowers.
Voices from my team
In their words
Three designers who reported to me directly, from their LinkedIn recommendations.
01
Tushar Verma, Product Designer
“He built a culture of psychological safety where everyone felt comfortable sharing ideas, taking creative risks, and doing their best work.”
02
Prachi Rathore, Product Designer
“As this was my first job, his mentorship and guidance played a significant role in shaping my approach to design and my growth as a designer.”
03
Swarna Awasthi, Product Designer
“Whenever I faced challenges, he was quick to lend a hand and work through problems with me.”
Impact
What the team delivered
For the team
Nobody left
Everyone who joined the team stayed through my two years.
Clear ownership
Every pod had one designer who knew it deeply.
Growth through scope
Designers moved from single pods to work that shaped the whole team.
For the product
Builder Studio shipped
A squad of 4+ designers from the team designed Natasha, the voice-first AI, and it launched in 2024.
Block Design System
A core group of 4 from the team cut design review cycles by 32% and made implementation 50% faster.
Hands-on throughout
While leading the team, I stayed the designer on Builder Enterprise.
Reflection
What I learned
Clarity is a kindness
Clear ownership did more for a junior team than any amount of review.
Teach the why
Feedback that explains the reason scales. Feedback that only asks for changes does not.
Let the system carry the rules
A good design system protects quality so people can spend their energy on the problem.
Next case study