Slack JR358869 — Your Buyer Already Named the Design Problem

Phase 1 — The Moment

Slack posted VP, Product Design, IC/Principal Architect on September 2. Michael Lenahan amplified it two days later and asked for portfolios showing vision and craft, which confirms him as the hiring manager. The posting is ten days old on paper. Labor Day weekend removed three of those days from the middle of week one, so applications only started accumulating in volume around September 8. Assume five business days of candidates ahead of you, not ten.

Role diagnosis: Senior IC architect reporting to Lenahan as CDO, partnering with CPO Jaime DeLanghe and engineering leadership. No direct reports. Two VPs already run the operational ~70-person design org: Will Miner and Miguel Fernandez. This third seat is platform-level design thinking about how agent collaboration works across Slack's whole surface. "Principal Architect" in the title means they want someone who defines the interaction model, not someone who manages designers or owns a component library.

Product trigger: Slack Code launched August 20, 23 days ago. Agents now work alongside people in shared channels with visible progress states, code review surfaces, approval flows, and archived session history. That launch created a design architecture problem at platform scale, and this role exists to own it.

Compensation: Base $310,200–$496,400 SF metro; $257,500–$451,700 nationally. Bonus and equity excluded from the posted range.

Location: Unresolved. Workday lists SF plus "Office Tech-Flexible." Lenahan's post says "San Francisco, CA (or remote)." Those don't agree. Confirm before you invest in deep prep if you're outside SF.

Rubric: Company 8 (AI centrality +2, stage 1, design influence 3, trajectory 2). Role 15 (comp 3, scope 3, craft 3, AI exposure 3, portfolio value 3). The Salesforce equity ceiling holds the company score under the Act threshold, but this is the strongest-scoring role in the current scan, and the buyer is confirmed. That's what you're acting on.

Urgency: Act this weekend.

Phase 2 — Portfolio Mapping

The intelligence-layer frame does not apply here. Slack Code is a collaboration surface where agents participate as teammates, so the design problem is agent-as-coworker interaction: how you structure the moments between a person's stated intent and an agent's delivered work so the team can follow it, redirect it, and sign off on it.

Narrative fit: Lenahan's Slack Code post describes a PM spotting a bug, tagging an agent, watching it pull the conversation in as context, and an engineer inspecting the diff and approving. Then he wrote:

That is the Trust essay's five handoffs, described by the person who decides whether you get an interview. Slack Code ships four of them as product surfaces: Intent-Setting (tagging an agent in channel with context), In-Progress (Working/Idle/Needs attention states, artifacts area), Output Review (line-level diff), Decision Gate (approval before a consequential change). The overlap is close enough that you can mirror his language and land on your own published work without stretching anything.

Lead with: Trust essay plus Carrier IQ. Carrier IQ implements staged review, approval controls, and provenance tracking — the interaction patterns Slack Code ships for code. Support with: TinyFish as technical currency. You shipped an enterprise web agent platform 0 to 1 in three months and worked daily with agent traces, auditability, and mid-task redirection in production. That practitioner depth is what makes the essay credible to someone who just built the product version. Secondary: Alibaba for platform-scale credibility — the $50B+ GMV redesign is relevant because this seat works across Slack's full surface rather than one feature.

Competitive landscape: An AI-native IC from Anthropic or Google (moderate confidence) brings brand pedigree but has almost certainly not published a framework that maps this cleanly onto Slack Code's interaction model, because that work stays internal. An enterprise design architect from Salesforce-internal or Adobe (moderate confidence) knows platform scale and lacks AI-native production depth. An internal promotion out of the 70-person org (speculative) is plausible with two VPs already seated. Your edge against all three: the framework is public, dated, and specific to the product Lenahan shipped three weeks ago.

The objection: His framing covers the full lifecycle, including learning. The Trust essay names Loop Feedback as the fifth handoff, but your published evidence doesn't yet show a complete correction lineage: wrong output, human correction, versioned change, improved later run. Carrier IQ covers review and redirect. The persistent-learning piece is still in development. Issue 10's proof-burden analysis took a stricter line on holding outreach when a key artifact is missing, and I'd revise that here: Issue 10 wasn't working with a confirmed buyer whose public language sits squarely on handoffs two through four, where your evidence is strongest. Build the correction sequence inside the role. You don't need it to earn the conversation.

Phase 3 — The Outreach Package

Warm path: Check mutuals with Lenahan on LinkedIn. Three or more, reference them in the close. None, his Slack Code post is recent and specific enough to carry a cold open on its own.

First Contact Message

Subject: Designing the handoff architecture for agent collaboration

Michael — your Slack Code post named something most agent-product teams haven't articulated yet: the design object isn't the agent's output, it's the shared reasoning that produces it. You described a PM spotting a bug, tagging an agent, watching it use the conversation as context, and an engineer inspecting the diff and approving, all in the same channel.

I mapped that sequence in "Trust Is the New Interface" as five handoffs that determine whether a team treats an agent as a tool they monitor or a collaborator they delegate to: Intent-Setting, In-Progress visibility, Output Review, Decision Gate, Loop Feedback. Slack Code ships the first four as product surfaces. The fifth is where the hard design work still is.

I've built three production agentic systems implementing those handoffs with live APIs and real agents. Most recently as Head of Product at TinyFish, I shipped an enterprise web agent platform from 0 to 1 in three months, working through the auditability and redirection problems Slack Code is now solving at platform scale.

Would 20 minutes work to discuss how the five-handoff framework maps to Slack Code's review and approval architecture?

— Juno

Resume Framing Note

Lead the summary with the Trust essay and Agentic Labs. Lenahan asked for vision plus craft, and the essay is the vision artifact that points directly at his product. Surface Carrier IQ first among the Labs, since staged review, approval controls, and provenance tracking mirror Slack Code's surfaces most closely. Put TinyFish in as most recent role context only: "Head of Product at TinyFish (enterprise web agent platform, Series A) — shipped agentic platform 0 to 1 in 3 months." Alibaba second, for cross-surface platform scale. Subordinate Red Cross, Equinox+, and Allē — they don't map to this mandate and they dilute a résumé built for an architect seat. Use "design architecture" to echo the posting's own language, and avoid "design systems" if it will read as component libraries. Frame the move as building AI-natively from zero and returning to design to define how agent collaboration works at platform scale.

Cover Letter

Slack Code turned the private sequence between a request and its output into shared, inspectable collaboration, and that shift created a design architecture problem: how do you structure the five moments between a person's intent and an agent's delivered work so that watching, redirecting, and approving feel like participation rather than supervision?

I mapped those five handoffs in "Trust Is the New Interface" and built three production systems that implement them. Carrier IQ, an InsurTech quote automation platform in my Agentic Labs portfolio, ships staged progress, provenance tracking, and an explicit approval gate before any binding action. The pattern is the one Slack Code uses for code review: the user follows the work as it develops, inspects the output with full context, and approves before anything consequential lands. The domain is different; the interaction architecture is the same. At Alibaba.com, as Head of Design and Research for North America, I led a platform redesign across $50B+ GMV — the kind of cross-surface work this role requires when the interaction model has to hold across every channel rather than one.

Most recently as Head of Product at TinyFish, I shipped an enterprise web agent platform from 0 to 1 in three months. I worked daily with agent traces, auditability, and mid-task redirection in production — the same problems Slack Code is solving one layer up. I moved to product to build AI-natively from zero. I'm returning to design because defining how agent collaboration works at platform scale is a design architecture problem, and it's the one I want to spend the next several years on.

My portfolio is at junochen.com; the Trust essay and Agentic Labs are the relevant starting points for this role. I'd welcome 20 minutes to discuss how the five-handoff framework maps to Slack Code's review and approval architecture.

Post-Outreach Signals

Salesforce recruiting infrastructure sits behind this, but Lenahan amplified the role personally, so expect faster than typical enterprise response. If he engages the design problem you named instead of sending an acknowledgment, reply inside 24 hours and go deeper on the thread. A recruiter-only response still has value: pursue it and get to Lenahan during the screen. If nothing by day 7, one follow-up hung on a new signal. Two follow-ups maximum, then close the loop internally.

Phase 4 — Window Summary

September 14.