Leadership Team Design Talent Strategy

Stop Hiring Every Designer for the Same Job

Strong design teams are not built by finding the same well-rounded designer eight times. They are built by combining complementary strengths, matching people to the problems the organization needs to solve, and creating assignments that grow capability over time.

People Leadership
Hiring Strategy
Team Composition
Talent Development
Organizational Design

The Problem

The mythical “complete designer” is a poor team-building strategy.

Job descriptions often ask every designer to be exceptional at research, facilitation, interaction design, visual craft, systems thinking, prototyping, data, accessibility, storytelling, product strategy, and stakeholder management.

That sounds flexible. At team scale, it can produce the opposite. When every role is defined against the same idealized profile, leaders start evaluating people against what they are missing instead of understanding where they create exceptional value.

I would rather build a team where people have overlapping fundamentals and meaningfully different strengths. The goal is not eight copies of one great designer. The goal is a team whose combined capability is greater than any individual member.

What goes wrong with the generalist-only model

Hiring criteria become unrealistically broad
Distinctive strengths are undervalued
Teams develop hidden capability gaps
Everyone is expected to solve every kind of problem
Staffing becomes capacity management instead of talent strategy
Growth becomes “be better at everything”

Design the Team

Start with the problems the organization needs to solve.

Before asking “What kind of designer should we hire?” I want to understand the portfolio of work the team will actually face over the next year or two.

A Different Hiring Question

What capability is missing from the team?

A hiring plan should begin with the organization’s product challenges, the strengths already available on the team, and the gaps that repeatedly create risk or dependency. Headcount is useful. Capability is what actually determines what the team can solve.

What Problems Are Coming?

New products, mature platforms, enterprise workflows, design systems, AI-enabled experiences, growth work, and accessibility challenges all demand different mixtures of capability.

What Can We Already Do Well?

Understanding the strengths already inside the team prevents leaders from repeatedly hiring capabilities they already have while leaving important gaps untouched.

Where Are We Fragile?

If one person leaving would eliminate the team’s ability to conduct research, manage a design system, facilitate strategy, or work with complex technical systems, that is an organizational risk.

Complementary Strengths

Build a capability portfolio, not a collection of identical résumés.

I think of these as strength profiles rather than rigid job types. Most experienced designers span several of them, but usually have areas where they create disproportionate value.

01 / Explorer

Strong in ambiguity and discovery.

Explorers are comfortable entering poorly defined spaces, asking difficult questions, facilitating discovery, working with research, and helping teams understand the problem before converging on a solution.

02 / Systems Thinker

Strong across interconnected experiences.

Systems thinkers see patterns across workflows, products, teams, and technology. They are particularly valuable in enterprise environments, platform work, design systems, and portfolios where local decisions create wider consequences.

03 / Experience Crafter

Strong in interaction and execution.

These designers excel at making complex experiences understandable, refining interaction behavior, raising visual quality, prototyping ideas, and turning strategy into a product people can actually use.

04 / Connector

Strong across people and disciplines.

Connectors excel at facilitation, storytelling, stakeholder relationships, shared decision-making, and translating between Product, Design, Engineering, customers, and business leadership.

05 / Evidence Builder

Strong in research and validation.

Evidence builders help teams replace assumptions with customer insight, behavioral evidence, testing, analytics, and structured learning. They increase confidence before the organization commits significant resources.

06 / Technical Partner

Strong at the Design and Engineering boundary.

Technical partners understand platforms, implementation constraints, component architecture, prototyping, and maintainability well enough to help teams shape solutions that work for both the experience and the system underneath it.

Staffing the Work

Different stages of product work benefit from different strengths.

Assignments should be based on more than who has availability. I look at the nature of the problem, the stage of the product, the team surrounding it, the risk involved, and what development opportunity the assignment creates.

Early / Ambiguous

Discovery and Direction

New problem spaces usually benefit from people strong in discovery, research, facilitation, systems thinking, and stakeholder alignment.

The primary risk is solving the wrong problem or committing too early.

Middle / Converging

Experience Definition

As direction becomes clearer, interaction design, workflow thinking, technical partnership, prototyping, and validation become increasingly important.

The primary risk is turning good intent into a weak or unbuildable experience.

Mature / Scaling

Systems and Optimization

Mature products often need systems thinking, accessibility, analytics, design-system expertise, workflow optimization, and deeper partnership with Engineering.

The primary risk becomes inconsistency, complexity, technical debt, and declining efficiency.

Development Through the Work

The best assignment is not always the most obvious assignment.

If leaders only assign people to work they already know how to do, teams become efficient but stagnant. If every assignment is a stretch, teams become exhausted and quality suffers.

I try to balance proven strengths with deliberate development. Someone strong in execution may benefit from leading discovery alongside an experienced researcher. A strong facilitator may need deeper exposure to systems work. A senior designer may be ready to own a stakeholder relationship instead of having their manager carry it.

The assignment still has to serve the product. But when possible, the same work should also increase the team’s future capability.

How I think about assignments

What does the project need to succeed?
Who already has strengths that fit?
Where does the team need more capability?
Who is ready for increased ownership?
Where can pairing reduce risk?
What will this person be better at afterward?

Hiring Differently

Interview for the capability you actually need.

Once the team understands its capability gaps, hiring conversations become substantially more useful. Instead of evaluating every candidate against the same universal checklist, I can evaluate whether their strengths expand what the organization is capable of doing.

Keep the Fundamentals

Every designer still needs baseline collaboration, product thinking, communication, empathy, and enough craft to operate effectively. Complementary strengths do not mean abandoning standards.

Go Deeper on the Gap

If the team needs systems thinking, research leadership, technical partnership, or complex facilitation, the interview should create room for the candidate to demonstrate depth in that area.

Evaluate Learning Ability

Strengths matter, but so does the ability to learn. I want people who know where they are strong, recognize where they are still growing, and can expand their range over time.

Hire for the Team, Not the Vacancy

The strongest individual candidate on paper is not automatically the person who creates the most value in the existing team. Team composition should influence the decision.

The Leadership Shift

Manage capability, not just headcount.

At Director level, the question is not simply whether every seat is filled. It is whether the organization has the right mixture of capabilities to solve the problems in front of it and enough resilience to adapt when those problems change.

Know the Portfolio

Understand what kinds of problems the organization will need the team to solve.

Know the Team

Understand individual strengths, aspirations, development needs, and hidden dependencies.

Close the Gaps

Use hiring, development, pairing, systems, and external expertise intentionally.

Keep Evolving

Revisit team composition as products, technology, people, and organizational priorities change.

The Principle I Come Back To

Do not hire eight versions of your favorite designer.

Build a team with enough shared foundation to work together and enough difference in perspective, experience, and capability to solve problems no individual designer could handle alone.

Leadership in Practice

Building a design practice around capability, not just capacity.

At LINQ, I built a design and research practice from zero to eight team members while introducing career frameworks, research operations, specialized capabilities, embedded product partnerships, and shared systems for scaling the work.

The goal was not simply to grow the team. It was to make the organization capable of solving a broader range of product problems without depending on one person or one type of designer.

View Leadership Case Study