TPM Podcast with Ivan Santa Maria – Part II

Podcast Transcript

Welcome to the TPM podcast with your host Mario Gerard. This is part two of the interview with Ivan Santamaria. Where we discuss what TPMs are doing in the industry and what differences are across various companies and so much more.  Stay tuned.

TPM vs SDM Role

Mario Gerard: So, yeah. So you moved from a TPM from being a TPM for nearly 13 years, you’ve moved to an engineering manager role. This is one of the fascinating reasons why I reached out to you was to understand, like somebody who’s been a TPM, you’ve been a senior TPM, you’ve been a principal TPM. You’ve been a staff TPM. You’ve been a senior staff TPM, right. You’ve literally like grown in that world for 13 years. And then you kind of switched into the SDM role. Let me start with, how’s the role different between the two?

Ivan Santamaria: It’s a different angle on the same problem, right? You’re finishing a product for a user. You want to make the user happy. There is a very different set of skews that you need to do to be able to do dev manager.

Mario Gerard: Yeah. And what are they?

Ivan Santamaria: Well, you’re going to write code. So the same way that no one should underestimate how hard it is to produce a proper spec or a schedule or not right. Should not underestimate how hard it is to produce a proper design. [01:25 inaudible] scale or not crashing interface. Will tolerate like hundreds of millions of users, which is like [01:29 inaudible].

Mario Gerard: Redundancy, designing for failure.

Ivan Santamaria: All of the other stuff, how to deploy, how [01:34 inaudible], how we manage, how we monitor all this stuff.  So it’s kind of like, it is an art on itself, but you know, even as a TPM, I never stopped writing code, my education actually I have undergrad in computer science. I have master’s degree in computer science. I have always written code my whole life. As a PM, I wrote samples.  And I always have my samples being part of the test suite. So the documentation will suck the samples out of the source code to put on a Wiki and those compile with the rest of the build.  So when you run your tests, you break my simple, you break your build. So I have always been someone that wants to have a very integrated experience. And one of the things about how much technical work you do as a TPM is that there are certain things that come with the job. So you go out and you do the, all the schedules, integration, APIs, and whatnot, but you also get stuff by invitation. And one constant thing of my career is several of my PM jobs were, looked a lot like architect jobs, right? And this is like a natural transition for me. I want to be a little bit more hands-on, you also have to wait what the differences are on different companies. When you were a dev lead or dev manager on Microsoft, there’s a certain amount of Coding and hands-on work that you want to do, and Google is different. Facebook is different and Amazon is different. Everywhere is different. So also have is the TPM position right from you Facebook or is the engineering manager position better? And for me it was the engineering manager. I look at the list of things that bring me happy. That’s it. So my transition is actually…

Mario Gerard: A natural transition.

Ivan Santamaria: A natural transition, right. The reason I got promoted a Google was actually because of competitive benchmarking that I did for Google cloud. So I can’t really go into the details, but it was really a lot of figuring out whether or not we’re competitive and why not in like some complicated scenarios. You’re not going to find a really a performance bug on any one component written by a Google developer. They’re outstanding.  So what you really find is you need to bring a new scenario. So I use what I know as a TPM to reach out to the sales team and look at them to be cases we’re losing. And then I’ll create a synthetic benchmark that represent the thing we’re not competitive. We’ll bring that back. And I analyze, then I can go talk to develop the road to feature and say, Hey, here’s the angle you didn’t see. Now, they go out and we collaborate on fix, right? But I need to go figure out a way to add value. And in that place, that is how I brought new information into the table and help people make better decisions. That’s what they needed. They needed this information, how’s the users are actually using the product to make the product better? So this is what I went out to go dig. So I don’t get stuck to the definition. And the more senior you are, the more you define what your job is.

Mario Gerard: No, I totally agree with that. So I met up with one of my friends recently, who I’d worked with, he’s an ex colleague of mine from a previous company. And he was like, he’s looking for opportunities. And I was like with his skillset and knowing how he works I was like, we’ll have to, we’ll create a job for you. Tell me what you want, tell me what’s the role you want. And we will find the team where you’d be a good fit and we’ll create a role for you. And I think that’s what happens as you move up. And as you have a lot of capabilities, I feel you’re like a Swiss army knife. You can do a lot of things, but you’re really maybe good at one or two things. And we want you to really kind of bring you in to fix or do those two, three things. So that’s interesting. Do you see the engineering manager role also, you know, you have people reporting to you. So that’s also an aspect which the TPMs don’t generally have, right? Because most of the TPMs are individual contributors or they might have a group of TPMs, but now we have, we have to take care of the personal aspects of a team. The morale, hiring, firing all those kind of things as well.

Ivan Santamaria: Yeah, I do. And actually I was a TPM lead.

Mario Gerard: So you had people reporting to you.

Ivan Santamaria: Yes. I had a team of five TPMs at some point. I like people, you know, say you should not go into management if you don’t like people, let me tell you that, like, don’t do it. They come with their complexities. And I like talking to them. I like understanding their motivations and suggesting things that they can do better. It comes with a cost as well. I mean, you have to objectively measure how they’re doing against their expectations. And if they’re not doing well, you kind of have to work out why. And sometimes it’s just like, you got to let them go. So this is part of the life of a manager. Also part of a life of a manager is something TPMs do. Which is you need to let go certain things.

You might know exactly what the right thing is. Or you might believe that you could do better yourself on something, or you might believe you’ll have better information. But if someone is convinced, you’ve got to give them like some role to run and maybe they’re right and you’re wrong. And there’s some, you need to be humble about that. And maybe you’re right. And they learn a lesson and you have to be mature enough and a decent enough person to go out and say, Hey, now I have an ally that understand my angle.

As opposed to go out and say like [07:02 inaudible]. So there’s this aspect of growing people and growing with people, they also bring like all sorts of different perspectives that I really enjoy. If you asked me if I enjoyed the process of writing the thing, no, I don’t. I think it is a miserable experience. I like few obligation of doing a good job representing what the people in my team did. And I torture myself for an extended period of time to make sure that I got it right. But one of the things about the review where I work now is the managers really help each other to make sure that we were doing it right. So you bring in a lot of people to help me make sure that I am, you know, setting the expectations correctly and judging the outcomes correctly against the expectation, which it’s a lot of work, but I don’t think, I don’t think I can do any better than this.

TPM and Dev Manager – The Overlap

Mario Gerard: And so where do you see the line of the dev manager and the TPM kind of overlap and kind of dive, where’s the overlap? There is definitely an overlap, right? Because I’ve seen TPMs kind of do the dev manager work a little bit, dev managers do some work. What’s the line. Do you think there’s a line?

Ivan Santamaria: Yes. There is a line and it’s kind of like, not every TPM can or should or would like to do some of the dev leader, dev manager or any sort of like dev work.  So going back to something you mentioned in the beginning is like, not everybody needs to be able to blur that line, but you can add a tone of value by never come even close to this. The line is, I own the quality of this call. I own the quality of the design. It’s on me.

Mario Gerard: It is on the dev manager.

Ivan Santamaria: Absolutely. It’s on the dev work. I used to have discussions when you have QA. And then one of the questions I used to ask is can you point a bug that a QA person ever wrote, show me a product that has a bug that was put there by the QA person. So that’s on the Dev, right? Objectively, someone sits down, writes the code, and puts the stuff in on the source control and [09:06 inaudible] product. Or on advice, an app and whatnot. That is on me.

Why that’s where the buck ends. So we need to make sure that one, I have the right people allocated here. The team is properly staffed. They understand their mission. We have a clean design. Like we can actually do a good job. We have the right metrics, but we actually write good code. And that goes in and it should satisfy where this blends a bit is, it should satisfy some customer and it should be coming out in a timely fashion. And it should have like some level of the correct quality. Now I can partner with the TPM to give me insights on how things are going.  And maybe even help me on where it my upstream dependencies that might be having changes, that I’m not aware.

Tell me that I need to prepare for some changes on an API or other services or whatnot.  This network of communication, which is kind of like the great channels of communication in any organization, typically you go find a lot of TPMs that know how to navigate this stuff.  As a dev manager, I have to like keep looking at what I’m doing here. I don’t necessarily have the time to do the legwork on that stuff. Again, going back with your regional job, remember it was like, Oh, the dev manager, they’re going to walk around and figure out how the teams connect. This is where you blur the lines quite a lot, but where the line is very clear is, I’m writing the code. And the code goes up.

Mario Gerard: Yeah. But I’m trying to digest what he said. And it’s like the dev manager is looking at the code, the architecture, the design, and looking almost like looking down while the TPM is looking more on a fan out approach of all the connections to the team, all the things the team needs to do, be aware of and in a sense, right. It’s a very, it’s a partnership which needs to kind of complement each other.

Ivan Santamaria: It only really works if it’s a partnership and the same way that the TPM has this blurred line, that they can come closer to help with the design, the dev manager can also walk the line and help with communication and engaging and whatnot. Right? So there are certain partners that react better for the fact that the dev manager goes there. So the TPM has to be aware enough to say, Hey, you should show up with me and I do the slides, you present.  So that might be a simple trick. So there is a line that’s clear, but there’s this blurred space where it’s collaboration and you figure out what works. Everybody should be looking into, making the customers happy, delivering something that solves the actual problem, that the make things better. This is everybody’s job. But you know, on the tasks like one [11:52 inaudible] the other writes different artifacts, that one is kind of like somewhat, most of the time clear.

TPM Levels

Mario Gerard: That’s a good summary. You started as a TPM and you’ve grown in several levels. How do you differentiate how senior a person is and how the level a person?

Ivan Santamaria: Every organization will have like some sort of career ladder. And this is like a recurrent team. So tell me if I’m running out of time here.

Mario Gerard: No you are not. We never run out of time.

Ivan Santamaria: So here’s the thing with this, every organization will have a career ladder and you go look at the career ladder. Some of them are super specific. You do this type of stuff, you’re at this level, you have this particular scope, this other level. So [12:34 inaudible] complexive task, goes with size, goes stuff like that. I actually think that there are four things that really will set your level and actually will get you promoted. So here’s Ivan’s secret to getting promoted in an organization.

Mario Gerard: I love it.

Ivan Santamaria: It’s just four things, I never found a fifth one. It is just four. And so the first thing is really the one we talked about the most. Are you ready to do the job? And do you own a particular scope? Some organizations will throw it on the deep end and say, Oh, you own everything. Go figure out what you can handle. And you view their job backwards from everything into manageable scope. What the organization is to say, take this little thing, make it succeed, they will give you a bigger thing, but it really goes into your readiness to take on a particular scope and complexity of work. Now, let me give you the other stuff that gets you promoted.

The first thing is, do we have budget to pay you? And this is like, if you never had to deal with this, good for you. But in some companies, most of the large tech companies, that’s really not a problem, but in a lot of places, it’s like, you get promotionally name only. It’s like, you got more work, but not more money. That’s not a promotion.  You just got sucked into more work. So promotions are like, do we have money to pay for you for reals? So number one, number two, do I have the business need to have you on the next level? A lot of Peking jobs for career projection is do we really need someone on this level and companies and leaders on those companies, will you find a way to organize, you know their people on the corresponded levels. You probably saw this with people saying, Oh, I know I’m going to have this as principal.

I need a bunch of seniors people and whatnot. So the sizing of the who I need the director, sometimes you don’t have the person for this. You just know this is the seniority you need, and you design the stuff and then you fuel it up, right? So you need to know that there’s a business need for that. You’re doing sustaining engineering on a V12 project, there is a ceiling for them. So do I have money to pay you? Do we have the business need to have you doing the next level? The third thing is what we started with. Are you ready? Can you do the next level job? And some companies do, yes, we’re going to make a bet. Some companies do trailing promotions. They say, no, no, no, no, you need to work on the next level for a while. Then, we are going to recognize that with some money, those are the things that people talk about the most.

It’s like money, need, readiness. Then I have the fourth one that it becomes more and more important as you become more senior, which is trust. And trust is a very interesting one. I’m not talking about AI trust you’re going to do an honest job. Do you not be hired if people didn’t trust you, but it’s what kind of problem or size of problem I trust you to take on and make things better, not worse. The more senior you are, the more trust overrides other things. It overrides even like if you know the domain or not.

Sometimes you look up and you look at, someone got promoted to vice-president and you say, why exactly, I mean, I could like find all five other people that are more qualified and then you go figure out and then you discover that, that one person is the person that can actually work with the other five. So we trust that that person will be able to make this organization as a whole do better. Do we don’t necessarily trust the opinionated people that might be better at knowing what to do. So those for me are the four secrets of being promoted. Like, do I have the money to pay you? Do I have the need to pay you? Where can I get the job done cheaper? Are you ready to do the job?

Either because I believe you can do it or because you already proved you can do it. Do I trust you to take on this scope and do something good about it? That for me is the secret. And some variations of this. When you show up on the ladder and people will slot you when you get hired, they say, well, you know, given what this person did so far, I trust them to tackle this type of problem. We did an interview, we probe, and we think it feeds so whatever, you know, principal or senior [16:48 inaudible] or senior staff, or they will put you there. That basically is how I abstracted away the differences is down to this.

Building Trust

Mario Gerard: So how do you build trust?

Ivan Santamaria: Building trust is a…

Mario Gerard: It is a secret right? It is a real secret.

Ivan Santamaria: It’s not really right. I can turn back to you and say, how do you build trust? And if we write this down on a white piece of paper, and say, tell me five things you do to build trust. And we compare at the end, as a blind exercise. I think we’re going to overlap on at least three.

Mario Gerard: Okay. I’ll start with one, which comes to my mind is be consistent in fixing problems or showing the right results your leadership is looking for. If you can consistently deliver on a variety of different problems and solutions or variety of different problems that organization wants to fix, and you can consistently deliver on that. That’s number one. I think having good ethics in general of making the right calls, even if they’re difficult calls or having difficult conversations, I think that’s really, really key. I think those are the two main things that come to my mind.

Ivan Santamaria: I’ll add something, like do what you say, right. It’s part of being consistent, but it’s also being in part of being predictable. So you say the right things and then you do the right things as you said, you would. If something changes, you keep people abreast of what changed, communicate well, this develops trust. You are a known quantity now. So, okay. This person will take this type of problem and consistently do it right. And I’ll know when something changes. I know they will be able to handle this. So I could stop here and say, you do this. You’re good. The other thing is in central organizations, you want results.

So you actually got the results based on how you’re measured, that you need to start knowing how you’re measured. But if you deliver those things according to what your organization expects of you, that also develops trust, you can go get results, you get success, right. You can create success for your organization doing the right things, being consistently doing those things. There’s really no secret in thrust. What there is in trust is there’s no instantaneous trust. The way I usually think about trust is, it’s like a bank account that you can go deposit, but you can only deposit a quarter at the time. So to build it, it’s this slow grind where you go adding and adding and adding and adding.

To lose it is instantaneous. Like it evaporates, right? So this is the trick with trust. We kind of like instinctively know how to build this thing. But it’s like, yeah, you build it. And then you can lose it on a snap.

Mario Gerard: I also think the more I think about it, I also think that you have to build trust with various parties within the organization. It’s just not one leader you’re aligned to, or you report in to. A lot of leaders, a lot of coworkers, a lot of stakeholders, a lot of sponsors, a lot of stakeholders or whatever you might call it. Literally everybody from your developers to the senior leadership.

Ivan Santamaria: That reflect a more democratic workplace. So when you say this, I kind of like, Oh, I know what kind of work environment you have, but there are places where you’re going to work, that you kind of like the owner is there. So one of the advantages of having worked on like small businesses before, there are certain things that are predefined. I have this joke that I tell, and I’m going to make a risk of telling a joke, but it’s you want to pick the next manager for your branch and there’s this small company. They only have one manager. They need to pick one manager and they decide to do what test.  They give like a thousand bucks for each and they come a month later. The first manager say, Hey, you know, I invested on a bunch of stuff, here’s 500 bucks back, but we’re better off. The second say I saved it. Here’s a thousand. And the third one comes back and say, I turned that into 5,000.  Which one gets the manager position?

Mario Gerard: Depends on the value of the organization.

Ivan Santamaria: It’s a small company. It’s the son of the owner. So we intact, we kind of, I have this thing that we’re very democratic and whatnot, but you know, not everybody works in that type of space and you should know where you are. So you know who to invest to get trust from. And if you’re not the son of the owner, I’m sorry, but you’re not getting the management position.

Mario Gerard: It’s interesting that you say that see, are you indirectly saying that you got to pick a leader within the organization.

Ivan Santamaria: Not necessarily, but I want to say something. You can make a leader. The person that actually makes the leader is the first follower. A leader by itself is just a lunatic. A leader only is a leader when someone follows. There is a skill that is the ability to follow someone that is getting rare and rare. It is more and more difficult to find someone to say, Oh, that sounds like a good vision. Let me contribute. This ability to actually get together and help with something, even though might not be perfect, it’s also something that builds trust. So you don’t necessarily have to pick a leader. You can be the leader, but if you’re [22:17 inaudible], make sure you have a following. Otherwise you’re really just a lunatic.

Advice to people who are starting their career as a Technical Program Manager

Mario Gerard: That’s interesting. I think the final and the last question is what kind of advice would you give people who are starting their career as a TPM.

Ivan Santamaria: 7$5. No, no [22:40 inaudible] the bank account. You know, we’ve talked about happiness, right? And that goes for everybody, starting and not starting and figure out the things that make you happy. But if you’re starting your career, one of the things you don’t know if you have not gone through enough experiences to actually try different things that might make you happy or not happy. So try to experience the profession. Try to experience different types of jobs, different companies, right? Leave a little, enjoy the fact that we’re in a boom in tech, like thousands of companies and all of them have different jobs. You can find something that aligns with your vision for the planet, but you can do a lot of things. You can work with art, creative types. You can work with like enterprise, you can work with small businesses. They are all different. And when you build this kind of like…

Mario Gerard: Varied experience.

Ivan Santamaria: Yeah. Experience, right. So there’s this other thing someone told me once that, you know, how do you gain where experience comes from, you say like experience comes out of, you know, bad decisions. So you have a lot of bad decisions. You gain experience. Go on a situation where you can actually make decisions. Some of them will be good. Some of them will not be as good. And you’re exposed for different types and biases and cultural views and like angles and, you know, motivations and mission statements and whatnot. So try it out. If you look at my resume, you see that I did exactly that.  So I’m not saying anything that’s not something I don’t myself.

Mario Gerard: I’m reflecting on your words. And I think what’s interesting is I’m kind of the same. So I started out my career. My first job was working at Oracle in the sales team. I finished my engineering and that’s my first day, I worked there for three years. That’s enough of a time.  And then I got into writing code. Then I got into like an [24:36 inaudible] role. So I think that is really what kind of makes you, you have gone through, you tried out like five or six different types of roles. You try different companies.

Ivan Santamaria: I like concrete examples. So since you work in sales, this might be something that gives you like [24:57 inaudible]. So when I was on Google cloud,  and I had this impossible mission to tell developers that do an excellent job, how to make it better. The way I went at value is I reach out to the sales team to figure out the deals we’re losing. So I gain access to the database. So I know we have leads. We know that the leads [25:19 inaudible] an engagement.

So I will go, and I jump in and I create a taxonomy of engagement types. We’ve, the Salesforce,  so now we have like groups of offerings, biotech, or oil or whatever industries. And I know how I score against each one of those. And I start building like reference architectures for those things that turn into my benchmark. So the experience I had before getting to Google, knowing the sales has this, the other people around me didn’t. So now I have a trick up my sleeve. I have a skew that came out of life experiences that other people around me didn’t have. It’s not like there are like very few other TPMs who have a combination of, you know, having done some perf work, having done some sales in my own company, and knowing how sales work, I even know that what type of salesperson I am. I’m a farmer.

So sales is like hunters and farmers. I’m not a Hunter, I’m a farmer. You give me a relationship. I build a great team. If you tell me to make a cold call, I don’t know what to do. So this knowledge, even the terminology is not something common. Unless you did the job or you try something different, you don’t have this. I will not have found what I considered probably like the happiest job I had in many years that was doing competitive benchmarking.

Mario Gerard: Yeah. Think as a TPM, I always look back and think, Hey, that thing I did five years ago, or seven years ago is helping me now. That’s exactly the same example which you gave, right? That varied experience really kind of comes to fruit. Like things I did back then, I was like, you know, five years into my career, six years into my career, I was like, why the heck did I do sales? Like, why did I get into that? But if you look at a [27:07 inaudible], just like what do you say exactly like what you said, I know the things I pulled out of that, that bag of tricks I had or that learning I had to make my job better or do something unique or bring a perspective, which other people don’t have. Just like what the example you mentioned.  It’s a very telling that, I’m just realizing that fact. It’s an unbelievable journey really.

Ivan Santamaria: It is. And like, I want to leave like a message to the people listening to this, that are starting their careers and they might be starting their careers, like [27:45 inaudible] or whatever. All your life experiences count. So when you go be a [27:51 inaudible]  developers, algorithms, and code, when you are going to work on TPM your life experiences, all of them count. Be that you were in the army. Be that you run like a tire shop or a donut shop. Like all the stuff. If you are open and willing to learn your environment and adjust what you learned, the lessons you learn to something new, that is a key advantage, a competitive advantage to do well on this particular profession. And I love this profession because if you are willing to do this, you have a really good chance of doing well on it.

Mario Gerard: Absolutely. It’s been amazing, amazing talking to you. Do you have anything to add?

Ivan Santamaria: This was a lot of fun.

Mario Gerard: Yeah. This is, I have tremendous amount of insight, fun. And it’s also like enlightening. That’s how I look at our conversation was definitely fun and extremely enlightening because you made me realize a lot of things, which I probably knew, but putting into words and putting into thoughts with the amazing experience you’ve had, it’s been an incredible conversation.

Ivan Santamaria: Thank you. Thank you for the opportunity.

 

Hi folks. I hope you really enjoyed that. This is the end of the interview with Ivan Santamaria. I’m so happy and so pleased that he spent his time talking to all of us. Take you in for the next episode with me, your host, Mario Gerard. The next one I’m trying to do is on

Scaled agile framework. I am just repairing the flow of the podcast for that. So stay tuned. Bye-bye.

Mario Gerard