Five Questions That Separate a Design Mandate from an Explanation Layer

Run this diagnostic on any posting before you write a word of outreach.

Anthropic carries the AI-native tier tag. Render carries growth-stage. Render's Agent Experience posting asks for more agent-native design thinking than plenty of roles inside frontier labs, and the two roles screen candidates more similarly than either resembles the rest of its own tier.

At Anthropic, model capability is outrunning the trust surface. Users delegate to agents whose reasoning they can't inspect. Working on that problem requires authority over the review gate, the moment before the system acts. At Render, developer infrastructure is growing an agent experience layer that didn't exist before, and working on that problem requires authority over a surface that is still being invented. The tier label won't tell you which of those two jobs a posting is hiring for. It also won't tell you whether the job comes with authority over the cause.

The tier playbooks map how each company archetype screens candidates. The decision-rights framework maps what a role controls. This piece sits between them: five questions that tell you whether a specific posting offers a design mandate or an explanation layer, answerable in ten minutes from public signals, before you write anything to anyone.

The five questions

1. What is advancing faster than the organization can manage?

Every company hiring a senior designer right now has something outpacing its current team. At frontier labs it's model capability. At growth-stage platforms it's usually surface area or a new customer segment. At enterprise platforms, accumulated complexity. In regulated domains, automation scope pressing against what compliance will allow.

The posting usually tells you, though not in those words. Read for the problem the role exists to solve, not the responsibilities it lists.

2. What breaks when it advances?

When model capability outruns the trust surface, people delegate decisions they don't understand. When surface area outruns design coherence, the product stops behaving consistently from one area to the next. When automation scope advances in a regulated domain, the system acts and the user finds out afterward, with no point in the flow where review was possible.

The transition map describes these breaks in terms of cost, detectability, reversibility, and intervention time. This diagnostic asks the narrower question: does the hire control the cause?

3. Who discovers the break, and who absorbs it?

A clinician reading an AI-generated note with an error in it discovers the break. The patient absorbs it. A fleet operator learns the drowsiness alert never fired when the accident is already on the report, and the driver has already absorbed it. A developer whose deploy fails because an agent misconfigured a service absorbs it as downtime.

Whoever absorbs the break is who the design work is actually for. Most portfolios at this level are built around the buyer or the administrator. Where yours contains work built for the person holding the consequence, that's the work to lead with, and most of your competition won't have it.

4. How reversible is the break?

A misclassified safety event in fleet management is irreversible once the accident has happened. A clinical note that enters the record with an error is reversible on paper and permanent in practice: corrections exist, but the original has already shaped downstream treatment. A misconfigured deploy is reversible in minutes.

Reversibility tells you how much of the role's authority has to sit on prevention rather than recovery. Low reversibility means the designer needs the gate in front of the action. A posting that puts the designer nowhere near that gate, in a failure regime that can't be undone, is describing a role that sits downstream of the decision.

5. What authority does this hire receive over the cause?

Most postings don't answer this. The residual-risk rights test gives you a way to ask.

The residual-risk rights test

Issue #4 established that decision rights are what the role controls, separate from reporting line. Issue #8 identified the gap between accountability and authority horizons. The residual-risk rights test sharpens both into four questions you can put to a posting, a recruiter, or a hiring manager. They are more precise than reporting line or "influence" because they test whether the designer's decisions change what the system does or only how it presents what was already decided.

Who defines the risk? Does the designer take part in identifying what could go wrong with a product behavior, or does that definition arrive from Research, Engineering, or Compliance as a constraint to work inside?

Who proposes the control? Once a risk is named, does the designer propose the interaction pattern, the review gate, the disclosure mechanism? Or does another function hand down a specification to execute?

Who can prevent release? Can the designer block a launch on experience grounds, because the trust surface is inadequate, because the user can't tell what the system did, because the review gate is too thin? Or does that authority sit entirely with Engineering, Product, or a safety team?

Who accepts what remains? Controls never reduce risk to zero. Someone decides the remainder is acceptable. If that person is never the designer, the designer's authority stops at the interface and does not extend to the behavior the interface represents.

Applied to current postings

Ambience — Staff Product Designer (the deep read)

The Ambience posting uses strong ownership language: "own and accelerate" the end-to-end experience, drive initiatives from whiteboard through launch, bring design thinking into product-strategy conversations.

Read the adjacent postings. The Staff ML Engineer, Frontier AI posting assigns Engineering the AI-quality strategy, the evaluation frameworks, production model behavior, failure-recovery loops, and technical direction for agentic systems. The Emergency Department Product Lead posting says Product defines what gets built, drives execution across Engineering, Design, and Clinical AI, and owns quality and adoption metrics.

Now run the five questions. What's advancing is clinical AI automation scope: the system generates notes, summaries, and documentation that enter the medical record. What breaks is a generated note with a clinical error in it. The patient absorbs it, through downstream treatment decisions shaped by that record. Reversibility is low in any way that matters. And the authority question answers itself from the adjacent postings.

Nothing in the design posting grants authority to define model correctness, set automation boundaries, establish evaluation criteria, approve or block a release, or determine which actions require clinician review. The ML Engineer posting assigns those to Engineering. The Product Lead posting assigns prioritization and execution ownership to Product.

The designer owns the experience of clinical AI output whose behavior Engineering controls and whose priorities Product sets. That's an explanation layer, and a consequential one: how well that output is presented determines whether a clinician catches an error before it reaches the patient. It still isn't authority over the thing producing the error.

Position accordingly. If you pursue this, lead with the Trust essay's framework for progressive delegation and the Thermo Fisher exception-first triage work. What you'd bring is a review gate that actually works, the moment where the clinician inspects AI output designed so errors are catchable. Go in knowing you wouldn't control the model behavior producing that output. Ask in the first call: Who decides when a new automation capability is ready for clinician-facing deployment, and what role does Design play in that decision?

Confidence: High that the posting does not advertise these rights. Moderate that the role lacks them in practice. Ambience is growth-stage, and actual authority often exceeds what's formalized. The adjacent-posting pattern is the stronger signal.

Samsara — Director, Product Design

The Samsara posting describes a manager-of-managers role: growing and coaching design managers, defining product-design strategy across product areas. The portfolio spans video-based safety, drowsiness detection, incident management, compliance, and connected operations.

What's advancing is sensor density and AI-driven safety detection. The system classifies driver behavior, generates safety alerts, triggers operational responses. A false negative means drowsiness goes undetected and an accident follows; a false positive erodes operator trust until alerts stop being read. The driver absorbs the first kind. Neither is reversible after the fact.

The posting grants no authority to set detection thresholds, classify safety events, define alert policies, control launch gates, or accept residual safety risk. Samsara's leadership page lists a CPO and no design executive. This is a team-leadership role inside a safety-critical product domain where the decisions that matter most, including what threshold fires an alert, how events get classified, and what the operator sees and when, are probably owned by Product and Engineering.

Position accordingly. Your Cummins/ZED Connect work is directly relevant here: dual-surface fleet management, IoT, connected operations. The real question is whether you want to lead a design team inside a product org that controls the safety-critical decisions. Ask in the first call: When the drowsiness detection threshold gets set, who's in the room, and does Design have a voice in that conversation?

Anthropic — AI-native

The failure regime is the one described at the top: model capability outrunning the trust surface. Run the rights test against it. Risk definition originates in research and safety, and Anthropic has published extensively enough on this that the point isn't in dispute. Control proposal is where it gets harder to read. Joel Lewenstein leads design but doesn't appear on the leadership page; CPO Ami Vora does. Whether the designer working on Claude's trust surface proposes the review gate architecture or implements gates specified by Safety and Research is not answerable from public signal. Release prevention and residual-risk acceptance are equally opaque.

The failure regime reads clearly from outside. The authority allocation doesn't. So make it your first-call question: When a new agent capability ships, who decides the trust surface is adequate, and is that a design decision, a safety decision, or a joint gate?

Headway — growth-stage platform

Headway's public org structure places Product Design under VP Product Jake Poses, who also owns Product and Product Marketing and reports to the CEO. No design executive. What's advancing is provider network scale and the therapist-patient matching surface. A match that doesn't work delays care, and the patient absorbs the delay. You can rematch, but time lost accessing mental health care isn't recovered.

You reach the structural answer before you get to the rights test: design reports to a VP Product who owns three functions. The designer most likely proposes the matching interface without controlling the matching algorithm or the provider quality criteria. Explanation layer, with the usual growth-stage caveat that real authority may be looser than the org chart. Worth noting that Gusto sits in the same tier with a CDO. Same tier label, different authority allocation.

Atlassian — enterprise platform

Atlassian lists Charlie Sutton as Chief Design Officer on its leadership page, the only company among these eight with a design executive at that level of public visibility. What's advancing is platform complexity across products plus AI integration through Atlassian Intelligence. What breaks is workflow coherence: AI features colliding with mental models teams have already built their operating rhythm around. Individual features roll back. Workflow disruption at organizational scale doesn't.

A CDO on the leadership page changes what you're testing for. The question stops being whether design holds authority and becomes over what scope. The rights test still applies, since a CDO's presence guarantees nothing about the specific role you're interviewing for, but the structural precondition for a mandate exists. Ask: For the product area this role covers, when a design decision and a product decision conflict, how does that get resolved?

The explanation-layer pattern

Ambience, Samsara, and Headway sit in three different tiers with three different failure regimes, and they produce the same arrangement: design owns the surface while another function owns the behavior the surface represents.

This arrangement shows up anywhere a system makes consequential automated decisions and the designer's job is to make those decisions visible, understandable, or reviewable without controlling the decision logic.

The fear analysis established that a company's fear predicts what it screens for. The failure-regime diagnostic asks the next question: does the role hold authority over what the company fears, or only over how that fear gets communicated to users?

A Glassdoor review from a senior product designer at Headspace, not a target company but illustrative of something that recurs across industries, describes the arrangement from inside: "PMs make all product decisions," designers left out of meetings about their own projects, research-backed proposals overridden by Product priorities. The distance between "own the experience" in a posting and that account of daily practice is what these five questions exist to measure before you sign.

For your search specifically, an explanation-layer role caps scope expandability. You can improve the explanation surface, but you can't expand into the behavior it represents. If function-building authority and design influence over product outcomes are what you're optimizing for, an explanation-layer role at a company where design holds no structural authority won't deliver them. That isn't an argument for skipping it. A consequential explanation layer at Ambience may be better work than a mandate at a company whose product doesn't matter. But go in with the ceiling priced correctly.

What gets you killed

Leading with gate-authority evidence for an explanation-layer role. The CarrierIQ provenance chain and the Trust essay framework show you designing the decision boundary itself. Where Engineering and Product own that boundary, this reads as a candidate who will spend her tenure fighting the org chart instead of doing the job she was hired for.

Leading with comprehension-under-pressure evidence for a mandate role. Alibaba's trust architecture and the Red Cross consolidation show you making complex systems legible. At a company that needs someone to own the decision logic, this undersells you as the person who explains rather than the person who decides.

Asking "who does this role report to?" as your mandate question. Reporting line gives you org-chart position and nothing else. A designer reporting to a CPO is still an explanation layer if Safety and Research control the behavior she presents. The four rights questions are the sharper instrument.

Reading "own the experience" as evidence of mandate. The Ambience deep read shows how "own" in the design posting coexists with "define" and "decide" in the Engineering and Product postings for the same product area. Read the adjacent postings before you conclude you own anything past the surface.

Framing the Trust essay as a philosophical position rather than a design method. Mandate roles want evidence you've built actual review gates and decision boundaries: the CarrierIQ approval flow, the Thermo Fisher exception-first triage. Present the five handoffs as a theory of trust and the evaluator hears a thinker when the role needs a builder.

How this changes your outreach

Run the five questions before you write to anyone. If the posting and its adjacent postings answer them, you already know which evidence leads.

For design mandate roles: Lead with the forward-looking artifacts, the interaction models and decision flows that show you designing the behavior itself. Trust essay five handoffs, CarrierIQ provenance chain, Thermo Fisher exception-first triage. These show you designing the gate.

For explanation-layer roles: Lead with the ability to make automated decisions inspectable and reviewable. Alibaba trust architecture, Red Cross system consolidation, Allē dual-surface work. These show you designing for comprehension under pressure, which is what the clinician reviewing AI output and the operator reading a safety alert are both doing.

When question five stays unanswered from public signals: Make it the first-call question. Not the reporting line. Ask: When the product makes a decision that affects the user and something goes wrong, who has authority to change the decision logic, and where does Design sit relative to that authority?

Corroborating signals

Two observable things strengthen the read.

Design executive visibility. Among the companies here: Atlassian lists a CDO. Gusto has a CDO but publishes no executive roster. Anthropic and Render have Heads of Design who don't appear on their leadership pages. Samsara, Ambience, Headway, and OpenAI show no design executive on any public leadership surface. A company with no visible design executive whose posting promises "strategic influence" carries a different risk profile than one where design has a named seat. Corroboration, not proof.

Verb allocation across adjacent postings. Ambience demonstrates it. Check who gets "define," "own," and "decide" in the postings next to the design role. If Engineering defines quality, Product decides priorities, and Design "influences" and "partners," the verbs have told you the authority structure regardless of what the design posting claims about ownership.

What this diagnostic does not cover

It doesn't map who beyond the design org absorbs product failures; that's a consequence-network question for a future piece. It doesn't tell you how to build and present evidence that survives a hiring panel, which is an evidence-architecture question. And it doesn't replace the mandate checksum, which tests a tier label against a posting, an interview, and a real decision. This diagnostic tells you what to ask. The checksum tells you whether the answers hold up.

The standing caution from Issue #10 still applies: unknown is not failure. A posting that doesn't advertise residual-risk rights may belong to a company that grants them informally, which happens often at growth stage where authority is still loose. Treat the output as a list of things to verify, not a verdict.

Quick-take card

Five questions, any posting: (1) What's advancing faster than the org can manage? (2) What breaks? (3) Who discovers and absorbs the break? (4) How reversible? (5) What authority does this hire receive over the cause?

Residual-risk rights test: Who defines risk, proposes the control, prevents release, accepts what remains? Two of four means design mandate. Zero or one means explanation layer.

Adjacent-posting read: Check who gets "define," "own," and "decide" in the Engineering and Product postings for the same team. Whoever holds the strong verbs holds the authority.

First-call question: When something goes wrong with a product decision that affects users, who has authority to change the decision logic, and where does Design sit relative to that?

Explanation-layer recognition cue: The design posting says "own the experience" while adjacent postings assign behavior, quality, and prioritization to other functions.