What
I usually don't enjoy having prescriptive definitions of who does what. However I have had successes in the past in having a sensible default. A RACI template (Responsible, Accountable, Consulted and Informed) has always been a good start for me here.
I wouldn't say this should be set in stone but more of a guideline over how Engineering Managers, Product Managers & Technical Leads should collaborate.
By having this document as a guiding light, when working together on cross functional tasks you can consult this list to have a vague understanding of who should be taking the lead and who should be weighing in on a particular topic.
You should also revisit this everytime someone new comes into the equation, you may want to tweak these depending on the particular skillsets of that contributor.
Finally, keeping the remit broad is important, if it's too specific you may find yourself being in a bit of analysis paralysis over who should be doing the work. At the end of the day it's a team effort.
How
Some of these may seem like simple answers, but there is nuance here and you can and probably will, find interesting talking points on where these responsibilities overlap somewhat. One thing I would stress however is there should, ideally, only ever be one member accountable, remember, accountable = final decision-maker or person who ensures progress
Equally, this is a living document, not set in stone.
(I've purposely not given detail here, it should be an alignment together)
| Area | Product Manager | Engineering Manager | Tech Lead (Staff Engineer) |
|---|---|---|---|
| Team mission | i.e. R | i.e. A | i.e. C/I |
| Drive product roadmap | |||
| Manage roadmap velocity | |||
| Drive creation of RFCs | |||
| Drive development of product specifications | |||
| Balance long term technical strategy | |||
| Ensure prioritisation of stability and performance | |||
| Manage technical debt | |||
| Drive OKR progress | |||
| Hold team accountable to results | |||
| Hold team accountable to delivery | |||
| Ensure work is technically sound | |||
| Ensure work is balanced | |||
| Ensure work is broke down for engineering readiness | |||
| Manage Ceremonies | |||
| Manage engineering metrics | |||
| Launch Readiness | |||
| Mid OKR Check-ins | |||
| Triage incoming bugs | |||
| Address engineering hiring needs and advocate for them | |||
| Facilitate engineering team management in/out/sideways | |||
| Ensure team has sufficient growth opportunities | |||
| Foster psychological safety and team health | |||
| Ensure code quality is at a high standard |
What's next
Sometimes the activity is the impact here, creating a space for a discussion where people feel others should be more or less prominent while working together. You can use this as a fallback to come to during retrospectives and ensure everyone feels like they held up their end of the bargain when looking at previous works and iterating from there.
Luke Curtis
Engineering Leader with over 10 years of experience in building and leading high-performing teams. Passionate about transforming organizations through technical excellence and empowered engineering cultures.