I don't think the same way of leading works for every team.
Over the years, I've led design teams of very different sizes, from a handful of designers to a function of nearly twenty. The dynamics change as the team grows: how much context people need, how decisions get made, where consistency starts to break down, and how involved a lead needs to be.
My approach depends a lot on the organization, the constraints around the work, and the people in the team. Different designers need different things depending on their strengths, how they work, where they want to grow, and how much support or autonomy they need.
Design also rarely operates in isolation. Many of the decisions that eventually shape the experience begin somewhere else: product rules, business constraints, technology, operations, or simply the way teams work together.
That has gradually pulled my work further upstream. I still come at problems with a Design perspective, but that often leads into questions about how the problem is framed, which assumptions should be challenged, how different teams align, and where the product should go next.
Stay involved before the brief
I stay close to product decisions while the problem is still open.
I look at what is being treated as fixed, where the complexity really comes from, what the evidence says, and what the product has to deal with in the real world.
That may mean questioning a product rule, tracing friction into operations or policy, using research or analytics to challenge an assumption, or making an abstract decision concrete enough to test.
Design does not need the final say on every product decision. It does need to be there early enough to contribute to the ones that eventually shape the experience, the operating model, or the direction of the product.
Build judgment, not dependence
Strong individual judgment is useful, but a team cannot rely on one person to carry it.
As the team grows, I pay more attention to whether designers can make good decisions across different problems without having to route everything through a lead.
Good leadership should leave the team with more judgment of its own, not another approval layer.
Set the quality bar
I do not want designers guessing what is standard.
When something feels weak, we need to be able to explain why. Maybe the problem itself is unclear. Maybe the flow is harder than it needs to be. Maybe the solution breaks an existing mental model, the evidence is thin, or the work simply needs another round.
A shared quality bar gives the team something more useful than personal taste. Critique, principles, patterns, evidence, and design systems all help make that judgment easier to share.
Over time, the team should become better at recognizing quality without waiting for approval.
I prefer giving designers the context behind a problem rather than prescribing the answer.
That includes the product goal, business reality, user evidence, technical constraints, previous decisions, and the trade-offs already on the table.
With enough context, people can form their own point of view. Without it, even strong designers end up asking for approval because too much of the reasoning is hidden from them.
My level of involvement changes with the situation. Sometimes I direct. Sometimes I add context or challenge the reasoning. Other times, the best thing I can do is step back.
Decision risk, the designer's experience, and the amount of uncertainty usually tell me how involved I need to be.
For me, shared judgment means the team has enough common context to reason about quality in broadly similar ways, even when individual opinions differ.
That context builds up from product knowledge, user research, analytics, customer feedback, operational signals, business outcomes, technical constraints, design principles, patterns, previous decisions, and individual experience.
As that shared understanding gets stronger, fewer decisions need to travel upward for approval.
Process can help with this, as long as it does not become ceremony for its own sake.
Product analyticsUser researchCustomer feedbackOperational signalsBusiness outcomesReal-world observationTechnical constraintsProduct contextDesign principlesCritiquePatterns and design systemsIndividual experience and past outcomes
↓
Interpretation+Context+Experience+Trade-offs
↓Shared team judgment↓Distributed design quality
Keep the product coherent as teams scale
Products often become inconsistent through a series of perfectly reasonable local decisions.
Different teams solve similar problems in different ways. New features introduce new patterns. Business exceptions stay around longer than expected. Eventually, decisions that made sense on their own start making the product harder to understand as a whole.
Centralizing every decision does not solve that very well.
I try to keep enough shared context across teams that local decisions still feel like parts of the same product.
That means paying attention to interaction models, information architecture, language, product behavior, reusable patterns, design systems, experience principles, and the mental models customers carry from one part of the product to another.
I care more about coherence than making everything identical.
Giving people ownership does not mean keeping the same distance from every problem.
Some situations need more involvement from me:
A high-risk product decision, a repeated quality problem, unclear ownership, a team stuck in circular discussion, a designer missing critical context, or a disagreement that has reached the point where a decision is needed.
I try to be deliberate about those moments. Most of the time, the team should have room to work through the problem themselves. Sometimes they need another perspective, more context, or a clear decision so the work can move again.
Help designers become better decision-makers
Judgment is probably the most useful thing I can help a designer develop.
Tools change. Processes change. Products change. Judgment travels with them.
It shows up in the ability to frame a problem, work with incomplete evidence, understand trade-offs, explain a decision, recognize weak work, and know when further exploration is actually useful.
The point for me is not to have designers solve problems the way I would.
I want them to become increasingly confident in how they make their own decisions.
Stay close enough to the work
Leadership judgment gets weaker when it becomes detached from the work.
Complex flows, information architecture, edge cases, interaction details, and occasional hands-on design help keep mine grounded.
Staying close does not mean taking the solution back from the team. It helps me understand why the problem is difficult, what they are actually dealing with, and whether the standards I am asking for are realistic.
The kind of design team I want to build
I like teams where people can disagree without making it personal, ask for help without giving up ownership, and give useful critique without turning every discussion into a review meeting.
A strong design team should be able to make good decisions with enough context, trust, and shared judgment.
When that happens, Design can have an impact well beyond the Design function itself.