1) POV

The best teams become two things simultaneously.

A support network, people who have your back when the work gets hard, who carry the load with you and pick things up without being asked. And a challenge network, people who tell you the truth, push the work further, and make you better by not letting things slide. Both matter. A team that only supports you gets comfortable. A team that only challenges you gets exhausting. The ones worth building have both.

I discovered this by actually doing it. Before ServiceNow I had led designers, managed workflows, driven delivery. But those were teams I inherited or was assigned. Building from nothing is different. You are not just filling roles. You are making a series of bets on people, and those bets compound over time in ways you cannot fully predict when you make them.

That is what I was trying to build at ServiceNow. Not just headcount. A team with that dual quality.

2) The scale

Before I get into how, here is what I was responsible for building:

• HR Service Delivery: 1 to 6 designers

• Legal Service Delivery: 1 to 2 designers

• Contract Lifecycle Management: 1 to 2 designers and 2 contractors

• 10 hires across pods

• 4 promotions supported across levels, including one move into people leadership

These numbers did not happen in one move. They were a sequence of deliberate decisions made while the work was already in flight.

3) How it unfolded

When I joined, the India design footprint was still forming. I was delivering critical HRSD work while the IDC growth plan started materialising in parallel. I supported my Design Director on the first few hires, then gradually took full ownership of team growth across hiring, onboarding and shaping how design would operate across pods.

Step 1: Seed the pods with the right first hires

The goal in the early phase was not to add people. It was to place the right first hires so pods could form across HRSD, LSD and CLM with real ownership rather than just execution coverage.

Some roles needed a rare combination: enterprise execution plus enough strategic judgment to hold ambiguity with PM and Engineering. When I found high-slope candidates who were strong on most dimensions and rampable on a few, I hired with an explicit 6 to 12 month ramp plan and owned that investment personally.

Step 2: Make ownership visible so the org does not route through one person

As the team formed, PMs and leaders would ask in release cycles: who owns this from design? That question was the signal. The org needed legible ownership as scope expanded.

I made pod ownership explicit across HRSD, LSD and CLM with clear partner touchpoints. When people know exactly who to go to, and that person knows exactly what they own, the quality of the work and the relationships both improve.

Step 3: Build owners through scope, feedback and sponsorship

Scaling teams is really about leadership density. I needed more people who could run rooms, drive tradeoffs and protect quality without escalation.

I built that through three repeatable moves: expanding scope gradually from feature slice to workflow area to roadmap thread over two to three cycles, giving feedback on problem framing and tradeoffs before UI, and creating sponsorship opportunities where pod owners presented in key reviews once the narrative was ready. Promotions were a downstream result of readiness built this way, not of timing or tenure.

The proof I look for is not when critique exists in a team. It is when critique changes direction. That shift, when a designer pushes back on a PM in a review and the room moves with them, is when you know the ownership is real.

Step 4: Keep the team sustainable as the surface area grows

Scaling breaks in quiet ways too. Overload, meeting bloat, and yes becoming the default.

One designer struggled with saying no because they worried it would damage relationships. We worked on a different posture together: no as a tradeoff and a path forward rather than a rejection. Over time their boundaries strengthened trust rather than undermining it and protected outcomes for everyone involved.

On the system side I focused on meeting hygiene. Reduced recurring meetings, kept critique and working sessions as the only standing defaults, and protected focus time for the people doing the actual making.

4) Where we landed

Pods started running reviews directly with PM and Engineering without me as the bridge. Partners came to pod owners first. Strategic work became owned and driven from India. The triads were functioning.

But the moment I remember most clearly is a secondhand one. An engineering lead reached out to tell me that one of my HRSD designers had run a Figma working session for the engineering team, covering how to navigate design files, read component structure, access dev mode and use it effectively. It helped newer engineers find their footing but it also, as the lead put it, cleared up questions that even senior people had been quietly carrying for a long time.

That was the moment I felt the team had truly arrived. Not because of what they delivered. Because of who they had become.