Your First Design Management Job Is Not a Bigger Design Job
I was talking with a senior designer recently who had spent years as the only designer inside small product companies.
She had done much more than the title suggested. She worked across product and engineering, created structure where there was none, made the case for better research, and helped teams ship. But when she looked for a formal leadership role, she kept running into the same problem: companies saw a strong individual contributor and hired someone else to lead.
The easy explanation is that she needed management experience. That is partly true. The part that stuck with me was how much leadership experience was already there, hidden inside a story about design work.
This happens to a lot of senior designers. They prepare for management by showing that they can handle more projects, make better design decisions, or review other people's work. Those capabilities matter. They are also still centered on the designer's own output.
Your first design management job is not a bigger design job. The unit of work changes. You are no longer measured mainly by what you make. You are measured by whether the team can make better decisions, do stronger work, and deliver results together.
The Promotion Can Reward the Wrong Skill
Designers are often promoted because they are dependable under difficult conditions. They can untangle a complicated flow, facilitate a tense review, find the missing state, and get the work across the line.
Then they become managers and keep doing exactly that for everyone.
At first, it looks useful. The new manager joins every project, fixes the hard screens, rewrites the presentation, and steps into every conversation that starts to drift. The team ships. The manager stays busy. Leadership sees someone who is willing to help.
But the system now depends on one person being present at every important moment.
The manager has increased personal output without increasing the team's capacity. People wait for reviews. Decisions collect at the top. The strongest designer gets less room to lead because the manager is still occupying that space. The team may be producing more, but it is not becoming stronger.
Craft does not stop mattering when you become a manager. It changes how it creates value. Your judgment should improve the conditions around the work, not make you the permanent finishing step.
The Unit of Work Changes
As an individual contributor, the unit of work may be a flow, a study, a prototype, or a product decision. As a manager, the unit of work is closer to the system that produces those decisions.
That system includes:
- whether people understand what they own;
- whether product, design, and engineering align early enough;
- whether feedback makes the work clearer or merely more cautious;
- whether the team can name the tradeoff behind a decision;
- whether designers are growing into problems that once required you;
- whether leadership can connect design work to customer and business outcomes.
This is why a manager can have a day full of useful work and produce no visible artifact. A well-framed planning conversation may prevent two weeks of rework. A direct coaching discussion may help a designer handle the next stakeholder conflict without escalation. A clearer role boundary may remove months of low-level friction between functions.
None of that appears in Figma. All of it affects what eventually ships.
This is close to the distinction I wrote about in The Signals That Tell You Design Is Working. Output tells you that people are busy. The operating signals tell you whether the team is making better decisions and moving with less friction.
Do Not Abandon Craft. Reinvest It.
Some designers hear this shift as an instruction to move away from the work. I do not think that is right.
A design manager still needs enough craft depth to recognize weak reasoning, coach through an interaction problem, and protect the experience when pressure narrows the conversation. The difference is where that expertise goes.
Instead of correcting the screen, ask the question that helps the designer see the issue.
Instead of taking over the stakeholder presentation, help them frame the decision and prepare for the likely objections.
Instead of becoming the translator between design and engineering, create shared language and working agreements so the relationship survives without you.
The goal is not to make yourself unnecessary. It is to stop making yourself a bottleneck.
I keep landing on a simple test: after you help, who has more capability than they had before?
If the answer is only you, you probably completed the work as a senior designer. If the designer, team, or cross-functional partnership can now handle a similar situation with less support, you did management work.
Learn to Describe the Business Around the Design
The other shift is language.
Senior designers often describe leadership through design activities: I ran the critique. I established the system. I mentored two designers. I partnered with product.
Those statements are not wrong. They leave the value unfinished.
What changed because you ran the critique? Did the team identify risk earlier? Did a shared pattern reduce implementation drift? Did mentoring allow someone to own a larger area? Did the product partnership turn an open-ended request into a decision the team could ship?
Business language does not mean forcing a revenue number onto every design choice. It means understanding what the organization is trying to accomplish and explaining how your leadership changed its ability to do that.
Sometimes the result is growth or retention. Sometimes it is faster learning, lower delivery risk, less rework, stronger adoption, or a team that can take on a more complex problem. The point is to connect the management action to the organizational result.
That connection also makes your existing leadership experience easier to see. A sole designer may not have direct reports, but they may have built an intake process, aligned several functions around a roadmap decision, established a research practice, or reduced uncertainty for engineering. Those are not substitutes for people management. They are evidence that the person already knows how to improve a system around the work.
The framing matters. As I wrote in The Frame That Shapes Your Influence, the way you describe the work reveals your relationship to the problem. Management interviews make that especially visible.
Start Practicing Before the Title Arrives
You do not need to wait for a manager title to make this shift.
Look for a small part of the team's operating system that depends too heavily on individual effort. It might be an unclear review process, a recurring handoff failure, a gap in how decisions get documented, or a junior designer who needs a larger problem and the support to own it.
Then work the system rather than rescuing the artifact.
A practical place to begin is with four questions:
- What result does the team need? Name the customer, product, or business change—not just the deliverable.
- What keeps the team from reaching it? Look for unclear ownership, missing context, weak feedback, or a decision arriving too late.
- What capability should exist after you help? Decide who should be able to do what without you next time.
- What evidence would show the system improved? Watch for less rework, faster decisions, stronger ownership, or a better product result.
This is also a useful way to build a management story for an interview. Do not claim that influencing peers is identical to managing people. It is not. Be honest about what you have and have not done. Then show that your attention has already moved beyond your own artifact toward the conditions that help other people succeed.
That is a more credible signal than saying you are ready to lead because you have been designing for ten years.
Leadership Changes What Counts as Your Work
The hardest part of moving into management may be letting go of work that made you successful and visible.
The polished flow is easy to point to. The critique that helped someone else find the answer is less visible. The process that prevented a problem is harder to celebrate than the late save that fixed it. A team member's growth should belong to them, even when your coaching helped create the conditions for it.
That can make management feel strangely indirect.
But indirect does not mean vague. The work is still observable. Is the team clearer about its decisions? Can people take on more responsibility? Do product and engineering involve design before choices become expensive? Can leadership explain how design affects the outcome?
A design manager's craft still matters. It just has to travel farther than the manager's own hands.
The shift is not from making to managing. It is from being the person who solves the problem to building a team that can keep solving better ones.