How I lead

I still stay close to product decisions, especially 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.

I do not need Design to own every product decision. I do want designers involved early enough to influence the ones that shape the experience.

Strong individual judgment is useful, but it does not scale by itself.

Once you lead a team, the more important question is how several designers can make good decisions across different problems without depending on one person to review everything.

That is where I spend most of my attention as a design leader.

I do not want designers guessing what I mean by better.

If something is weak, I try to make the reason visible. Is the problem unclear? Is the flow harder than it needs to be? Does the solution break an existing mental model? Are we missing evidence? Is the work simply unfinished?

A shared quality bar is more useful than personal taste. Critique, principles, patterns, and design systems help when they make judgment easier for the team to share.

The team should gradually 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 start asking for approval because they do not have enough information to decide.

Not every situation needs the same level of involvement from me. Sometimes I direct. Sometimes I add context. Sometimes I challenge the reasoning. Sometimes I step back.

The amount of involvement depends on the risk of the decision, the experience of the designer, and how much uncertainty is still in the problem.

Shared judgment is not everyone having the same taste. It is the team having enough shared context to reason about quality in a similar way.

That context comes from product knowledge, user research, analytics, critique, design principles, patterns, design systems, previous decisions and outcomes, and individual experience.

The stronger that shared judgment becomes, the less quality depends on one senior person approving everything. Process should support this, not become another layer of ceremony.

Products usually become inconsistent one reasonable local decision at a time. Different teams solve similar problems differently. New features introduce new patterns. Business exceptions become permanent.

The answer is not central approval. I try to keep enough shared context across teams that local decisions still add up to one product.

That means being deliberate about interaction models, information architecture, language, product behavior, reusable patterns, design systems, and experience principles.

Consistency is not the goal everywhere. Coherence is.

Autonomy does not mean staying hands-off when the work is going wrong. There are moments where I become more direct:

A high-risk product decision. A repeated quality problem. Unclear ownership. A team stuck in circular discussion. A designer missing critical context. A disagreement that now needs a decision.

I try to be selective about those moments. If I intervene everywhere, the team stops owning the work. If I never intervene, leadership becomes passive.

The most useful thing I can help a designer build is judgment.

Tools change. Processes change. Products change. Judgment travels with them.

That means being able to frame a problem, work with incomplete evidence, understand trade-offs, explain a decision, recognize weak work, and know when more exploration is actually useful.

I am less interested in designers learning how I would solve something. I would rather they become better at deciding for themselves.

Leadership judgment gets weaker when it becomes detached from the work. Complex flows, information architecture, edge cases, interaction details, and occasional hands-on design keep that judgment grounded.

The point is not to own the solution. It is to understand why the problem is difficult and whether the standards being asked of the team are realistic.