Building the Design Team

The Starting State

The problems with the scattered structure weren't always visible from the outside. Projects got delivered. Designers were capable. But a few things were consistently true:

Design quality depended entirely on individual ability. There was no shared standard — no critique culture, no design system, no review process that could raise the floor. When someone was good, the work was good. When they struggled, there was no structure to catch it.

Designers didn't learn from each other. Distributed across units, they had no regular opportunity to share what they were working on, exchange feedback, or build a collective sense of craft.

Cross-functional expectations were inconsistent. PMs and other stakeholders had different mental models of what design was for and what designers did. This created friction on every project — and meant designers were constantly having to re-establish basic trust rather than building on it.

No one owned the overall experience.Individual designers owned their pages, their features. But the product's experience as a whole — its consistency, its direction, its quality across touchpoints — belonged to no one. This was the root condition that let everything else persist.

Framing the Problem

Early on, I had to make a choice about where to start.

The obvious options were outputs: ship a design system, run better critiques, establish a process. All of those were right. But I'd seen enough organizations mistake the artifact for the change — producing a design system that nobody used, running critiques that felt unsafe, establishing processes that created compliance rather than conviction.

The actual problem was more fundamental: how do you get a group of people who are used to working independently to start operating as a team — and how do you make that team trusted by the rest of the organization?

That framing pointed me toward something less glamorous than systems or process frameworks: how we worked together, consistently, over time. The answer was structure: repeatable mechanisms that would generate culture as a byproduct, not slogans.

Building Structure Before Culture

I started with four recurring touchpoints:

Design Weekly — a regular sync for aligning on project status and experience direction across the team. This created a forcing function for designers to articulate what they were working on and why, rather than just executing in isolation.

Design Critique — structured sessions for sharing work and receiving feedback. The goal wasn't polish. It was building a shared quality standard and, critically, making feedback feel safe enough to give and receive honestly. Psychological safety doesn't emerge from a policy; it emerges from repeated positive experiences of being heard.

Design Sharing — sessions focused on craft, tools, and ideas from outside the team. Not project work, just learning. These were lower-stakes than critiques and often where I saw designers start to connect with each other as people rather than just colleagues.

Monthly 1:1s — individual conversations connecting personal growth to team direction. This was where I learned what was actually going on — where designers felt stuck, what they were proud of, what they needed that the structure wasn't giving them.

None of these were immediately welcomed. Time pressure was real. The psychological cost of vulnerability in a new context was real. I didn't push the value proposition — I led by example, showed up consistently, and designed each session to actually make the work better rather than adding process overhead. When designers started noticing that critique sessions made their projects go smoother, and that sharing sessions gave them things they used the next week, the habits began to form on their own.

Building Influence Without Authority

The design lead role at KKBOX wasn't an established position when I stepped into it. There was no inherited credibility, no existing organizational trust to draw on. I had to build influence the same way any design team builds trust: through results.

Three things established that influence over time.

Project outcomes. When a project had strong design support — when the designer was involved early, when the brief was well-framed, when decisions had a clear rationale — the results were better. Cross-functional partners could see the difference. That visibility was what made the case for investing in design as a function rather than individual contributors.

Team coherence. The shift from "one strong designer" to "a trustworthy design team" is a different kind of credibility. It means someone can be assigned to a project knowing they'll work well with PMs, ask the right questions, and deliver at a consistent standard — not because they're exceptional, but because the team operates that way. Getting to that point took years of consistent process.

Shared standards. The design system and UX research practice weren't pursued for their own sake. They were infrastructure for reducing the amount of work that depended on individual judgment. When a designer could point to a component or a research finding rather than defending a personal preference, it changed the nature of design reviews. Decisions stopped being about taste and started being about rationale.

From Managing to Enabling

The question I used to assess whether the team was developing real ownership wasn't "are they producing good work?" It was subtler: are they behaving like owners?

Ownership shows up in specific behaviors. A designer who initiates a discussion with a PM rather than waiting for a brief. A designer who raises an experience concern outside their immediate scope because they feel responsible for the product's overall quality. A designer who comes to a critique with a clear point of view rather than seeking approval.

When those behaviors started appearing consistently, I knew the direction was right.

One specific transition marked the shift clearly. I worked with a senior visual and marketing designer over time, helping him develop into a part-time management role. The effect wasn't just that he took on more responsibility. It was that the team's design leadership stopped being concentrated in me. When design direction and organizational decisions could come from someone other than the lead, the structure had become more resilient than its org chart.

That's the version of "delegation" that actually works: creating conditions where others develop the judgment to lead, not just assigning tasks.

People Before Projects

One of the harder lessons from four years of building this team: misaligned people slow everything down more than any structural problem.

When I sensed that a project was stalling, my first question stopped being "what's wrong with the project?" and started being "what's wrong with the working relationships?" More often than I expected, the answer was that expectations hadn't been set clearly — about roles, about decision rights, about what success looked like — and the project was absorbing the cost of that ambiguity.

I made the call more than once to pause project progress in order to realign people first. In the short term, this looked like slowing down. In practice, it usually meant the subsequent work moved faster and required less management intervention. Friction that gets ignored doesn't dissolve — it just moves deeper.

Some teams are right for pushing quickly together. Some combinations of people need clarity before they can move at all. Learning to tell the difference — and acting on it without waiting for a project to collapse — is a management skill that I developed slowly and still refine.

What Stayed

The clearest test of whether organizational work is real is what persists when the person who built it isn't actively maintaining it.

By the time I left KKBOX, the following didn't need me to sustain them:

The Design Weekly, Critique, and Sharing rhythm was running on its own momentum. Designers were owning and facilitating sessions I used to run. The calendar held because people wanted it to, not because it was required.

The designer-PM collaboration model had become a shared expectation across the product organization. PMs knew how to work with designers, and designers knew how to partner on problem definition rather than waiting for specs.

The design system was in active use and being extended by the team. It had become infrastructure — something designers reached for rather than worked around.

The UX research practice had established a basic norm: that design decisions should be grounded in something beyond individual intuition. Not every project had research. But the expectation existed, and teams knew how to request it and use it.

Building those conditions was the actual work. None of it shows up as a discrete deliverable.

Reflection

For most of my career before this, "doing the work well" meant producing strong design output. At KKBOX, I had to internalize something different: the highest-leverage thing I could do was create conditions where other people could do strong work, then get out of the way. My output was their output. The quality standard lived in their decisions.

The other shift that mattered: I moved from a mindset of ensuring things get done to ensuring the team doesn't get stuck. Those sound similar but point in different directions. The first leads to oversight and approval loops. The second leads to clearing obstacles, building trust with cross-functional partners, and investing in the skills and clarity that let people solve problems independently.

What I'd do differently: I'd invest earlier in the 1:1 relationships with individual designers, particularly in the first year. I was good at building the structural layer — the processes, the design system, the cross-functional alignment. I was slower to build the individual trust that makes people tell you what's actually hard before it becomes a crisis. That trust is built in conversations, not systems.

The structure I built at KKBOX outlasted my active management of it. That's the version of success I was working toward — and the version of leadership I want to keep building toward.