📮Monday TPM Field Dispatch 001
Short form thoughts on technical program management, plus curated content for further exploration, delivered Monday morning to your inbox to kickstart your week.
You (my reader) and I (writer of this newsletter) have a straightforward social contract:
As long as I provide useful, insightful, and occasionally novel knowledge, you'll remain subscribed to this newsletter.
With over a decade of experience in TPM roles at Apple, Google, Blackberry, Nike and Humane, I have gained valuable knowledge which I strive to share through my essays and insights.
Crafting valuable content takes intentional preparation and being conscious of its value. I come up with ideas that can't be expanded into a full post or don't offer enough depth, so I get rid of them, anxious that they aren't worth your attention. I still grapple with impostor syndrome.
To uphold our social contract, I'm introducing a new experiment today:
📮 Monday TPM Field Dispatch — Short form thoughts on technical program management, plus curated content for further exploration, delivered Monday morning to your inbox to kickstart your week.
📝 Essays on Technical Program Management — I will still continue to share regular posts with more depth and breadth on different technical program management topics.
Let’s see how this experiment works out.
-Aadil 👋
1️⃣ Framework for Creating Milestones
How do I approach defining milestones in my project plans?
How many milestones is too many?
What should be a milestone?
Where should a milestone go?
What happens if a milestone(s) slips?
Milestones are the anchors and conduits that keep every software and hardware project rolling in the right direction.
Every TPM or Project Leader wrestles with the above questions when putting a plan together. Over time, I have observed that there are two types of milestones:
Convergence milestones — These milestones move the entire program forward and thus operate at that 10,000ft level. Delays in these milestones will impact the overall schedule. Example:
Design Complete
Zero Bugs
Feature / Code Complete
Way point milestones — These marker points reflect progress in certain work streams and are used as guides for engineering team on a certain path. Delays in these milestones may not always impact the overall schedule however they are health indicators of whether certain Convergence milestones are at risk. Example:
Complete Spike on New Auth Proposal
Wireframe UI Available
Stub APIs for Account Auth Ready.
When drafting your milestones, think about what milestones or heartbeats matter for the program and then the individual work streams.
Further Reading: How to manage a milestone, or managing by deliverables
2️⃣ Three Software Architecture Patterns Every TPM Must Know
All knowledge begins with a foundation in the fundamentals and basics.
Technical acumen is what sets apart a general Program Manager from a Technical Program Manager.
If you are either thinking about transitioning or looking to transition into this role and come from a non-technical background then here are three software architecture patterns that will give you the foundation to get started and allow you to explore more difficult topics without feeling overwhelmed:
Model-View-Controller — MVC is a popular software design pattern, especially of web applications, that divides an application into three interconnected parts. The MVC pattern allows for separation of concerns, making it easier to maintain and test an application.
Model: Represents the data and business logic of the application
View: Displays the data to the user
Controller: Handles user input and modifies the model accordingly
Client-Server (C/S) — In a client-server architecture, the application is split between two types of software: the client and the server.
Client: Front-end application that the user interacts with.
Server: Back-end application that processes requests from the client, retrieves data from a database, and sends data back
Service-OrientedArchitecture (SOA) — SOA builds on client-server architecture by breaking the application into small services, each with a specific function that communicates with one another through defined protocols. This allows for greater flexibility and reusability of code.
🤔 Why these three?
MVC is the skeleton that gives you a systems lens into how modern web and mobiles are developed. This will help you build better plans because you understand how a user input on the UI travels through the entire application in a layered cake view, apis, databases, ui frameworks, etc.
C/S and SOA are the foundations upon which cloud computing and pretty much the internet stands on and will help you grasp more complicated topics on backend infrastructure.
Having a foundational understanding of these three patterns will set you on the path to explore more complex software designs and architectures.
Stay curious and keep learning.
Suggested Reading: Pretty much everything from Justin is worth reading. For this note, here is the a logic companion article to give you more exploration ideas in systems architecture and app development.
3️⃣ The Interview Questions I Ask Every Experienced TPM
An experienced TPM's resume is indicative of two things:
they possess the basic project management skills
they have practiced the “tell me about a big project you worked on” questions
Instead of spending much of the interview time focusing on these signals, I spend a better part ascertaining if they have developed a learning mindset.
How? I focus my inquires on when things didn’t go well:
Tell me about a time your project went completely wrong. What did you do in the moment to course correct? What did you learn from the situation? How did you improve yourself and your approach on future projects?
Have you ever faced a situation where you knew something was “wrong” with a process or project but were not able to do anything about it? Why?
Have you ever faced a situation where senior leadership placed you in the wrong direction? What did you do?
I want to know how you rebound from failure. Though it's impressive how far you've come, it's how you climb back up from the tough times that reveals your truest strength:
What did you do when you hit failure?
Were you a team player or went rogue?
How much did you participate in fixing things?
Were you a driver or observer in the solutioning?
How did you communicate this to senior leadership?
Did you take away any learnings to apply in the future?
📅 An intensive 1-day seminar on “Becoming A Great Technical Program Manager”
It took me years and many difficult projects at places like Apple, Google, Nike to understand what it means to be a "Great TPM".
😁 Good news for you, you won't have to spend years. Become a standout TPM in a few hours. Learn the skills and knowledge needed to gain senior leadership's trust to lead large cross-functional programs and take your career to the next level.
Level-up your TPM skills with lessons based on real-world experiences, tried-and-tested frameworks, and successful strategies I picked up from working on complex 0 to 1 programs at Apple, Google, Nike, Blackberry.
Follow the like to my course page on maven here for more details about pricing, content, dates.
How was this week’s newsletter?
If you enjoy and love reading what I write, perhaps you know someone who could also enjoy and love reading these essays and dispatches. Share this with your friends and colleagues and lets grow together. 🙏 ☺️ ❤️
You can suggest topics or questions for me to write about in the future. It could be something you are curious about or maybe something you're struggling with right now.
I love these two buckets of milestones. It's a very nice dividing line.