TPM Podcast with Ivan Santa Maria – Part I

Podcast Transcript 

Mario Gerard:  Hello, and welcome to the TPM podcast with your host Mario Gerard. I have a very interesting guest with me today. Ivan Santamaria. He’s been in the tech industry for more than 20 years. He’s been an SD, he’s been a TPM. And then he’s right now a software dev manager. He’s worked over 10 years at Microsoft. He’s worked at Google for five years, and now he’s at Facebook for a little over two years. Several cool, interesting projects like working on SQL server, Bing, the cloud programs, both at Microsoft and at Facebook. He’s been a TPM for over 13 years, and now he’s kind of transitioned into the software dev manager role over the last two years at Facebook. So why don’t you introduce yourself?

Ivan Santamaria: Hello everybody. I hope this is interesting for you guys. I’m going to share a little bit about myself. I think I did a little bit of everything in my career. I used to have my own company, so, you know, you’ve got to do everything you want. And then I started on corporate life on all the different places that you listed. And one of the things that I usually tell people is like name something in software. And I probably I’ve done it right from like, I’ll do in layout, like network cabling and designing networks, hardware to, you know, search engines and whatnot through organizing chicken factories, to like cookie factories, beauty salons to, so everything from small businesses, all the way to those massive services. Big chunk of it was a TPM, but I pretty much did, you know, Dev for hire, Dev for large corporations. I did, you know, performance work.

Mario Gerard:  You did some SDT work as well. Like a test engineer at Microsoft as well.

Ivan Santamaria: I did. And there’s this interesting thing that I kind of don’t like specializing too much. So I have always been the odd person on any one discipline that I did. So when I was on SDT, I did performance benchmarking for SQL server. I made my way all the way to test manager. And at some point, right, one of the things that people might be curious is like, why TPM? Why did you move to TPM? And this deserves like a longer answer, but I figured that I could actually impact the quality in the scope of what my product was moving to a program manager position better than I could as a test manager position. And I have a little secret for anyone starting, like, I want to share a secret for people choosing their careers. So I’m a big believer that you should optimize for happiness. And the thing that I had when I was as that, is I actually got really angry when I found a bug. It’s like, what is this thing doing to my product. And the problem with that is like, if I’m very good and I find the bugs, I get angry by doing a good job. If I don’t find the bugs, I get anxious because I’m not finding it. So that is like, I should not be working on that stuff.  So going to program management at the time, it was my way to go and impact with the features who go into the product and like make sure that we pay attention to the customer and kind of have a more rounded view of what the product was.

Mario Gerard:  Nice. It’s been a long journey for you? You’ve as dev, TPM for so many years. And then now you’re still in the tech industry.

Ivan Santamaria: Yeah. Full loop. I started like a Dev in business owner and like whatever. Then I moved to the [03:37 inaudible] made the transition to program manager. Then the industry kind of start specializing. So you end up with things like technical program manager versus program manager versus product manager. But this is not how the scene started. And now I’m back to being a developer. So it’s like I did the full loop and every one of those jobs have like some pros and cons from them. But I’m kind of a curious guy. I like to jump around.

What does it mean to be a TPM?

Mario Gerard:  Tell me, so since you’ve been at TPM for so long, what does it mean to be a TPM? How do you define the role?

Ivan Santamaria: Yeah, so there’s an interesting article on this. So when the position of the program manager, not necessarily the technical program manager was created, Microsoft kind of figure out that, you know, you have those big teams that need to talk to each other. I kind of need a dev manager that can walk around and do the leg work to do coordination. And they kind of invented this role to be this integration, coordination, and collaboration type of role.  And no one else had this cause no one had to scale. It’s easy to forget today how dominant Microsoft was. But in, you know, around 2000 there was like, no one else. So what ended up happening is like, even inside Microsoft, some people specialize in doing market research and they became like, Oh, that is the marketing PM. And some people went to take care of features and say, Oh, that became like the technical PM. And what happened is, as the rest of the industry kind of caught up in size, like things like Google and Facebook and.

Mario Gerard:  Amazon.

Ivan Santamaria: Amazon. They caught up in size. They say, Oh, we need a role like this, but not really exactly like that because we don’t have the same structure as Microsoft. And you start having this transition of the role in the separation of program managers that tend to be today more oriented towards like process and tracking with the…

Mario Gerard:  And business.

Ivan Santamaria: In business, they split with product managers on that, because product managers like go figure out what the user is and the features and the gaps and whatnot. And the technical program manager who became more specialized on a team efficiency, but also more technical space. But in essence, I still think that two things, one, I still look at it as a leadership position. Your degree is that moves the product on the right direction. You kind of like make it work. And then you have to adjust the amount of organization that you have in a particular place. If you walk into a place that is, has a lot of yellow tape, your job is to cut yellow tape and go through the bureaucracy to make the right things happen. If you go on a place that is too confusing and disorganized, it’s your job to produce structure. So you get the team more efficient on the product and correct for the users. This I think is the essence of the role, make it move forward on a very efficient manner, paying attention to what’s important, which is the user satisfaction.

Mario Gerard:  And all along the way, you’re adding some kind of a technical value as well, because you see from a technical perspective, you also see what could be done. What could not be done. If somebody thinking about, is the product manager thinking about X or Y, or Z, the technical implications of what we’re going to do, or a particular technical design, which is already existing. And we need to add a new feature to that. How would that technically impact the stack?  So I think there’s a technical aspect to that as well, which the TPM kind of is bringing to the table.

Ivan Santamaria: Absolutely. So usually those answers are complicated answers. So adding to what you said, and I agree with it is you, as the TPM is trying to figure out how to make things forward, you need to one, get the information on what the right thing is, and you also work as like a nexus of collaboration. You can talk about two dissenting parts, diagnose what one side is saying in technical terms and do the translation in a way that they start collaborating. A lot of disagreements in large corporations come out of miscommunication or lack of agreement on what the priorities are. And the technical program manager has like a unique position to be able to understand both sides and do the translation. There’s this old anecdote that I heard that some Microsoft product, top 20 features, most requested features were already implemented. So a lot of times when you have a platform like particularly people working on things like cloud, or Middleware business tiers and whatnot, it’s a lot about, whoever’s asking for you to change something, not knowing how to use it. And then you kind of have to have this, you know, the smarts and the emotional smarts as well to bring them up and really understand what’s a real gap versus a perceived gap. Like then work that back with the team.

What are the competencies which you look for in TPMs?

Mario Gerard:  Yeah. So you brought up a lot of interesting points. Like collaboration, communication, and prioritization. And then I think more, or right now, if you look at the senior TPM level, there’s a lot of integrating work when you are having upstream teams, downstream teams, communicating effectively, how the API is talk to each other, you know, timelines of when these things are going to happen and how it impacts the feature, which we’re trying to release at the end of the day. So from a core functions and perspective, I think we spoke about that. What do you think are the competencies which you look for in TPMs?

Ivan Santamaria: It is a very varied role. Situational leadership is very important. Mario Gerard:  What does it mean when you say situational leadership? Can you elaborate a little bit.

Ivan Santamaria: Yes. So you need to understand the relationship among the teams, or the parties involved. You need to understand what the business goals are, and you need to understand what the value system for the place you’re working is. And then you have to align those things. So you have to align the interests and the value systems of the place to make this work, right? So there’s no fixed formula for you to come up and solve something that is general, right? You can buy a book that’ll give you some sort of a template, but that’s not going to tell you what each place you work for is about really. So if you look at a place like Microsoft, it’s very carefully planned. You want to know all the features, when you’re done, if you’re going to be ahead, if you’re going to be behind. It’s kind of like build to compete on the checklist type of thing. So [09:49 inaudible] the products, V1 V2, V3. It’s almost always excellent by V3. Because they kind of have this plan. You go work in a place like Google and Google really values complexity. You got to do excellent engineering on this. And that does not necessarily always translate to exactly what the user wants. Amazon is famous and paranoid like about, you know, users or whatever they ask, I get it, right.

Mario Gerard:  Yeah. And they’re also very fast in iterating. They don’t wander too long on a plan. You don’t need to produce a one-year plan, get it out quick, test it for a small AB test. Whereas a small percent of users see what your [10:29 inaudible] test tells you. Then go ahead and you know, launch it in full scale mode. And we’ll see if it makes sense or not. So each organization,  what you’re saying is kind of each organization have, has different value system [10:43 inaudible], different leadership principles or whatever you might call it. And that keeps the organization like helping organization priorities of how the work needs to be done.

Ivan Santamaria: That’s absolutely correct. And the reason I use the term situational leadership is not only the organization, but you have subcultures within your organization, and they evolve over time.  They evolve the maturity of the product. They evolve with like what the market is doing.

Mario Gerard:  And the leadership, right? The leadership, the people who are in the executive positions within those teams, the type of decisions they make.  But some might be overtly risky, right? Some might be trying to get a new product to the market. So every leader who comes in has his own way of working and that kind of permeates down to the team.

Ivan Santamaria: Yeah, absolutely. So that for me is like, number one, and then you have to do the other things. Like you need to have good structure communication. You need to have technical acumen, like be able to understand what the requirement is, what the platform can do, produce the gap analysis. Organizational skills, like there’s a little bit to process for you to fix the communication. I mean, things smoother, right? The least, it really depends on you the better you did your job. Because it will naturally just move forward. You view the positives in action and then it gets done.

What is technical acumen?

Mario Gerard:  You spoke a little bit about having the technical acumen. I think a lot of TPMs struggle with what’s the right depth, or am I going to fail or succeed in this job? Because I’m not technically strong in a particular area. So let’s talk a little bit about like technical acumen. Before you got to working on the cloud, you probably didn’t know much about the cloud. Maybe, you know [12:35 inaudible] a little bit. But let me phrase it the other way. What is technical Acumen and where do you start with that?

Ivan Santamaria: So there are a few different ways to look at this. So there are certain things that [12:46 inaudible] and if you have the algorithms training, like, you know how to LogRhythm analysis, you understand patterns, you actually did some sort of distributed system work. Those things transfer actually quite well.

Mario Gerard:  Very well. Yeah.

Ivan Santamaria: If you work on business and you understand multi-tiered architectures and why, it’s very important to understand why you do certain things, you understand that there’s a speed of refresh on the, why does different than on your database, which is different than the business tier, right? So if you understand this, you’re going to do well. It transfers very well as you go from product to product, to product, right? So there are several patterns that will carry If you, even if you don’t necessarily know what the new domain is, but you can, I’m a big fan of using the skews you have to make things move forward. I do work with people that are both technical and non-technical. And if I had to go and rate what I go out on the last six months, one of the people that are not really a computer science person produce the absolute best impact from the program management on my organization. Because what she did is, she actually brought intelligence about the users of our systems in a way that we didn’t get. And she came up and say, you know what? I’m not going to argue with you about design, but I’m going to make a list of capabilities that I should be able to do with this. So what she did is she was very creative on the way she used her skews to come back and make sure that I was able to understand the message. And I was able to identify where we’re not doing well. So we partner the best type of TPM or the best part of co-worker, actually she is the one [14:24 inaudible] and helps you do better in whatever capacity they can contribute.

Mario Gerard:  It’s very important to, I think, know the basics. And then as needs arise, learn more in the domain. You have some fundamental basics from where we are coming, and then you slowly start adding building blocks of technical acumen as you move forward. And I think one important thing there is continuous learning. As long as you continuously, you know, keep yourself fresh with what’s happening in the space and are being able to contribute actively. I think that’s a really good sign.

Ivan Santamaria: I think I can give a negative example as well. This is not happening right now. So if anyone who is working with me is listening to this, you guys are doing great. But I want to also share anti-pattern. So there’s like, at what point you need the TPM and why some teams don’t have them. And the thing is like, if you were working on a tiny organization, where everybody knows what everybody else’s doing, odds are people pitching and kind of do this,  kind of do the work, [15:32 inaudible] it is small enough, right?  But as the organization grows, you end up having this interesting dynamic that if the technical person is the manager or the person that leads your organization, at some point, this is too big for them to keep track. You will add the manager of managers and whatnot. And this person now we think the job is easy, it is a very hard job, you lose control over what’s going on. Like, Hey, I used to know everything that was going on, now I can’t. And I don’t have time to actually go probe and learn. So let me try to manage it by proxy. And then the TPM is hired as the proxy to go around, ask people what’s going on to deliver a summary to this person. And that creates like this negative feedback cycle because everybody will go poke for information, tells it like, what are you adding to me here? What is the value for me? And you might not get the thrust of this manager that hired you was the proxy, because he or she doesn’t necessarily trust your technical depth to do this. So this for me is an anti-pattern 40 PMs. You cannot be the proxy of someone. You can identify the situation and fix the communication in a way that automatically this is clear. That is great, but you cannot be the person that go like bullying people one by one and poking people for, you know, status updates, and think that that adds value. And you’re going to be bored out of your mind very soon. Like you’re going to be miserable in your work. So if you are in this pattern, like fix it.

What does TPM do after the team is highly performing

Mario Gerard:  I have an interesting thought. You work with so many teams at some point, a team becomes very highly performing, right? It’s a high-performing team. You ironed a lot of the kinks out, you set up these processes, everything happens kind of as a well-oiled machine. Then what do you think is the job of the TPM at that point? Because I’ve been in those situations where, you know, it takes a year, year, and a half, and then you ironed out all the communication channels. You have established good relationships between the teams. They can operate fairly well with all the upstream and downstream dependent teams. Even if it’s like 20,30 teams, because you know, you have API specs written, and you have your swagger. There’s so many things you could set up that for the team for success. But then what does TPM do after the team’s highly performing.

Ivan Santamaria: So there’s the varying definitions of what a team is. So I was lucky to receive training , one of the benefits of large corporations like they put you through training. And one of the instructors that I had was like a Navy seal. And he was saying, you know, what is the definition of a team? And he was telling us that there’s this group listening. And he said, a team is a group that has a common mission. And everybody on the team is necessary to achieve the mission. And everybody knows why everybody else is in it. You need everybody and they all know we need everybody. They all know…

Mario Gerard:  And they have specific skill sets.

Ivan Santamaria: That is right. You don’t get it done without everybody there. Now under this definition, I think I’ve been on a team twice in 30 years. So this is very rare. So you can get to some steady state and whatnot.

Mario Gerard:  Now what if the steady state doesn’t last for too long.

Ivan Santamaria: You hire someone and then you have the team dynamics.

Mario Gerard:  Key people move around. There’s always, so what I’ve had is when I bring it to a steady state, there’s always some kind of disruption. Either there’s a market disruption or there’s people disruption, which does not lend itself to a steady state lasting for too long.

Ivan Santamaria: That’s exactly my experience. So when you reach a steady stage and what do I do now? Well, you know, [19:24 inaudible] take a beer, enjoy the sun. Because next week something is coming, right? So maybe that’s the time. There’s this trick I learned. It’s very old. It’s like a lot of people’s [19:36 inaudible] ideas, it is called the Eisenhower matrix for time management. And this is like from second world war. Eisenhower had this matrix that you have to split your activities in important, non-important versus urgent and not origin. So you make this little square, like the four boxes, and then you go and use account, how you spend your time, your hours, right? And for most people, not everybody, but for most people, we tend to spend a total time on urgent things that are not important, like instant messenger or whatnot. This email need to reply now, it’s kind of this might be urgent for them. It’s not necessarily urgent for you. It might be important for them, but not important to you. And we tend to postpone certain things like things that are important, but not urgent. So when was the last time you learn a new skill, a new tool, a new programming language. When you last time you actually did like learn a new language or did any of this. So if you ever get to one of those rare moments where the things steady state, go look at your box of important, but not urgent. I am willing to bet money that you have a stack of stuff that you like to get you and you didn’t. So, you know, enjoy it and do it. It’s important.

Mario Gerard:  Yeah. It’s also, I feel sometimes that we don’t do important things, which are not urgent because that’s not something you want to do. It’s something which you’re not like totally interested in doing. And that’s the reason you keep postponing. But it’s still important. Then it’s probably a good thing to, you know, look at.

Ivan Santamaria: So when I started, I mentioned like, I like to optimize the job [21:13 inaudible] by happiness, right? So I like people to be very precise on this. So what I do is I make a list on every time I finish a task, if I’m starting to look for a job and what not, every time I finish a task, I say, I did the bugging or writing code, talk to customer and say, I felt happy doing this, or I lost track of the time. So this is a very concrete thing, actionable thing. And then at the end, you look at the list and you’re going to find a pattern. So you want to find a job where you do the task that makes you happy more often, right?  The same goals for intrinsic motivations. I have this craving that attracted me to TTM of being able to solve a complicated problem that will not be solved otherwise. Like, Hey, you know, great job, Ivan, it’s kind of silly to have validation like that, but I crave that. So I go for jobs that allow me to do tasks that make me happy and where the things that motivate me for my own internal values, like resolving problems from other people, like in a sense, serving others. This is something that the job, the perfect job is the tasks that make me happy and the things that make me happy. And by the way when I cannot get a job like that, I manufacture that. And one of the ways is volunteering. So, you know, there are years where all my intrinsic happiness, whatever comes out of volunteering on other places.

Mario Gerard:  Yeah. Happiness is key. And as a TPM in particular, I think since the job is so that you have to wear so many different hats and do different things, you really have to be happy and motivated. And you have to own it because in some essence you are like a CEO. You need to love what you’re doing to actually do that because you completely own it.  It’s your baby in essence.

Ivan Santamaria: Let me share another trick. One of the advantage of doing this for a while is like, I accumulate tricks. So here’s another trick. I manufacture victories. So basically, you know, my team knows this and they kind of like, not necessarily happy, but I force everybody to go out to like once a quarter and make a toast about what we finished this quarter. Like it should take the form of, I am very proud and happy because we finished this and it made this and this benefit for XYZ. So, this is a way for them to look back and have like this quarterly Thanksgiving for all the things that got done. TPM and software development all of it, they have whatever has a similar effect the teaching has. You really don’t know if you did well, you know, on services slightly better. For all the rest, it’s like, it is so difficult to know if you did well. Like if you fix the communication for a group, how do we exactly know that that made, did you really fix it? It’s like…

Mario Gerard:  Hard to imagine it sometimes.

Ivan Santamaria: And tomorrow there’s another problem. And you go from problem to problem to problem to problem in six months, you’re like the Preston, you know, you have self-doubt whether you’re helping or not helping or whatnot.  So manufacture the milestones, they have to be meaningful, but they give you a chance to actually celebrate finishing things and concluding things and, you know, measuring your mathematics and reassessing if you’re focusing on the correct things

How do you quantify impact?

Mario Gerard:  And talking about that, you also, when we started, we also spoke about having impact, right? How do you quantify this? When you’re a TPM, how do you know that you have an impact or what that impact in values?

Ivan Santamaria: You better know the answer to that. Otherwise you’re going to be in trouble. You might end [24:57 inaudible] proxy thing. So what impact is situational? What is the problem you’re solving? Are you solving communication. Maybe you should have like some way to measure it. Like examples and from my life, we had a project where we didn’t know what features were agreed on or not. So a simple Wiki page where you publish documents that are approved, and you don’t even have a process for it. It’s like if someone disagrees, they can complain, then you move it out and say, this needs more discussion.

But having just a central repository where people can find is great, you will measure the visits on it.  And you know, you had impact on this, right? You see the number of meetings doing lean down to some healthy level. Like when people are spending more time on execution, you see this, you can measure what you do and you see, did they change the speed of check-ins or the number of times to deploy where, you know, satisfaction from a customer or whatnot. And frequently it’s on the TPM to go, come up with the metric. Because unless this is second nature for the org people really don’t like to be measured. It’s funny, right? We say like, we’re all metric driven and whatnot, but you want to see someone really angry.

It’s just, you give them a bad number. I learned that doing perf. I have the funny thing about how perf works and it’s usually starts to like this. You show up with good numbers. You’re a genius. Great. Thank you. You know, you show up with bad number. So, the test is wrong. That is exactly right. You prove this is right. It’s like your methodology is flawed. You prove the methodology say, this is the wrong scenario. So you have this like cycle. Finally they say, Oh, now it’s too late to change anything. People really don’t like to see bad news. So it’s usually on the TPM to be the person that comes up with the metrics and help us track and expose it and bring it to light. If that’s what the team needs.

Mario Gerard:  That’s very interesting. Exactly, right. I feel that every team evolves, every organization evolves. Every small business unit evolves, and the needs of the team change over a period of time. And it’s kind of important for the TPM to realize where the team is and what the team actually needs.

Ivan Santamaria: Situational leadership.

Mario Gerard:  Situational leadership, it is emotional intelligence, right? Because nobody’s going to come to you and say, Hey, there’s a communication problem. Nobody tells you what the problem is. You are dropped into a situation, you’re dropped into a team and you need to figure out what the team needs. And then you can’t probably fix  everything, you have to prioritize and fix one thing at a time and probably have a little bit of metrics to know that the problem has been fixed. And it will not reoccur again, because you don’t want to be just keep tweeting the same thing over and over again. You want to go and fix that, fix the problem in a scalable manner and that it’s repeatable that you don’t need to stay there. And the team’s needs really, really evolve over a periods of time, a change in the leadership could make you do different things, right? That changing the team dynamics can do different things. There are hundreds of scenarios where you need to do different things.

Ivan Santamaria: Absolutely. And you want to hear a funny story? I like to poke developers. Like I’m a developer. I like to poke some fun. We need to have fun of ourselves a little bit. But there’s this thing that from time to time, you hear that people say, well, you know, like go ask the customer. And they say, well, if the customer, if we ask them, they will ask for a faster horse, which is the famous story about, you know, the model T and whatnot. But then they hired the TPM and you go out and say, what do you want me to fix? And they don’t know. So all of a sudden, they’re the customer asking for the faster horse, just make them communicate better or whatever, make them work faster. So it’s like, you know, give me foster horses, right? And these on you to figure out that, okay, this is what you’re saying, but this is what I really need to go fix. And that’s where it takes all this stuff we’ve been talking about, emotional intelligence, figure out what stage it is, technical Acumen. Like some experience, life experiences are also very important. You recognize, you know where things are, right? You find a lot of super interesting people in the TPM profession. If you go in a room and  you try to like do life stories or something like that, you’re going to find like some super interesting life paths. He was like, I have no idea. And you know that this person was like this. So yeah, this is a big value. Being able to recognize this and then recognize what’s behind the mask, the request, but you go out and then figure out what to do next.

Mario: I feel personally for me, it’s been a very fascinating and fulfilling role. That’s how I look at it. It’s very, very fulfilling to see the multiplier effect I feel TPM generally have. It’s not a very linear relation. It’s not a linear value, like a developer building something. I think TPMs have this multiplier effect value. If you do the right things, what the team needs, it could have tremendous value to the organization.

Ivan Santamaria: Yes, absolutely. If you go on the anti-pattern [30:27 inaudible].

Mario Gerard:  Yeah. You could pull things down tremendously.

Ivan Santamaria: Exactly. So you are kind of this multiplier that you come in and you have to be careful. So yeah. You got to be careful. You need to know what you’re going to be doing to the org, right?

Facebook vs Microsoft vs Google – How was the TPM role different?

Mario Gerard:  And that’s very interesting as well. When we hire TPMs, you really look for that cultural fit, you know, what the team needs and what this person is bringing. He, or she might be a fantastic problem solver, but that’s probably not what we need right now. We need something else. So it’s interesting to understand what people bring to the table. So let me ask you this other question. So you worked at Facebook, you worked at Microsoft, you worked at Google. How was the TPM role different in each of those organizations?

Ivan Santamaria: Yeah, so I think I hinted that it is different even inside. If you go talk to someone that works on, let’s say data center management, there’s like one set of skills. If you’re going to work on someone that does some sort of messaging applications, like completely different set of skills, the commonalities are communication, making sure that your processes help, don’t get in the way, like make sure that people have what they need. There’s some, you know, efficiency there, but the essential difference between those places, this is what’s common. What’s essentially different in those places is what is the value system for the place. So on Microsoft, you know, you got to go produce your checklist to make sure that we’re delivering on those things and we’re tracking the integrations right. And there’s a time to hit the schedule and whatnot.

Mario Gerard:  Sometimes there are even release streams, right?

Ivan Santamaria: Oh those things [32:13 inaudible]. I think like more, if you multiply the number of hours by the number of people in those things, by how much of [32:22 inaudible]

Mario Gerard:  Standing room only. That is what he said right?

Ivan Santamaria: So they get tired.  Nd then like people get in good shape and then they start taking forever as well. But it’s like, if you count how many dollars we waste, just salaries. I just think how many doors we waste of people in those meeting rooms. And you see why places like Google and Amazon they develop on trunk, right? So it’s like, nah, there’s no integration in anything. It’s like, you check in and you break everybody. So those meetings are like, I have PTSD attacks with the stuff, like allergies. Yeah. So when you go to something like Google, there are different value systems. So you want to make sure that you’re tracking what they care. So in a place of values, like you have really sophisticated technology that when you ship looks like magic, which is what their thing is. It looks effortless when they put out to say, wow, how they did this thing? [33:21 inaudible] behind the scenes. It just looks like that. So for you, as a TPM, you need to integrate what is discovered into the product in a way that will, you know, shine for user the way they want this to happen. You know, Facebook [33:35 inaudible] market, you want to iterate [33:37 inaudible]. Amazon was also the customer. Did you satisfy the scenario? Do you have like, you know, the five pager, it lines up to what is doing and you’re doing what the customer wants. So each of those places has a different value system. There’s different artifacts that you’re going to have to produce. Be that the design, be that the checklist. Be that the release.

Mario Gerard:  [34:00 inaudible] at Amazon, the [34:02 inaudible] document you write before you start your project of what the PR is going to look like for that particular project of that particular feature. What does Google use?

Ivan Santamaria: Google evolve quite a lot while I was there. It’s a mix. It really depends on what the org wants. And some orgs are more process-oriented and some orgs are more product oriented. A number of orgs don’t have TPMs. So it really depends on how they split the work.

Mario Gerard:  And that’s like micro cultures within each of these bigger organizations.

Ivan Santamaria: Absolutely. Yes.

Mario Gerard:  So it’s kind of important to understand what the culture of that particular organization or business unit is.

Ivan Santamaria: I’ve been on a lot of meetings in Microsoft where they say, Oh, the ratio of this stage of the product is three developers for one [34:54 inaudible], that type of stuff.

Mario Gerard:  At that time, I think even when you were there, probably there was QA too, because I was a QA manager as well. I think you have [35:05 inaudible].

Ivan Santamaria:  So this discussion about ratio, like doesn’t exist in Google. Doesn’t exist on Facebook. It is really like, okay, what do we want out of this person? And sometimes the leadership will come up and say, might be communication, might be process, might be some specific results, might be lack of an integration schedule. And then this person comes in to actually solve a problem. It’s not really aid I have a bureaucratic view of how software development works is more, a pragmatic need that you walk into go solve. And by the way, I don’t say bureaucratic as a curse word, it’s like, it is a teary of management. The idea that you design the org [35:46 inaudible] the results you want. Then you populate that org. As opposed to a talent base direction, where you say, here’s the talent I have on my organization. This is what I [35:55 inaudible] out of this. So there’s a lot of stuff in between, but there are different ways. Like office is famous for I’ll design the org that delivers what I need. I’m going to look like my competitor. And then I’m going to put the right people in place. And this is how I’m going to go compete.

Mario Gerard:  It was the startup, right. I was just thinking about a startup, right? Where you hire the right talent. You hire, if you’re doing something like NLP, you hire a data scientist, you hire your NLP engineer, NLP guys. And then you have a basic front end team. So you will get the right talent and then you design the organization. But the stuff that might not matter at all.

Ivan Santamaria: So this is another difference. So if you go in an organization that’s mature and is on this phase where they think they have a template and ratios is one way. If you jump on a place where no, it’s like, we don’t even know what we’re going to do because we don’t know what kind of talent we’re going to attract.  It’s a completely different thing that you go add to this particular group.

Mario Gerard:  So summary would be that you need to understand the different value systems across any organization that you want giant. And it’s probably good to understand that before you joined the organization so that you have, you also change a good number of jobs.

Ivan Santamaria: I did. Yeah.

Mario Gerard:  Yeah. You have been at Microsoft, Google, Facebook, and then you’ve been at some other places before that.

Ivan Santamaria: I’ve been Inside the corporatization jobs as well.

Mario Gerard:  Yeah. You changed jobs quite a few times at Microsoft because you were there for 10 years.

Ivan Santamaria: [37:20 inaudible] too. So remember when I mentioned, like, I optimize for happiness and I say, this is the task I want to do because it makes me happy. And it gives me the opportunity to have the type of satisfaction. You know, at some point I find something better and I move on. One of the things I like to do is I really like the ones. I like the idea that I don’t know what to do here. Let’s figure out.  The hardest, the most, the [37:46 inaudible] problem, the gnarliest the problem, the happier I am.  So for me, we want to have more of that. So if you look at my resume, you’re going to see a lot of [37:55 inaudible]. That’s it. That’s what I crave. That’s what makes me happy. When we finally figure out and have some success, I have an amazing amount of satisfaction. You put me on a V3, I don’t have as much satisfaction.

Related read – How to create resume for a TPM Job

Mario Gerard:  And that’s also because at V3, it’s a more iterative effect. And the effect is much lower for end customer value, right? Because most likely 80% of the problems are solved at a V3 stage. You’re maybe hitting 20% of the problems after that, which is, you know, I don’t know, I see you not agreeing.

Ivan Santamaria: I do agree, but there’s always a trick, right? Yeah. So you know, I said something about office. Let me say something I think is brilliant about office. So at some point there are 98% of the market. There’s nowhere to go but down. So what they did is they redefined the market. We’re not a productivity suite anymore. We’re a platform. Boom! They got SharePoint. You’re always want to be on like all the top five, but you don’t want to be the number one on the market. So when you get the V3, V3 is time to find an adjacent markets for you to redefine what you are in a way that you are no longer the leader and you have to go stretch yourself. And now you compare yourself with the slightly bigger competitors, and then you have to go do this stuff.

Mario Gerard:  If the organization has the stomach for it. Because I think Microsoft is a beautiful organization. But not a lot of organizations have the stomach to go say, okay, we’re going to redefine the market. Sometimes it’s just very incremental work. And that’s why I think, so I worked on v1s. And the reason I’m at Oracle right now is because we are building out our cloud. For me personally, it’s a rocket ship right now. Because we are, you know, we have a long way to go. And it’s a very interesting place to be building, be one of several different things. And I think that’s a little different scale. I was talking to my manager like a month ago and we were talking that TPMs who build the ones have a different skillset versus TPMs who are in a sustaining mode. It’s a different skillset. So it’s like some people excel in this. And some people excel in that, not to say that this is good versus that is bad. Or this is high skill versus that is low skill. I think you really need to know where you’re happy and where you can do the most amount of effect because you put somebody who’s very good at sustaining engineering into a V1 product they might not be successful or the other way around.

See also- Important Technical Program Manager skills

Ivan Santamaria: It’s funny. Because you know, optimize for happiness and yes, cavate you need to add enough value that they pay you. If you want to be unhappy, let me tell you I’ve been poor. And then like, I was very unhappy. It’s like people that say that money doesn’t bring happiness. Let me tell you, they have not been poor. It might rent happiness. Let’s put this way. It doesn’t buy it, but you can rent. So yeah, and you need to add value in those things, and you need to enjoy what you’re doing, because the job is difficult, right? So you need to have the things that bring you joy. Otherwise you burn out. It really happens. Going back to metrics, and how you measure  impact is, TPMs are less objective. I work as performance engineer. When I reduce CPU usage by 5%, congratulations, I just reduce CPU usage by 5% given the workload. When you work as task manager and you find bugs, here’s the bug list.  If you work as a developer and you say, here’s my feature list and say, here’s the feature list, right. You can actually go and use [41:49 inaudible]. So I go out to my communication streamline [41:56 inaudible] how do you measure this? So it’s more difficult. It’s more fuzzy and whatnot. So yeah, it has this, that’s specific to the role that’s different than yours. So you need to figure out what artifacts you want to produce, and you want to be able to count those things as well.

And that my friends is end of part one of the podcast with Ivan. I hope you really enjoyed it. Do check out the next parts where Ivan talks about his secrets to getting promoted and so much more. Also stop by www.mariogerard.com and follow my blog. Thank you, see you on the other side.