| name | cross-functional-alignment-contract |
| description | Establish a high-trust "social contract" between Product, Design, Engineering, and Data to eliminate role ambiguity and execution friction. Trigger this when starting a new team, when responsibilities are falling through the cracks, or when execution velocity slows down due to decision-making bottlenecks. |
Cross-Functional Alignment Contract
The "Cross-Functional Alignment Contract" is a tactical framework to move beyond generic job descriptions and establish specific, negotiated expectations between the four pillars of a product team: Product, Design, Engineering, and Data (The "Quartet" or "Chair"). By having each leader define both their own role and their expectations of others, teams eliminate the "unspoken assumptions" that lead to conflict and project delays.
The Quartet Structure
While many teams use a "Triad," high-performing teams treat Data as a first-class citizen in the leadership core.
- Product: Strategy, "the why," and decision-making velocity.
- Design: User experience and business-oriented design outcomes.
- Engineering: Technical execution, velocity, and sprint management.
- Data: Pattern recognition, experiment briefs, and objective analysis.
The Alignment Process
1. The Individual Draft
Each member of the quartet independently writes down three lists:
- My Role: What I own and am accountable for day-to-day.
- My Counterpart Expectations: What I specifically need from the other three roles to be successful.
- Shared Territory: Tasks where ownership is collective (e.g., evangelizing the vision, analyzing experiment results).
2. The Negotiation Session
Meet in person (ideally) for a 2-4 hour session to review the drafts.
- Identify Gaps: Where does everyone think someone else is owning a task (e.g., "I thought the PM was running the sprint, but the PM thought the EM was doing it")?
- Resolve Overlaps: Where are two people trying to own the same decision, causing friction?
- Define the "Contract": Arrive at a single, agreed-upon document that serves as the "team operating system."
3. The "Optimization" Filter
For every disputed responsibility, ask the core question: "What are we optimizing for?"
- If optimizing for speed, move project management closer to Engineering.
- If optimizing for discovery, move data analysis closer to the PM/Designer.
The Responsibility Template
| Category | Product Ownership | Design Ownership | Engineering Ownership | Data Ownership |
|---|
| Core Accountability | Strategy, Priortization, The "Why" | User Research, UX, Business Goals | System Health, Code Quality, Velocity | Data Integrity, Experiment Accuracy |
| Project Management | High-level roadmap/milestones | Design sprints/handoffs | Sprint goals and ticket breakdown | Tracking implementation |
| Documentation | Product Briefs | Design Specs | Technical Specs | Experiment Briefs |
| Shared Tasks | Evangelizing vision, competitive pulse, post-launch retros, data analysis | | | |
Examples
Example 1: Resolving Sprint Ownership
Context: A team is missing deadlines because the PM is overwhelmed and the EM is waiting for instructions.
Input: The PM lists "Sprint Management" as an EM expectation; the EM lists "Sprint Management" as a PM expectation.
Application: During the negotiation, they realize the team lacks a Scrum Master. They agree to shift "Execution Urgency" and "Ticket Breakdown" entirely to the EM.
Output: The PM focuses on "Decision Velocity" (clearing blockers), while the EM owns the "Cycle Time" and sprint health.
Example 2: Experimentation Workflow
Context: A team launches experiments but waits weeks for results because they "have to ask the data team."
Input: The Data Scientist is added to the Quartet contract.
Application: They agree that the PM writes the Product Brief, but the Data Scientist must co-author the Experiment Brief before a single line of code is written.
Output: Data becomes a proactive partner rather than a reactive blocker, spotting patterns before the feature is even built.
Common Pitfalls
- Setting and Forgetting: This is not a one-time document. Revisit it every 3–6 months or whenever "execution friction" is felt during a retro.
- Treating it like a Job Description: Job descriptions are for HR; Contracts are for the team. Be specific about this team's current needs and the specific individuals' strengths.
- The Outcome/Output Trap: Do not optimize so heavily for "Outcomes" (goals) that you forget to monitor "Output" (velocity). If the team isn't shipping quickly, the contract must be adjusted to increase execution urgency.
- Remote Isolation: Do not attempt to resolve deep "Quartet" conflicts over Slack or asynchronous docs. If a role conflict is gnarly, wave the flag and get the core leaders together in person for 48 hours to "break bread" and hash it out.
