DtG #8: How to scale quality without being a bottleneck.

Design leaders don’t scale quality by holding on tighter. Here’s what I learned when I stopped trying to protect the work—and started enabling the people doing it.

Welcome to the eighth installment of Designing the Gap!

It’s been a month since I last posted, which I’m feeling a little guilty about. But, after finishing my postgraduate course, focusing my design energy on writing a comprehensive guide to brand and product design collaboration for design systems, and officiating my friend’s wedding, I didn’t have much time for my newsletter.

In this edition, I want to talk about scaling quality, and how to do it as a design leader in a meaningful way without becoming a bottleneck. It’s on the longer side, but there’s a checklist at the end if you want to skip ahead.

TL;DR: Quality doesn’t scale through control. It scales through clear expectations, psychological safety, healthy feedback rituals, shared ownership, and the humility to step back. Here’s how to build that kind of culture.

Let’s get into it!

The quality trap

In my early design leadership career, I thought I was doing everything right. I was present in every design review. I left thoughtful feedback in docs and Figma files. I joined planning sessions. I facilitated and weighed in on crit. I nudged teams toward polish.

I saw, and established, myself as the final quality checkpoint—the person helping elevate the work before it left the door. But somewhere along the way, the process started to feel kinda heavy. Not just for me, but for the team.

Designers, and their stakeholders, hesitated to move forward without my input. Team members would ask “has Ben seen this?” before sharing anything upstream. Work was slowing down—not because the team lacked talent or drive, but because they were waiting. For me.

That’s when it hit me: I wasn’t just involved, I was in the way.

It’s easy to fall into this trap, especially as a new manager or a recently promoted design lead. We get recognized for our eye for detail, our ability to make the work better, to spot the thing no one else sees. So when we step into leadership, it’s tempting to think our role is to keep doing that—just at scale.

But, as you grow as a leader, your calendar fills up and your team expands. This means that the volume of decisions increases. And no matter how much context you have, or how fast you type, you can’t be everywhere at once. Not without burning out and definitely not without slowing the team down.

This flawed approach was most evident when I was leading content design and content strategy at an agency. I had a team working across multiple client projects, many of them high profile. Because I had been the protector of quality for my own work as an IC, it felt sensible for me to take the same stance for my team’s work when I became a manager. When it was just me and a couple of content designers, this approach was manageable—tight, even. We could bounce ideas around easily and share reviews informally. Our clients were happy, and the pace of work felt sustainable.

As the team started to grow, however, the scope of our work broadened, and the size of our client engagements grew. My need to be in all of the work became unmanageable. I slowed the work down for teams or projects I wasn’t even a part of. And my own client work started to slip too, as I tried to split my time across all of it. Clients noticed delays, and I found myself struggling to explain why things were stuck when I was the one causing the hold-up. It was a hard realization, but a necessary one.

That’s when I started to realize that my definition of quality—and my relationship to it—had to change.

What does it really mean to ensure quality?

For a while, I wrestled with that question. If I’m not the last set of eyes on the work, how do I make sure it’s good? If I’m not in the room, how do I trust it’s on track?

It took time (and a few hard lessons), but I eventually landed on this:

My job isn’t to prevent bad work. It’s to make good work inevitable.

Not by controlling every decision, but by creating the conditions for quality to emerge reliably, repeatedly, and without my constant intervention. Moving from “guarding the gates” to designing the system. Instead of being the person with the answers, I needed to become the person who helps others ask better questions.

Here’s what I’ve learned about how to do that.

1. Make quality visible, not personal

One of the biggest mistakes I made early on was assuming the team understood my expectations, because I did.

But quality is subjective. What looks “polished” or “clear” or “strategic” to you may not look that way to someone else unless you define it.

So I started documenting what “good” looked like. Not as a rigid checklist, but as a set of shared principles and examples. I worked with the team to align on standards: what a strong handoff looks like, what kind of thinking should go into early exploration, how to tell if something’s ready for exec review. That clarity became the foundation—because when expectations are visible, it becomes much easier to create a culture where people feel safe sharing early and often.

How I showed up in design reviews mattered too. I made a point to avoid purely tactical feedback whenever possible. Instead, I focused on explaining why something might benefit from a change, and offering clear examples of how it could evolve—never how it "should." That subtle difference helped shift feedback from directive to collaborative.

It gave people the ability to self-assess, aim high without guessing, and build confidence in their own judgment, not just rely on mine.

2. Make it safe to show work that’s not ready

Quality suffers when people are afraid to show rough work. If your team feels like early-stage thinking will be scrutinized too early or shut down too quickly, they’ll wait. They’ll polish, and they’ll overwork. By the time feedback arrives, it’s too late to shift direction without wasted effort.

Designing for quality means designing for safety. It’s vital that design leaders make it okay—expected, even—for ICs to share half-baked ideas and say “I’m not sure about this yet”. In this context, feedback is about evolution, not evaluation.

Of course, this only works if you’ve established a culture of psychological safety. Designers will not share unpolished work if they feel they’re going to be punished or judged for doing so. It’s important for leaders to hold up examples of their team sharing work in progress as a good habit to develop, as well as acknowledging that you know the work is still coming to fruition, and that you’re excited to see how it develops.

I’m deliberately staying clear of the fidelity debate here. While the use of grey boxes and abstract wireframes may feel outdated in an era where design systems make higher-fidelity work quicker to produce, that’s not really the point. What matters is fostering a team culture where sharing in-progress work—regardless of how polished it is—isn’t seen as risky. In the strongest teams I’ve worked with, showing messy work wasn’t a red flag. It was a healthy, welcomed part of the process.

3. Establish feedback rituals that reduce friction

If the only way a designer gets feedback is through a formal design review that requires your presence, you’re already behind.

Once your team feels safe sharing, you need to give them regular, accessible ways to do it.

I started to notice that a lot of what people were looking for wasn’t approval—they just wanted a pulse check. A gut check. Someone to say, “Yep, this is heading in the right direction.”, they just wanted a pulse check. A gut check. Someone to say, “Yep, this is heading in the right direction.”

So I created lower-friction ways to give and get feedback.

Quick async comments. Screenshots shared over GChat (Slack hadn’t yet gained traction at my company), peer-led critiques, etc. The goal was to normalize early feedback, not just late-stage review.

It made feedback less scary. It made iteration faster. And it decoupled my calendar from the team’s momentum.

Thankfully, design and collaboration tooling has made this much easier. Commenting features are everywhere now, but tools like Slack can also help carve out space for asynchronous crit. At Mailchimp, we had channels like “#content-design-workshare” for those moments when someone just wanted to float a line or two of copy, gut check a headline, or gather input—without having to wait for a formal review session. That kind of lightweight feedback loop kept momentum going and helped normalize the habit of sharing early and often.

4. Normalize peer feedback as a strength, not a shortcut

There’s a common (and unfortunate) assumption that the most senior person gives the most valuable feedback. But that mindset creates dependency, and it misses the point of working in a team. It also biases action toward feedback that might’ve come from someone more senior, but less familiar with the actual problem space.

When teams give each other feedback, they build shared ownership and build trust. And the quality of the work rises faster, because it doesn’t hinge on one person’s schedule.

So, when I wanted my team to keep moving forward without my continuous involvement, I encouraged them to share their work more often with each other. This helped keep things moving, quality of the work high, understanding of quality shared, and also built important soft skills for my team around giving and receiving feedback.

A little later in my career, shortly after I joined Mailchimp in 2020 as a design manager, our directors posed a question to my fellow managers and me: “Should we, as directors, join crit?” Having seen firsthand how feedback dynamics can shift when someone with a big title enters the room, I said no; crit should primarily be a space for designers to help designers. My peers felt the same way, and the directors agreed.

With the directors stepping back from crit, the managers' role shifted from reviewer to facilitator—and more importantly, to culture builder. We took that responsibility seriously. We modeled what good feedback looked like, offered prompts when the conversation stalled, and encouraged designers to lean into critique as a shared learning moment. And what we saw was encouraging: some of the most valuable insights didn’t come from us at all. They came from peers—designers who understood the problem space deeply or had wrestled with something similar just weeks before. That’s when it really clicked: peer feedback wasn’t a backup plan. It was a strength worth designing for.

5. Give up control to gain momentum

This might be the hardest part.

You need to be ok with letting go. Not because you don’t care about the work—but because you care about the people doing it. Because you trust them, and because you want them to grow.

When I stopped trying to be the final reviewer on everything, something surprising happened: the work didn’t get worse. It got better.

Designers leaned into their judgment. Peers gave sharper, more thoughtful feedback. More voices contributed to shaping the outcome.

And I got time back—time to zoom out, to advocate for the team, to solve bigger problems, to actually lead. That was the unlock: my job wasn’t to prevent bad work. It was to create the conditions where good work could happen without me.

The bottom line

Scaling quality isn’t about doing more, being in more reviews, or commenting on more work. It’s about building systems that make great work the default.

You won’t always get it right. There will still be times you need to step in, course-correct, or give the nudge only you can give. I’ve even had moments where I didn’t lean in soon enough and had to reset expectations with my team. That’s part of the job, too.

But overall, the more you focus on building clarity, establishing a healthy feedback culture, and nurturing trust, the less you’ll find yourself pulled into the weeds. You’ll still be present—but more as a multiplier than a gatekeeper.

So if you’re feeling stuck in endless reviews or overworked trying to “hold the bar,” ask yourself: What if your real job isn’t to review all the work? What if, instead, it’s to make sure the work doesn’t need you to be good?

That’s not letting go of quality; that’s how you scale it.

Recap: 5 ways to scale quality without being a bottleneck

✅ Make quality visible, not personal
Define shared standards and principles so everyone understands what "good" looks like—without guessing.

✅ Make it safe to show work that’s not ready
Psychological safety leads to earlier feedback, more collaboration, and faster learning.

✅ Design feedback rituals that reduce friction
Use async tools, lightweight reviews, and team-led critique to keep momentum going.

✅ Normalize peer feedback as a strength, not a shortcut
Empower designers to learn from each other—not just from you.

✅ Give up control to gain momentum
Trust the systems you've built and let the team lead. You're not disappearing—you're multiplying impact.

Thinks I’ve been reading

  • A case for slow growth by Jon Daiello. I really appreciated this perspective on slow growth—not just as something acceptable, but as something good. Earlier in my career, especially working in agencies, it felt like title-chasing was everything. You were either moving up or falling behind. But over time, I’ve become more at peace with a slower, more sustainable path that prioritizes depth, not just velocity. I’ve also seen younger designers get caught up in chasing the next big jump without fully sitting in where they are. This piece offers a generous, thoughtful reminder that you’re not behind, you’re becoming.

  • Fostering an Accessibility Culture by Daniel Devesa Derksen-Staats. As a design leader overseeing systems, I’ve often found that accessibility responsibilities default to our team. While ensuring components are accessible is crucial, this approach can inadvertently suggest that accessibility is solely a component-level concern. This perspective overlooks the holistic nature of accessibility, which encompasses not just individual elements but the entire user experience and organizational culture. This piece serves as a compelling reminder that building an accessibility culture requires intentionality, continuous effort, and a shift in mindset from reactive fixes to proactive inclusivity.

  • The Post-UX Era by Nate Schloesser. I nodded along with a lot of this piece. It echoes something I’ve felt for a while: we’re past the era where UX is a competitive advantage. It’s expected. And yet, I’m still surprised how often people treat things like IDEO’s design thinking model or NNG’s heuristics as if they’re still cutting-edge. They were useful frameworks—but they’re not the frontier anymore. If we want to keep delivering impact, we have to go deeper. That means leaning harder into the psychology and emotions underneath it all.