What makes this buyer different
When a design leader hires against a predecessor, they evaluate you against that person's performance, the team's memory of what worked, and a job architecture refined by at least one hiring cycle. When they create a new-category seat, they have none of that. They evaluate against their own mental model of the problem, assembled from whatever organizational failure forced them to create the seat.
This has two operational consequences. The job posting is less reliable than usual because it describes what the buyer thinks they need before any candidate has pressure-tested the definition. And the buyer is unusually open to having their model improved — someone who arrives with a sharper framework for the problem than the buyer currently holds is offering intellectual partnership on the problem definition itself.
Your Trust essay is a mental model: five handoffs, a trust ladder, a named architecture for agentic systems. It competes directly with whatever partial model the buyer has assembled from their own experience. How it plays depends on what failure created the seat. The same is true for your forward-looking design artifacts — the interaction models, decision flows, and state diagrams that show the framework producing actual design deliverables for frontier problems.
I covered how IC craft buyers evaluate across these same three tiers in Issue #11. That piece was about buyers with established design functions hiring for known roles. This piece is about the buyer who is defining the role while hiring for it.
AI-native startup — the product shipped without designed experience
Grounding example: Samia Saleem, Head of Design at Render, hiring for Agent Experience.
The failure that created the seat. Render's developer platform now includes agent-facing surfaces — CLI, API, MCP, SDKs, Blueprints — that shipped as engineering artifacts. The deploy-verify-debug-iterate loop works, but nobody designed it as an experience. Saleem says publicly that Render is "still defining what agent experience means" and expects to learn from the hire.
What she says she's evaluating. Craft quality, technical fluency, detail orientation, developer-experience sensibility, autonomous shipping, constructive team behavior. She asks for a portfolio or examples.
What she's actually evaluating. Whether you can name the design problem inside agent experience more precisely than she currently can — and whether you can work in the specific environment where that problem lives. Programmatic surfaces, command-line interfaces, API ergonomics. A brilliant framework with no evidence of working in those surfaces reads as theory. Deep CLI/API experience with no articulated design philosophy reads as execution without judgment. She needs both.
Saleem has built design functions before: Nike enterprise design from 3 to 30+ people in eight months, GitHub's design org — over 80 people across product design, design engineering, management, and research, including a new Design Engineer job family. Her mental model is more developed than most AI-native startup buyers. Framework alone won't impress her.
Tells. If she spends the first ten minutes asking you what agent experience should be, she's in mental-model mode and the Trust essay is your strongest asset. If she pivots quickly to a specific Render surface — making MCP tool selection inspectable to a developer debugging an agent run — she needs to see that you can think concretely about programmatic interfaces.
Who you're competing against (confidence: moderate to speculative). Developer-tools designers from companies like Vercel and Supabase who ship daily and think in code. Design engineers who own production front-end — Vercel's published model explicitly spans dashboard, CLI, API, and code. AI-lab designers from OpenAI or Anthropic with model-adjacent product experience. The developer-tools designer outperforms you on programmatic-surface fluency. The design engineer outperforms on code ownership. The AI-lab designer outperforms on brand. None are likely to arrive with a published framework for trust architecture in agentic systems or enterprise-scale platform outcomes at Alibaba's level.
What wins. Lead with the Trust essay mapped to Render's specific agent surfaces. Name the design problem underneath their product before you list credentials: the gap between what an agent did and what a developer can verify. Your forward-looking design artifacts — interaction models, decision flows, state diagrams rooted in the five handoffs — show this framework producing original design work rather than staying at the essay level. Carrier IQ demonstrates regulated agentic automation with all five handoffs in a live application. That combination — published framework, design deliverables that operationalize it, working demonstration, enterprise scale proof — is a profile the competitive set doesn't assemble.
What loses. Presenting enterprise case studies first. Saleem has enterprise experience herself; she doesn't need your scale credentials before she sees your thinking about her actual problem. Implying code ownership you can't substantiate. Your portfolio has no public production-code evidence, and Saleem is separately hiring Design Engineers against explicit code-ownership criteria — she knows the difference. Position your technical depth as interaction judgment and agent-behavior fluency from your time at TinyFish, not as front-end implementation.
Your honest vulnerability. The programmatic-surface gap is real. Your published portfolio doesn't show command design, API ergonomics, or MCP behavior. The Trust essay and Carrier IQ get you into the conversation. Whether they carry you through a portfolio review that probes developer-interface specifics depends on how much weight Saleem places on surface-level evidence versus design-problem framing. That weighting is not public, and I can't resolve it from signal alone.
Growth-stage platform — the existing team's skills don't transfer
Grounding example: May-Li Khoe, VP of Design at Handshake, building a multi-level design organization after the departure of CDO Malthe Sigurdsson.
The failure that created the seat. Handshake has a design team that serves its core student-employer matching platform. Autonomous Recruiting is a different category: agentic systems that act on behalf of recruiters, taking consequential action where the user needs to trust, verify, and override. The existing team's interaction-design skills don't transfer cleanly to that problem.
What the public language says they're evaluating. Khoe's hiring posts emphasize multi-level organizational building, high standards, and cross-functional integration. The Autonomous Recruiting posting frames the role around agent-mediated recruiting workflows. The specific buyer for this role remains unidentified publicly, so the stated criteria come from the posting and Khoe's general design-leadership language rather than from the hiring manager's own framing.
What the buyer is actually evaluating. Whether you can do the thing their current team can't — design for agent autonomy, trust calibration, human override — while fitting into the organization Khoe is building. Easy to underestimate that second condition. Khoe's background spans design, research, prototyping, engineering, and game development. She installed design management, research, design systems, brand, and UX writing functions at Khan Academy. She is building organizational infrastructure. A candidate who reads as a solo operator or who can't articulate how they'd work within a multi-level design org will lose to someone with less AI depth but better organizational fit.
Tells. If the buyer asks about your design process for trust and autonomy, they're evaluating your mental model. If they ask how you'd work with the existing platform design team, they're evaluating organizational integration. If they describe the role in compound terms — interaction design, AI behavior design, user research — they're pattern-matching against an imagined hybrid they've never managed. Ask which of those capabilities is most urgent rather than claiming all three equally.
Who you're competing against (confidence: speculative). Platform designers from growth-stage companies like Figma, Notion, or Canva who've scaled with the org and understand growth-stage pace. AI-adjacent designers from companies building autonomous professional workflows — Ironclad, Harvey, or similar where agents take consequential action in someone's professional domain. The platform designer outperforms you on growth-stage organizational fluency. The AI-adjacent designer outperforms on domain proximity to autonomous recruiting. Neither arrives with a published trust architecture framework, enterprise-scale regulated delivery proof, or the range of 0-to-1 builds across multiple high-stakes verticals.
What wins. Map the Trust essay's five handoffs to a recruiter delegating consequential hiring actions to an agent. Your forward-looking artifacts — particularly anything modeling human-agent system design or intent-based interaction — show how the framework applies to this category of problem. Thermo Fisher and Red Cross (both as Product Design Director at BCG Digital Ventures) prove you've shipped 0-to-1 in high-stakes, regulated contexts where the system takes action on behalf of a professional user. Frame your TinyFish experience as direct evidence that you've already worked through agent traces, auditability, and governance in enterprise deployment — the exact capability gap their existing team has.
What loses. Leading with Alibaba scale. Khoe is building a growth-stage org; enterprise scale is supporting evidence, not the lead. Treating the role as purely an AI-design problem without acknowledging the recruiting domain. You don't need recruiting expertise, but you need to show you understand the stakes of autonomous action in someone else's professional workflow.
Your honest vulnerability. Domain transfer. Your agentic work is in brand intelligence, retail, and insurance (Agentic Labs) and enterprise web agents (TinyFish). Recruiting is different terrain with different trust thresholds and different failure costs. The counter-move: the Trust essay's framework is domain-agnostic by design — the five handoffs apply to any system where an agent acts on behalf of a human — and your track record shows repeated domain transfer across pharma supply chain, disaster relief, fitness, aesthetics, and B2B trade. That pattern is the evidence.
Enterprise — the problem is institutional change
Grounding example: Capital One's AI-in-XD Director role, tracked across three requisitions and seven months.
The failure that created the seat. The design organization needs to integrate AI into its practice, but nobody currently owns that integration. The buyer may not have separated methodology leadership (how should designers think about AI?), tool adoption (which AI tools should designers use?), and design technology (how do we build AI into design infrastructure?). The posting language has shifted across iterations from personal visionary authority toward infrastructure that existing design leaders can use, a pattern I described in the mandate laundering piece.
What the posting says they're evaluating. The current language emphasizes methodology, practice integration, and cross-functional influence. Daniela Jorge's public guidance emphasizes showing the customer, the problem, the options considered, and the evidence behind decisions — language oriented toward institutional accountability.
What the buyer is actually evaluating. Whether you can install a practice across a hundreds-person design org without breaking the org. The posting evolved away from visionary language for a reason: the buyer learned — likely through a failed or stalled search — that they need someone who can work through existing leadership rather than around it.
Tells. If the buyer asks about your framework for AI in design, they're in methodology mode and the Trust essay is your lead. If they ask about stakeholder management and executive buy-in, they're in political mode and your function-building proof (Alibaba cross-functional leadership, BCG DV engagement scale) matters more than your AI thinking. If they ask about specific AI tools or platforms, they may be conflating tool adoption with methodology leadership. Clarify the distinction before answering — this is a useful moment to demonstrate the kind of conceptual sorting the role actually requires.
Who you're competing against (confidence: moderate). Internal-mobility candidates who already know Capital One's design org, its political landscape, and its institutional constraints. Design-ops and methodology leaders from large orgs — Intuit, Microsoft, IBM — who've run practice adoption at hundreds-person scale. The internal candidate outperforms you on institutional knowledge and political navigation. The methodology leader outperforms on proven org-scale installation. Neither arrives with a published AI-specific design framework backed by working demonstrations or the combination of 0-to-1 delivery proof and agentic production experience.
What wins. Position the Trust essay as an installable methodology — something their existing design leaders could adopt and apply to their current work. Forward-looking artifacts show how the framework translates into design deliverables at that level. Carrier IQ proves the methodology produces working outcomes in a regulated context. Together: here is a framework your existing design leaders can use, here is evidence it works.
What loses. Positioning yourself as the visionary who will transform the org — the posting language moved away from that framing for a reason, and the reason is almost certainly a search failure. Any claim about installing methodology at organizational scale that you can't back with evidence. Your function-building experience is real (Alibaba, BCG DV engagements), but you haven't installed an AI design methodology across a hundreds-person org. Say so directly if asked. A candid answer that clarifies role geometry is better than an overclaim that comes apart in the panel.
The move that works across all three
Lead with the Trust essay. Not as a credential, but as a mental model mapped to the buyer's specific product problem, in the first three sentences of contact. Support it with the forward-looking design artifacts that show the framework producing real deliverables, then with whichever case study or demonstration matches the tier:
- AI-native startup: Carrier IQ and programmatic-surface thinking.
- Growth-stage platform: Domain-transfer proof and organizational fit.
- Enterprise: Installable methodology and institutional accountability.
Your differentiated position across all three tiers is the same: a published framework that competes with the buyer's own mental model of the problem they just created a seat to solve, backed by working demonstrations and enterprise-scale delivery proof. Each competitive archetype outperforms you somewhere — Anthropic on brand pedigree, enterprise methodology leaders on org-scale proof, developer-tools designers on surface fluency. But none of them combine a published trust architecture, forward-looking design artifacts, live agentic demonstrations, and regulated enterprise delivery outcomes. That combination is what you open with.
- Atlassian's published interview architecture: The only company among the six targets with a public design interview handbook, including structured scenario questions, portfolio review criteria, and a Product/Engineering/Design triad for senior roles — worth studying before any Rovo & AI outreach.
- LinkedIn's first Conversation Designer: Aubry Ellison's retrospective on joining LinkedIn as its first Conversation Designer shows how a new-category seat scoped to a help-center bot expanded into reusable system patterns, cross-disciplinary education, and independent standard-setting — the clearest public example of what happens after the hire.
- Vercel's design-engineering model: Their published description of Design Engineering at Vercel defines the profile Render's competitive slate likely includes — autonomous shipping across dashboard, CLI, API, and code — and clarifies exactly where your evidence is differentiated and where it's thin.
- Capital One's historical portfolio-review tool: In 2018, Peter Merholz published a Capital One-approved portfolio assessment instrument with defined skill descriptions intended to reduce evaluator bias — whether it's still in use is unverified, but it reveals how the org has thought about structured design evaluation.
