Six rooms, six fears
Every person in a senior design loop controls access to something the role needs: a budget line, an engineering partnership, craft credibility inside the design team, executive cover, the cooperation of a product org. Each of them also carries a private fear about what goes wrong if this hire is the wrong one. That fear, not the scorecard, is what they screen against.
The six: Recruiter, Hiring Manager, Craft Judge, Engineering Partner, Cross-Functional Partner, Sponsor. When all six describe the same job, you are interviewing for one role. When they describe different jobs, you are interviewing for a role the company has not finished defining internally — and you want to know which situation you're in before you accept anything.
Earlier pieces mapped feared failures to evidence types and read the interview loop itself as organizational evidence. This one takes each room separately, gives you a method for reading the rooms against each other, and pins a positioning move to each.
Craft Judge, Cross-Functional Partner, and Sponsor get the framework here — feared failure, evidence appetite, register — with fuller treatment coming in their own pieces. Recruiter, Hiring Manager, and Engineering Partner get the full version below.
Craft Judge — framework
Feared failure: You don't have the taste, rigor, or current craft fluency to raise the bar. Senior ICs won't accept your judgment, and the org absorbs a leader who dilutes quality.
Evidence appetite: Work at resolution. Interaction states, edge cases, hierarchy, with the reasoning attached. Strategy decks don't register in this room. The Agentic Labs apps carry weight because they're live and a reviewer can use them. The forward-looking artifacts carry weight in a live conversation, labeled clearly as original work in progress, but they have no public destination yet; until they do, they're something you walk someone through, not something you send ahead. Alibaba carries weight for a different reason — decisions made at platform scale.
Conversational register: Peer. This person is deciding whether they'd want you reviewing their work. When you describe a design decision, name what you gave up.
Companion piece: how craft judgment shifts by tier, the altitude mismatch that kills Director candidates in IC-heavy orgs, and how your IC+manager positioning changes depending on whether the Craft Judge sits above the role or beside it.
Cross-Functional Partner — framework
Feared failure: You'll be a bottleneck, a territory defender, or someone who folds the moment product priorities move. They're screening for whether design multiplies what the team can do or adds a step to it.
Evidence appetite: Decision narratives. A scope change you navigated, a priority conflict, a moment when the right design answer and the right business answer pulled apart. Your BCG DV work is strong here — Thermo Fisher's six-partner ecosystem and the Allē dual-surface redesign both ran on continuous cross-functional negotiation.
Conversational register: Outcome-first. Process description is what this room least wants. Tell them what shipped, what was different because you were in the room, and what you did the time you didn't get your way.
Companion piece: how this room behaves differently in product-led versus engineering-led orgs, and the specific risk that your TinyFish product title sets off a "will she try to own product decisions?" concern.
Sponsor — framework
Feared failure: You can't operate at altitude. The sponsor — CPO, CTO, sometimes the CEO — needs someone who can hold the design position in rooms where nobody else in attendance cares about design. What they fear is spending political capital on the hire and then having to explain, two quarters later, why design still isn't delivering.
Evidence appetite: Business impact and organizational narrative. How you changed what a team could do: built a function, moved a number, created a capability that didn't exist. Alibaba's $50B GMV context and the +20% transaction lift belong here. So does the TinyFish bridge — you went to product to build AI-natively from zero, shipped in three months, and came back to design with technical depth a portfolio-only candidate doesn't have.
Conversational register: Executive. Shorter sentences, fewer qualifications.
Companion piece: telling a real sponsor from a ceremonial one, and what to do when there's no sponsor in the loop at all.
Recruiter
The recruiter decides whether you enter the process at all. That is the whole scope of the room, and it makes them conservative.
What they actually decide. Published hiring guides from Atlassian and GitLab are representative on this point: category fit, level, motivation, career direction, compensation alignment, logistics. Craft, leadership philosophy, and portfolio depth are not being assessed yet. The question is whether you belong in the pipeline.
The feared failure. Advancing someone who fails on a basic filter — wrong level, wrong band, wrong authorization — and burning four to six hours of interviewer time across the loop. Recruiters get remembered for that.
Your classification problem. Head of Product, then Product Design Director at BCG DV, then Head of Design and Research at Alibaba, read backward from the most recent. Someone scanning that sequence has to work to decide whether you're a product person, a design person, or a researcher. Do the work for them in the first ninety seconds: design leader, deliberate detour into product to build AI-natively, now returning to design. The bridge narrative exists mainly to prevent miscategorization here.
The portfolio gate. A Figma design recruiter describes having "minutes or seconds" to classify a candidate's work. Read that as directional rather than literal — it's an employer-side account of employer-side behavior — but the operational implication holds. If your type of work isn't identifiable within a few seconds of landing on the site, what sits deeper in the portfolio may never get seen.
Tier variation. At AI-native companies the screen often includes a mission or product-familiarity filter. OpenAI's guide asks about "familiarity with recent work relevant to the team," which is a check on whether you've engaged with what they actually ship. At enterprise platforms the same call is more procedural: background, skills, goals, timeline.
Your move. Have a sixty-second version ready and deliver it before you're asked. Design leadership; most recently shipped an AI-native enterprise platform as Head of Product at TinyFish; returning to design to apply that technical depth in a vertical domain; looking for a role that keeps you hands-on while leading the function.
Hiring Manager
This room has the widest remit. The hiring manager usually sets the loop composition, decides whether you advance past the first real conversation, and carries the most personal version of the fear, because they're the one who lives with the hire daily.
What they actually decide. Whether you understand the problem they're trying to solve, and whether they believe you can solve it. They wrote the job description or approved it, and that description is an organizational problem passed through HR language. The evaluation is whether you read the problem correctly through the filter.
Which fear is operative depends on what went wrong last time. If the previous design leader couldn't ship, they fear another perfectionist. If the previous leader couldn't influence product, they fear another designer who waits to be invited. If there was no previous design leader, they fear hiring someone who needs infrastructure that doesn't exist. Posting language usually tells you which — as covered in the requirements piece, a posting that says "cross-functional collaboration" three times is telling you design currently has no seat at the table.
Forty-five minutes, and at Director or Staff level most candidates advance or get cut here. Three assessments run at once:
- Do you understand their situation — this team, this product, this organizational moment?
- Can you hold the right altitude? Too high and you sound like a consultant. Too low and you sound like someone who will disappear into the work and never surface.
- Do you have a point of view about what the role should do first?
The third one does the cutting. A candidate who asks good questions and never commits to a perspective loses to one who says "based on what you've described, here's where I'd start in the first ninety days." At an AI-native company that might be: "I'd map every place a user has to act on model output without enough evidence to justify it." At an enterprise platform: "I'd audit the distance between the design system as it stands and what the twelve-month roadmap needs it to do." At a regulated company: "I'd find the three highest-stakes decision points where the current experience gives users the least support." The direction can be wrong and corrected later. Having none reads as having no judgment, and judgment is what they're hiring for.
How your background plays. Lead with the pillar that matches their problem, in the first five minutes. AI-native: the TinyFish bridge and the forward-looking artifacts. Enterprise: Alibaba. Regulated: Thermo Fisher and Red Cross. Don't walk your career chronologically. Bridge to the other pillars only when asked.
The TinyFish-to-design bridge matters more in this room than anywhere else, because this is the person most likely to ask why you left design and why you're coming back. Keep the answer short: you went to product to build AI-natively from zero, shipped the platform in three months, and returned because you want that depth applied to a specific vertical problem and you miss the creative work and the design community.
Tier variation. At AI-native companies the conversation often runs technical — expect a specific design problem the team currently has, at a level of specificity that requires you to have used the product. At growth-stage platforms the hiring manager is assessing whether you can build the function: hiring, process, establishing design credibility where none existed. At enterprise platforms this is often a VP or Senior Director with a large existing team, and the conversation moves toward strategic alignment and organizational fit rather than build capability.
Engineering Partner
This room decides whether the role gets a working partnership with engineering or a transactional one. At this level that difference determines whether you can ship.
What they screen for. Published criteria from Atlassian, GitLab, Intercom, and Zalando converge on the same three things: understanding of technical constraints, trade-off reasoning, and collaboration as an ongoing relationship rather than a handoff. Atlassian's triad interview asks about "trade-offs, the role of Design, and how the candidate collaborates with Product and Engineering." Intercom puts the PM and Engineering Manager in one session for a project deep dive covering "constraints, trade-offs, team execution." GitLab includes the Engineering Manager to assess "trio fit, domain alignment, and understanding of product-specific workflows and technical constraints." High confidence on the pattern, with one caveat: all four sources are employer-published, so they describe what these companies intend to evaluate rather than what happens in the room.
Three feared failures, weighted differently by tier:
Late technical surprise. You settle a design decision without knowing what it costs to build, and engineering finds out after committing people to it. Strongest at enterprise platforms, where rework at scale is expensive.
Poor trade-off judgment. You treat the ideal interaction as the only acceptable one and can't say what to preserve when scope, time, or architecture moves. Strongest at growth-stage companies, where a good-enough decision made this week beats a perfect one made next month.
Collaboration friction. You work through handoffs instead of working sessions, add process that doesn't move decisions, or can't hold a disagreement without it going sideways. Most acute at AI-native companies, where the design-engineering boundary is blurry and the work is co-created continuously.
How your background plays. TinyFish does its heaviest work in this room, not as portfolio proof but as evidence that you've stood on the engineering side of the boundary. You shipped an agentic platform from zero to one. You worked daily with agent traces, auditability, attribution, governance. You know what things cost to build because you were the person deciding what got built.
But the calibration matters. Lead too hard on the product and technical narrative and this person starts wondering whether you'll make engineering decisions that aren't yours. Demonstrate that you understand their world well enough to be a genuine partner, and stop short of sounding like you want their job.
Tier variation. GitLab's process documentation shows the room shifting by level inside a single company: stage-aligned designers meet the Engineering Manager from their product group, and the test is trio fit and domain constraints; Staff and Principal designers working across platforms meet engineering leadership, and the test is cross-team influence and system-level reasoning. Same label on the room, different thing being decided.
At AI-native companies this room may also screen for whether you can treat model behavior as a design material. For roles touching agent workflows or trust architecture, the fear moves from buildability toward whether you understand failure modes, confidence boundaries, and recovery paths. Carrier IQ and the five-handoffs framework from the Trust essay are relevant, but the stronger signal is a specific failure state you hit at TinyFish and what you designed to contain it.
Your move. Tell one story about a technical constraint that changed your design direction, with enough detail that the engineer can verify you understood the constraint rather than merely worked around it. Then ask what the hardest technical constraint their design team is currently working around. The question shows you think about engineering reality unprompted, and the answer tells you something real about the operating environment.
Where screening power concentrates
All six rooms exist at every tier. They don't carry equal weight. Where the real cuts happen moves with the company archetype — moderate confidence on what follows, since the evidence is employer-published process documentation and I haven't found candidate-side accounts detailed enough to corroborate the weighting.
AI-native. Screening power concentrates in the Engineering Partner and Craft Judge rooms. OpenAI's process allocates four to six hours of final interviews heavily toward "role-specific skills assessments." The hiring manager conversation may be a thirty-minute screen; the technical and craft sessions do the filtering. The Sponsor room carries less independent weight at this size because the hiring manager often is the senior leader. Prepare disproportionately for Engineering Partner and Craft Judge. Your forward-looking artifacts and TinyFish depth are working hardest in the rooms where the cuts happen.
Enterprise platforms. Weight moves to Hiring Manager and Sponsor. Atlassian's published process includes a values interview with someone from a different part of the organization, formalizing an organizational-fit judgment that smaller companies leave implicit. The triad interview is a documented gate, but the strategic conversation with the hiring manager and the cross-organizational read determine whether you get an offer and at what level. Alibaba leads in the rooms with the most authority here. The forward-looking artifacts differentiate you from the rest of the enterprise field, but they aren't what opens the gate.
Growth-stage. Rooms collapse. At a Series B or C company hiring its first design leader, the founder or VP Product may be hiring manager, sponsor, and cross-functional partner at once. Intercom's process merges the cross-functional and engineering rooms into a single session with the PM and Engineering Manager together. When rooms collapse, that one conversation carries nearly everything, so your function-building proof — Red Cross, Thermo Fisher — has to land there. There may be no second room where it gets evaluated independently.
Level matters as much as tier. GitLab's handbook shows the Sponsor room acquiring formal gate power as role scope increases: Staff+ candidates meet the CDO and senior leadership where stage-aligned candidates don't. Scale your preparation for that room to the seniority of the role, not just the tier of the company.
The contested-decision diagnostic
The rooms are most useful as a comparison set.
Before the loop, pick one decision the role will plausibly face in its first six months. A release gate: who decides when something is ready to ship. An automation boundary: which workflows get automated and which stay human-controlled. A design-system standard: who owns it and who can override it.
Put that decision to every room, as a real question about how the team works rather than as a hypothetical. Then compare the answers.
Ask in every room: "When there's disagreement about whether a feature is ready to ship, how does that get resolved?" Convergent answers mean a settled mandate. Divergent answers mean the role hasn't been internally resolved.
Convergence — every room describing roughly the same process, the same authority, the same escalation path — means the role has been defined internally. You're interviewing for one job.
Divergence — the hiring manager says you'd own the call, the engineering partner calls it a joint decision, the sponsor says they're still figuring that out — means it hasn't been. Executive search firms describe unclear mandates as common at this level, with each stakeholder reacting to their own version of what the hire is supposed to fix. A recruiter documents the extreme case: a senior engineer met three interviewers testing for three incompatible roles and withdrew when nobody could say which job was real.
Divergence isn't automatically disqualifying. Some of the best roles begin with an unresolved mandate, and resolving it is the job. What matters is whether the company knows. If the divergence is acknowledged — "we need someone to figure this out" — you can negotiate for the authority to do it. If every room claims alignment while describing different jobs, you'll inherit the disagreement without the standing to settle it.
Three mandates the rooms reveal
Answer patterns across the six tend to cluster into three shapes. Knowing which one you're walking into changes what you prepare and what you negotiate.
Perform. The function exists, the team is built, you're the next operator. High convergence across rooms, specific expectations, detailed descriptions of current workflow. The hiring manager describes the role in terms of what the last person did. Ask what would change about the function if the right person were in the seat; if the answer is "keep it running," the ceiling is probably low.
Build. The function doesn't exist, or exists in name. The hiring manager has a clear vision and the other rooms are vague, or describe design work currently being done by non-designers. The engineering partner may never have worked with a dedicated design leader. Red Cross and Thermo Fisher are your strongest proof here — functions built from zero in environments with no design precedent.
Absorb. The role consolidates work currently distributed across other functions, which means you're taking authority someone else holds today. The hiring manager describes the role expansively; the cross-functional or engineering partner describes something narrower, because the expansive version includes work they own. This is the highest-risk of the three. You're being hired to take something from people who are interviewing you, and they may not have agreed to give it up. When the cross-functional partner's version of the role is materially narrower than the hiring manager's, weight that gap above anything else you learn in the loop.
Two-directional red flags
No sponsor appears. Ask who approved the headcount and whether you'll meet them before an offer. You need to know whose budget you are, because that's the person who decides what happens when design and product disagree six months in.
The engineering partner describes a service relationship. If the questions are about how you'll deliver specs, turn around requests, and stay out of the way, rather than how you'll work on product direction together, design is a service function here regardless of what the posting says.
Every room asks about process and none about judgment. "How do you run a design review" is process. "How do you decide when a product isn't ready" is judgment. An all-process loop wants a design manager.
The hiring manager can't say what the previous person got wrong. If there was a predecessor and the description stays generic — it wasn't the right fit — the feared failure hasn't been diagnosed, and you can't position against a fear nobody has articulated.
What gets you killed
Giving the same presentation in every room. The recruiter needs classification, the craft judge needs resolution, the engineering partner needs constraint reasoning, the sponsor needs business impact. One walkthrough at one altitude satisfies none of them.
Treating the recruiter screen as a formality. If they can't classify you in ninety seconds, you don't reach the hiring manager. Your title history makes that harder than it should be, and nobody else is going to solve it for you.
Performing technical depth for the sponsor. They don't care about agent traces. They care whether you can hold the design position in a leadership meeting where nobody else will.
Asking about authority only in the hiring manager room. The hiring manager will describe the role's authority generously; they're selling. The engineering and cross-functional partners describe it closer to how it works. Ask the same question everywhere and compare.
Skipping past the engineering partner's constraint framing. When they name a constraint, they're checking whether you heard it. Acknowledge the constraint before you respond with design. Jumping straight to the solution confirms the fear.
Quick-take card
Six rooms, six different feared failures. Each interviewer controls access to something the role needs and screens against their own version of what goes wrong.
Lead with the pillar that matches the hiring manager's problem. AI-native: TinyFish bridge plus forward-looking artifacts. Enterprise: Alibaba. Regulated: Thermo Fisher and Red Cross.
Top landmine: one presentation at one altitude in every room. The recruiter needs classification, the craft judge needs resolution, the engineering partner needs constraint reasoning, the sponsor needs business impact.
Ask in every room: "When there's disagreement about whether a feature is ready to ship, how does that get resolved?" Matching answers mean a settled mandate. Conflicting answers mean the role is still being negotiated internally.
Pattern break: if the engineering partner asks about your code rather than your collaboration, the role may require production-code authorship, which changes the evidence you need entirely.
- GitLab's level-dependent panels: Their public handbook shows stage-aligned designers meeting their direct trio while Staff+ designers meet the CDO and senior leadership, the clearest documented example of room jurisdiction shifting by role scope within a single company.
- Atlassian's IC-versus-manager portfolio split: Their design interview handbook explicitly questions IC candidates more deeply on design decisions and management candidates more heavily on how they led the team, which means the Craft Judge room recalibrates its evidence appetite based on the track you're on.
- Maven's two design roles as tier-breaker evidence: The same company posts a Consumer Design Lead screened on growth, acquisition, and D2C product leadership alongside a Senior Staff Care Delivery role screened on uncertainty, human deferral, and model behavior, confirming that company name does not predict which rooms carry the most weight.
- Vanta's Design Recruiter posting: Their current recruiter vacancy expects portfolio evaluation and leveling across senior and leadership roles, evidence that at least one company treats the recruiter room as a substantive craft-classification gate rather than a logistics screen.
