Accountability For Product Engineering Teams

How should we hold Product Engineering teams accountable when different kinds of work require completely different ways of working? In this episode, James explores why accountability needs to match the work being done, rather than being applied uniformly to an engineering team. For well-understood, roadmap-driven work, success might mean delivering an agreed scope by an agreed date. But when a team is working towards an outcome — improving adoption, reducing churn or increasing system performance — measuring them by features shipped or delivery velocity can actively work against the learning required to achieve that outcome. James covers: Why accountability is essential for both teams and the organisations investing in them The difference between Roadmap-Driven Engineering and Outcome-Driven Engineering accountability Why delivery metrics can be harmful when applied to outcome-driven work How technical initiatives such as improving API performance can require experimentation and learning A real-world example of one team simultaneously handling predictable document-generation work and uncertain product-adoption work Why accountability models should be attached to pieces of work, not teams Why an unsuccessful result should usually lead to learning and improvement rather than blame How regular, predictable reviews give teams clarity about what they will actually be judged on The central idea: you cannot ask a team to optimise for an outcome and then hold them accountable for output. Different work requires different definitions of success — and teams need to know those definitions before the work begins. Find out more about The Product Engineering Podcast at doproductengineering.com. Feedback or questions? Email [email protected].