The PM-Engineering Alignment Operating System
Run product and engineering as one leadership unit with clear ownership and async, iterated reviews.
- Difficulty
- Advanced
- Time to result
- ~months to results
- Steps
- 6
- Confidence
- 93%
Yehoshua's most tactical framework: how a product leader and engineering leader operate as a tightly-aligned pair. It starts with choosing and valuing your engineering partner, establishes crisp divide-and-conquer ownership so no one can play the leaders against each other, and runs a specific cadence of joint OKR reviews (moved async as the org scaled) plus a lean weekly leadership meeting—iterated every quarter like a product.
Origin
Tamar Yehoshua's operating model as CPO at Slack, partnered with co-founder/CTO Cal Henderson.
Core principles
- 01If you have great ideas but can't get them built, you go nowhere—so a good engineering partner is foundational.
- 02Evaluate and value your engineering partner before you join; if it's the wrong one, the org must be willing to change it.
- 03Get explicitly aligned on roles, responsibilities, and where you divide-and-conquer vs. stay joined.
- 04Never let people 'ask Mom, ask Dad'—redirect questions to the owning leader instead of overriding them.
- 05The bottom line is respect and trust that each leader follows up on what they say.
- 06Treat your operating cadence like a product: iterate it every quarter.
How to run it
- 1
Choose and value your engineering partner
Make assessing the quality of your engineering partner part of your evaluation criteria before joining. A great partner (like Cal Henderson) is the single most important enabler; if it's wrong, ensure the org is willing to make a change.
Watch out Great product ideas are worthless if you can't get them built—don't join where the engineering partnership is broken and immovable.
- 2
Define ownership and refuse the end-run
Agree explicitly on who drives what. When someone brings you a question in your partner's domain, ask 'did you talk to [partner]?' rather than answering around them.
Pro tip Say it out loud between the leaders: 'you're going to drive this, I'm going to drive this'—and talk when it's unclear.
Watch out Playing one leader against the other ('they asked Mom, they asked Dad and got different opinions') breaks the organization.
- 3
Run joint, time-limited OKR reviews
Have every team post their OKRs in a per-team channel plus a short Slack video walking the major points, under a strict length limit. The two leaders (plus their two chiefs of staff) watch them all together in a 'marathon' and post follow-up questions in-channel.
Pro tip Move reviews fully async once synchronous reviews balloon—Slack's had grown to ~300+ aggregate hours before they cut over (enabled by Slack Clips).
Watch out Reviewing every team synchronously doesn't scale; watch for the total-hours number getting out of hand.
- 4
Escalate only the reds
Hold a weekly Monday meeting reviewing top OKRs in red/yellow/green. Skip the greens entirely; only talk through the reds and their issues. Follow up with just the 5-10 teams that are high-priority or question-heavy.
Pro tip Keep the Monday meeting as the one required, must-attend forum where owners must speak to their project.
- 5
Hold a lean weekly leadership sync
Run a weekly meeting of the four (product leader, CTO, and both chiefs of staff) to surface any org issues; pull in a specific leader (e.g. QA) only when there's a relevant issue.
Pro tip Use huddles to grab a quick synchronous answer from someone mid-review instead of scheduling more meetings.
Watch out Limit the number of standing meetings with teams—protect against meeting sprawl.
- 6
Iterate the cadence quarterly
Every quarter, ask whether the OKR planning process worked and adjust it, exactly as you'd iterate on a product.
In the wild
Slack's OKR reviews grew until the leaders added up all the review hours across all attendees and got 'some insane number like 300 and something.' They decided it had gotten out of hand and moved reviews async—right after Slack Clips (the video feature) launched, which made the async doc-plus-video format possible.
→ Reviews shifted to async doc + Slack video, reclaiming hundreds of aggregate hours while preserving alignment.
When Yehoshua told Cal or fuzzy (fuzzyeko) that a product needed more mobile engineers to ship, the answer was 'I'm on it, got it'—and things simply got done, with a flag back only if a real problem emerged.
→ High-trust ownership meant escalations resolved with minimal overhead.
Is it for you?
Best for
Product and engineering leaders at a scaling company who need to stay aligned as team count outgrows synchronous reviews
Not ideal for
Tiny early-stage teams where a handful of people already share full context and this cadence would be pure overhead
From the transcript
“if you have great ideas of what to build but you can't get them built then you go nowhere”
“you don't want any of this like people in the organization they ask mom they asked Dad and they got different opinions”
“we had a time limit of how long they were allowed to be”
“Cal and I would do a marathon and we would watch them all together”
“don't talk through the green ones only talk through the red ones”
“we iterate it every quarter just like you iterate on a product”
“we added up all the hours of Oki reviews and all the people in them and it was like some insane number like 300 and…”
From the episode
Lessons in product leadership and AI strategy from Glean, Google, Amazon, and Slack
Tamar Yehoshua (Product at Glean, ex-Google and Slack)