Partnering with Research and Engineering: The Triadic Craft (2026)

The triadic partnership pattern: Cagan's Empowered framing

Marty Cagan's Empowered (Wiley, 2020) codifies the triadic product-design-engineering partnership as the default model for modern tech companies. The mechanics:

• The triad. Product, design, and engineering as functional peers on every major product surface. The PM, the design manager (or senior IC designer), and the engineering manager (or senior IC engineer) operate as a unit. Cross-functional disagreement is resolved through structured decision-forums rather than through hierarchical escalation.
• The companies that operationalize the triad. Stripe (codified in Stripe Press's writing and Larson's An Elegant Puzzle), Figma (the designer-PM-engineer partnership at design-tooling), Airbnb (post-2022 product-led-growth reorg), Linear (small-team triadic culture), and Notion (design-fluent founder triadic culture). Companies with the triad pattern have explicit cross-functional working-agreement documents.
• The companies that don't. Meta and Google operate in a more product-led-with-engineering-strong dynamic where PM dominates the cross-functional voice. Apple operates in a design-strong-with-engineering-craft-deep dynamic where design has unusual voice. The triadic pattern is less prevalent at engineering-tilted FAANG.
• The implication for design managers. A design manager moving between companies needs to recalibrate to the cross-functional dynamic. The triadic-culture design manager who moves to a product-led FAANG often experiences PM as 'too dominant' for the first 6 months; the FAANG-trained design manager who moves to a triadic-culture company often experiences PM as 'too collaborative' for the first 6 months. Both are recalibration challenges, not partnership failures.

Design-research partnership: user-evidence as the shared currency

Design-research partnership runs on shared user-evidence and pre-registered hypotheses. The mechanics drawn from Kim Goodwin's Designing for the Digital Age chapter 25, the Google UX Research culture (Tomer Sharon-era and post-Sharon writing), Don Norman's heritage (Nielsen Norman Group), and the publicly-discussed research-and-design partnership at Airbnb and Stripe:

1. Co-writing the research-and-design plan. The strong pattern: design and research co-write the research-and-design plan before any work begins. The plan answers: what user question are we asking? What design hypotheses are we testing? What evidence would change our minds? What evidence would confirm our direction? The plan is signed by both the design lead and the research lead.
2. Pre-registering hypotheses. Before any user evidence is collected, the team pre-registers what they expect to find and what would constitute a falsifying signal. Pre-registration prevents post-hoc rationalization (the team finds whatever evidence they were going to find regardless of the design direction).
3. Research-shaping-design, not validating-design. The strong pattern: research informs design decisions before they're made. The failure mode: 'we did research after the design' — the research becomes a validation exercise rather than a shaping exercise. The team has typically already committed to the design direction; the research either confirms it (cherry-picked) or is dismissed (if the evidence is contradictory).
4. Shared user-evidence as currency. Cross-functional conversations reference specific user-evidence: 'in the user-research from Q3, three of five participants said X'; 'in the analytics data from the upgrade flow, conversion drops by 40% at step 3.' The strong pattern is conversation-grounded-in-evidence; the weak pattern is conversation-grounded-in-opinion.
5. Different research-org structures. Some companies have research embedded in design teams (Airbnb pre-2020); some have research as a separate function (Google, with the historically large UX Research org); some have research distributed (Stripe, where designers do their own research). The structure shapes the partnership pattern; new design managers should ask about the structure in interview.

Design-engineering partnership: shared design-system foundations

Design-engineering partnership runs on shared design-system foundations and explicit handoff protocols. The mechanics drawn from Goodwin's chapter 25, Cagan's Empowered, the publicly-discussed design-engineering partnerships at Stripe, Figma, and Apple, and the Material Design 3 / Material You evolution as cross-platform worked example:

1. Co-evolving the design system. The strong pattern: design and engineering co-evolve the design system. Design-system engineers and senior IC designers operate as functional peers on the design-system team. The design-system roadmap is jointly owned. The decision about whether a new pattern requires a new component or extends an existing one is made jointly.
2. Explicit handoff protocols. The strong pattern: design-engineering handoffs use Figma's dev-mode or equivalent to make the handoff structured. The designer publishes the handoff with: design tokens used, components referenced, accessibility annotations, motion specifications, edge-case handling, and known constraints. The engineer reviews the handoff with the designer before estimation; estimation conversations surface design refinements.
3. Co-located decision-making. The strong pattern: design and engineering decision-making are co-located in time and space. The triadic team meets weekly; cross-functional decisions are made in those meetings, not in separate design-team meetings followed by separate engineering-team meetings.
4. Failure modes. The 'over-the-wall' handoff: designer ships the design, engineer implements without conversation, design-engineering quality is poor. The 'designer-as-engineering-blocker' pattern: designer iterates indefinitely, engineering can't ship, the team misses commitments. The 'engineering-disregards-design' pattern: engineer implements without consulting the designer, design-system alignment breaks. All three are partnership-failures rather than craft-failures.
5. Apple's craft specificity. Apple's design-engineering partnership is unusually specific about craft choices (motion-curve choices, color-precision, micro-interaction timing). The Apple-distinctive pattern is documented in WWDC design-team session videos and in Bob Baxley's writing on his Apple tenure.

The design-PM partnership: triadic vs. product-led dynamics

The design-PM partnership is the most-variable cross-functional dynamic across companies. Three patterns:

1. Triadic (Stripe, Figma, Airbnb, Linear, Notion). Design and PM operate as functional peers. The PM owns the product strategy and roadmap; the design lead owns the design strategy and design-language direction. Cross-functional disagreement is resolved through written memos and structured decision-forums. The triadic pattern works when both the PM and the design lead have strong design-fluency or strong product-fluency respectively.
2. Product-led with design-strong (Meta, Google). PM dominates the cross-functional voice; design has voice but operates within product-strategy decisions. The pattern works when the PM has strong design respect and the design lead has strong product-fluency. The pattern fails when the PM treats design as decoration or the design lead treats product strategy as PM-territory-only.
3. Design-strong (Apple). Design has unusual voice in product strategy. The pattern works because of the historical Steve Jobs-and-Jony Ive elevation of design and the continued post-Ive distribution of design leadership at Apple. The pattern is unique to Apple at FAANG-tier.

The implication for design managers: the cross-functional dynamic shapes the daily partnership work. New design managers should ask about the dynamic in interview rather than assume their previous company's pattern applies.