Imperatives: The Cross-Team Must-Do List
A short force-ranked list every team must absorb — defined by what it excludes.
- Difficulty
- Easy
- Time to result
- ~weeks to results
- Steps
- 5
- Confidence
- 89%
Rippling's most recent planning innovation, per Henrickson: a small force-ranked list of 'imperatives' — things that everybody across the entire product and engineering org must do — that each team then factors into its own priorities. The list can be sourced bottom-up or top-down. Its power comes from the drawn line: what is on it matters less than what is deliberately left off.
Origin
Jeremy Henrickson names this as his most impactful recent change at Rippling, introduced as the company hit the scale where cross-team simultaneous efforts (globalization, large platform improvements, enterprise-readiness) multiplied faster than any team could absorb them.
Core principles
- 01In a world where you could do hundreds of things at once, focus comes from force-ranking and drawing a line.
- 02What's important about the list is the things that are not on it.
- 03Imperatives can originate bottom-up or top-down — provenance doesn't matter, the cross-team obligation does.
- 04Imperatives don't replace team priorities; teams still build their own, and factor the imperatives in.
- 05Roughly ten is a lot — the count depends on the granularity you choose to describe them at.
- 06The need for imperatives is a natural stage in a company's evolution, arriving when cross-team simultaneous work becomes structural.
- 07This complements, rather than substitutes for, deep product thinking — it is 'just enough process to create a frame.'
How to run it
- 1
Gather candidates from both directions
Collect the things that plausibly require everybody across product and engineering to act — sourced bottom-up from teams and top-down from leadership. At scale, cross-team simultaneous needs (globalization, platform improvements, enterprise requirements) generate many of these naturally.
- 2
Force-rank the whole list
Rank the candidates against each other. Force-ranking is what makes the next step possible; an unranked list cannot be cut credibly.
Watch out A tie is a refusal to prioritize. Force the ordering.
- 3
Draw the line
Cut the list. Declare explicitly: these, and only these, are the things everyone has to do. Be equally explicit about what fell below the line — the exclusions are the product of the exercise.
Pro tip Around ten is already a lot; the right count depends on the granularity you're describing them at.
Watch out A leader who cannot say clearly what all the priorities are NOT has not created focus. Plausible-sounding non-priorities are the primary distraction from the core mission.
- 4
Hand the list down as an input, not a replacement
Publish the imperatives as the priorities for the next quarter or six months for everybody. Each team still builds its own priorities — but must factor the imperatives in.
Pro tip Keeping team-level planning autonomous preserves the small-team-with-clear-mission structure that produces velocity in the first place.
Watch out If imperatives become the team's entire roadmap, you have recentralized planning and lost the pod model.
- 5
Wire it to the one unified process you keep
Attach imperatives to the quarterly planning cycle — the one place Henrickson insists on unification (along with everything living in Jira, so you can rationalize about what is actually getting done). Do not add more process around it.
Pro tip Beyond quarterly planning and a shared tracker, let each team choose its own process — scrum, kanban, or none. The right amount of process depends on the team's lifecycle stage.
Watch out Process as a substitute for deep product thinking is the failure mode. Categorizing everything perfectly in Jira does not decide what is important to build.
In the wild
As Rippling scaled, it hit a stage where globalization, large platform improvements, and enterprise requirements all demanded simultaneous cross-team work. Rather than letting each initiative negotiate with each team, Henrickson introduced a force-ranked list of roughly ten imperatives that every product and engineering team must factor into their own quarterly priorities.
→ Henrickson names this as the relatively minor change with the largest impact on the team's ability to execute — creating substantially more focus and clarity than the org had before.
Common mistakes
Publishing a list without publishing the exclusions
The value of the imperatives is the line, not the items. Without an explicit 'these are not priorities,' every plausible-sounding initiative still competes for attention and the list adds work rather than focus.
Letting imperatives become the roadmap
Imperatives are an input to each team's own priorities, not a substitute for them. Turning them into the whole plan recentralizes planning and destroys the autonomy that makes small teams fast.
Adding process instead of making the call
Henrickson's warning: teams at scale start believing that if only they categorized everything correctly in Jira, good prioritization would emerge. It won't. You still have to decide what is important to build.
Is it for you?
Best for
Product/engineering leaders at a company that has grown past the point where a handful of cross-cutting initiatives (internationalization, platform migration, enterprise-readiness) can be coordinated informally.
Not ideal for
Small single-team companies where the entire roadmap is already the shared priority list, or orgs whose real problem is lack of deep product thinking rather than lack of cross-team focus.
From the transcript
“the kind of introduction of what I'm calling imperatives these things that whether they come bottom up or top down are things that like everybody…”
“what's important about that list is the things that are not on it”
“so imperatives are essentially like here's the priorities for the next say quarter six months here the these here are the priorities for everybody”
“so I like to have just enough process to create a frame right so that the right decisions can happen and like no more”
From the episode
Moving fast and navigating uncertainty
Jeremy Henrickson (Rippling, Coinbase)