How to Become a TPM

Posted byYevPosted inCareer Advice, Project Management, Technical Program ManagementTags:, , , , , ,
concentrated coworkers having meeting at table
Photo by Anna Shvets on Pexels.com

I am often asked how did I become a TPM or what can I do to become a TPM?

I have to admit it is not an easy question. Program Management is different than many other information technology fields in that it doesn’t really have a traditional path to it. You can go to school to learn the fundamentals of software development or practice on your own and gain some level of proficiency, while doing that for the field of Project or Program Management is a bit more ambiguous.

It is a profession that is almost entirely reliant on experience, rather than sheer knowledge gained from studying and practicing a set of skills. In a way it’s similar to asking a coach of a sports team, how do I become a coach?

I thought about this question for a long time and realized there is a path and it doesn’t have to be so ambiguous. This amazing career choice can be accessible to a lot of great people who would have a great opportunity to succeed.

I put together several steps that I would advice any aspiring Technical Program Managers to take.

Step 1. Decide why you want to be a TPM or a Program Manager?

Spend some time understanding what Technical Program Managers do and ask yourself why you want pursue this field. Will you be really happy doing it.

I was surprised to find out that some people I talked to answered that it was easier than being an engineer. You work less and make an excellent salary. I also heard someone say that if you have a good engineering team, you would excel in your career by simply tagging along.

I am sorry if I disappoint some of you, but most of the above is completely false.

Program Management is a leadership position, which carries a very high level of ownership. This means the work of a program manager is never done. What is the right execution strategy? Will the budget be approved? Do we have enough data to make right decisions and choose the right priorities? How can we achieve alignment with our stakeholders? How can we set the right expectations? How can we make sure we have a high performing team, who are able to resolve internal conflicts without imploding? Because of these heavy responsibility, Program Managers are often working more hours than you may expect.

Also good high performing engineering teams are not created by sheer luck. It is very often great TPMs working behind the scenes, who facilitate this exceptional dynamic and performance by creating synergy, setting the programs’ frameworks, rules of engagement, rhythm, unblocking dependencies, managing communication, protecting the team from political pressure and changing priorities.

So who are TPMs and what do they do?

When you think of any endeavor we can explain it by thinking of it in terms of three fundamental questions. What are we doing? Why are we doing it? and How we are going to do it?

I can depend on where you work, but for the most part by the time TPMs get involved, the “What” or the problem statement is at least partially defined. The Product Managers often take the lead on defining the problem to be solved, but the TPMs also have influence in this part of the program.

Why are do doing this? Here again TPMs play a big part is defining the vision for the program and it business objectives. Making sure there is a strong alignment between the program’s deliverables and what the business needs. This is often done in collaboration with PMs (Product Managers)

How are we going to get it done? Here is where TPMs truly take the steering wheel and drive. TPMs own implementation or execution of the program. This includes all of the details, including budget, scheduling, communication, stakeholder management, dependencies, risks and infinite number of changes and unknowns that inevitably arise.

It is ultimately a role that owns getting something from idea to a completion / release or GA. To put things into perspective, let’s assume you have a customer who wants to build their dream home. They got an idea of what they want to build, a blue print they put together with an architect (PM), they got a certain budget and completion date in mind. Now they would get a Project / Program Manager to take on the “headache” of getting their dream home built on time and on budget and keeping them up-to-date on the progress throughout. I use the word “headache” to make a point, what I really meant is the ownership of execution.

Now if you think of all the details you would have to think about while building a house, I can assure you, building a large complex software system is infinitely more complex.

Do you still want to become a Program Manager or a TPM. If yes, let’s move to the next step.

Step 2: Gain Knowledge

Now that you’ve decided you want to pursue a career in Program Management. You need to have some tools in your toolbox.

Here my advice would be different than most. Don’t spend too much time on this step.

Read a 1-2 good practical books to get you started. Below are a couple I would recommend:

What will be even more valuable while you are reading, spend time talking with Program Manager / TMPs in your company or elsewhere. This mentorship will give you infinitely more than any book. Imagine yourself leading a major project step by step, from initiation to completion. How would you kick-off the program, how would you know who your stakeholders are, how would you estimate the budget and schedule. What will you do if the requirements change, how would you influence someone without authority over them, if they are not reporting to you? The answers may be hard to find in a book, but the answers to most of your questions will certainly be in the minds of experienced, battle-tested TPMs. Buy them a cup of coffee or even a sandwich, it will be well worth it.

In my life, these conversations with TPMs I admired forever shaped my thinking about the profession and to this day are a big part of how I lead my programs and teams. I am also happy to be that mentor for you (feel free to book a free intro coaching session with me here or a free mentorship group session)

Obtain Scrum Alliance Certified Scrum Master Certification. This is an excellent certification that will only require taking a single class to obtain. It is extremely useful, since most of the software programs will be managed using agile methodology. It is also a well recognized credential that many employers are looking for. It also shows you have the fundamental tools to get started and that you are serious and willing to invest in your own development.

What about PMP Certification? I have it. I think it’s awesome. I also think it’s very relevant because most programs will rely on the elements you learn while studying for this certification. It is also very well recognized. However, it is a significant time investment, since I would estimate it may take 3-6 months of daily study. It is also something I would recommend for someone who has a Program Management or TPM role and wants to add to their credentials, since this certification does require a level of prior experience to qualify for. If you do have program management experience from leading projects in your professional life, but may not have a formal program or project management title, then I would recommend this certification for the knowledge you would gain the the doors in can potentially open for you.

Step 3: Gain Experience

At the top of this article, we’ve stated the Program Management is a very tricky role that is hard to really get from just learning a set of skills. It requires experience. But how do you get the experience if just about any TPM role requires some level of experience? How do you get your foot in the door?

The best place to start is your current job. This is specially true if you work for a company that uses Program Managers and TPMs. Here are a few things you can do:

  1. In your discussion with your manager mention that you are interested in Program Management is your future career goal and see if your manager is supportive. If so he or she can provide some opportunities to work on programs or project or point you to people or resources that will set you on the right path.
  2. Talk to Program Managers and TPMs in your department or elsewhere in the company. Tell them that you are really interested in the role and ask them how you can help. Do they have any aspects of their programs that you can take on. This is an excellent mentorship opportunity for you as well.
  3. See if there is an opportunity to transition to a Program or TPM track for your current employer. The majority of the Program Managers and TPMs I have talked to, including myself, have started this way. It is by far, the most straight-forward way to make a transition. If at all possible, I would strongly suggest pursuing this route.
  4. If your organization currently does not have Program Managers or TPMs, you can make a case for why a TPM would make a difference and add value. You may even offer to continue performing your current role, while offering to spend your own time managing some of your company’s projects and programs. You can then demonstrate the value you were able to deliver and the feedback from the teams you helped. Then making a case for a full time Program Management or TPM role maybe a lot easier. This will also help in gaining important skills and most importantly experience. If this isn’t feasible, let’s consider other options below.
  5. If the above two steps aren’t an option for you, find volunteering opportunities. Local non-profit organizations, schools, home owners associations are all places that may be in need of your skills and more importantly project / program management. I have worked for a non-profit that provided IT services at no cost for retirement facilities. It was not only an excellent project management experience, but also hugely rewarding on a professional and on a personal level.
  6. Start your own side project. This can actually be a fantastic opportunity. For instance, have you ever wanted to create an app or provide training or consulting service. You can build a team, vision, objectives, roadmap and implement your plan. Measure results, create documentation, etc. This can be a fantastic opportunity to build something, while also sharpening and highlighting your project and program management skills.

Step 4. Prepare to get the Job

  1. Update your resume / Linkedin profile. Emphasize the work you did that was directly relevant to leadership, and achieving results, something you owned from start to finish or the part of the projects you were directly responsible for driving. Where you took the initiatives, made a difference and delivered value. Use the STAR method in your resume also. Situation (problem statement), Task (solution), Action (Work you did), Result measurable impact, value delivered) Here are some great examples (example 1, example 2)
  2. Behavioral / Situational Interview Prep. TPM interviews are not easy. You have to break it into two parts. The behavioral portion – where you have to demonstrate your ability to implement solid program management methodology, leadership, emotional intelligence, and what I think is super important is an ability to communicate clearly and concisely. How do you prepare for something like this? Again, here it’s critical we rely on our trusty STAR method. The interviewers don’t really want to hear you can figure out the answer in theory, they want to make sure you can rely on your prior experience. Again, if this happens to be one of your first roles as a Program Manager or a TPM you may not have a ton of experience to rely on but you can still answer question from a practical stand point if you have done any leadership role on any projects you have been a part of.
    • Here is what you need to do:
      • 1) Write down all of the successful projects (ideally 3-5) you have been a part of. Including information about the project objectives, problem statement, solution design and execution in as much detail as you can, any challenges encountered and how you and the team have overcome those challenges. What were the keys to the project success. What would have done differently if you were asked to lead the same project now.
      • 2) Do the same for project that did not succeed. But this time think about what made those projects to be unsuccessful. Now that you have this information in front of you, when you answer situational or behavioral question you would answer these questions from the perspective of these questions. Think from a mindset of a leader who prioritizes people on their team, while driving business objectives. Someone who is confident, decisive, while being data-driven, strategic and customer-focused. Keep sound program management principles in mind when answering these questions, such making trade-offs between time, quality / features, cost / budget. Also have a good idea about general SDLC principles: Ideation, Gathering Requirements, Design, Implement, Test (unit, integration), Deployment / Release, Maintenance – done incrementally using CI/CD principles.
      • Pro Tip: When answering these questions. Use “I” for things you have done yourself as program or project manger. If you keep using “We” it would indicate to your interviewer that you were a participant rather than a leader who took the initiative and ownership to get he work done. I would rather say “my team” rather than we, when referring to the work that was done by a group of people rather than yourself individually. Let’s look at a few examples:
        • Tell me about a time when you encountered a technical blocker and how you resolve it?
        • Tell the time when there was a blocker caused by a dependency on another team. How did you resolve it?
        • Tell me the time when there was conflict on your team. How did you address it.
        • Tell me the time when you had an engineer who was not performing up to the standard. How did you address that situation.
        • Tell me about the time when your project scope or requirements changed unexpectedly. How did you address it.
        • Tell me the time when you had to communicate the fact that your project will not be delivered on time. How did you do that.
        • Tell me about a time when you had several project and had to make a prioritization decision. How did you go about it.
  3. Interview Prep (System Design) This is arguable the most challenging part, especially for people who are not used to dealing with systems and their design. So how do you prepare for this portion of an interview and keep your sanity. I must say, if you have not had exposure to basic computer science and know in good amount of detail how internet and services offered over the internet work, you would have a hard time preparing. However, if you have decent level of technical knowledge and experience. It is not that impossible. Let’s break it down using a real life examle
    • On this interview you will be asked to design a system that can scale and provide some service accessible to customers. Let’s use an example. You are asked to build a system allows employees in a company to store and retrieve various internal documents.
      • So what is next? Do you start thinking about what kind of database you need to have? It’s too soon. Your problem statement is not clear. Let’s not forget our SDLC before we start designing anything we must gather requirements. This is arguably the most important aspect of the interview as a TPM, since the interviewer represents the user, so it’s in your best interest to demonstrate that you are only interested in building solutions that match your users’ requirements or in other words address their problems. The best way to gather requirements is to ask questions so we can paint the picture of what are customers needs. Let’s try asking a few questions. The requirements can be functional and non-functional. Functional requirements is about what our system will do. In this case allow users to store, search and retrieve their files. The non-functional requirements is more about
        • Q: Approximately, how many users will our system support? A: Let’s assume ~10K users.
        • Q: Approximately how many files would we expect each user to upload? A: ~10 files per day.
        • Q: What would be our estimate on the average number of files we would expect each user to download per day? A: About 100 files per day
        • Q: What is the rough estimate of the storage capacity we want the system to have? A: There are should be capacity to support 100 million files with each file being ~10MB.
        • Q: Are all users located in the same geographic location or are they distributed around the world? A: Distributed around the world?
        • Q: Can we store these data in a 3rd party provider such AWS. A: We want to build our system in-house, but can leverage public cloud data storage solution if we choose to do so.
        • Q: Do we care about being able to access data quickly or is some latency acceptable? A: The users need to have a quick access to data.
        • Q: Do we care about consistency or is some inconsistency OK. A: We want the data to be very consistent.
        • All of these questions give you a really good idea of not only the scale of what we need to build but also some of the very important characteristics. So what have we learned?
        • Q: Are all users located in the same geographic location or are they distributed around the world? A: Distributed around the world?
        • Q: Can we store these data in a 3rd party provider such AWS. A: No we must store the data in-house.
        • Q: Do we care about being able to access data quickly or is some latency acceptable? A: The users need to have a quick access to data
      • All of these questions give you a really good idea of not only the scale of what we need to build but also some of the very important characteristics.
      • Now let’s do some back of the napkin calculations and estimate the amount of resources we would require
        • What is our storage capacity: 100,000,000 (files) x 10MB (file size) = 1Pb
        • What is the bandwidth we need to support: upload 10,000 (users) x 10 MB = 100 GB per 24 hrs or 100 GB / 86400 (seconds) = 1.2 MB / Sec. Download is going to be 10x in our case of 12MB / Sec. We know that we have a ready-heavy system.
        • How much memory do we need? Typically we want to cache 20% of the most frequently used content. In our case 1 BT x .20 = 200 GB.
      • Next thing we can do is think about what type of data we will have and how we may want to store this data in tables.
        • In our case, we would have a files table with file_id as a primary key, another column may be a path to where the file is stored. We would also have a users table containing various user attributes.
      • What we have done so far is figured out what system we need to build and the capacity we need. So we are about 50% done. Now let’s design.
      • Let’s start from the back and work our way to the front. The place where our data will ultimately rest is what we refer to as object storage which is really just a place to store our users’ files and associated metadata as objects. AWS S3 is. a great example of this and something we can easily leverage for this purpose.
      • The limitation of object storage is that it’s not very smart it just stores data but doesn’t support much in the way transactions or CRUD operations (create, read, update, delete). For that we need a database. But what kind of database should we use. Let’s look at different types of databases and then select one that is the best match for our requirements.
        • First thing to mention is that databases can be roughly broken into two categories SQL and NoSQL. SQL are more structured, more strictly adhere to to a particular schema and are designed to support complex transactions and operations like joins. SQL databases (i.e MySQL) have ACID attributes. Let’s lookin. abit more detail:
          • Atomicity, Consistency, Isolation, Durability -> Database Transaction Properties
            • This is typical for SQL relational databases storing structured data and having specific schemas capable of managing complex relationships between objects that may require join operations. Normalization and strict consistency are important properties.
            • Atomicity – for operations that involve multiple steps, they should all be completed entirely or the entire operation fails.
              • Bank transfer to another account, the transfer is complete when money is extracted from the source account and fully moved to the destination account. So these two operations are treated a single unit
            • Consistency – Transactions bring database from one valid state to another. Guarantee of data integrity, preventing data corruption.
            • Isolation – Even though some transactions can be executed concurrently, they are processed as though they are were executed serially. Serialized isolation, avoiding conflict between different operations
          • Durability – executed transactions are recorded in non-volatile memory, they they persist even in an event of system failure
        • NoSQL databases, on the other hand, don’t rely on a strict schema, they have less overhead, and can be faster and much easier to deal with when horizontally and sharding.
          • Designed for high frequency reads and writes
          • Lack strong consistency (ACID transactions) but have eventual consistency instead
          • Easy replication and horizontal scalability
          • Not ideal for maintaining complex relationships and join operations.
          • Not normalized – same entities can reside in multiple places
          • Examples MongoDB, Redis, wide-column databases (Cassandra, HBase)
      • So what database should we choose? In our case, because strict consistency and ACID are most important than just availability we may prefer SQL database such as MySQL. Plus supporting complex queries that include joins is a good added bonus. You may ask why can’t I have instant availability and strict consistency at the same time. For the answer to this question let’s refer to CAP theorem (apparently you can’t have your cake and eat it too):
        • Consistency, Availability, Partition Tolerance
          • Consistency: Every read receives the most recent write or an error
          • Availability: Every request receives a (non-error) response, without the guarantee that it contains the most recent write
          • Partition tolerance: The system continues to operate despite an arbitrary number of messages being dropped (or delayed) by the network between nodes
        • During the network failure we have to choose between Availability and Consistency. Just as we’ve discussed in the context of eventual vs strict consistency. Choosing eventual consistency means the user will get a response to their request (availability) but with potentially outdated information. Choosing strict consistency means the user may not get a response but when the system is unlocked the response is guaranteed to contain up-to-date information.
        • When a network partition failure happens should we decide to cancel the operation and thus decrease the availability but ensure consistency or proceed with the operation and thus provide availability, while risking to provide inconsistent data, our choice will depend on the application.

Published by Yev

Happy to meet you all. I am a Technical Program Manager who is passionate about learning, teaching and mentoring.

Leave a Reply

%d bloggers like this: