Building the system behind a high-performing design team

The challenge

When I became Design Lead in 2022, I inherited a talented team, but the system around them was thin.

Critique depended on designers seeking feedback. Work was assigned largely by country rather than expertise. Designers sometimes entered technical conversations after important constraints had already been set.

The problems looked different, but I saw the same pattern underneath them: too much depended on individual effort.

I didn’t want quality to depend on a lead reviewing everything, or collaboration to depend on individual designers knowing when and whom to involve.

My belief was simple:

Over the next four years, I focused on four interconnected systems: quality, learning, operations, and influence.

The system I built

• 01 · Quality — make quality a team responsibility. Embed critique and peer review into delivery rather than relying on final-stage reviews.
• 02 · Learning — make capability-building part of the work. Create space for designers to learn from one another and adapt to emerging capabilities.
• 03 · Operations — design the environment around the designers. Match work to expertise, make capacity visible, and build intentional mechanisms for growth.
• 04 · Influence — move design upstream. Bring UX into problem framing and technical decisions before solutions are committed.

The four systems at a glance — quality, learning, operations, and influence — and the outcomes they produced.

The goal wasn’t more process. It was to create an environment where good design could happen consistently without depending on individual heroics.

01 · Quality

Make quality a team responsibility

Feedback was happening, but inconsistently. Designers had to actively seek it, or leads had to catch issues before development.

I wanted quality to be built into how we worked.

We experimented with several approaches. One was a designer checklist, which quickly proved to add more overhead than value. We dropped it.

What survived was deliberately lightweight: regular critique and peer review embedded in the delivery workflow, with every key project reviewed before development.

The bigger change wasn’t the meeting itself. Designers became collectively responsible for the quality of the team’s work.

Over time, the practice required less reinforcement from me and became established enough that I helped two other design teams adopt it.

The shift: from a lead maintaining the quality bar to the team maintaining it together.

02 · Learning

Make capability-building part of the work

Learning usually has to compete with delivery. I wanted it to be part of delivery instead.

I built a regular learning rhythm through DADA, our knowledge-sharing series, and weekly peer learning where designers shared techniques, unpacked projects, and taught one another.

When generative AI emerged, we used that existing system to learn through practice rather than adding another training program. We introduced bi-weekly AI sessions and design challenges using AI for ideation, wireframing, and research synthesis.

The progression was simple: learn together → experiment together → apply it to real problems.

That culminated in NetSuite’s global Promptathon, where I led a cross-region team tackling an audit-readiness problem for a nonprofit customer. Our design contribution centered on context engineering: defining roles, establishing source rules to reduce hallucination, and iterating prompts until the output was reliably useful.

The team won its track.

The award was a useful signal, but the more important outcome was capability: designers had moved from learning about AI to applying it with engineering and solution partners to solve a real customer problem.

03 · Operations

Design the environment around the designers

Some of the biggest constraints on design quality had little to do with craft.

Historically, projects tended to be assigned by country. I shifted us toward an expertise-based UX Support Framework, matching designers to domains, strengths, and development opportunities rather than geography alone.

I also introduced workload visibility through JIRA and a productivity dashboard, giving us a clearer basis for capacity and priority decisions.

For team development, I established quarterly retrospectives where designers identified problems in our own ways of working and carried actions into the following quarter.

I took a similar approach to mentorship: rather than pairing people based on availability, I first asked designers what they wanted to learn and where they needed support, then structured mentorship around those needs.

The principle was:

The shift: from managing individual assignments and problems to creating mechanisms that helped the team manage them more intentionally.

04 · Influence

Move design upstream

A strong design team can still have limited impact if it’s brought in after important decisions have already been made.

Instead of repeatedly asking PMs to “involve UX earlier,” I treated our product-development process as a design problem.

I ran a journey-mapping workshop with PMs to understand where UX entered, where information was lost, and where earlier collaboration would change the outcome. It revealed that late involvement wasn’t simply a relationship problem. Our process lacked reliable mechanisms for bringing design into early decisions.

We responded structurally: increasing adoption of our research framework, adding UX considerations to product requirements, and bringing designers into technical spikes. Eventually, UX participated in 100% of technical spike discussions, allowing technical constraints to shape designs during exploration rather than arriving as surprises afterward.

I also created opportunities for PMs, developers, technical writers, and designers to solve problems together through design-thinking workshops.

During one Hyderabad workshop, cross-functional teams worked on the same onboarding problem but developed very different hypotheses. More important than the ideas themselves was the behavior change: people were discussing the user problem together before discussing implementation.

Designers increasingly moved from participating in these conversations to facilitating them.

The shift: from design receiving problems downstream to helping the organization frame and solve them upstream.

Leadership also means knowing when to intervene

Building systems doesn’t mean every decision needs a manager. In fact, my goal was the opposite: most decisions should move forward without me.

But leadership also means recognizing the few decisions whose consequences will outlast the project.

On a Philippines localization project, a technical limitation led the scrum team toward an expedient solution: placing multiple invoice numbers into a single text area.

It would have shipped faster, but it would also have created a poor data-entry pattern customers could potentially live with for years.

This was one of the times I chose not to compromise. After several rounds of negotiation, we found an alternative — a shuttle component that respected the technical constraints while maintaining the usability bar.

Most days, I compromise early and often. The lesson wasn’t to fight harder for design. It was to know which fights matter.

What changed

Over four years, practices that initially required active leadership increasingly became part of how the team operated.

• Quality — peer review became standard workflow for key projects and was adopted by two other design teams.
• Capability — designers moved from peer learning to facilitating cross-functional problem solving, engaging directly with customers, and applying AI to real customer problems.
• Operations — staffing shifted from geography toward expertise, while structured mentorship, retrospectives, and workload visibility became part of the team’s operating model.
• Influence — UX became part of 100% of technical spike discussions, bringing designers into important technical decisions earlier.
• Partnership — PMs described the team as “seamless and dependable” and reported that our solutions consistently required “minimal rework.”

The work was reflected in my own progression as well: I was rated “exceeds expectations” and promoted to UX Manager in 2025.

What I learned

Early in my leadership journey, I thought maintaining a high quality bar meant staying closely involved in the work. Over time, I learned that this doesn’t scale.

The systems that lasted weren’t always the ones I designed correctly the first time. We discarded critique formats. Learning programs evolved. Mentorship started with listening before designing the structure.

More importantly, systems survived when the team owned them.

And influence didn’t come from asking the organization to value design. It came from creating situations where people experienced the value of working differently — a PM framing a problem with a designer, a developer joining an ideation session, or a designer hearing a customer’s frustration firsthand.

That changed how I saw my role. My job wasn’t to personally maintain the quality bar. It was to build an environment where the team could maintain — and raise — that bar together.