DtG #7: The visibility tax of design management.

I’ve had to take a couple weeks off from DtG while I wrapped up my UX/UI certification from the University of Texas—but now that that’s behind me, I’m excited to get back to talking about design leadership again.

I’ve got some thoughts about the program I went through (especially around the gap between academic theory and real-world practice), but I’ll save those for a later post.

I run a design system team and, as Q2 begins, I’m planning how we’ll connect with our customers—i.e. the product teams—to communicate what’s new in the design system and what’s coming next. That process always makes me reflect on the dynamics between teams, especially the subtle ways leadership expectations shift depending on what kind of team you’re on.

And it’s brought me back to this realization: Design pays a higher visibility tax than its partners.

Because design is fast, visual, and easy to show, it’s often the first team tapped to produce artifacts that serve executive visibility—not necessarily customer outcomes. But how that tax is paid depends on the nature of the team you lead.

On product teams, it shows up as pressure to produce beautiful, high-fidelity, and fast design artifacts—slides, decks, mocks, and vision prototypes that help executives tell a story. On design system teams, the tax takes the form of ongoing influence and internal service work: support requests, tooling, documentation, and the invisible work of building alignment and trust.

Same job title. Very different expectations. And far too little said about either.

Let’s break it down.

The product side: fast work, unclear asks, high stakes

Because design is seen as easy to spin up, product design managers often find themselves on the receiving end of urgent requests like:

• Can you pull together a few screens for the QBR deck?

• We need a prototype to show the board.

• Leadership wants to see a vision concept by Friday.

These asks tend to come out of nowhere. They might be loosely tied to the roadmap, or not at all. But they need to be polished, narrative-driven, and ready yesterday.

No one’s asking engineering to fake a working backend on short notice. PMs might get pulled into modeling or planning, but the expectations are different. Design? We’re expected to make something look real. Fast.

As a design manager, you end up doing the emotional labor of protecting your team’s focus, helping them prioritize, managing stakeholder expectations, and smoothing over unclear priorities. And all of that is in addition to running your team and delivering on the actual roadmap.

That’s the visibility tax. It’s not just about the work itself; it’s about absorbing the messy, in-between parts of executive communication that rarely show up in retros or OKRs.

I saw this constantly in a former role. The company had recently been acquired, and the new CEO and board regularly wanted to see future-state design provocations—bold visions of where the product might go. Because my team, a design system team, wasn’t directly tied to shipping near-term customer features, we were often pulled into this work. On paper, we were well-positioned to help. In practice, it meant our roadmap was constantly getting sidelined in favor of work that rarely saw the light of day.

The systems side: invisible work, distributed pressure

Design system managers—like me—usually aren’t asked to build vision decks or create high-fidelity mockups for executive meetings. But that doesn’t mean we’re off the hook. We just pay the visibility tax in different ways.

We’re responsible for making the design system seamless, scalable, and widely adopted—often with limited resources and without direct control over the teams who rely on it. That responsibility comes with a significant amount of cross-team stakeholder management. Not only do we have to invest in relationships with our own engineering and product partners, but we also need to maintain connections with those same roles across other teams. And when you factor in non-product stakeholders like brand and marketing, the relationship map grows quickly.

All of that happens alongside managing the design system’s own roadmap—and the program that supports it. Support requests, office hours, contribution processes, tooling and documentation upkeep… they all need consistent attention and care.

Unlike product teams, we’re one step removed from the end customer, which makes measuring success trickier. Instead of user outcomes, we’re often evaluated on proxies like adoption, engagement, and consistency—valuable, yes, but harder to tie directly to impact.

So while we may not be in the executive spotlight, we still have to be highly visible to the teams we support. In fact, sometimes we have to fight to be visible—advocating for our roadmap in rooms we’re not always invited to.

This added emphasis on communication, coordination, and influence is something we don’t always account for enough—whether we’re hiring for these roles or evaluating their impact.

Same title. Different game.

Product design managers and design system managers often sit at the same level in the org chart, but the weight they carry day to day can feel entirely different.

The visibility tax just manifests in different forms. For product design managers, it shows up as pressure to move fast, present polished work, and persuade stakeholders with compelling visuals. For design system managers, it’s about sustaining influence across teams, delivering internal service at scale, and maintaining consistency—often without much direct recognition.

Neither path is easier. But both are under-discussed.

What leaders can do

If you’re in a position to support design managers—whether they’re on product teams, system teams, or somewhere in between—here are a few ways to help lighten the visibility tax:

1. Make the invisible work visible.
   Talk openly about the emotional labor, stakeholder management, and behind-the-scenes coordination that goes into design leadership. Acknowledge it in 1:1s. Reflect it in performance reviews.

2. Create space for reflection, not just reaction.
   Design leaders need room to think strategically, not just react to requests. Protect time for them to focus on their team’s roadmap and long-term impact.

3. Invite them into the right rooms.
   If a design system manager isn’t at the table where prioritization happens, that’s a gap. Bring them into conversations early. Trust them to advocate for broader org health.

4. Normalize tradeoff conversations

   When design leaders are asked to contribute to executive-facing or visionary work that falls outside their team’s roadmap, there’s seldom space for them to push back. But you can create space to talk about tradeoffs. Acknowledge how this work impacts the team’s priorities, and support your design managers in navigating those asks transparently.

5. Clarify expectations across roles.

   Recognize that not all design leadership looks the same. What success looks like for a product design manager isn’t necessarily what it looks like for a systems manager. Tailor goals and evaluations accordingly.

Why this matters

When we don’t acknowledge these realities of design management, we risk setting design leaders up to fail.

We overlook the invisible work that makes the visible work possible—the negotiations, the shielding, the constant context switching, the quiet advocacy, and the influence without authority. We celebrate output without recognizing the coordination it took to get there.

If we want to support, promote, and grow design leaders effectively, we need to recognize what each role actually demands—not just what shows up in dashboards or delivery metrics.

Some of the most important work design managers do happens behind the scenes Let’s stop pretending that means it’s not valuable.

Things I’ve been reading:

• Duolingo just ended the term UX design by Punit Chalway. That’s right folks, we’re back to renaming disciplines and teams. It’s been a couple years since we’ve had a naming trend (content strategy → content design? product designer → experience designer?), so we were due another. Snark aside, this shift from Duolingo feels less like a bold move and more like an acknowledgment that “UX” is no longer role-specific—it’s distributed across functions. Should other teams follow suit? Who knows. These changes always feel big at first, but usually just create noise before things settle into something we can all mostly agree on.

• Can we actually design for sustainability? by Allie Paschal. This post stuck with me. We tend to think of digital products as inherently cleaner than physical ones, but the truth is, the internet has a carbon footprint—and UX plays a role in that. This is even more true now that AI tools pervade our everyday workflows. Allie outlines four practical strategies for reducing a product’s environmental impact without tanking usability. What I appreciated most is that the focus isn’t on being perfect—it’s about being intentional. Worth a read if you’re thinking about sustainability beyond just your materials library.

• Making designs without a designer by Adam Judelson & Dr. Ryan Brotman. I’ve quickly grown tired of the “AI will kill design” takes. They’re dramatic, and they ignore the realities of what good product design actually involves. That said, AI is changing how we work—and this piece is a thoughtful look at how. It walks through using v0.dev to spin up UIs, generate design systems, and iterate on product ideas with speed and structure. What I liked is that it doesn’t oversell the magic—it shows where AI helps, where it stumbles, and how a more strategic workflow can make the difference.