Feeling overwhelmed by information / TPMs are World Builders / The Right Amount of Slack
Welcome to 📮Monday TPM Field Dispatch 011 - Shortform thoughts on tech program management + curated content for further exploration, delivered every Monday to your inbox to kickstart your week.
1️⃣ Feeling Overwhelmed by Information
Technical Program Managers deal in information.
Change in scope.
That roadblock QA found.
The risk of delay from business contracts.
Design iterating on UX.
Lack of engineering resources during critical time period.
Underestimating the lift to build the solution.
Hardest part of running multiple programs means keeping your information organized in a way that you can remain effective at pushing the program's momentum forward.
Getting Things Done, Bullet Journal, Simple Notetaking, there is no shortage of methodologies for managing information like to do lists.
Challenge is less about methodology and more about value of information.
The approach I took early in my career was to find a methodology to help me remember everything. I would right down everything I came across and painfully organize the information. Result: I would switch methodologies and tools (apps, pen and paper) every few weeks because it would get overwhelming.
The approach I take now is to learn what information I need to let go of instead. This means assessing the value and importance of the information I have acquired in that moment and writing down that will matter later. This is something you must do in the moment and will take time to develop this sixth sense.
Build a system designed for rapid recall and reference of only what matters. That might be GTD for you, or simple notes for someone else, an app or simple paper and pen.
Suggested Reading: https://frantic.im/todo-for-robots/
2️⃣ TPMs are World Builders
The lifecycle of Programs is a long opera punctuated with brief pauses to catch our breath before we plunge into the chaotic madness of building something once more.
This observation was pointed out to me by Shannon Vettes (an extraordinary engineering, product and program leader I deeply deeply admire).
What do TPMs do in between Programs?
Answer: World building.
Organizations, in particular engineering ones, are a microcosm consisting of distinct culture, people, ideals, and objectives.
TPMs bring more than just driving projects and programs. We can help develop these organizations by helping leaders develop effective engineering organizations. How?
How we approach building things?
How we approach decision making?
How we approach recovering from failure?
How we approach thinking in stepping stones?
How we turn product strategy into execution?
How we build a quality first organization?
How do we balance new work against debt?
How do we standardize the our approach to the work of work?
How do we build systems to help our engineers grow?
How do we activate the action of building strategy, vision, roadmaps?
The list can go on...
TPMs should not limit their value to running programs. Our 10,000ft visibility across the entire organization gives us a unique perspective that can help scale up organizations. This is our hidden value oft overlooked by those that hire us TPMs.
3️⃣ The Right Amount of Slack
Slack is the primary way for TPMs to build flexibility into plans to account for uncertainty.
Padding a schedule is the most common approach to adding slack:
Add an extra amount of time to engineering estimates.
Add extra time to the whole project.
My favorite way approach is a focused slack, something we did at Apple and something Fred Brooks suggested in his essay on Engineering Estimates - plan deliberately up front for testing.
At Apple, at the end of each development milestone, we planned for focused convergence time where we tested and converged the feature work we did in the milestone.
The most fatal mistake in software project plans is the absence of "testing time"; it is the place where slack helps to account for the most. Testing is where we find the hidden obstacles.
Remember that software is a system composed of systems. Rarely do we build systems in isolation. Rubber hits the road when feature work is done and testing begins. If we can account for testing up front and development progresses, we reduce surprises later in the project schedule allowing teams to react earlier than later.
How do you add slack to your project plans? Leave your response in the comments.
Suggested Reading: https://martinfowler.com/bliki/Slack.html
How was this week’s newsletter?
P.S.
Cohort 2 of my course Become A Great Technical Program Manager is Open for Enrollment
It took me years and many difficult projects at places like Apple, Google, Nike to understand what it means to be "Great".
😁 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.
More real world examples.
More case studies.
More discussions.
More deep dive into topics like Systems Philosophy, Influence, Shape of Power, approaching complex technology and much more.
Now 2 Days long / 6-8 hours in total (Cohort is scheduled for July 29-30).
Course Fee: $899.
🚨 Spots are limited, don’t miss this chance → 🚀 Click here to enroll today.
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.