Since taking on a TPM role at Amazon about 18 months ago, some friends have asked: what does TPM mean? “What is it you do exactly?”

Sometimes it’s really hard to explain, because the TPM role at Amazon is unique. It’s born out of necessity due to the unique organizational structure at Amazon. Our development teams are small, mostly independent, and have an incredible amount of flexibility to choose their own priorities. And due to the scale we operate at, it’s near-impossible for just one or two teams to deliver a major change. It takes the coordinated effort of 5, 10, 20, 50 (or sometimes even more) separate teams to deliver meaningful programs that significantly impact the bottom line. And the coordination of those pieces is a TPM’s ultimate responsiblity. They may not have to do every single thing; but they are the ultimate owner of the solution that is delivered. To succeed, a good TPM needs to be good at multiple skills: an understanding of software development and system design, product design awareness, project management, communication, business analysis, quality assessment, time management, a knack for key metrics, an appetite for conflict resolution and simplicity… etc. etc. They are the glue that holds everything together and fills any gaps needed to get to the goal. On any given day they could be playing 4-5 different roles.

Due to the shape-shifting nature of the role, at first I found it difficult to define my success criteria, my “value-add”. It only became crystal clear in week 3 when I heard this offhand exchange in a leadership meeting:

“Yeah, that effort is not going well at all. Someone needs to TPM that ^&*%.”

Ah! Gotcha - so “to TPM something” = “make sure it gets done right.”

A good TPM, above all, thinks like a business owner. In the true spirit of Extreme Ownership, they make it their personal responsibility to ensure the program succeeds. This can include any of these things and more: 1) defining and measuring success, 2) getting the required team together, 3) ensuring requirements are complete and accurate, 4) ruthlessly prioritizing to ensure only the highest priority features are in the WIP, 5) keeping development on track, 6) ensuring the right people are communicating, 7) running effective status meetings, 8) communicating accurate status out to executives (including escalating or asking for help when needed), 9) helping refine the QA test plan, 10) launch and rollout planning, 11) communicating with the customer, 12) gathering feedback from the customer, 13) documenting and sharing key pieces of information and 14) iterating fast (because speed matters in business).

TPMs thrive on information. Like Mentats in the sci-fi novel Dune, they function best when they have a stream of high-quality information at their fingertips. For me, the saying “Context is worth 80 IQ points” was true. Knowing the business domain, the key players, current technical intricacies, the dependencies, the risks etc. makes your life so much easier when you are creating change. Learning all of this is priority #1 for a new TPM.

Once you’re past the ramp-up phase, the role entails a lot of context-shifting and juggling priorities constantly. There’s always a risk of getting lost in the weeds, of feeling like you’re making progress while you’re just stuck in a loop. A good TPM will always balance delegation (ensuring the work gets done) and diving deep (being part of the “solutioning”). Strong judgment and good communication mechanisms are key. An effective TPM will set up high-efficiency, high-impact mechanisms to make progress; for instance, making sure decisions that can be made in a 1-hour meeting don’t dither for 2 weeks. Accountability to an outside group (e.g. a leadership steering committee) with frequent check-ins always helps. TPMs don’t shy away from rigorous questioning; they welcome it as a way to test if their planning is robust.

There is also the risk of burnout: a busy TPM can unwittingly take on too much and simply get overwhelmed. I found myself learning to curb my natural inclination to say “yes” to requests for help. To modify Craig Ferguson’s “3 things”: 1) Does this thing need to be done? 2) Does it need to be done by me? 3) Does it need to be done by me right now?

Finally, a good TPM will take the long view of things. And key to that is keeping themselves energized, motivated, and constantly learning new skills. To re-energize myself frequently and continue to improve, I found myself leaning heavily on certain books. Books that, if I were to randomly open a page and start reading, immediately gets my wheels turning on new ways to solve the problems of the day. Here are my top 5 go-tos:

  1. Scott Berkun: Making Things Happen (the mastery of project management
  2. Jerry Madden and Rod Stewart’s 100 Rules for NASA Project Managers
  3. (the ultimate:) Peter Drucker’s Managing Oneself
  4. Tom Peters: Pursuing the perfect project manager
  5. Scott Berkun: The Art of Project management

Here are some excerpts I love revisiting from time to time:

Handling Pressure: Success in a project requires change. New projects intend to change the state of the world. Maintaining the status quo won’t work. The underlying pressure on the PM is to not just sit there - it is to make things better. There is always a new way to think, a new thing to learn and apply, or a new process to make things more fun and more effective. Good managers are leaders. Good leaders are excellent managers. You need some of both in order to be effective. A good PM does not shy away from the “leadership moments” - where the project needs someone to take decisive action (instead retreating to tracking the movement of others). Pressure-adverse PMs fade into the periphery and add little value.

NASA Rule 5: Vicious, despicable, or thoroughly disliked persons, gentlemen, and ladies can be project managers. Lost souls, procrastinators, and wishy-washies cannot.

The process is not the goal. Unsure of what to do, or afraid to do what most needs to be done, some PMs resort to occupying their time with secondary work - quantifying what doesn’t need to be, etc. At some point they believe the process becomes the goal. To minimize the possibility of confusing process with goals, good project managers resist defining strict boundaries around the kind of work they are willing or not willing to do. Adherence to checklists, “the process” or well-defined roles can help achieve the goal but can never guarantee an outcome. In reality, there are always just three things: a goal, a pile of work, and a bunch of people. If you spend more time with your checklists and processes than with your team, that’s a huge red flag. Just because a book or executive or “history” says to do something, doesn’t mean it applies today to your situation.

NASA Rule 28: People who monitor work and don’t help get it done never seem to know exactly what is going on (being involved is the key to excellence).

Scale yourself. Focus. Measure. Your job is to deliver an outcome. At all times, know which work you’re doing that isn’t contributing, that perhaps someone else could be doing, or that maybe can be postponed to later. Say no to the thankless work. Know the price you are paying by deviating (i.e. what you could be doing instead.) The less of this work you can do, the more effective you will be. Decide. Be quick about it. Speed matters. Don’t spend 2-3 meetings on the same topic. Do your due diligence. Some people think “calling a meeting” is the solution to the problem. Well, only sometimes. Most such meetings are like organizing a buffet where no one in the group thought to bring any food. What will be your outcome? Assign owners - specific people who need to “own” the solution. Rely on their smarts and allow them the freedom to think for themslves.

Get involved at the right levels. The ambiguity of the PM role can be a cause for insecurity. You know you’re not the same kind of contributor as a coder - you’re not directly on the production line. Your value isn’t directly measurable. That insecurity may drive you to get over-involved and micro-managey. Know that your value comes from being an amplifier, a value-multiplier for others. It takes confidence, conviction and awareness to be effective and happy as the leader of the team.

NASA Rule 13: A manager who is his own systems engineer or financial manager is one who will probably try to do open heart surgery on himself.

Take advantage of your unique perspective and create unique value. PMs attend more meetings, have more 1:1s with the teams, see things from multiple perspectives than anyone else on the project. You have more ability than anyone else to nudge the ship in the right direction at the right time. Project schedules slip slowly and in little chunks - and it takes those thousand corrective nudges over time to keep it going. Timely injection of the correct information is what makes mediocre teams great - and a great PM will make it their business to know all sorts of useful things about the state of the project (and the state of the outer world.) The actions and decisions PMs make should have clear positive impacts on the team and the end goal - over the weeks and months, the benefits to outcomes, vibe and energy will become drastically clear; but the work is done one meeting at a time.

So, if the PM is happy, committed to, focused on and capable of success, the odds increase that everyone else will behave in the same way. Managers have a position of leverage. This doesn’t mean having a hero complex - it means being genuinely interested in the success of your peers’ reports and the project goal.