Wartime and Peacetime TPM
Post # 66 - When do you bring in what kind of a TPM will make a huge difference to your program. Wartime and Peacetime TPMs each bring something different to the game.
Apologies for my absence. 🙇 🙏
For the past two weeks I have been focused on my first cohort course for Technical Program Managers - Becoming a Great TPM. That was one heck of an experience. I will write a more detailed post on that later. If you want to join a future cohort, sign up for the waitlist.
Now back to regular transmission of essay’s on technical program management.
This is a bonus post for all subscribers (paid and free).
There are two types of Technical Program Manager personalities I have had the privilege of working with:
Some that thrived in ambiguous and volatile environments.
Some that did better in structured and well paced environments.
These, Wartime and Peacetime TPMs, bring a different mindset and approach to how they drive and work on large complex programs. Sometimes having the right mindset is better than strictly following a specific agile or project management methodology.
So, how do you know which TPM to bring in when? The answer to this question will require answers to a few other questions.
What is wartime and peacetime environment?
What are the characteristics of a wartime and peacetime program?
What are the wartime and peacetime TPM qualities?
Wartime vs Peacetime Environment
Wartime
0 to 1 Programs - the birth of something new or monumental shift in your company’s product and service offerings.
Make or Break Program - Might be new revenue stream, critical customer, or significant shift in your companies history.
External threat/responding to a shift in the industry - think AI everywhere in everything, think Bard vs ChatGPT, think the iPhone enters the market.
Peacetime
n to 1 Programs - incremental changes, tech debt, improvements.
Experimentation & Enhancements - A/B testing, explorations of logical new technology, evolutionary in nature.
No external threat to the business - imagine Blackberry and Nokia before the iPhone showed up.
The Characteristics of Wartime and Peacetime Program
Wartime programs requires the ideal path to be determined and a singular focus to get that outcome. Success is only one path and must be done now/within this window. Decisions must be pushed to the frontline with only extremely strategic touch points needed from senior leadership. The program demands improvisation and on the fly thinking especially when it comes to process and change management. Status reporting is replaced with regular working code and demos. Requirements from Design and Product is lock in step with engineering by identifying, designing, building and iterating simultaneously. Engineering must rely on existing technologies that have proven track records, high maturity, and established community and support; prioritizing buy over build where possible. Wartime programs can sometimes underestimate or neglect assessing properly risk and tech debt decisions given their singular focus on the outcome.
Peacetime programs allow for more experimentation and multiple avenues for success. Success can mean many paths and teams' can take time to achieve it. You can be more phased with the releases and deliverables. Decisions need to go up and down the organization chart with senior leadership having a large control. The program is run methodically, with precision process, tight change management and control. Status reporting is more bureaucratic, revered, and communicated in a written format. Requirements from Design and Product hand off to engineering in a more sequential format. Engineering can explore various technologies in different maturity states, focus more on build over buy where possible. Peacetime programs often overestimate or dig too deep into assessing risk and tech debt decisions resulting in slower decision making.
Wartime vs Peacetime TPM Qualities
Peacetime TPM knows that proper process leads to winning. Wartime CEO TPM violates process in order to win.
Peacetime TPM always prepares a contingency plan. Wartime TPM knows that sometimes there is only one path to success (roll a hard six).
Peacetime TPM strives for broad based buy in. Wartime TPM bypasses consensus-building focusing on action.
Peacetime TPM strives to tolerate deviations from the plan when coupled with effort and creativity. Wartime TPM is completely intolerant.
Peacetime TPM have the patience to teach people. Wartime TPM works better as an individual contributor.
Peacetime TPM have patience to make change happen. Wartime TPM want change immediately.
Both TPMs bring a different mindset and presence to the product development team. It may seem like Wartime TPMs might sound like assholes but that is not what I want you to see. Wartime TPMs are the ones you rely on to get complex programs over the finish line. Peacetime TPMs are the ones you bring into build long-term organization changes.
Wartime and Peacetime TPM in Action
Wartime TPM might not worry about comprehensive documentation or requirements preferring to working with engineering, product and design to figure out what the next steps and clarifying confusion on the fly.
Peacetime TPM is methodical and working with engineering, product, and design to ensure the appropriate documentation exists to prevent confusion and create artifacts for people to reference and to clarify.
Wartime TPM might not worry about how the work is broken-down, story points or estimates present, proper acceptance criteria etc as long as there is a direct line between desired program outcome and working demos. Wartime TPM is constantly keeping an eye on the desired outcome to reduce delta between current progress and desired outcome on the fly.
Peacetime TPM might worry about the product spec broken down into proper task<>subtask structure, proper process being followed, estimates, story points, and ensure in a data driven way that work is completing. Peacetime TPM is driving the work to a specific written spec and driving a consensus driven correction to the delta between progress and desired outcome.
Wartime TPM is the nervous system of the product development; they might be feel comfortable not knowing every single aspect of the program allowing teams to focus on the work to be done.
Peacetime TPM although operating as the nervous system might feel uncomfortable not knowing all aspects of the program even risking the perception of micromanagement and bureaucratic approach to working with the product development team.
Can a TPM be both?
Many TPMs might only be able to function in their respective environments. However, the really great TPMs can switch between the two modes with comfort often times switching just when the program needs it the most.
Wartime TPMs are ideally suited for Individual Contributor career ladders while Peacetime TPMs are naturally inclined to operate in growing organizations with people management opportunity.
What are some examples of peacetime or wartime programs that come to your mind that you may have been a part of?
Peacetime Programs
Developing the 1st version of the iOS Home App - There was no existential threat to the Apple HomeKit business. This was an evolutionary move that we could take time to perfect.
The first Blackberry flip smartphone - That always felt like a solution without a problem, an exploration or experimentation.
Developing a next generation consent management data privacy platform - Assumption is the company is already in compliance with various privacy legislations. This is an attempt to make things better.
Wartime Programs
Developing the first Google Visual Assistant devices using Android Things platform - The future of the Android Things team depended on us getting this right.
Literally every team at every company working on AI - It is a mix of existential thread, industry shifting as well as potential future revenue streams.
Developing a brand new operating system that will power your strategic response to your competitors (aka QNX powered Blackberry OS)
Fixing the broken iOS Maps experience after initial launch.
Final thoughts
Is Wartime TPM better than a Peacetime TPM?
That is the wrong way to think about it even though I might have lead you to believe that the Wartime TPM sounds more agile while Peacetime more waterfall.
Think about it like a chemical compound.
The effectiveness of your TPM PMO or Organization will depend on having the right mix of both of these style of TPMs. It might even be a case where you start with one and then slowly add the other.
Take a hard look at the program you are trying to run and then bring in the TPM with the right personality and mindset.
What examples might you have of wartime and peacetime programs you might have worked on? What personality traits do you think I missed for Wartime and Peacetime TPMs you might have worked with?
Until next time 👋!
-Aadil
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.
If you want to join the next cohort of my course - “Become a Great TPM” - sign up for the waitlist to receive updates on when enrollment opens up again.
Sometimes its also about 1)a war that breaks out in peacetime and 2)a war that is managed with peace. Any project or work stream is likely to have experienced both. In either scenario, how you manage (or what happens as) the aftermath depends a lot on your relationships and on the air cover that you are provided.