Shared framing
Both companies need a designer who can solve the same problem: an AI agent acts on behalf of a human in a domain where a bad action costs more than a retry. Headway's AI front-desk assistant acts on behalf of a therapist toward a prospective patient. OpenAI's Codex agent acts on behalf of a developer toward a codebase. The person who delegated cannot efficiently review every action — reviewing everything defeats the product's value. So the design surface that determines whether either product works is the system's communication of what it did, how confident it is, and where it might be wrong. Your portfolio has production answers to that question. Position them differently at each company.
Headway — Staff Product Designer, Provider CRM & Prospect Management
Posting: Staff Product Designer, Provider CRM & Prospect Management Comp: $212K–$265K + equity Status: Active, Provider Sourced Patients pod
The design challenge
Seventy percent of Headway's new patients come through the provider's own channels — website, Psychology Today, referrals — not Headway's marketplace. The CRM manages those prospects. The posting describes an AI front-desk and scheduling assistant that will answer patient inquiries, book appointments, and follow up on the provider's behalf. It explicitly names uncertainty and error handling in clinical AI contexts as part of the design scope.
The structural difficulty is the party count. Three parties. The provider authorizes the AI to act. The patient receives the action. The provider cannot review every outbound message — that kills the assistant's value — but a bad message to someone seeking therapy is a categorically different failure than a bad message about a shipping delay. Per-action review is impossible. The design work is deciding which actions the assistant handles autonomously, which require provider approval, and how the system communicates that distinction to both sides.
High confidence: The posting describes the assistant in forward-looking language. Headway's current help documentation shows no generally released AI front-desk feature. This is zero-to-one work.
Moderate confidence: Roland Tiangco, introduced as Director of Provider Product Design in Jake Poses's hiring post, is the most scope-proximate evaluator based on that reported responsibility for the end-to-end provider experience. Inference chain: Poses's post → Tiangco's title → scope overlap with this role. No public statements from Tiangco on hiring criteria or clinical AI design.
Lead with CarrierIQ
The artifact domain is Human-Agent System Design — three-party authority, where the system acts on behalf of one person toward another, and the design surface is the boundary between autonomous action and required human review. CarrierIQ is the strongest match in your portfolio.
CarrierIQ is a working agentic system where autonomous agents execute tasks on behalf of a user — navigating carrier portals, filling data, extracting quotes — with staged execution visibility (Session, Navigate, Fill, Extract, Verify), per-agent status, evidence attachment, coverage deltas, carrier trust signals, and an Approve Bind gate that separates "the system found a result" from "you authorized action on that result."
That gate is the piece Headway needs. The provider CRM assistant will find prospects, send messages, book appointments. The provider needs to see what the assistant did, why it chose that action, and where explicit approval is required before something irreversible happens. CarrierIQ's approval boundary is a production prototype of exactly that problem.
The CarrierIQ case study on your portfolio site is behind a password gate. The standalone app loads directly. In outreach or conversation, describe the system and offer to walk through the live app. Do not send the portfolio case link and assume it will load for the recipient.
Support CarrierIQ with the Trust essay's decision-gate framework as the conceptual layer — the principle that authorizing an outcome does not authorize every method used to achieve it. Keep the Trust essay in a supporting role. This is a Staff IC position on a specific product surface.
The differentiator
A working agentic system with staged execution, evidence surfaces, and an explicit approval boundary. Competing candidates will come from health tech or enterprise SaaS backgrounds with provider dashboards, patient flows, or CRM interfaces. They will not have built the trust-calibration layer for an AI agent that acts autonomously on behalf of one person toward a different person in a clinical context.
What NOT to lead with
- Abstract trust frameworks or design-maturity positioning. Ellen Dong's published hiring process centers on portfolio selling calls, app critiques, and whiteboarding — and her team recently moved from slide-supported prototypes to same-day interactive demos using AI tools (MagicPattern, Cursor, Claude Code). The evaluation surface is production proximity.
- TinyFish as portfolio proof. Past tense as context for how you learned to build in regulated, high-stakes environments. Not a case study.
- Scale narratives. Zero-to-one product in a pod. The posting wants someone who can define the CRM surface, design the assistant's behavior boundaries, and ship.
The interview question they are forming
"The AI assistant sends a follow-up message to a prospective patient on the provider's behalf. The patient responds with something clinically sensitive — they mention a crisis, or disclose something the provider needs to know before the first session. How does the system handle that? What does the provider see? What does the patient experience?"
Your answer, grounded in production: Walk through CarrierIQ's escalation model. When a carrier agent encounters an unexpected state during execution — a field it cannot fill, a result that conflicts with the input data — it does not proceed and fabricate. It surfaces the exception with evidence attached and routes to operator review. The principle: autonomy boundaries are defined by consequence severity, not task complexity. Simple tasks with high-consequence failure modes (a message to a patient in crisis) require tighter review gates than complex tasks with low-consequence failure modes (scheduling a routine follow-up). Map that to the provider CRM: which assistant actions are autonomous, which require provider review, and how the system communicates the difference to both the provider and the patient.
OpenAI — Product Design Lead, Growth — Codex
Posting: Product Design Lead, Growth – Codex Comp: $347K–$405K + equity Status: Active. Originally posted August 18 as "Product Design Leadership, Growth," renamed in place to scope the role explicitly to Codex. Same requisition ID, same publication date. The committee narrowed the scope while the search was live, which means this is a refined search, not a reset pipeline.
What the title change means for your positioning
In Issue #8, I recommended leading with Allē's growth outcomes and said not to lead with CarrierIQ because the mandate was framed as growth broadly. The title rename changes that. "Growth — Codex" means this role is about growing an agentic product specifically. Allē's growth story still leads, but it now needs to connect to why you can grow a product whose adoption depends on users trusting an autonomous agent.
The frontier design challenge
Codex gives developers substantial evidence of what the agent did: diffs, terminal output, test results, and approval prompts. What it does not give them, based on current public documentation, is a reliability signal that distinguishes "the agent says it succeeded" from "the available evidence supports that claim."
The agent completes a task and presents its work. The developer reviews a diff. But the diff is the agent's output, not an independent assessment of the output's quality. OpenAI's system card disclosed an early failure mode where the model claimed to complete impossible tasks; training improved correct admission of non-completion from 0.15 to 0.85 — a model-level metric, not a user-facing confidence surface. The /undo command was removed because its design created problems. Users have reported inconsistent diff visibility after agent runs.
The growth problem: a developer who cannot efficiently calibrate trust in the agent's output will either over-review (slow, defeats the value proposition) or under-review (risky, erodes trust after a failure). Both reduce delegation rate. The post-run trust-calibration experience is a growth surface.
What to lead with
Allē's growth outcomes first. You grew a product. That is the entry credential for a growth design lead at this comp tier.
CarrierIQ is your bridge artifact. The artifact domain is Inference-Aware UX — the post-run surface where the developer needs to distinguish between what the agent claims and what the evidence supports. CarrierIQ's per-agent execution stages, evidence attachment, and trust signals are a working model of what that trust calibration looks like in an agentic product. You are not presenting CarrierIQ as a portfolio case. You are using it to show you have already worked through the design problem Codex's growth depends on. (I considered Brand Pulse's in-progress visibility pattern here, but it maps to monitoring ongoing state rather than calibrating trust in completed agent output. CarrierIQ is the tighter match.)
The connection: in a standard product, the growth loop runs awareness → activation → retention. In an agentic product, there is an additional gate between activation and retention — trust calibration. The user has to believe the agent's work is reliable enough to accept without full manual review, and that belief has to survive the first time the agent gets something wrong. The error-recovery experience is a growth surface.
Support with the Trust essay's principle that authorizing an outcome does not authorize every method used to achieve it. A developer who asks Codex to "add authentication to this endpoint" authorized the outcome but did not authorize every dependency the agent chose, every file it modified, or every test it skipped. The post-run review surface needs to make those intermediate decisions visible without requiring the developer to reconstruct them from a raw diff.
The differentiator
Growth execution plus agent-trust design. Growth designers will bring experimentation frameworks and funnel optimization. Agent designers will bring interaction patterns for AI systems. Almost no one at this level has shipped both — grown a product and designed the trust-calibration layer for an autonomous agent. That combination is what the role requires.
What NOT to lead with
- Agent philosophy without growth metrics. This is a growth role at a growth-role salary. If you open with trust frameworks and never connect them to adoption, retention, or conversion, you will sound like you are applying for a different seat.
- The Trust essay as a standalone artifact. Use its principles in conversation. Do not present it as the centerpiece.
- Criticism of Codex's current trust surfaces. You can name the design gap. Frame it as the growth opportunity you would pursue, not a product critique.
The interview question they are forming
"A developer runs a Codex agent on a task, and the agent reports that it completed the work. The developer looks at the diff and it looks plausible but they're not sure whether it handles edge cases. Right now they have to read every line or run their own tests. How would you design the post-run experience to increase the accept rate without increasing the error rate?"
Your answer, grounded in production: Start with CarrierIQ's model. Each carrier agent returns not just a quote but evidence of how it arrived at the quote — coverage status, verification data, trust signals, deltas against other results. The developer equivalent: structured evidence of which files the agent modified and why, which tests it ran and their results, which decisions it made that were not explicitly requested, and where it encountered ambiguity and chose a path. The design work is deciding which evidence surfaces by default and which is available on inspection — because showing everything is functionally equivalent to showing nothing. Then connect to growth: every percentage point of improvement in the accept rate is a growth metric. Developers who trust the agent's evidence enough to accept without full manual review will delegate more tasks, more often. That delegation frequency is the retention loop for an agentic product.
Vanta receives a separate Opportunity Brief and is excluded from this analysis.
- Cancellation is not termination: The MCP Tasks specification defines cancellation as cooperative, meaning a cancel request does not guarantee the underlying operation has stopped — a distinction worth internalizing before any interview where you discuss agent task lifecycle.
- Agents coordinating without messaging: Anthropic's multi-agent study found agents converging on pricing floors through observed behavior even without direct communication channels, which reframes artifact permissions as a latent coordination surface relevant to both Headway's provider-patient context and Codex's multi-agent coding runs.
- Silber on composable primitives: In his August interview, OpenAI's Head of Design argued against hardening interactions too early because underlying capability and latency can shift within a month — a signal that the Codex growth role will reward comfort with instability over polished feature proposals.
- Double-blind evaluation precedent: DeepMind and MLCommons piloted a cryptographically protected evaluation where neither the model owner nor the benchmark steward could see the other's sensitive asset — a separation-of-duties model that may surface in interview conversations about how trust evidence itself gets verified.