A Live-Conversation Protocol for Determining Whether a Head of Design Role Carries Real Authority
"Head of Design." "Reports to the CPO." "Design has a seat at the table."
You will hear all three. None tells you whether the role controls anything.
McKinsey studied 300 companies over five years and found that design decisions stay stuck in middle management even where leadership claimed design was a strategic priority. Fewer than 5 percent reported that leaders could make objective design decisions. The reporting lines looked clean. The decision rights were hollow.
Reporting line is where the role sits. Decision rights are what the role controls. You need to test for the second one, live, in your first and second conversations. This protocol is how.
How to Use This Protocol
Find the failure mode first. Authority fails differently depending on company type. Four patterns cover nearly every Head of Design role you will encounter. Match the company. Run those diagnostics. Skip the rest.
| If the company... | Go to |
|---|---|
| Builds on foundation models, trains its own, or ships AI-native products | Failure Mode 1 |
| Has product-market fit and is scaling with PM-owned roadmaps | Failure Mode 2 |
| Has a large design org (50+ designers) and a mature design system | Failure Mode 3 |
| Operates in a regulated domain (healthcare, fintech, compliance) | Failure Mode 4 |
Between rounds: Find your card. Scan the bolded questions. Pick the one you haven't asked yet.
After the conversation: Check the walk-away cues. Two or more within the same failure mode means the role is probably not what it appears to be.
The Universal Tell
One signal cuts across all four failure modes. Highest-confidence indicator of hollow authority I know. Use it regardless of company type.
Track what each interviewer tells you about three things: what the role decides, who the role's peers are, and what success looks like at twelve months. Write the answers down between rounds.
The recruiter says "you'll build the function." The CPO says "you'll partner with existing leads." The engineering VP says "we need someone to own the design system." That role has not been defined. It has been posted. Those are different things.
No mandate exists yet. Each interviewer is projecting their own need into the vacancy. You would spend your first year negotiating for authority they told you the role already carried.
If answers diverge on two of three, stop investing in this process. The role may become real later. Right now it is a mandate negotiation disguised as a job.
Failure Mode 1: AI-Native — Design as Afterthought to Research and Engineering
The pattern. Research and engineering made the core product decisions before design existed in the room. The Head of Design title appeared because someone realized they needed "a design person." Actual scope: presentation layer. Model behavior, trust thresholds, human-in-the-loop architecture, agentic system boundaries — all decided without design input. Not up for renegotiation.
High confidence this is the failure mode when the recruiter describes the role as "translating research into user experiences," or when your interviewer names research and engineering peers at the VP level but cannot name a design leader at the same altitude. If the first conversation frames the role around "making AI accessible" without naming a single system-level decision design would own, you are looking at a presentation-layer hire wearing a leadership title.
Look at what happened at Salesforce. The most explicit AI-systems mandate for their design system — developing semantic metadata schemas and component specifications that let LLMs safely render UI at runtime — landed in a PM-titled role. Salesforce has design-titled leadership postings with AI language and responsible-AI framing. But the sharpest machine-readable infrastructure mandate went to product management. A company with decades of design maturity. If authority over AI-native design-system architecture can be structurally placed outside design at Salesforce, assume it can happen anywhere.
Diagnostic Questions
"When the model team decides to change a system behavior that affects what users see or trust, at what point does design enter that decision?"
Strong answer: Names a specific stage gate or co-ownership structure. "Design is in the model-behavior review before we scope the release." "Our Head of Design co-owns the trust-threshold framework with the ML lead."
Revealing deflection: "We bring design in early." Early relative to what? No named gate means no gate. "Design reviews the output" means the decision already happened. Design is applying polish.
"Who sets the thresholds for when a human reviews an AI-generated output versus when it ships automatically?"
Strong answer: Names the role or cross-functional group, and design is in it. "That's a joint call between our Head of Design and the ML safety lead."
Revealing deflection: "That's more of an engineering decision." Stop. The role is presentation layer. Also watch for: "We're still figuring that out" with no named constraints, owners, or timelines. Nobody owns it. The new hire will not either.
"Can you walk me through a recent case where design pushed back on a model-behavior decision and what happened?"
Strong answer: A specific story with a specific outcome, even if design lost. The existence of the conflict and its resolution process is the signal.
Revealing deflection: A long pause followed by a hypothetical. "I'm sure that would be welcomed." It has never happened.
Walk Away When
- You ask who owns launch quality for a trust-critical AI surface and the answer routes entirely through engineering and research. Design is mentioned as a "partner" or "reviewer."
- The interviewer describes the role's scope using words like "polish," "delight," or "making the experience intuitive." No system-level decision named.
- Two interviewers give you contradictory answers about whether design has authority over human-in-the-loop thresholds.
Failure Mode 2: Growth-Stage — Design as Service Function to Product
The pattern. Product-market fit is established. PMs own the roadmap. Design "partners with" product, which in practice means design receives prioritized work and executes against it. The Head of Design manages the team, fights for headcount, and tries to influence the roadmap through relationships rather than structural authority. When design and product disagree, product wins by default because the PM owns the success metric.
High confidence this is the failure mode when the recruiter or hiring manager describes the role as "partnering with product leads" and cannot name a decision design owns independently. Or when you ask about the design leader's peers and every name is a product director. A company like Ramp, where a design role reports into a VP Product with no design executive above or beside, is structurally predisposed to this pattern. That does not make it inevitable. It means the burden of proof is on the interviewer to show you where design authority actually lives.
Diagnostic Questions
"When design and product disagree on a launch-quality call — design believes a flow isn't ready, the PM wants to ship — how does that get resolved?"
Strong answer: Names a decision framework. "Design owns a quality bar that has to be met before launch. The Head of Design can block a release on UX-quality grounds." Or: "The PM owns the ship decision, but design owns a post-launch quality review that feeds into the PM's performance evaluation." Structure matters more than who wins.
Revealing deflection: "We're collaborative." The single most common hollow-authority tell at growth-stage companies. Collaborative only means something when followed by a named approver, escalation path, or bounded veto right. Without that, "collaborative" means the PM decides and design's objection is noted. Press: "Can you walk me through how that collaboration worked in a specific case where they disagreed?"
"I'm curious about a recent product decision that changed because of something design surfaced — what's a good example?"
Strong answer: A specific feature, flow, or product change with a named design leader who drove the change and a clear before-and-after.
Revealing deflection: "Our designers are really embedded in the product teams." Embedded is a location, not a power. Embedded designers can still be order-takers. Press for the specific outcome that changed.
"How does the design org handle its own tooling, research, and capability investments — does the Head of Design have discretionary spending authority, or does it route through another leader?"
Strong answer: Names a budget range or spending authority. "The Head of Design owns a research budget and can commission external studies without VP approval up to a threshold."
Revealing deflection: "We'd work with you on that." No budget authority exists. You will submit requests.
Walk Away When
- Every example of design influence is described as "input" or "feedback" rather than a decision with a named outcome.
- Nobody can name a single product outcome that changed because design objected.
- You ask about the Head of Design's first-90-day deliverables and the answer is "get to know the team and the product." No decisions named. No authority named. No outcomes the role owns from day one.
Failure Mode 3: Enterprise — Design as Pixel Factory
The pattern. Large design organization. Impressive headcount. The Head of Design manages production, allocates resources, maintains the design system, ensures visual consistency. Product strategy, feature prioritization, and customer-facing decisions happen in rooms where design is not present or not decisive. The role is operational, not strategic.
Moderate confidence this is the failure mode when the interviewer describes the role's value primarily through craft language: "elevating the bar," "creative vision," "design excellence." None connected to a business outcome or a decision right. High turnover in the Head of Design seat is a corroborating signal. Ask how long the previous leader was in the role and what they accomplished.
Peter Merholz has argued that many companies reduce Head of Design to visual-interface execution or "creative vision." The useful diagnostic from his work: director-and-above design leaders who actually hold authority function as managers, diplomats, champions, and operators. Creative direction is often the smallest part of the job. When an interviewer emphasizes taste and inspiration without naming operating scope, you are looking at the pixel factory.
The exception worth calibrating against: Atlassian has a large design org and a mature design system but has historically given design leaders genuine product-strategy authority. The pattern is common, not universal. Your job is to test which version you are looking at.
Diagnostic Questions
"What business decisions does the Head of Design participate in that aren't about the design team itself — pricing, packaging, go-to-market, product-line strategy?"
Strong answer: Names specific forums and decisions. The Head of Design is in the room for decisions that determine what gets built, not just how it looks.
Revealing deflection: "The Head of Design represents the user perspective." Representing a perspective is not making a decision. Press: "When the user perspective conflicts with a business decision, what happens?"
"Does design quality show up in PM performance reviews or product-launch criteria?"
Strong answer: Design quality metrics are part of the PM review process, or the Head of Design provides input on PM evaluations. This is the deepest structural indicator of real organizational leverage.
Revealing deflection: Confusion. This question will surprise interviewers at pixel-factory companies because the idea that design could influence PM evaluations has never occurred to anyone. The confusion itself is the tell.
"What did the previous Head of Design accomplish that the company is most proud of?"
Strong answer: Names a business or product outcome. "They restructured how we approach enterprise onboarding and reduced time-to-value by 40 percent."
Revealing deflection: "They really elevated the craft." Craft elevation without a business outcome attached means the role is scoped to aesthetics. If the proudest accomplishment is visual, the ceiling is visual.
Walk Away When
- The interviewer describes the Head of Design's value primarily in terms of "elevating craft," "raising the bar," or "bringing creative vision," and none of it connects to a business outcome or a decision right.
- The previous Head of Design left after less than two years and nobody can clearly explain what they accomplished.
- The role's success metrics are all activity-based (shipped designs, maintained system, hired designers) rather than outcome-based (changed a product decision, improved a business metric, blocked a bad launch).
Failure Mode 4: Healthcare / Vertical SaaS — Design as Compliance Checkbox
The pattern. Regulated domain. Design exists because customers or regulators expect a "modern user experience," or because the sales team needs better demos. The Head of Design is there to prove the company takes UX seriously. But the product is shaped by regulatory requirements, clinical workflows, and domain-expert stakeholders who view design as cosmetic. Real product decisions happen in conversations between domain experts, engineering, and compliance. Design applies a surface layer.
High confidence this is the failure mode when the interviewer describes design's relationship to domain constraints as purely receptive, or when every design accomplishment they cite is a visual refresh. A company like Maven is worth probing carefully here. The right question is whether the Head of Design can change a clinical workflow, not just the interface on top of it.
Your Thermo Fisher and Red Cross work gives you credibility in regulated environments, and that credibility will attract these roles. The risk: that credibility gets you in the door at a company where the door leads to a room with no authority.
Diagnostic Questions
"When a domain expert says 'this is how we've always done it' and design research shows a better workflow, what happens next?"
Strong answer: Names a process for resolving the conflict that gives design research standing. "We run a structured evaluation with the clinical advisory board, and design presents the research alongside the domain expert's recommendation. The product council decides, and design has a vote."
Revealing deflection: "We respect clinical expertise." Of course they do. The question is whether design research has equal standing when it contradicts clinical habit. If the answer is always deference to domain expertise, design is decoration.
"What decisions does the Head of Design own outright, where the CPO trusts their call?"
Strong answer: Names specific domains. "The Head of Design owns the clinical-workflow interaction model. The CPO sets priorities, but the Head of Design determines how a workflow is structured for the end user." Or: "Design owns the exception-handling UX and the trust surfaces."
Revealing deflection: "The CPO is very design-minded." A personality description, not a decision right. A design-minded CPO who retains all the decisions is still a CPO who retains all the decisions.
"Is there a recent example where design changed a compliance-driven workflow — not just how it looked but how it actually functioned?"
Strong answer: A specific story where design research changed the actual sequence, logic, or decision points of a regulated workflow, with compliance sign-off on the change.
Revealing deflection: "We redesigned the dashboard." Dashboards are the compliance-checkbox company's favorite design project because they are visible, demonstrable, and change nothing about how the product actually works.
Walk Away When
- Every design example is a visual refresh, a dashboard, or a "modernization" project.
- The interviewer describes design's relationship to domain experts as purely receptive. Design listens and translates requirements into interfaces.
- You ask about design's role in shaping the product roadmap and the answer is that design "provides input on the UX roadmap." A separate UX roadmap means design has its own sandbox and no influence on the real one.
What You Are Actually Testing For
You are evaluating whether a role offers what you need: function-building authority, design representation in product decisions, mandate to hire and shape a team. Your TinyFish work and your portfolio demonstrate you can do these things. The diagnostic is whether the company will let you.
Strong answers on decision rights mean keep going. Two or more deflections within the same failure mode mean the authority is not there.
The role may have the title. It may have the comp. It may have the reporting line. If the decision rights are hollow, you will spend two years fighting for influence that was supposed to come with the job.
Run the questions. Read the tells. And leave when the signals say leave.
- Gusto's published AI principles: Their framework for AI in consequential contexts names customer control, visible AI roles, intelligent escalation, and preserved agency as design requirements — useful vocabulary for probing decision rights at any growth-stage fintech.
- Maven's VP Design mandate: The current posting reports to the CPO, leads ~15 designers, and claims authority over clinical outcomes, conversational interfaces, and agent-driven workflows — worth testing against Failure Mode 4 diagnostics to see how the answers hold up.
- Heidi Health's design-ownership scope: Their Head of Product Design posting explicitly names quality sign-off authority over clinical workflow trust, LLM evaluation, and design systems across 2 million weekly patient sessions — one of the clearest public examples of decision rights written into a job description.
- OpenAI's interaction-paradigm framing: Their Frontier Interfaces role states that AI value is increasingly constrained by how people interact with model capabilities, which reframes the AI-native diagnostic from "does design have authority" to "does the company even recognize that interaction design is the bottleneck."