SSkilltecabyclaudinhocode
Enviar skill
← Voltar para o catálogo

design-org-decisions

Marketing

Navigate Leadership & Org Decisions as a design leader (VP of Design, Head of Design, CPO, CTO). Use this skill when making decisions about org structure, hiring, managing up, cross-functional partnerships, team culture, vision-setting, performance management, team scaling, or self-management as a senior design executive. Trigger on: "how should I structure my team", "how do I get a seat at the ta

3estrelas
Ver no GitHub ↗Autor: rastian

Design Leadership & Org Decisions

A comprehensive decision framework for design executives — VP of Design, Head of Design, CPO, CTO.


How to Use This Skill

When a design leader brings you a challenge, first identify the domain, then apply the relevant frameworks. Always ground your advice in:

  1. What stage the org is at (see Maturity Stages below)
  2. What the leader's specific authority and constraints are
  3. The trade-offs between short-term execution and long-term culture

DOMAIN 1: Org Structure & Team Models

The Three Archetypes

ModelHow It WorksWhen to UseWatch Out For
CentralizedAll designers report to one design leaderEarly stage; < 10 designers; building craft standardsDesign feels like a service bureau; disconnected from product
EmbeddedDesigners report into product/eng teamsWhen speed > consistency; strong design culture already existsQuality degrades; designers become pixel-pushers; no career home
Federated (Hybrid)Design "home base" in central org + assignment to product teams20+ designers; multiple product lines; need both craft AND speedRequires clear dual accountability; manager overhead increases

Recommended at scale: Federated. Designers owe allegiance to both the design org (craft, culture, career) and their product team (delivery, business outcomes). This is not a compromise — it is the architecture.

Design Org Maturity Stages

StageDescriptionWhat's Missing
1 — UndefinedAd hoc design, scattered designers, no shared languageLeadership
2 — EmergingDesign leader hired, some structure exists, inconsistent practiceShared process, principles
3 — DefinedShared process, principles, standards. Design has a product seatMeasurement, DesignOps
4 — ManagedDesign is measured. KPIs tied to outcomes. Ops systems existStrategic proactivity
5 — OptimizedDesign drives strategy. Permeates the org. Competitive differentiator(Sustain)

Most companies are stuck at Stage 2 or 3. The jump from Defined → Managed requires DesignOps investment.

Diagnosis question to ask first: "What stage are we actually at — and what does the next stage require?" Don't try to skip stages.

Span of Control

  • Design manager: 5–8 direct reports (below 4 = under-leveraged; above 8 = superficial relationships)
  • Director/VP: 3–5 direct reports (strategic + coaching load is higher)
  • Rule: Every layer of management added is a layer of information distortion. Add layers deliberately.

The 12 Qualities of Effective Design Orgs

Foundation (Preconditions)

  1. Shared Sense of Purpose — Every designer can articulate why the org exists
  2. Focused, Empowered Leadership — Design leader has actual authority, not just a title
  3. Authentic User Empathy — Research drives decisions, not justifies them

Output (What the org produces) 4. Understand, Articulate, Create Value — Design proves business impact, not just craft 5. Support the Entire Customer Journey — End-to-end experience, not just screens 6. Deliver at All Levels of Scale — Micro-interactions to systemic service design 7. Establish and Uphold Quality Standards — Design language, components, review rituals 8. Value Delivery Over Perfection — Ships. Iterates. Does not gold-plate.

Management (How the org runs) 9. Teams Are People, Not Resources — Individuals developed, not just allocated 10. Diversity of Perspective — Cognitive, demographic, experiential diversity actively cultivated 11. Foster a Collaborative Environment — Critiques are psychologically safe 12. Manage Operations Effectively — DesignOps exists; capacity, tooling, rituals are managed

The Three-Legged Stool

Product delivery requires three balanced legs: Business insight + Technical expertise + Design empathy. If design is weak, the stool tips.

Practical implication: The VP of Design should have equivalent standing to VP of Engineering and VP of Product. Design must be in the room at strategy time — not handed requirements from downstream.


DOMAIN 2: Hiring & Building the Team

The Single Most Important Lever

Hiring well is the single most important thing a growing organization can do. The people you bring on set the stage for everything that follows.

The "Weak Hire" Anti-Pattern

The bar for a hire should NOT be "no objections." It should be "someone in the room is genuinely excited and can articulate specifically why this person is exceptional." A lukewarm yes is a no.

Hire/no-hire decision test: "Would I be excited to work with this person every day?" If uncertain — it's a no.

Future Org Chart Exercise

Before hiring, draw the org chart you need in 12–18 months. Identify gaps in skills, roles, and strengths. Hire into future needs — not just current pain points.

What to Look For at Each Level

LevelDesign-Specific Signals
Junior/MidCraft quality, growth trajectory, learning agility, collaborative instincts. Portfolio shows range + iteration.
SeniorSelf-direction, strategic thinking, ability to work without a brief. Portfolio shows systems thinking.
Principal/StaffOrg-wide influence, mentorship, shapes product strategy. Raises the floor — doesn't just execute.
Design ManagerEvidence they've developed people, not just shipped projects. Can have hard conversations. Portfolio = team's output.

Hiring for Managers

Ask candidates to talk about their personal values and management philosophy. Look for evidence they've grown people — not just shipped features. Strong signal: can name a person they mentored who grew significantly.

IC vs. Manager Track

Not every senior IC should become a manager. The two tracks require different skills:

  • IC track (Principal/Staff): Technical depth, org-wide influence, architectural thinking
  • Manager track: People development, organizational design, navigating ambiguity

The best technical coordinator is not the most senior person — it's the person who can balance technical work with coordination and communication.

Forcing great ICs into management is a common mistake. Provide a parallel career path.

Onboarding New Leaders

New leaders join as either: Apprentice (expanding their scope), Pioneer (building new team), New Boss (inheriting existing team), or Successor (replacing a departing leader). Each requires a different onboarding playbook. Know which type you're bringing in.


DOMAIN 3: Managing Up & Stakeholder Influence

Earning Credibility as a VP of Design

The VP's first job is to make design legible to the business. This means:

  • Translating design quality into business outcomes (conversion, retention, NPS, revenue)
  • Having a clear point of view on product strategy — not just execution
  • Demonstrating taste AND judgment: knowing when to fight for quality and when to ship

The Double Diamond as an Executive Tool

The Double Diamond (Discover → Define → Develop → Deliver) is not just a design process. It is a frame for where design should be involved in business decisions. Most orgs only bring design in for the second diamond (Execution). The VP of Design's job is to push design involvement upstream into the first diamond (Definition/Strategy).

Practical move: Get design into product planning rituals — roadmapping, OKR-setting, strategy offsites — before requirements are written. If you arrive after requirements, you are a service bureau.

Managing Up: Language That Works

  • Speak in outcomes, not activities: "We reduced onboarding drop-off by 23%" not "We redesigned onboarding"
  • Frame design risks as business risks: "If we ship this without the research, we risk building the wrong thing at 10x the cost of doing the research now"
  • Use the voca

Como adicionar

/plugin marketplace add rastian/design-leadership-skills

O comando exato pode variar conforme o repositório. Confira o README no GitHub.

Comentários · Nenhum comentário

Entre para comentar. Entrar

  • Ainda não há comentários. Seja o primeiro.