CONTEXT
The situation: a team growing faster than its infrastructure
The Myntra catalog design org had scaled to 100+ people, but the systems supporting them hadn’t kept pace. Handoffs were inconsistent, performance tracking measured only errors, and institutional knowledge lived entirely in individual heads. The team was growing, but the infrastructure was fraying.
THREE CRITICAL GAPS
- No standardised delivery framework — handoffs to engineering and product were inconsistent.
- Deficit-based performance tracking — the “Monthly FTP” system measured only error rates.
- No documentation infrastructure — successful practices lived in individuals’ heads.
“Don’t just fix morale. Build the operational infrastructure that makes quality the default — at scale.”
— The mandate
APPROACH
Applying design thinking to the team itself
I treated the 100+ person team as the end-user. Instead of jumping to solutions, I spent three weeks in diagnosis mode — observing workflows, sitting in on reviews, and mapping where breakdowns actually happened.
“80% of the errors I found were systemic — rooted in unclear briefs, inconsistent processes, and absent documentation — not individual performance failures.”
— Audit finding
THE FRAMEWORK
Three operational pillars, one integrated system
Pillar 1
Business Operations — Standardizing how work gets done
Design Delivery Framework defining who sees work, at what fidelity, at which stage. Tiered review schema, Notion-based documentation, tooling guidelines, and prioritization criteria — all designed to remove ambiguity from the production pipeline.
Pillar 2
Team Operations — Rebuilding communication across the org
Weekly async “Visibility Ritual” replacing status meetings with structured updates. Cross-functional sync cadences, a comprehensive onboarding guide, and a Daily Brand Nudge standup to keep alignment tight without adding meeting load.
Pillar 3
People Operations — Shifting from monitoring to mentoring
UX Excellence Program built around growth signals, not failure metrics. “Value velocity” KPIs, a Blueprint Playbook for career development, peer recognition rituals, and quarterly health surveys to measure team sentiment alongside output.
LEADERSHIP
How I showed up for the team
- Set clear expectations and removed ambiguity from every handoff
- Gave the team voice and visibility through structured communication rituals
- Built trust through consistency — showing up the same way every day
- Tracked growth, not just output — making development part of the operating rhythm
- Invested in people through mentoring, not monitoring
- Provided strategic direction while leaving room for ownership at every level
IMPACT
“The result wasn’t just better metrics. It was a team that trusted the system enough to take creative risks again.”
REFLECTION
What I learned about ops as a design problem
Operations is a design problem. The same principles that make a good product — clarity, consistency, feedback loops, progressive disclosure — make a good operating system for a team. When you treat your team as the end-user, the diagnosis changes completely.
User-centered thinking applies to teams, not just customers. The three weeks I spent in diagnosis — observing, interviewing, mapping — were the most important weeks of the project. Without that, I would have built solutions for problems that weren’t the real ones.
Trust is the infrastructure beneath the infrastructure. Every system, ritual, and framework only works if the team believes it’s there to help them, not surveil them. Building that trust was the hardest and most important part of the entire intervention.