All systems operate on feedback loops.
The more complex the system, the more important the feedback loops.
In Engineering teams or cross-functional projects, how TPMs stay on top of things and ahead of the curve is by building and leveraging feedback loops.
Some examples of feedback loops you can create or leverage in projects and for teams:
end of sprint demos
ending a meeting by recapping action items
launch readiness reviews
This is the whole point of Agile, which everyone seems to miss and gets frustrated when agile fails; not the 2-week sprints, not the kanbans, or scrums or what have you - its all about the feedback loops.
What makes a feedback loop good?
Short - if your loop is a project on its own, you missed the mark.
Ex: if your status reports take a whole week to put together, that information is stale and useless.
Timely - strategically placed loops during project development can help prevent roadblocks or risks from impacting project progress.
Ex: At Apple, development happened across 4 milestones - 6wks of development, 2 wks of convergence - spaced out by 1wk for replanning. That 1wk between milestones allowed the teams to pause, evaluate, and reset expectations based on the progress made thus far. That replanning isn’t helpful if it is placed in the middle of development.
This is also why Waterfall is often hated upon; the opportunity for feedback often comes too late.
Actionable - vague or obtuse feedback loop is as useful as waving a fist at the clouds.
Ex: Retros and Post-Morterms without explicit action items at the end with owners are useless and mostly going through motions of a framework.
The Mother of All Feedback Loops In Engineering
At Apple, we had a very demo heavy culture. Engineers would directly present their latest progress to Craig and his directs on a weekly basis during the development stage of an iOS release for feedback and discussion. They were quick, focused, and wonderful.
Demos are arguable the greatest feedback loop any project can have.
🎯 In your next project, establish a practice of demos with your leadership and give them the opportunity to provide feedback early and often. See if you notice a difference. Stretch Goal: Did leadership prefer that over a written status report? 😁🌝
Now be careful, too many or too few feedback loops mean you cannot course correct or fix a blocker or resolve personnel issues that can impact an engineering teams progress towards achieving an objective.
How will you know you have enough feedback loops? You guessed it - Feedback.
TPMs must always be monitoring, assessing, adjusting, actioning, repeating; Feedback loop.
Until next time. 👋🏽
Ken Kocienda is a legend. I feel it a privilege to be working with him at Humane. His book “Creative Selection” on his time at Apple and working on the original iPhone as well as with Steve Jobs is a must ready for anyone interested in building great products and Apple history in general. He recently had a chat with Daring Fireball’s John Gruber. There is mention of the importance of demos in there. If you have 2.5 hours to spare, have a listen - its freaking great episode.
Feedback on this week’s newsletter: