The Technical Program Manager (TPMs) is newer to our industry. You don?t read about it this in many agile teams yet many larger organisations have this role. In this interview, you?ll learn more about why the role exists, what some of the common focuses are and learn more about one of N26’s Technical Program Managers.
Patrick: Hi Meysam. Thanks for taking the time out of your busy day. Would you please tell us a bit about yourself?
Meysam: Of course! I?m Meysam. I?ve been with N26 for almost a year now. My background is in software engineering and I moved into product and program management. Most recently in my career I?ve been working on mostly technical programs.
Meysam (Technical Program Manager at N26)
Patrick: You?re in this role, ?Technical Program Manager?. How do you describe this role to other people?
Meysam: This role manages multiple areas at the same time and mostly focused on technical projects. This means the person playing the role should have a technical background but also have great project management skills to manage programs of work. This is a very complex role requiring many interdisciplinary skills. This role coordinates projects across many teams who all have stakes in a technical project. This person requires a technical background because they need to understand and traverse technical dependencies, work very closely with deeply technical people and at the same time manage the roadmap and often non-technical stakeholders to ensure teams are on track.
Patrick: Sounds hard! What is a concrete example of a technical topic that touches many teams?
Meysam: I can think of many different examples. I can talk about some projects we?ve had in the past. One, which all European organisations have had is GDPR. There are strong technical elements to this, although I haven?t managed this topic. We also recently launched into the US and there are many technical infrastructure elements to something that cuts across all product teams. Another more recent example I?ve managed is migration from one environment to another. We?re constantly improving our standards and compliance. This means migrating many microservices from one environment to another. As an example, a recent project required touching 100+ microservices owned by 40?50 developers and tech leads across multiple teams. This makes it very complex.
Patrick: If I understand it right, this is quite different from a typical product manager role because the nature of the initiative is often deeply technical. In the last example, migrating environments has business value but the topic is deeply technical, requiring a good understanding of infrastructure, configuration and technical dependencies. This is also classically different from a product manager who works with a single team because a change in environment touches almost all teams. Where a product manager may have zero external team dependencies or a few, these projects tend to touch many.
Meysam: Yes that?s absolutely correct.
Patrick: What do you think is required to be a good TPM?
Meysam: I believe this is a relatively new role in the market. At least compared to both project and product management. Our industry seems to need this role because you need to have a very strong technical background to understand what you are managing. You need this deep understanding of technical topics, so you can dive into areas where there may be hidden assumptions or complexity to uncover. At the same time, you need someone who can also interpret or translate that complexity into an easy-to-understand format to help leaders and managers make better decisions.
It?s not enough to be a Product Manager or a Technical Product Manager because you need skills to manage multiple teams and stakeholders. At the same time, a Project Manager is not enough because you also need to have a deep understanding of the area you?re managing. I fell into this role because there are many companies with this need and they?re looking for people with this experience.
Patrick: Let?s take a typical week. Who do you interact with and how do you interact with them?
Meysam: It?s a very interesting role because on some weeks, I could be interacting with all parts of the company. That depends on the project and the current need. For the most part though, I?m working with technical people. This means mostly Tech Leads, Principal Engineers, Engineering Managers and Product Managers as well. I talk to engineers on a daily basis to understand what we are delivering, where the risks are and what is still outstanding. A TPM really needs to understand the detail. Of course, I also work with management such as the CTO to be able to outline the next steps or decisions that need to be made in a timely manner. I also work with a team of Technical Delivery Managers who help me with different projects and help me scale.
Patrick: How would you describe the main value add for this role? Why can?t a team, or existing roles take care of this?
Meysam: It?s a good question. I?m sure everyone can take care of some aspect. Let?s take a role of a Product Manager. That person is focused very much on a product area, or a piece of software they are delivering. They often don?t have time to manage technical integrations of that product. A TPM on the other hand doesn?t focus on a single area, but ensures a technical project moves forward. They use their technical background to ensure all dependencies and technical integrations move forward for the project, and not just a single product area. A TPM create a project roadmap based on this understanding and also communicates this to management to show milestones in a much easier to read way. A TPM is able to break down very complex technical projects, abstract technical complexity and can present this information to non-technical stakeholders who need to be informed and made aware of risks and trade-offs as a project progresses.
Patrick: That can be really useful to drive decisions, keeping everyone, including non-technical stakeholders informed on topics that are very technical.
Meysam: Exactly. This is very important for decision making. You have a lot of responsibility because management will use this data to make decisions. There are, of course, many other challenges on how to produce data that?s helpful to drive decisions.
Patrick: I think it?s always useful to compare and contrast roles. How would you describe the difference between a TPM and maybe a Tech Lead and Engineering Manager?
Meysam: Tech Leads are mostly focused on leading technical topics such as design and architectural decisions and enabling and aligning engineers within their team. Engineering Managers support the team, by creating the right environment for teams to deliver what they need and grow. A TPM does not focus on these two areas. Of course, a TPM can provide 1?1 feedback or give ideas on direction but that?s not their strong focus. Their role is really about connecting the dots. Particularly across teams where a technical initiative is not a team?s particular focus. A key responsibility of a TPM is to also drive the roadmap of that project, to see it delivered end-to-end.
Patrick: Let me try to summarise my understanding from you described. A tech lead is driving the technical solution with the team for a particular product area. The engineering manager is working with that team to help grow people, ensure they have the right capacity for planning and to optimise the flow of development. You are working across product teams to coordinate dependencies, keep track of the critical path, to expose risk to the overall roadmap and to drive decisions around priorities that come in conflict with a cross-team wide versus a product team centric set of priorities.
Meysam: That?s also how I would see it.
Patrick: What do you enjoy most about the role?
Meysam: It?s very challenging and I like challenges. Every day presents a new challenge. You?re challenged by management because they?re using the data you generate. They want confidence that the data is high quality to make better decisions. At the same time, you don?t have a team of people ? they belong to product teams. So it?s a challenge to persuade teams to ensure their part of a project is prioritised. It?s a huge challenge to gain the support of all teams to ensure your needs are reflected in their plans. This can often be seen as quite disruptive.
Patrick: It?s also a great way to develop and refine good influencing skills.
Meysam: Absolutely. You need to practice influencing. However I really enjoy this challenge because it helps me grow while I see a project move forward.
Patrick: What is one way that you?ve grown in since you?ve become a TPM?
Meysam: One recent thing is helping me be more precise when I answer questions. It?s not enough to answer with a yes or no. You need back up answers with more information. When you?re talking with technical people details can potentially change a solution or spark an entirely different conversation. When an engineer asks questions, you also need to have the right answers. This has made me focus on how I answer differently, to be able to dive into the topic, drive good answers and it helps me be more precise.
Patrick: I can imagine it?s also then adapting that mode of communication for a different audience such as talking to upper management, non technical stakeholders, down to an engineer. There?s a lot of different types of ways of communicating the same message.
Meysam: Yes it?s really not that easy because you?re dealing with so many people with so many different backgrounds.
Patrick: What do you think are the top three skills needed for the role?
Meysam: The first one is having the expertise in the technical domain. If you don?t understand the complexities of this, you cannot drive conversations, or you will be blind to certain types of risks. It?s very helpful to have a solid background in engineering and perhaps even the domain in which you?re managing the technical project. The second skill is strong communication skills, as we?ve just talked upon. The last one is really strong leadership skills. Remember that you don?t often have a team ? you need to rely on others. So you need to use leadership skills to lead a topic, generate buy in from others and to move the topic forward. You need to lead people to own their own topics because the success of your projects is dependent on how well they implement it.
Patrick: What advice would you give to people considering the TPM role?
Meysam: Apart from requiring the skills mentioned above, people should prepare themselves for this being a very high traffic role. This means having many conversations, often tough conversations with many people across an organisation. It depends on the complexity of the program, the size of the company and structure but the role itself requires a lot of adaptability. My advice for dealing with this is ensuring you have a good work-life balance for coping with this.
Patrick: If someone is already in this role, what advice would you give them?
Meysam: If you?re in this role, you?ll realise it requires a lot of context switching across people, teams and projects. You shouldn?t look at this role like you do as an engineer ? with a binary perspective. It?s rare you have a day with a clear success or failure. You?re there to enable others to drive a topic forward on its milestones. Change your mindset from execution to enablement. Instead of doing, you will need to talk, communicate, lead and enable people from many different perspectives, teams and roles to lead a project to success.
Patrick: Wow. It sounds very much like a strong leadership challenge and opportunity for people. Thank you so much for sharing your insights into this very interesting role.
Interested in joining the bank the world loves to use?
Join us on the journey of building the mobile bank the world loves to use, have a look at our open roles here.
