The Roles and Responsibilities Contract
Each function writes what it expects of the others, then the group negotiates one shared contract.
- Difficulty
- Moderate
- Time to result
- ~weeks to results
- Steps
- 5
- Confidence
- 95%
Instead of a leader handing down a RACI chart, every leader in the cross-functional group (product, design, engineering, data) writes down what they believe their own role is AND what they expect of each counterpart role. The group then reviews all versions together, argues out the deltas, and arrives at an explicit contract that gets cascaded down through the org. It converts the invisible, assumed division of labour — the thing that silently overloads PMs — into a negotiated artefact you can point at when work falls through the cracks.
Origin
Developed by Nikita Miller across Trello/Atlassian, Dooley, and The Knot Worldwide. She credits Atlassian with a related practice in the form of their public Team Playbooks, and evolves the standard product/design/engineering 'Triad' into a four-way group by adding data science.
Core principles
- 01Ambiguity about the PM role is the default state of the industry; no one company's definition transfers, so it must be re-derived locally.
- 02You write your own role AND your expectations of others — the friction between the two documents is the actual signal.
- 03It is a contract, not a job description: it names duties owed to each other, not just duties owed to the company.
- 04Some responsibilities are deliberately shared (e.g. evangelising the 'why'), and the contract should say so explicitly rather than assigning a single owner.
- 05No one human can absorb everything that lands on a PM; the exercise exists to force redistribution.
- 06Data science belongs inside the group, not as a service desk you negotiate with for resources.
How to run it
- 1
Name the roles in the group
Define the cross-functional unit explicitly. Miller's is product + design + engineering + data science — the classic Triad plus an embedded data person, which she jokes is no longer a triad but 'a chair'. Adjust to your org, but include data.
Pro tip Embed the data scientist or analyst in the team's product area rather than pulling from a central pool — focused people spot patterns; ticket-takers re-learn the product every request.
- 2
Everyone writes their own version, independently
Each leader writes, for themselves and for every counterpart role: expectations as an IC, expectations as a manager / with your team, and expectations toward each other — plus which responsibilities are shared. Do this before any group discussion so nobody anchors on the loudest voice.
Pro tip Use three buckets per role: IC expectations, team/manager expectations, and mutual obligations. Miller keeps templates for this.
- 3
Review together and argue out the deltas
Put the versions side by side. Where your expectation of engineering differs from engineering's self-description, you have found a real gap. Debate it. Expect this to be slow and contentious because people import expectations from previous orgs with different norms.
Pro tip Work the known battlegrounds first: who owns project management now that scrum masters have largely disappeared (Miller's answer: increasingly the engineering manager, not the PM), and who owns velocity of decision-making.
Watch out This is time-intensive and generates a lot of debate. If you schedule it as a 60-minute meeting it will fail.
- 4
Land the contract and cascade it
Converge on one agreed document per role pairing, then push it down through the org so individual teams run the same exercise among themselves rather than inheriting it as a decree.
Pro tip Worked example: on an experiment, the PM writes the product brief, the data scientist writes the experiment brief, everyone contributes inputs — but analysis of the results is explicitly a shared duty of PM and data together.
- 5
Revisit on a cadence, and on every derailment
Aim for a review every three to six months. In practice the trigger is a conflict, a tension, or a dropped ball — something someone thought was theirs, or thought wasn't. Treat that as a signal to run a quick retro against the contract.
Pro tip The most common failure mode surfaced by these retros is not confusion about ownership but execution and velocity — the team isn't moving fast enough. Diagnose which velocity is broken (decision-making vs. shipping) rather than exhorting people to hurry.
Watch out Do not wait for the scheduled review if the roles are already visibly failing; something falling off the rails IS the review trigger.
In the wild
Scrum masters have largely vanished from many companies, but project management didn't vanish with them. Miller found that in many orgs the residue silently landed on PMs, who ended up chasing what's in the sprint, what slipped, and why. Running the contract exercise surfaced the assumption, and the group re-assigned active sprint-goal ownership to engineering managers while PMs stay accountable for tracking.
→ The responsibility was named and moved deliberately rather than defaulting onto the PM, freeing PM time — though Miller notes it remains a point of debate the group has to re-litigate.
When a group lays their independent versions side by side, PMs typically find that everyone has assigned them a huge stack of duties — precisely because nobody agrees what a PM is. Miller uses that moment: the group looks at the pile and concludes no single person could ever do all of it all the time, which forces a conversation about what shared responsibility actually looks like.
→ Responsibilities like 'making sure everyone understands what we're doing and why' get reframed as PM-led but evangelised by designers, engineering managers, and data scientists too.
Common mistakes
The leader writes the chart alone
If one person authors the roles doc, you get compliance, not a contract. The value lives entirely in the mismatch between what you think your job is and what everyone else thinks your job is — and that only surfaces if each person writes independently first.
Treating it as a one-off onboarding artefact
Expectations drift, headcount changes, and the industry's definition of each role keeps moving (PMs more technical, designers more business-oriented, engineers more product-focused). A contract that is never revisited becomes a fossil people ignore the moment tension appears.
Leaving data science outside the group
Keeping data as a centralised team you negotiate with turns data into a permanent blocker — PMs can't get their hands on numbers and have to bargain for resources, and the analysts never build enough product depth to spot patterns.
Is it for you?
Best for
Product leaders inheriting a cross-functional org where the PM role is overloaded and ill-defined, or where work regularly falls between product, design, engineering, and data.
Not ideal for
Very small teams where two or three people do everything, or organisations in the middle of an acute delivery crisis that needs shipping now, not a multi-week alignment exercise.
From the transcript
“do in the form of playbooks but it's basically I as a product leader I'm going to write down what I think the expectations and…”
“you write your own so I as a product manager I write what I think my role is and also what I think what my…”
“what the expectations as an IC what's the expectation kind of as a manager or with your team and then what is it to each…”
“I encourage them to revisit it and it's usually because something's fallen off the rails”
“helping product teams try as product design engineering and data understand their shared roles and responsibilities”
From the episode
Driving alignment and urgency within teams, work-life balance, and the changing PM landscape
Nikita Miller (The Knot, Trello)