You start a role on Monday. By week three, someone asks why the design quality hasn't improved. You were hired to fix it. But you haven't changed the review process because you're still learning which teams use one. You haven't hired because the approved headcount is tied to a fiscal plan you didn't participate in. You haven't set standards because the enforcement mechanism doesn't exist and building one requires relationships you're still forming.
The question lands anyway. The person asking isn't wrong — they hired you to fix this. They're evaluating you on a timeline that has nothing to do with the timeline on which you can actually change the inputs.
Two dates matter in every Director+ design role:
Accountability horizon — when you start being evaluated on outcomes. For most roles at this level, it's immediate. The company hired you because something isn't working.
Authority horizon — when you gain actual decision-making power over the inputs to those outcomes. Hiring. Standards enforcement. Process changes. Resource allocation. Review gates.
The gap between those two dates is the risk.
What the gap looks like from inside
Published onboarding research puts general executive integration at roughly six months, but that number measures full performance, not the transfer of specific decision rights. The timeline for gaining real authority over staffing, quality gates, or release decisions depends on organizational readiness, sponsor behavior, and whether anyone did transfer work before you arrived.
Peter Merholz described a case that shows the worst version. A company hired a senior design leader specifically because product quality was poor. Clear mandate. But when the leader's changes generated friction, executives told them to back off and conform to existing norms. Meanwhile, newly hired Product and Product Marketing leaders who generated similar friction received executive support. Several years later, the design leader was described as underperforming — evaluated on the outcome, after the authority to produce it had been withdrawn.
Rachel Kobetz's experience at Expedia went differently. Before she started, company leaders explained her charter to the organization, established a runway, and clarified how others should support the role. Foundation work that might have taken a year to eighteen months happened in six months. The gap still existed, but someone compressed it before day one.
The leader's skill mattered in both cases — Merholz noted that more relationship-building might have helped. But the structural difference was whether the organization did the authority-transfer work before or after the leader arrived, and whether sponsor support survived the first moment of conflict.
Where the gap lives in each tier
The accountability is always immediate. The authority mechanism and its timeline vary by tier.
AI-native companies
High confidence on the pattern. You're accountable for how users experience model outputs — trust, failure recovery, perceived quality. But the decisions that determine model behavior may sit with Research, Alignment, or ML Engineering, and your influence over those decisions ranges from direct to nonexistent depending on the specific role.
This is role-specific, and the postings reveal which version you'd be walking into. OpenAI's Model Designer sits inside Core Models and collaborates with researchers to design model behavior directly. Google DeepMind's Senior Staff Model UX Designer initiates qualitative assessment of model performance and develops quality-improvement strategy through the evaluation process. These roles have model-behavior authority written into the job description.
At other AI companies, behavioral defaults, safety evaluations, and guardrails sit with Product or Safety Research functions working alongside Research. Design's relationship to those decisions isn't publicly specified. If you own the experience of probabilistic behavior and recovery but have no stated authority over the model inputs that produce that behavior, the gap may not be a timing problem. It may be permanent.
That distinction changes whether to accept. A permanent structural separation isn't automatically disqualifying — if accountability is also scoped to what you can control. A role where you own interface trust, failure recovery, and user-facing quality, and you're evaluated on those outcomes, can work without model-behavior authority. But a role where your review includes model-quality metrics while your authority stops at the interface layer means you're absorbing evaluation on outcomes someone else controls, with no transfer date on the horizon. Ask which version you're looking at.
Ask in the first or second conversation:
- "Walk me through the last model or feature release. Where did this role first enter the behavior-evaluation loop?"
- "When user evidence shows the model's behavior needs to change, who owns that change today? Which part of that decision would belong to me on day one?"
- "What will I be evaluated on in the first quarter — interface outcomes, model-quality evaluations, or both? Which of those can I actually change by then?"
- "When Design, Research, and Product disagree about an evaluation result or release threshold, who decides?"
The first question asks for a concrete recent example, which is harder to answer with aspiration. The last one surfaces the conflict-resolution mechanism — or its absence.
Growth-stage platforms
High confidence. You're accountable for team delivery — shipping velocity, design quality, customer outcomes — against a roadmap that was committed before you arrived. But the team was staffed for the old plan, and your authority over hiring, allocation, and scope may be months away.
Christina Goldschmidt described a version of this dynamic when she joined Warner Music Group with substantial design headcount already allocated. She could decide how to divide it. But fiscal planning was nearly complete, and she had to prove value "immediately from day one" to avoid losing those positions. The authority was real but conditional — it could evaporate before she'd learned enough to use it well. That pattern intensifies at growth-stage companies where fiscal cycles are shorter, headcount is more contested, and proving value quickly is existential.
At growth-stage companies, the roadmap is the binding constraint. Commitments to customers, investors, or the board were made before you existed. If the team is understaffed relative to those commitments, delivery will suffer. The question is whether that gap gets attributed to the team's capacity or to your leadership.
Ask:
- "How is the team staffed against the next two quarters of committed work?"
- "Which staffing or allocation decisions would be mine in the first month? Which require a planning cycle I haven't participated in yet?"
- "If delivery misses because capacity is below the commitment, how does the company separate that from the new leader's performance?"
- "When was the current roadmap locked, and when is the next window where I could influence scope?"
The third question is the one most interviewers won't have a ready answer for. If they can't articulate how they'd separate inherited capacity problems from leadership performance, the gap is unmanaged.
Enterprise platforms
Moderate confidence. You're accountable for design coherence across products — consistency, accessibility, quality. But the enforcement mechanisms that produce coherence may not exist yet, or may be advisory rather than binding.
The timelines here are worth calibrating against. Salesforce documents a five-year arc from recognizing the coherence problem (2013) to platform-wide adoption of the Lightning Design System (2018). GitLab's public history shows nearly four years between launching a design-system component lifecycle (2019) and clarifying that designers must approve merge requests containing user-facing changes (2023). Atlassian describes a 15-year evolution that produces coherence through constrained infrastructure rather than central veto.
These are organizational maturation timelines, not an incoming leader's personal journey. But the enforcement mechanisms that make coherence achievable — shared code, required reviews, exception governance, release gates — take years to build. If you're hired to deliver coherence and those mechanisms don't exist yet, you're accountable for an outcome whose infrastructure hasn't been constructed. If you're evaluated annually and the infrastructure takes three years, your first review judges you on outcomes you could produce only through persuasion, not process.
Ask:
- "Is the design standard currently advisory, review-required, or release-blocking?" Advisory vs. release-blocking is the difference between influence and authority.
- "Which products are inside that mechanism today, and which can opt out?"
- "If a product team needs an exception, who approves it and what evidence do they need?"
- "What coherence outcome would belong to me before the enforcement mechanism transfers? What's the first roadmap cycle whose coherence I'd own?"
If the answer to the first question is advisory, every coherence outcome you're evaluated on depends on persuasion, not process.
Healthcare and regulated companies
Speculative. This tier's gap is the least documented in public design-leadership accounts. Design leaders in regulated industries rarely discuss governance structures publicly, and compliance constraints limit what can be shared about internal decision processes. The pattern here is inferred from the structure of regulated environments, and the evidence is thinner than in any other tier.
You're accountable for compliance outcomes, clinical safety, and auditability. But governance authority — membership in launch-decision bodies, sign-off rights, incident-response ownership — may require credentialing, relationship-building, or organizational trust that takes months to establish. Governance bodies in regulated environments have formal membership criteria. Validation evidence requires domain-specific knowledge to evaluate. Sign-off authority is typically earned through demonstrated competence in the regulatory framework, not granted at hire.
If a compliance incident occurs during the period when you're accountable for safety outcomes but haven't yet joined the governance mechanism that controls releases, the organizational response may treat you as responsible without having given you the tools to prevent it.
Ask:
- "Which compliance or safety outcomes enter my scorecard in the first quarter?"
- "When does this role join the formal governance or launch-decision body? What's required before that happens?"
- "Until I have that seat, who retains accountability for those outcomes?"
- "After the last significant error or incident, what changed before the next release — and which part of that response would this role control?"
The third question is critical. If nobody retains accountability during the gap, you're absorbing risk without authority. If someone does retain it, you need to understand the handoff timeline and what triggers it.
Reading the answers
Every detection question above is a version of the same probe: who is accountable for this outcome between the day I start and the day I can influence it?
Three answers you'll hear, ranked by risk:
Someone specific retains it and will hand it off on a defined timeline. Lowest risk. The gap exists but is managed. Kobetz's Expedia experience is the closest public example.
The accountability is shared or ambiguous during the transition. Moderate risk. Shared accountability during a transition often means nobody owns the gap, and the first visible failure gets attributed to the newest leader in the room.
You own it from day one, and the authority timeline is unspecified. Highest risk. This is Merholz's case: full accountability, withdrawn authority, eventual judgment.
You can surface which of these you're walking into during a first or second conversation without sounding adversarial. The questions above are framed as operational curiosity — how does this work, who owns what, what's the sequence. They reveal the timeline without requiring the interviewer to admit a structural problem.
If the responses are aspirational ("we want you to own this") rather than operational ("here's who holds it now and here's when it transfers"), the gap is unmanaged. You're being asked to absorb it.
- Formal vs. real authority: Aghion and Tirole's foundational distinction between the right to decide and effective control over decisions is the academic backbone of this gap — their 1997 paper remains the clearest framework for why an org chart cannot tell you who actually decides.
- Onboarding networks stay incomplete: A large-scale Microsoft study found that new employees' communication networks were still significantly different from tenured employees' after six months, which suggests the information access that real authority depends on takes longer to build than most onboarding plans assume.
- Org structure doesn't predict integration: McKinsey's analysis of three million designers across 100,000+ departments found no single organizational structure associated with better design-team integration, with cross-functional alignment and incentive design mattering more than reporting lines.
- Portfolio reviews lack validation: A 2022 meta-analysis of personnel selection methods found structured interviews to be the highest-ranked general selection procedure but did not validate design portfolios or senior design-leadership hiring specifically, which means the evaluation you're preparing for has no established criterion validity.