BA 39/52: Push and Pull
This piece is part of an ongoing stream of thought on Systems of Work. Together, these individual pieces form a playbook on how TPMs can leverage their skills to help teams do the work of doing work effectively.
Much of my career has been spent shipping 0 to 1 projects (features, new devices, platforms) at places like Apple, Google, Nike, Blackberry. It has shaped what I believe a great Technical Program Manager (TPM) is and what the role of Technical Program Management is within an engineering organization.
The privilege of being a TPM at an early stage startup has given me a new lens through which to evaluate the role I serve or can serve within an engineering organization.
It has given me new experiences through which to examine the art of technical program management; to look at its more core, basic elements, to break it down to its essence.
Being a TPM, or someone who has knowledge of the study of technical program management, is more than just managing processes and frameworks, schedules and project plans, or implementors of latest fashion agile trend. We are Systems Thinkers who play an important role in ensuring that the engineering organizations within which we report is operating optimally.
How we achieve this feat is either operating in a push or pull mode.
Push is when we leverage our skills, influence, experience and knowledge to help engineering teams to cut through road blocks, grid locks, planning paralysis, lack of focus, crisis issues, or not afraid to take charge so to move the momentum forward when progress seems to have stalled, etc. Imagine literally pushing the engineering team stuck in one place forward.
Example: A deadline looms, progress seems stalled, you see your team flutter and struggling to stay on top of the growing bug and task list. You as the TPM can see what the team is struggling with is focus. But, something is missing. You quickly pull up the entire backlog the team needs to get through before the deadline. You first group the backlog by priority. You sit and review with your Product Manager which tasks matter more than others. You get your EM’s buy-in to start running a daily stand up where we review the prioritized list of tasks, assign owners, and begin to burn through the list. You get the Product Manager to attend and help reset the priority order as you learn more by completing tasks and as the deadline grows ever closer. You have the EM make tactical decisions on the fly and quickly push more strategic decisions up. Evaluate, Identify, Assign, Fix, Repeat.
Pull is when we leverage our systems thinking to find opportunities for improving processes and frameworks, identifying risk and developing strategies to manage them, help engineering leaders to activate strategic initiatives, shape how an organization makes decisions or does work (read: implement more agile 😂 😃), deals with future crisis yet to happen, etc. Imagine grabbing multiple people and pulling them towards a specific direction in unison.
Example: Your team struggles with delivering what they have committed to, delivering quality, and not meeting leadership expectation. You see the frustration in leadership (“if we can just get our estimates to be right and build the right thing”). You see the frustration in the engineers (“If only we don’t commit to so much work, we could spend time doing it right”). You’ve been here before or you have trained through experience to look deeper and find the true root causes/patterns. You see it is actually neither an estimates or scope problem, its one of expectations and communication. You propose a solution: demos & replan. At brief intervals throughout development, you get leadership and engineering teams to commit to freeing up time on their calendars and make themselves available for demos and feedback from engineering teams. You get them both to agree to regular heartbeat milestones to evaluate progress made and replan the scope of the project based on work done, left to be done, and remaining time but most importantly what we have learned from the demos. Plan, Commit, Work, Demo, Evaluate, Repeat.
Your effectiveness as a TPM depends on this basic principle of push and pull. It is less about how well you implemented scrum or how cool your Gantt chart looks, or how deep your spreadsheet can go.
You are always looking at the whole machine, looking for areas of problem or coming risk. In those difficult moments, knowing when to push or pull is what will set you apart as a Great TPM.
Until next time 👋!
-Aadil
How was this week’s newsletter?