What Does 10X Engineering Mean for Technical Program Managers?

Galen Low: Technical program managers aren't typically expected to write code, but these days, neither are software engineers, not by hand anyway. So the question isn't necessarily whether TPMs should be able to code. The question is: What depth of understanding is needed for technical program managers to shift where they add value in a world where the teams around them are using AI to move five, 10, sometimes 50 times faster than they did just a few years ago?

To explore how the role of a technical program manager is evolving in today's software industry, I've brought in a VP of Delivery and Engineering Ops who has led teams of TPMs at organizations like Dell and Google, as well as other fast-paced, high-growth software environments. Together, we're going to be exploring everything from what skills are being demanded of TPMs today to how heads of delivery can champion their team's value when there are changes in leadership.

We'll also be talking about how hiring managers can assess TPM candidates during the recruitment process and what the impact would be if the TPM role were to go the way of the dodo. Hope you enjoy the episode.

Welcome to the Digital Project Manager Podcast—the show that helps delivery leaders work smarter, deliver smoother, and lead their teams with confidence in the age of AI. I'm Galen, and every week we dive into real-world strategies, emerging trends, proven frameworks, and the occasional war story from the project front lines. Whether you're steering massive transformation projects, wrangling AI workflows, or just trying to keep the chaos under control, you're in the right place.

And if you've been liking what you've been hearing from us lately, please consider following us wherever you're finding us and maybe even leaving us a review. All right. Let's get into it.

With me today is Satish Menon, a technical program management and engineering operations leader who has headed up delivery at tech giants like Google and Dell, as well as at software companies like Tenable, Cohesity, and Seismic.

The programs under Satish's remit have ranged from hardware and software launches to cloud infrastructure and data center optimization products, relying on Satish's ability to navigate C-suite decisions, provide organizational leadership, develop and implement operational strategy, transform processes, and advise on product development.

Today, Satish has been helping teams of technical program managers navigate the world of AI-enhanced software engineering and program management while also championing the value that the technical program manager role plays in tech-led organizations.

Satish, thanks so much for joining me today.

Satish Menon: Hey, Galen. Thanks for the opportunity. I'm excited to be here.

Galen Low: Here's the little roadmap that I've set up for us today. First, I just wanted to hit you with a bit of a controversial question that my listeners would love to hear your take on. But then I'd like to use that as a lens to look at three things.

First, I wanted to look at how the role of the technical program manager is being disrupted, especially in the software space. I thought we could talk about how department heads and team leads can defend the value of their technical program managers. And also, I thought we could just dive into what the implications are of role hybridization between software team managers and technical program managers.

How does that sound to you?

Satish Menon: Wonderful. Looking forward to it.

Galen Low: Awesome. Let's dive in. Here's my spicy question to kick us off. Technical program managers say that they don't need to be able to code to deliver value. Meanwhile, many of the tech execs seem to disagree. They say AI means that a software engineering team manager and a technical program manager are now one and the same.

So my question is, who's right? Has AI created the circumstances that make it reasonable for organizations to expect software team managers to also be technical program managers and vice versa?

Satish Menon: You can agree with me that the software engineer's role has gone through a lot of transformation in the recent times, right?

They have gone from writing the code themselves, which was the bottleneck before, to right now using a lot of vibe coding and using AI tools to generate code at 10x, even 100x the speed And then the problem has now shifted to the review cycle, like the PR review cycle, the PR size has gone up. And so in, in the human oversight part of what AI generates in software, that's where the burden has shifted.

So sim- similar to the change that we see in the software engineering workflow and speed and on what software engineers do, there has to be a similar adaptation on the TPM side as well. And so, for example, three to five years ago, there used to be The big load of prior to three to five years ago, there used to be a big load of, you know, this is the plan, but what is the status?

Where are things at? How are the dependencies matching up? What are the risks, and how do we mitigate that? How is QE doing? And i-is, is the quality assurance aspect of our project on track, and is there a risk over there? And monitoring the bugs and the bug reduction and, and monitoring the test coverage and so on and so forth.

So those were the problems, and those were all ha-handled at that point, you know, kind of same manually or semi-manually by the TPMs. Then came four to five years ago where we started transforming that with Jira and Atlassian. All of this, once you set up the plan, the status started bubbling up automatically, and you could just have the TPMs look at those dashboards and assess what's red, what yellow, what-- And then start involving themselves in problem-solving.

So then the role changed from okay, I'm making a plan, but I'm also doing a lot of status collection, reporting and risk reporting and, and facilitating risk mitigations. I'm now observing live dashboards that tell me what the status is, but then as we see reds and yellows, I'm coordinating all of the solution-oriented, you know, problem-solving there.

So that evolved. And then now with AI, there's more opportunities, for example, for TPMs. Example being, if you look at the tools that are in play today you know, you have on the one hand you have Jira, and then you have GitHub where the code is written. Then you have BrowserStack, where all quality and the deployment parts are managed.

And if you, if you can triangulate between these three different tools or other tools at play, then you get more richer dashboards. You have more richer data. You have more richer analysis of risks and issues and so on and so forth. So the TPM role evolves that way, you know. We, we no longer have to manually find out what's red and yellow.

We could use AI to triangulate across multiple tools and the right signals and the right things to look at to figure out where the reds and yellows are much better than we ever did before.

Galen Low: I love that. I really like the framing of the bottleneck shifting, but the fact that they're actually two different bottles.

So on the engineering side, it's like, yes, coders are spending less time manually writing code. They're working with Cursor, they're able to work faster, and that pushes that bottleneck into the review. When you're talking about like a you know, an engineering team manager that means more review for them actually, right?

It's like the bottleneck shifts. Now there's probably more review. There's more code to, you know, be to, to kind of oversee and they deliver value by keeping that, you know, pipeline moving solving problems quickly on the code side. But in other words, that's where they can deliver more value.

There's not this extra capacity to then maybe do some technical program management. On the other side, the other bottle, right, is that, you know, the bottleneck used to be about, you know, gathering information, gath-gathering status updates and now, yeah, w- our role is being disrupted as well. We're, we're using other tools, like you mentioned, Jira, we're using AI, and some of this automation is, is moving us closer to solving the problems, not, you know, having us twiddling our thumbs all day and, you know, suddenly have capacity to be overseeing a software engineering team.

Yeah, I like that framing. Disruption's happening on both, but it doesn't equal this doesn't add up to one pie. These are two separate things.

Satish Menon: There's also another aspect which is like an, a software engineering manager Software engineering director. They can-- they are responsible for de- delivering high quality code that is secure and accessible and has the right performance from their teams with, you know, pretty much good velocity these days.

They're, they're improving that velocity with AI and all of that. But if you expect them to also be responsible for the cross-functional parts of that delivery, which is number one, dependencies from other software teams. Number two, you know, making sure that the test or the QE teams are actually finishing high level of code coverage and test coverage and so on and so forth.

Making sure that the performance scale system integration testing are going on track and, you know, making sure the customers will get the product on time. All of those aspects of looking at the cross-functional aspects, including things like deliverables from the infrastructure team, the branching team, DevOps team, so on and so forth, plus even the field, you know.

What are the field expectations? Who's taking care of their tech docs and who's taking care of the messaging to the field and so on and so forth? There's so many cross-functional aspects. All of that needs to be taken care of by somebody, and I think DPMs with the aid of all these tools can do those much, much more efficiently, much faster, but it needs to be done.

And if you expect software engineering directors and software engineering managers to actually do that, that's a little bit of an extra burden. There's one more aspect. It's, it's important to i- you know, take the analogy of the roadside safety. We have DMV issuing licenses, making sure cars are registered and the traffic rules are well known.

But there's also, you know, highway patrol that is actually issuing tickets and making sure that, you know, people who are truants to the system are penalized through random audits or even systematic audits. So you need both of that for a good system to work, and, and you can't just expect to issue licenses, register every car, teach how people should drive safely, and then expect a good outcome.

You need the checks and balances.

Galen Low: I really like that because I, I, you know, there's so much automation happening in, in, in a lot of different roles right now, especially technical program management, especially in software engineering. And sometimes, you know, I, I hear people talk a lot about, you know, they're, they're automating using these frameworks so that, you know, all of those rules, the highway rules, you know, are all laid out for people and people are just gonna follow them.

And to your point, it's like, no, that's actually not what humans do well. There's always gonna be people who are, you know, running into problems, who are maybe truants like on purpose, who might not understand where the priorities are. And fundamentally, yeah, it needs someone to kind of shepherd the process as well.

Less so than before, but you know, there's still value in that. And I think you raise a really good point about so many puzzle pieces need to come together to deliver a software product, only a portion of that is code quality. And the rest of it is like this cross-functional orchestration to make sure it all comes together when it needs to come together.

And if you're distracted by managing a team of software engineers, and I'm thinking, you know, correct me if I'm wrong, but I'm like, you know, you're doing like one-on-ones with them, you're kind of their career manager, you are auditing code quality, you are helping solve technical problems. And that's important, and if that got in the way of delivery, you know, there's like the priority prioritizing between those two things would be very difficult.

Maybe we can actually sort of like zoom out a bit because, you know, in your background, you've led teams of technical program managers at companies like Dell and at Google, as well as other large software firms, and we're talking about problem-solving in a way. You know, we've been talking about, okay, well, if you are a software team lead, you might be solving technical problems.

And then we were talking about the technical program manager solving problems as well, especially because, you know, a lot of this reporting and the dashboarding that's available to them lets them be more proactive about solving problems. But then there's this like chasm, right? It's like, well, w- what problems can a technical program manager solve without being someone who has a coding background?

So I, I, I wanted to ask you, like what level of technical fluency do you expect from your technical program managers? Or like what are some concepts that every TPM working with software engineers should understand and, and why?

Satish Menon: Wonderful. So that leads me to one point I wanted to bring up elaborating on some of the discussion we had so far prior to this question, and then we'll connect that to this question of yours, right?

So there's one other point which is you can have a software manager or software director really manage the projects that are well-contained within their organization. But when it comes to a bigger deliverable that has dependencies across other teams, you know, then th-that's when the TPM comes in. Not just cross-functional from engineering to product management to design to, you know, the field and go-to-market motion and, and tech docs and so on and so forth, but also the dependencies that exist within the software deliverable itself, that is, that are across teams.

So, so that's one important point, right? So we should never leave this conversation with the understanding that a software manager or software director does not do project management. They do, but they do it for deliverables that are completely contained within their organization. When it comes to cross-functional things, you know, it's much better done with a TPM from a neutral standpoint.

So that's one point. And then when it comes to this question that you had in terms of what level of technical do the TPMs need to be, I mean, I'm in favor of largely using TPM or hiring TPMs who have actually been a coder in the past or a lot of exposure to coding, because what that does is their ability to understand the language of engineers, and then you can win their respect and you can collaborate with them to-- When, when you're collaborating with them, if you don't understand their language, then you lose respect.

And so that's number one. But second thing, you know, you wanna really be an equal partner where they're good at coding, they, they understand. But if you don't understand the lifestyle of the code, for example you know What are check-ins? What is commits? What is PR review? What is PR review cycle? What is the linting and static analysis?

And what is like unit testing versus system testing, integration testing, performance testing, and deployment, and so on and so forth. So what are the nuances of the various variables in a, in a life cycle of coding? You need to understand all of that. If you've done some coding before, then you, you would know that.

But, you know, after five to 10 years of being a good TPM and getting into seniority, seniority of actually handling more complex things, you might get to a stage where coding is a little rough right now, but you haven't really left the college behind in terms of the s- life cycle of, of a code on the coding side of things.

You're very good with the life cycle of things outside of it, which is you know, requirements, coding, testing, you know, piloting, and then eventually getting into those GA and the GA checklist and shipping. So you know this broader thing, but you should also know the life cycle within the coding community and the engineers.

So that's why I prefer that. And second level of technicality they need to be is it, it helps if the TPM is aware of what the product is that they're shipping. I've seen TPMs that are basically just able to overlay a process on the technical workflow, but then they don't know exactly what exactly is the software that you're developing, what exactly it does.

Because in today's world, a lot of systems software, a lot of SaaS software is pretty complex in terms of how it is used by the end cons- customer. So if you can understand that, then when a new feature is requested, you have a much better understanding of what it is that is getting developed. What are we shipping?

What does this feature mean? When you know that, then you can have better conversation with product managers, designers a- and software engineers and, and even, for example, customer success managers and, and systems engineers. You'll have a much better cross-functional neutral equal partnership and facilitation skills if you understand what it is they are shipping and what the features are.

Third level of technical they really need to be is they need to be able to write their own scripts, generate their own dashboards generate their own live dashboards on whether it is in, Jira or, or other tools like Tableau or Sisense or any of the other tools that are there. If you can do some script- scripting, if you can generate those dashboards, if you can look for the right signals and figure out what else we need to measure, so on and so forth, that would be helpful.

So those are also technical, but not to the point that you can actually write code. That's my view, but, you know, people differ in that.

Galen Low: No, I really like that, and I-- it's coming back to the first thing you said there, which is really important. It's not binary. It's not that a only program managers can do program management, and it's not that, oh, program managers will vanish because don't worry, the software team managers are gonna do the program management.

That's it's not that black and white. There's definitely a spectrum in between, and one of the variables there is complexity, right? It's like, okay, well, if you're just delivering software within your team, and there's not a lot of moving parts, and you know your team so well, and you've got that system, by all means, some of that delivery will be less less complex.

Even if it's complicated, it'll still be less complex. It's things that you know. Versus the highly complex project ecosystems, which might include vendors, which include marketing. You know, you've got maybe various product stakeholders and it becomes more to manage and, you know, the, the value there is to stitch it all together and navigate that complexity so that it still gets delivered which I really appreciate.

And I, and I really like this yeah, your theme on better conversations, right? Deeper understanding, having the vocabulary equals, you know, being able to collaborate better with people. And then point well taken especially. I'm glad you called it out on also, there's just a technicality to almost all roles right now, including the technical program manager role, where you do need to have the sensibility to build a report or build a dashboard or automate a process, and that's becoming part of it.

But to your point, stopping shy of necessarily being a person who, you know, habitually writes code as part of you know, their job either today or in the past. Two things I wanna ask you. One there's that depth of understanding piece, right? It's like we're gonna have better conversations, you know, we're gonna earn respect.

For the business leaders out there who are kinda like, "Yeah, that sounds nice, Satish," but what's the ROI on somebody having a deeper understanding or having better conversations with a team? What does that translate to for you?

Satish Menon: So look, if you're having better conversations and That will lead to better respect.

Better respect means you'll then be invited into bigger tables of strategic discussions where they'll look at you as a strategic partner on the execution side, and also making sure that the strategy converts to good plans. If you don't win their respect, if you don't have that vocabulary and the depth to win their respect, then what happens is PMs and engineering will figure it out what the strategy is, and you'll not have a place on their table.

And, and secondly, they'll create a plan, and then they'll hand it over to you and say "You know, here's the plan. I would, I would like for you to track it," because that's where they put you. You don't have the vocabulary that they have, so they don't have respect. They don't invite you to table, and you become a tracker.

They, they slot you there. So look, here is one thing that is an im- is an important concept that everybody needs to understand is life in software engineering didn't begin with TPMs. It began with like engineering people, and it began with product managers. So product managers have ideas, and engineering folks are collaborating with them and executing and so on and so forth.

Sometimes it's a technology in- in- innovation, and when a technology innovation, then it started with engineers and, and, and then you have product managers being brought in to add more to it and mar- the, the marketization of that technology. Product managers then they come in and they partner and they work.

And until you have 50, 100 people in that startup where things were born from product management or things were born from engineering or so- or a CTO, like a technology innovation team, and then they brought in other engineers to do the coding and product managers to marketize that whole thing, you know.

So that's how, you know, things start as a new concept or a, or a new startup and, and how new concepts are, are brought and they even ship the first product and there's no TPM in sight. But then the, the, the team starts growing, the startup sta- sta- starts growing, and you have larger teams, and then now you have multiple engineering teams, and now you need-- there is a need for a common platform, otherwise engineering is not scaling.

It's too expensive to scale. So then we develop a common platform where six verticals can exit on, exist on that one platform, and then you create all these interdependencies within engineering teams. That's when you say, "You know what? Let's get a TPM on this, you know, so that we can track all the dependencies."

So TPM is a function, let's accept this, is a function that comes later in the game, not in the beginning of the game of this. So by, by definition, you are somebody who's going to be told when you just come in as the first TPM of the organization, you're gonna be told what to do, how to do, what, what is the outcome and all of that.

And slowly you can start influencing. So you're already starting off with that delayed entry point, okay? So on top of that, if you're not now g- now what happens in that stage is the t- the PMs and the engineering all have been talking and strategizing and making plans forever. You're just new on the block.

You just joined day zero. So the respect that you have to have in order to be an equal partner has to be, you have to start from zero. They are already there, so they have to give you the respect. It's not the other way around. So in that case, you have, you better have that language. You know, that's when you start getting a seat to the table.

So you, because you, you, you're a late entrant to the whole life cycle, it's important to know that, right? So when you have, "Oh yeah, it makes sense. Okay, I came in late. You know, I'm, I'm required only when the dependencies became complex." So bread and butter is dependency management, but many other things as well we talked about before.

Galen Low: I really like that because there's two things in there. One, it's yeah, don't forget, you're probably late to the party. You know, go in, you have to earn respect. Go in humble. You're gonna be figuring out, you know, how they've been doing things, you know, for a long time before you arrived. But the other thing I think is very empowering, which is but by the way, they can't scale without you.

The value you bring to the table is that you are, you know, a growth lever for them as things get more complex as they're more, there's more teams involved, you know, the stakes are higher. There's a lot more that can go wrong. And I was really happy earlier that you used the word strategic partner, and I know we were talking about technical fluency, but you really wove it in about you have to speak the language of both really.

You have to speak the language of all the teams you're working with on a cross-functional team, including product, and I'm looking at it from like the executive layer of being like, okay, well, what does the executive team think of when they think of strategic partner? And the thing that popped into my head is that the biggest complaint I hear from executives on the delivery side most of the time is just that, you know, people d- didn't get it.

They don't get it. You know? They're just doing stuff and, you know, trying to do it on time, but they ship something and it's wrong. Or, you know, they didn't think of this opportunity that they came across. You know, we walked by this opportunity to you know, deepen a partnership or to deliver more value for a customer.

And that's the big frustration. And when you're talking about like speaking the language, earning respect, and having a deeper understanding both ways, right? Technical side, business side, product side. What we're talking about is, you know, developing the sort of mechanics of being a strategic partner who gets it, who can, you know, champion the vision for, you know, what is being delivered.

Yes, the product owner as well but also the, the delivery thereof. It's like, how are we going to strategize the delivery of this software product or this product in general so that It is like as high value as it possibly can be, you know? Whether that means, you know, is shipping early gonna create more value?

Is, you know, like being intense about quality, being real sticklers about quality going to like create value, you know? Is delighting the customer going to create value? And I think the more people understand, anyone on the team, but specifically, you know, the, the program manager, then they can sort of tilt their delivery strategy in that direction.

And it's funny because I don't know if a lot of people see it that way because of exactly what you said. Sometimes, you know, not not just-- I'm not picking on program managers here obviously, but you know, there are roles where you're just expected to be administrative, right? Check the boxes, did the task get done, look at the Jira tickets, you know.

You know, monitor the burndown chart and that's all you do. But that isn't actually delivering as much value as someone who could understand the problem set better, and instead of just executing on a plan be iterating on variations of that plan to get to value that's maybe even more than the value of what was originally planned.

And I think that's that's a really cool like value add of okay, well, you know, why should you have... Like who cares if your team respects you? All you do is make sure they get their thing done. It's like that's not the game anymore.

Satish Menon: Yeah. So a couple of points there. One is the, talked about business value.

So one of the things We have an opportunity with in, in, in this AI world right now is if you have a concept, producing a vibe coded demo of that is pretty quick. You can do that, and then once that-- once that's there, you can show it to some three or three to five, you know, high confidence value or good friendly customers who are, who are willing to take a look at it and give you feedback.

And in the old days, it used to be like, you know, a ton of coding before you had a demo that you could show to a customer for feedback, and that loop was basically so slow that it, it was not very effective. But right now with vibe coding, you can generate a demo quickly, and we call it, at Seismic, we called it a research preview.

So, you know, show the early code to customers and, and get their feedback. And so you get an opportunity to refine the final requirements, and then you go on this next phase of basically refining that and hardening it into, into GA. So a role can be played by TPMs to enforce this process of research preview and so on and so forth to get higher value before taking something to GA.

The second part of it is the strategic value that you talked about. It's much easier when you and your C-level executive, you know, has an alignment how you add value in this whole cycle. Sometimes you come across brand new C-level executive that is a change that is happening in your company, and then it goes through you know, the TPM and the teams go through an uncertain time.

And that's because every C-level executive comes into the company, or every time that I take up a new opportunity, the C-level is a CC, CPO, CTO, you know, chief development officer. They are looking at me, and everybody has different preconceived notions, right? Sometimes there's a good alignment on here's how I want the value from this person, and then I speak that language and kind of get the opportunity.

Or I'm sitting fine and dandy in some company, humming along, doing well with partnership with my CTO or CDO, and then suddenly there's a change of management, there's a new person coming in, and now there's an, a period of uncertainty because that person's preconceived notions are different. And he might say "Why do we have all of these people?

What are they doing here?" And, "I don't think that's valuable." And, and sometimes they give you an opportunity to talk, you know, to talk and then to have an alignment as to give me three months to figure out how I demonstrate the value, or here's the value I've brought so far in the past. Sometimes there is not that opportunity.

The guy is interested in making changes right away, and that happens too. So that's something that we have to accept, you know, preconceived notions. Sometimes we have an opportunity to fight it. Sometimes you are a victim of how they think.

Galen Low: This segment is brought to you by Fingerprint. Every visitor on your platform looks the same at first. Can you trust them or are they a threat? Fingerprint recognizes bots, AI agents, VPNs, tampering, and over 100 more unique signals to give you durable risk scoring and threat detection in real time. Even as human and agentic activity blends together, you can identify suspicious traffic faster and build safer and more secure sites and apps.

Over 6,000 companies rely on Fingerprint every day. Join them now at fingerprint.com. And now back to the show.

I wanna come back to that research preview thing in a little bit, but I think you've raised a really good point about the fact that, you know, perhaps more than ever before, but maybe it's the same, but there's a lot of change right now, right?

Especially at that leadership layer. And you know, I, I hear a lot of people experiencing that. I've experienced it myself. People in my network are experiencing it all the time where, you know, that, that really core pillar of the organization is swapped out, right? We're talking C-suite executives, you know, CDOs, CPOs.

It they need to get up to speed quickly, but they have been brought in to bring in their own ideas. And to your point, they might move fast. They have to move fast.

Satish Menon: Yes, exactly. And we are, we are definitely an organization that is considered to be something on the periphery, not core. You know, b- the sooner we accept that and then add value where there's a good alignment you know, we'll be more peaceful with ourselves.

Galen Low: Well, I-- m-maybe let's go there because, you know, in some cases you have a very short window to defend yourself and to defend your team, especially, you know, you're, you're sort of, the head of delivery, right? You're overseeing your team of program managers. A new leader comes in. They've got their own preconceived notions, you know.

You can read that they are probably going to make changes to, you know, get some wins under their belt quickly. How do you, A, get in there into the conversation, and B, how do you sort of defend the value that your team adds? And, you know, how has that argument, I guess I should say, you know, how, how does the case that you make for your team, how has that changed in the world of AI, where, you know, software development is being disrupted program management is being disrupted?

You know, what are some of the ways that you can get at the table and explain why your team is doing things the way they do things, and why that's valuable?

Satish Menon: In terms of the AI era versus the past, I mean, the, the core idea of having that conversation with the new management or the new C-level executive is the same.

But now, I have to now use a different standard to have that conversation. So in the past, it used to be like, "Okay, here's how we've organized, and here's how we are automating the dashboards to get the status previews, and here's how we are now actively involved in problem-solving, risk mitigation," so on and so forth, and with the best of what was there five years ago.

But today, you know, I have to have this conversation as to how we've taken that and how we've transformed that to the AI world, where we're now triangulating across multiple systems and looking for a lot of the leading indicators to prevent a bad outcome as opposed to you know, just reacting to a bad outcome, which, you know, people will talk about, okay, you know, there are consequences for bad outcome, but it's after the fact.

You know, if you had TPMs and looking at leading indicators, then you would probably be able to prevent some bad outcomes. So to have that conversation, so these are our leading indicators, these are our current dashboards, these are the ways that we are triangulating across multiple systems, these are the ways we've used AI in the TPM world to augment AI use in engineering, and here's how we are leading this team and have adapted to this AI world.

That's the conversation I would have. Sometimes you have enough time to have those conversations in one-on-ones with the new person or in team meetings or in other settings, and you should actually, I, I seek out for that opportunity, you know, as soon as I know that there's a change happening, and sometimes I win and sometimes I don't.

It's okay.

Galen Low: Yeah. Some battles are unwinnable, I, I would say in that context, you know, especially with an executive who's come in and is under pressure to make change you know, to you know, impact, you know, profitability and the bottom line to, you know, make changes in staffing. But what I really like about that is it's an educational piece because the role is different than probably these preconceived notions of what some people, anybody, not just executives, but the preconceived notions of what a program manager does.

You know, there's a sort of picture in people's mind and they're like, "Well, you know, we've got all these we have tools, we've got software, we've got smart people. We don't need more smart people making sure smart people do things," which is not the job anymore. The value is in avoiding issues, right?

Risk management and especially at speed, being able to ensure a good outcome with the value attached to it. 'Cause to your point it's a much better win story than what I see happen a lot, which is "Ugh, that was a disaster. You know, we collided with all these things," and then that new exec kind of has to wash their hands of it, right?

They're like, "Okay, well, that was before my time. You know, like I you know, that's, that's clearly something we need to fix." Why not just not have that moment and remove as much risk as possible from delivery, have that value highlighted? You're really supporting that executive's you know, win story for them as well, 'cause nobody wants things to just go off the rails.

There is the strategy of let things go off the rails so you can fire those people, but I think in general it's much cleaner to say, "Okay, well yeah, like I've been able to pull all these teams together, make sure we're focusing on value. The program management team gets it. They are helping us mitigate and manage risk so that we can move our strategy forward," is, you know, to me, I'm like, that, that's pretty compelling.

Satish Menon: Exactly. And my view honestly is that a good solid TPM team with the right way of operating in this AI age, they can be an effective way of identifying leading indicators of risks in any program, in any execution, in any operationally efficient team to warn of the upcoming of a bad outcome and then, and then mitigate it.

Otherwise, yes, there are consequences to bad outcomes, but it is basically late and expensive.

Galen Low: You know, it's actually a, a good segue. I know we've been talking about it you know, at a high level throughout, but the role is different now. And yes, it's because of AI and changes in software development, but it's also just evolving, you know, just like a lot of professions are evolving.

We were talking about, you know, your research preview and this notion of like vibe coding and, you know, working with product. You know, you're talking about building dashboards that have leading indicators so that we-- you know, it's our crystal ball so that we can avoid problems. How different is the role of the technical program manager today versus, you know, three or four years ago?

Like what areas have changed? What priorities have changed? What are your expectations when it comes to, you know, having your teams deliver value?

Satish Menon: Look, there's going to be software engineers are operating 10x, 100x, really superstars 100x compared to before. We have to do the same. It's very important.

So we have to stop being people that make manual reports or do manual status collection. We have to stop being people that are not looking at automated live dashboards and, and then assessing red, yellows. To be honest with you, right now, we should validate the reds and yellows that are coming from one tool based on triangulation with other tools that basically consolidate information from multiple areas.

For example, I mean, if Jira is declaring something as coming close to completion, but GitHub assessment and Claude assessment of where things are at, it does not correlate. And if you look at the software coding life cycle, you know, from, from initial code writing to check-in commits, so on and so forth, PR reviews, if you see that cycle being disconnected from the Jira report of something coming close to con-completion, that's a red flag.

So you, you, you have that triangulation risk coming up early on before it's too late. Also, you know, if you're thinking-- if you're looking at the progress on the testing side, you should look at what's BrowserStack telling you about where things are at in terms of you know, quality assessment and deployment on the cloud or testing and staging, so on and so forth.

You look at that, those three, and then you get a better, richer assessment. So if you don't adapt to, to all of these changes and new ways of thinking, thinking about where the project's at and where we are with delivering value, you know, then, then yeah, we deserve to be defunct at some point. But if you if you keep up, then those are the best people that survive.

Similarly, if, if there's an, if there's a software engineer that's only looking to AI for help when he's stuck or for some suggestions or you know, AI-assisted coding, but it's 15% AI-based and 85% your own effort. If there are software engineers like that today, their time is also limited. They have to get to get on board with you know, pretty much all of the code is generated by AI, but there is a human oversight to make sure that it's doing the right things and it's you know, making sure that it's not violating key boundaries.

We better do the same thing in the TPM side as well. And, and then there is basically value on both sides. We, as a team between software engineering and TPMs, we will be delivering things much, much faster going forward. But it's still a partnership where both functions are accelerating to do things faster and better.

Galen Low: I really like that, like the whole, comes back to that scale enablement and value, I was gonna say value enablement. Yeah, I think that might be the right descriptor, right? It's like n- not being more of a bottleneck because we're, you know, outdated in the, the way things work, especially in software engineering today, but also, you know, being an active participant in it.

I really like that notion of yeah, identifying discrepancies between systems because it's still early days in terms of, you know, how all of the, the cross-functional teams work together with their tooling. And it is possible for there to be, you know, discrepancies that create risk. But I also wanna come back to we, we were talking about problem-solving, and I know we had said okay, well, yes, a technical program manager does not need to have a coding background, does not need to be expected to write code, should understand a bit about the software development life cycle, yes, to earn respect.

But we touched on a little bit about and also to like help solve problems. What level of problems do you expect your technical program managers to be able to solve? Is it all sort of coordinating teams and make sure that, making sure that they are on the same page and finding that alignment? Or is it deeper?

Because I, I w- I was thinking about your research preview that you were saying earlier, you know. It's like, is, Are, are these teams of technical program managers now sort of, you know, vibe coding to sort of drive alignment with stakeholders or to model a solution to a problem? Like, how close do you expect your team to get to problem-solving in a technical context versus more of the standard program management problem-solving?

Satish Menon: So look, there, there's a spectrum, okay? So when I worked at Google, the TPMs were like super technical, where we could basically do a lot more of the technical problem-solving at the TPM level, but that's very uncommon, and that's really not common across the industry. So to be honest with you, typical TPMs should be able to figure out based on a problem, you know, okay, this team is lagging behind.

We need to give them help. But at least based on what that team is doing and how it's functioning and what it's delivering, you should be able to say there are some sister teams that are of similar capability, and let me just voice the idea of getting help from some other similar teams on, you know, helping here, so on and so forth.

If there's a platform team that is basically delayed and will affect the release of a particular vertical, then, you know, it's important to make sure that the platform work within the team is prioritized to ensure a high priority vertical ships on time, and so on and so forth. But I think to understand if this team has a problem, who else can be brought in to assist solving for that?

You can brainstorm with the engineering director there, and so on and so forth as well. But if you bring some original thoughts to the table for the consideration from the engineering leader, you know, then that brings you more respect and alleviates some of the brainstorming that they have to do themselves.

So at least take something off of their plate. And I think it-- once you do that, you know, get the right parties on the table, look where the parties we could source from, and then frame the question and frame the problem-solving next steps in a way that they have to do less work to figure out the next steps towards a solution.

I think that adds quite a bit of value, and that's what I'm seeing practically. I'm not seeing people who can actually be the person who can go and tell certain group of engineers to do a certain thing to, to solve the problem, you know. So I'm not seeing that.

Galen Low: I like the sort of recurring theme of a deeper understanding actually ends up creating more value along the way.

For example, if you already know, right, you can do intelligent resourcing. You know, you already know that another team has the right capabilities, is available, and could be a solution. You can bring that to your team instead of being like, "Hey, this is your problem to solve. Solve it by Friday."

You could be collaborative about it and maybe get to a solution faster.

Satish Menon: So when you do that former part, like this is your problem, you solve it, and then you just keep them accountable to a date, then you know that that's when you- your respect goes down. But if you have enough, you have enough knowledge of what they're doing to say, okay, you know, and c-come up with some 70% solutions in terms of resource assignment at least, or some creative ways to solve the problems.

You can give them even a little bit and say, "Hey, here's something that I'm thinking about, but you guys own this, so if this is useful, use it. Otherwise, figure out." Then they'll automatically start appreciating that you're coming in with you know, at least some suggestions. And I think that's where people tend to give you a little bit more respect than, than if you just went in there and said, "Hey, this is your problem. Can you solve it?" Or-

Galen Low: I love that phrase, 70% solutions. You know? Bring them something that's like partially baked. It's not final, but at least it's a starting point. Actually, before I, I kind of, I, I framed it as though you were saying that TPM would be vibe coding a thing for the research preview.

And I- Oh, no ... I did it deliberately, but I don't think you were saying that.

Satish Menon: No, no, no. So look that's more of a process thing, but I did not mean TPMs would be vibe coding it for customer demos. No, not at all. In fact it is just a process change and something that, you know, they can bring together in terms of a process flow.

So, PMs and, and senior engineers, they are the ones who would be vibe coding, and PMs would be the one that would coordinate and make sure that there are good customer demos and so on, and then get more requirements and so on. But it's more of TPMs are just overseeing that process in that flow, to be clear. Yes.

Galen Low: And actually, you know, and I think the thing that's kind of also coming out is you know, everyone's moving faster, right? 10x 50x, 100x especially on the software engineering side. But the sense I get is togetherness is valuable, too. It's not like the silos don't have to be there anymore because the teams are more efficient.

And I guess what I'm thinking in my head is, you know, that research preview doesn't happen without engineering. You know? It's not like we have to work in the silo because engineering needs to do all these things, so we'll do our own little prototype and talk to the clien- It's like there's actually more togetherness.

There's more collaboration, partly because developers are not just hand-typing code, partly because program managers have, you know, tools and dashboards and effi- other efficiencies available to them through technology, partly because, you know, product managers, you know, can do a, a prototype vibe coded or otherwise, very rapidly so that we can all understand the value, move the, the the progress bar forward make sure we have stakeholder alignment.

And like all of that is removing risk from delivery you know, in the grand scheme of things.

Satish Menon: From what I've seen, vibe coding and, and early demos or research previews, I've seen that happen based on vibe coding that engineers did based on what PMs did or even what people from product design did.

So they have an cool idea, they just quickly vibe code it and then, you know, we are no longer restricted to what we did in the older days, which was just start showing some how things would be based on just a Figma design. You know, we, we are past that stage.

Galen Low: You know, we're talking about technical program managers.

That role, they don't need to be coders, but it would help if they, you know, understood something about the software development life cycle and sort of spoke the lingo. How do you approach hiring decisions around that lens? Would you rather hire a former developer who has since become a great program manager, or would you rather hire a longtime program manager who just doesn't even know what a merge request is?

Satish Menon: Like I said before, I think TPMs who've been coding before is a better TPM. However, there are exceptions because I've seen TPMs who became TPMs and then they spent a lot of time with coders to understand and then learn it that way as well. So I'm testing for the outcome as opposed to really looking for that in their resume to say have they been a coder before?

I look for can they effectively talk the language of the engineers? Can they effectively talk the language of product managers and designers? And in that case, that's what I test for. So how they got there, whether they got there because they were a coder before or because they-- once they took their job, they actually partnered and really studied how their partners in coding did their work.

Regardless of how they did that, if they are-- if that's the product that is in front of me, then I would hire them. The-- I would say, though, today the opportunities that a TPM has to get into software TPM work without a coding background, even if it's dist- in their distant past, and having the opportunity to, on the job, collaborate with the coders to kind of learn their workflow and so on, so forth, that opportunity is really low right now.

So this, this worst case, like 15 years ago, you could do that. You're a hardware program manager and some software project needs a great TPM to come in and help. They would say, "Okay, you know, you can come in and then you can talk to these folks, and you can learn how software works." That kind of openness was more prevalent in those days.

Today, that opportunity is less. The tolerance for somebody who needs some training on the job is very, very low. They're looking for ready-made people. So that's an unfortunate market dynamic, but that's how I would put it in terms of how I hire and what's required.

Galen Low: It's a very realistic lens you know, and it maps to, you know, what, what I hear out in the market right now.

And yeah, you know, it's the-- not to say if you don't know what a merge request is, then you won't get a job. But be prepared to educate yourself and find every opportunity to be able- Yeah ... to speak that language, to be conversant with those crunk- cross-functional teams, because the tolerance is less right now for you to go in there and be like, "What's Jira?"

Like it's probably, you know-

Satish Menon: You could do that 15 years ago, not- Right. Yeah.

Galen Low: Yeah. Now, 'cause it's not seen as separate anymore, and ag- you know, again, I, it's kind of like, the bar is higher because the togetherness is higher. Also, the delivery pressure is higher, don't get me wrong. It's like we can't afford to slow down or make mistakes.

The, the, the expectation is that we are flawless at, you know, 10x, 50x, 100x. But also I, I, I like that idea that it's like, well, yeah, we want you to come and start being part of this team and and be able to have the dialogue and, and be up to speed really quickly 'cause, you know, that, that is what we need.

And I think it's a, it's a great lens to look at things through, even if you're somebody who does not have a technical background, wants to work at some of these software companies. There may be some work to do beforehand or, you know, as you are sort of ramping up, get to that point quickly because that is what's going to be expected of you.

Satish Menon: Yes, and there are some companies and, and hiring managers that hire strictly on situational questions that are non-technical. I don't do that. In all of my interviews, I have a specific question bank that I create to test for the technical fluencies in the areas that I expect. And of course, I'll cater it to the candidate to make sure that it is within range of what that person should have done and should be knowledgeable technically based on all the claims in their resume.

in terms of the products they have shipped before and all of that. So there is a, a ton of technical fluency questions that kind of objectively determines that, you know, is this g- what, what scale this person is on a scale of zero to 10 in terms of technical fluency, both in the vertical market aspect of their area that they have shipped, and also on the general workflow of a software engineer and so on and so forth.

And then there are situational questions on that people aspect and that emotional quotient of the candidate, right? If I interview... You, you talked about ca- type of candidates that I would hire and so on. That's why I thought I'd mention that. And it's a very objective set of question bank that I create, and I also tailor make the interview panel to test different aspects of that question bank from the candidate, and therefore you have an objective assessment in the end as to what they did.

And I learned this objective interviewing methodology at Google. They, they, they were the first place that I figured, "Oh, wow, this is like very objective, very, very scientific way of hiring." And, and I got updated and learned from them. So credit to them but I follow that process even-

Galen Low: I really like that.

I like that it's like handcrafted for the candidate. Not to put you too much on the spot, but do you have an example that you could share with us of a situational question that tests some of the technical knowledge, you know, of a particular type of candidate?

Satish Menon: Yeah. So for example, like someone claims they've been working in a SaaS environment and optimized the release env- environment there for faster delivery or something like that, or somebody talks about having released SaaS products before.

Then I would have questions about, you know, what is different about a SaaS software delivery compared to on-prem and, and what are some of the areas that they have taken shortcuts compared to on-prem delivery and why, and so on and so forth. So I would kind of question them on the detail, and then, I mean, they give me some question, I would ask them some more follow-ups to go deeper and deeper to see, you know, how much did they understand about really the SaaS delivery or the how the product functioned.

And some people might talk about some product they released in Disney, or some other people talk about the product they released at Salesforce. Then I will do some research about the products of the company that they came from and what those products did. And then I would ask some questions about some of the features that they released for that product, for that company, and that they should be familiar with.

What, what was the feature that they released, for example, right? So that means they tell me that they didn't just overlay process on top of a software life cycle that was going on, and they didn't know whether wha- what was the starting point, what was delivered, and what was the change that the software they delivered brought about for their customers.

They should be able to explain that to me. And then, you know, that, that's that sort of thing. Yeah, and I would have some basic other questions on like software life cycle on the coding side, for example, or on the DevOps side, or on the difference between staging and, and a real production environment and what were the guardrails there and how was the separation of making sure that there is no security vulnerability that would just be introduced by having staging in a production environment, for example.

So I would a, question them on all of those details to understand did they get the concepts of how software works, how cloud works, how, you know, the things like that.

Galen Low: Yeah. We started this conversation out kind of around the idea of mismatched expectations of, you know, technical program managers, where they think that they deliver value versus, you know, some business leaders and executives who, you know, would really wish that the TPM role and the software engineering team manager role would just combine and become, you know, one single class instead of, instead of, you know, two headcount, it would be, it'd be one.

And I think you've made a lot of like really good cases of why that shouldn't be the case. But as we know, and as you mentioned, sometimes we don't control everything. I, I thought maybe if, if we look into the future, and I'm not usually pessimistic about the future, but I'm gonna go there today. But let's say that the sort of, you know, software manager TPM hybrid role prevails as like the dominant team structure in software development.

What do you think the impact would be, and what would it mean for leaders like you who believe strongly in the idea that the two roles actually should stay separate?

Satish Menon: As a community, what we can do should then be thought of as stuff that we can control. And, and what we cannot control is, is beyond our hands.

So what we can control is to be ahead of the game in terms of what the tools of today are enabling us to do that would still be A value add for a product delivery. Think in terms of cross-functional. Think in terms of multi-team. Think in terms of interdisciplinary. At the intersection of multiple functions coming together to deliver a product, that's where our value is the biggest.

At the rudimentary level, it's multiple engineering teams. At the next level is engineering and QE. At the next level is engineering, QE, DevOps, and, and tech docs and so on, like still within the realm of what needs to be delivered. Then at the next level, that is cross-functional between what is being delivered from the product organization to the people that are beyond like the field customer success managers, sales engineers customer support you know and then premium platinum services that the customers get from the company and all of the variables there.

And then launch events and marketing messages and so on. And there's like different functions doing different parts of their role in all of this cross-functional big picture. And then, and then you have an opportunity to be the orchestrator across all of that. So if you think more and more-- And then there is this other thing about multiple companies and partnerships.

You know, you have this company releasing something, but this is now a joint launch with that other partner product that works together with ours, and there's like program management across companies. So think bigger in terms of the evolving landscape of what the tools can do and what else is remaining in, in our hands.

And for the today's world at the level I talked about in terms of you know, automated live dashboards and then triangulation across multiple tools, using AI tools, this, that, and the other, and get involved in product and problem-solving. And then the next stage is think bigger and bigger in terms of larger and larger cross-functional problems to solve.

Galen Low: I really love that. Like we're, we're at the hub. If you take someone-- If you take that role away from the hub and it's only software engineering focused, then we lose all that value. And it's that scale, it's that complexity of, you know, different partners and different sort of teams that are coming together, different disciplines.

That's to where we really add value and is the reason why it should be a separate role to conduct and orchestrate that value. But it needs that depth of understanding. We can't just be, you know, ticking boxes and overlaying frameworks onto products that we don't understand. We actually really need to know what value is, how the sausage is made, and how we can help ensure the delivery of those products in a way that is meaningful and impactful.

Satish, thank you so much for spending the time with me today. It's been a lot of fun. For folks who are enjoying what you have to say, where can people go to learn more about you?

Satish Menon: Oh, just look me up on LinkedIn.

Galen Low: Again, thank you so much.

Satish Menon: I enjoyed my conversation with you, Galen. Thank you so much for the opportunity.

Galen Low: All right, folks. That's it for this episode of Digital Project Manager Podcast. If you enjoyed this conversation, make sure to subscribe wherever you're listening, and if you want even more tactical insights, case studies, and playbooks, create a free account with us at thedigitalprojectmanager.com.

Until next time, thanks for listening.