Design & UX

I've Been Managing Design Wrong, and Here's Why It Took Me Two Roles to Figure It Out

A

Admin User

Author

Jun 10, 2026
5 min read
2 views

Last month, I sat in a retrospective where our design manager and lead designer had what looked like two completely different conversations about the same problem. One was worried about team burnout and skill gaps. The other was concerned whether we were actually solving for users. I watched them go back and forth, wondering if we'd somehow hired people who didn't listen to each other.

Then I realized: they weren't having different conversations. They were speaking two essential languages about the same organism, and I'd been thinking about design leadership all wrong.

I've spent most of my career as a full stack developer watching design teams function. Sometimes they run beautifully. Often they don't. The ones that struggled usually had this nagging problem—ambiguity about who owned what. But the really healthy teams I've worked with? They had something different entirely. They had clarity about why their structure existed, not just what the structure was.

The Problem With Org Charts

Here's what I thought I understood: Design Manager handles people. Lead Designer handles craft. Clean boxes on a org chart. Problem solved.

Except it never worked that way in practice. Both roles cared about shipping quality work. Both cared about team health. Both had opinions about strategic direction. The overlap wasn't a bug—it was actually where the good decisions happened. The problem was we kept treating it like confusion instead of intentional partnership.

What changed my perspective was thinking about it like a living system instead of a machine. A team isn't a set of modular components. It's an organism with interconnected systems that all need each other to function.

Three Systems, Two Leaders, One Team

The framework I've been working with lately divides design leadership into three systems:

The Nervous System (psychological safety, feedback, growth) lives with the Design Manager, but the Lead Designer plays a crucial supporting role. If the team doesn't feel safe, they won't do bold design work. If the Lead Designer isn't helping identify skill gaps, the manager is flying blind.

The Muscular System (craft standards, execution, quality) lives with the Lead Designer, but the Design Manager enables it. You can have beautiful standards nobody follows because the manager didn't build organizational muscle around them. That's a failure of both roles.

The Circulatory System (strategy, communication, flow) belongs to both equally. This is where I see most partnerships fail. One person disappears strategically while the other doesn't communicate effectively, and suddenly nothing moves.

What This Actually Means When You're Shipping

I've been thinking about how this applies to the teams I work closest with. When we're deciding whether to rebuild a design system component, the Lead Designer needs to answer: "Is this the right design?" The Design Manager needs to answer: "Can the team absorb this change without breaking?"

Both answers matter. If you ignore the craft question, you ship the wrong thing. If you ignore the people question, you burn out the team shipping it. Neither person is wrong. They're just tending different parts of the same system.

The practical shift I've made is being explicit about which lens I'm using in conversations. Instead of just offering an opinion, I say something like, "From a technical debt perspective..." or "From a team capacity standpoint..." This gives the other person context for my input instead of making them guess what problem I'm actually trying to solve.

What I'd Do Differently

I think this framework is solid, but it assumes something that doesn't always exist: two people who are genuinely curious about each other's domain instead of territorial about it.

I've seen Design Managers who don't care about design quality and Lead Designers who think people management is "not their job." Those partnerships fail not because the framework is wrong, but because one person checked out from their supporting role.

The real work is cultural. Both roles need to believe they're responsible for the whole team's health, even when they're not the primary caretaker. That requires psychological safety and security that I don't think every design leader actually has.

Also—what happens when you only have one person doing both jobs? Most startups and smaller teams have a Lead Designer who's also managing people. This framework doesn't solve for that scenario, which is probably where most of us actually live.

The Experiment

I'm going to test this more deliberately with the design teams I work with. Next time we're in a decision that feels stuck, I'll suggest naming which system we're optimizing for first. "Let's make sure we're thinking about team capacity here, not just design quality." See if that unsticks things.

I'm curious if you've experienced this tension in your teams. Do you have clarity about who owns what, or does it feel like an ongoing negotiation? And if you're in a single-person design role, how do you balance both perspectives?


Source: This post was inspired by "An Holistic Framework for Shared Design Leadership" by A List Apart. Read the original article

Share this article

Related Articles

Design & UX Jun 8

Stop Waiting for Frameworks to Save You: Why I'm Building Smaller Again

I spent two hours last week debugging why a fresh Next.js project was pulling in 847KB of JavaScript just to display a contact form. The form itself? Plain HTML with basic validation. The irony hit me hard: I'd reached for a tool designed to solve a problem I didn't have, and now...

Design & UX Jun 9

When AI Design Tools Became Too Good: Why Sameness is the Real Danger

I built a quick landing page last week using Claude's design feature. Thirty minutes later, I had something that looked *professionally competent*. Rounded corners, a clean color palette, proper spacing, accessible contrast ratios. It was better than 90% of what I could hand-code...