TPM Podcast With David Glick – Part I

Mario Gerard: Hello, and welcome to the TPM podcast with your host Mario Gerard. Today, we have a very interesting guest with us, David Glick. A lot of you might know him. He’s been a mentor. He does a lot of linkedin posts and he’s a cool person to follow, so do follow him. 

He’s worked at Amazon For 19 years and was a VP of Amazon fulfillment technologies. And then Amazon tickets. He left Amazon to go join as a CTO of flex. He has incredible, incredible experience in building high performing teams and building high performing organizations, some very excited to have today with us and share his thoughts. 

David, thank you for being here with us today. And why don’t you introduce yourself to our audience?

David Glick: Yeah. Hi, this is Dave click. Thanks for having me on Mario. You did a great job of introducing me, but I can say that most all of my career was at Amazon for almost 20 years. I’ve been at flex as CTO for the last three years. And so it’s been a fun ride at both of those places and I’m sure we’ll get into some of the things I did both at Amazon and flex. So I won’t take too much time with that here.

What flex is doing

Mario Gerard: Do you wanna like quickly go over like what flex is doing and maybe do a pitch because I know you guys are hiring like crazy too.

David Glick: So yeah. Flex is a marketplace which matches enterprise shippers. That’s big retailers and brands with logistics capabilities or fulfillment capabilities. And we work with six of the top 10 retailers in the us and we are building our own WMS, building our own transportation network and so on. 

And so we’re always looking for TPMS engineers, product managers, basically everything.

Mario Gerard: Everything, whole nine yards. Now that’s amazing. Did you say four of the top 10 retailers?

David Glick: Six of the top 10.

Mario Gerard: Six of the top 10 retailers, you work with six of the top 10 retailers in managing their logistic process?

David Glick: Yeah.

Mario Gerard: That’s something

David Glick: My goal for 2022 has been to, i’ve been assigned to get the other four.

Mario Gerard: That’s incredible that being operational only for like a couple of years and you’re able to do that, that says something about the product. So thank you so much for being here, David, to our listeners. What we are gonna do today is we’re gonna split the podcast, kinda two sections. The first section, we’re gonna talk about David and ask him what he thinks are the fundamentals of the TPM roles. We’ll go about the, we’ll asking questions about the role, the skillset, how to be a great TPM and those kinda things. 

And then the second part, we’re gonna ask him and we’re gonna like work around the topic of how high level leaders like David, who VP of like a hundred or thousand people or several thousands of people. How do they get the right people working on the right set of problems? And that’s what we’re gonna focus on on the second part. So let’s get started with kinda the first part here. So David, why don’t you kinda give us your take on what would you describe as a TPM role and, and the function of the TPM role?

David Glick: Yeah. Thank you. The number one thing that the TPM does is deliver. Like if you summed up the role in one word, it’ll be delivery. And so their job is to get projects or programs over the line on schedule and under budget or at budget. 

And so what does that mean? Have to be very detail oriented drive and your number one tool is the Gant chart, right? When are people going to get things done? What do they depend on, how much time is it going to take? And so you could stop there and say, that’s the job of the TPM, but what I found, and I don’t have a CS degree and Amazon talks about big T technical being someone who can write code and little T technical, being someone like me, who has led in technical places, but can’t write code. 

Anyway, What I always found is that if I was a little more technical, I would be more effective. And I guess if I was a lot more technical, what would be a lot more effective, but the point being, being able to understand deeply the trade offs, both in technology, as well as in your domain makes folks much more effective tpms. 

And so you own the schedule, you own the resources, or you don’t actually own the resources, but you control the resources that you don’t own. And then you have to be good at making trade offs and getting people to commit.

Large Scale Project – Managing heavy dependencies and resource management

Mario Gerard: That’s an interesting take. I also like about when you spoke about G charts. That’s a very interesting take because though we work in tech, it’s interesting that a lot of large scale tech projects are actually managed, though They worked at an agile level, right? Like teams are working independently, they are managed at a milestone level. 

And I think it’s kind of forgotten sometimes that large scale projects we do use Gant charts. We do use Microsoft project to something very similar it to that Smartsheet or something like that, where we manage these heavy dependencies and resource management, right?

David Glick: Yeah. And I was working on a project for, at Amazon around pricing and we were working with a subsidiary team and they were in San Francisco. This was before everybody was remote, but they were in San Francisco. We were in Seattle and we weren’t getting the progress we wanted from them. And so my boss said, okay, let’s get on a plane. We flew down to San Francisco and we sat with them all day. And we like went through all the stories and the sticky sheets and all the things you do for agile. 

And at the end of the day, I said, great. When can you deliver? And the guy said, well, many software development professionals today think it’s not necessary to have delivery dates cause it’s not effective. And I was like, look, I’m about to fly back to reality. And there’s an angry guy with an SVP on his t-shirt who’s gonna yell at me if I don’t have dates. And so it is fine and dandy to have this agile. 

And by the way, i’ve run agile teams. And I think it’s actually the right way. But You have to have some high level understanding because if you’ve got teams, you know, dozens of people or hundreds of people working together on a project, it all has to come together at the end.

Mario Gerard: And there’s no way to do it rather than go old school tradit and use Gant chars and use Microsoft project or something. Some kinda similar type of a tool, which gives you that level of granularity and tracking because otherwise you’re not gonna be successful, especially if you’re running these large scale projects. 

David Glick: One of my colleagues and friends from early days of Amazon, we didn’t use Gant charts. We used, he just used Excel.

And in the end, like a project or a TPMS job is to get a set of action items and then action items defined as sort of a description, an owner and a date, get a set of those and probably a dependency, get a set of those written down with owners and dates and that will allow you to March forward. 

And so he would just come in and say, what are the five most important milestones on this project? Yeah. And you know, who’s the owner and when’s it gonna be due. And if we couldn’t get a date, we got a date for a date. 

Mario Gerard: Yeah. And that’s just the simplest way to take things forward. It doesn’t need to be fancy. Doesn’t need to be too complicated, especially if you are working with teams and you can just work off Excel. That means your teams are ideally meeting those targets. And as long as they’re meeting those targets, you don’t need to do it too much of over-engineering in creating the project plan. 

If they’re unable to meet the milestones of this slipping or those kind of things, I think the TPM probably needs to get a little more involved there and help out more. 

David Glick: Yeah. And I would say what you wanna do is front load all your dependencies. And so, because the thing that kills projects are not, it’s not hardware and it’s not software. There was a book called Peopleware. Which is working together and communicating with each other is the things that kills projects or not working together and not communicating.

And so if you have one team who has a little bit of work to create an API, to unlock other teams. They should do that work first, even if it’s a stub that returns assertions or returns dummy variables, at least you can know it’s working and the other team can be unlocked and move forward.

Computer Science Degree – Being technical?

Mario Gerard: Absolutely. David, you spoke about, you know, big T and the little T, you also spoke about that you are, you don’t have a computer science degree, but you are the CTO. You’ve been a VP for a very long time at Amazon leading one of the big technology, you know, development teams, both at AFT and Amazon tickets. And you’re a CTO now, like how do you say that? Or why do you say humbly that you’re not very technical?

David Glick: Well, I got my CS degree from the school of hard knocks at Amazon. I got the Amazon MBA, the Amazon CS degree and so on. But basically what I, the way I sort of upscaled my game was I got CC’d or called into every Sev 1 that we had in the fulfillment centers for like many years in the early days of Amazon. And I read all the Sev 2 tickets. 

And so I could see what breaks and what makes a bad system and what makes a good system. But then in 2004, I had worked as a, I was actually called a PM, not a TPM, but I worked my first couple years as a PM, then a manager and systems and networking. And then I did deployment and QA and sort of all the things that aren’t software development. And in 2004, I went to work for a woman named Kim Racmiller, who was sort of the first TPM at Amazon. And she created a lot of the TPM practices. 

But one of the things she told me, she was a great mentor for me is product process people. So when you’re a junior, all you have is the product you produce. And for TPMS that’s Gant charts, and for engineers, that’s writing code and the, a college hire junior engineer is not producing anything for the company while they’re sleeping. Like their value is typing on the keyboard. 

As you get it to a senior engineer or first line manager, then you’re setting up processes. Ticket reviews and Code reviews. Yeah. One of the processes we use to make the product more effective and raise productivity. And then as you get more senior to senior manager, director and VP, you spend a lot more time on people. And do I have the right people on the bus, do I have the wrong people on the bus? You know, how do I, I spend a ton of time recruiting. 

I spend a ton of time coaching and my team and I do performance reviews and calibration. We called it [10:28 inaudible] at Amazon twice a year. And where we look at, you know, who are top performers and who are the folks who aren’t meeting the bar and take action on those.

And so what I found is, you know, they say hire people smarter than you, or hire people better than you. I try my best to do that. And what I have, our social contract is they are going to do the things that are more technical and make a lot of the technical trade off decisions while I audit those. And then my job is to make sure that they have the head count they need that they’re being, they and their teams are being compensated appropriately. 

TPM Role and its value for organizations

Mario Gerard: So you are setting them up for success. Fantastic. So probably the next question I have is when we spoke earlier, you were saying, yeah, I’m a big believer of TPM role. Can you tell our audience, like, why do you believe in the TPM role? Why do you think valuable for an organization?

David Glick: When I was coming to flex the guy who recruited me described it as we have a great target addressable market, huge target addressable market, or Tam, great product market fit, and we need work on the product, but we need help executing. And so it’s, again, you know, 1% inspiration and 99% perspiration. Once you have your direction you’re going. And once you’re, you know, you’ve got great product market fit, then you have to execute and tpms are the Kings and Queens of execution. 

And so my example, when I joined flex was there weren’t any tpms. And we had, we had a big project for the world’s biggest retailer or one of the world’s biggest retailers. And they had, we need these five features launched before we, or we’re not gonna sign up. And, you know, we are trying to commit to that without doing any bottoms up work.

We basically said, we have to commit, or we’re gonna lose our biggest customer, so we’re gonna do it. But then once we committed, we said, where’s the Gant chart. Like who’s working on this. And no one could answer that question. And so the first thing I did as I hire a great TPM and so serendipity brought her to me and she came and said, you know, I need all the engineers dedicated to my project. And within a week she put together a Gant chart. It actually like integrated Smartsheet with JIRA. So that all the, all the cards in JIRA rolled up to the Smartsheet and you can see the dependencies move when things were late. And that is exactly what I think of in the TPM role.

Skills needed to be a TPM

Mario Gerard: Yeah. It’s working magic almost, right. It just gives me, it’s so important. And sometimes it’s not valued enough, I think at certain places. So, it’s fantastic that this person came in and they were able to like move the needle and make things happen. So talking about that, like, what do you think are the core skills like TPM should have?

David Glick: So the first thing is they need to be super detail oriented and you know, they need to be, they know exactly what’s going on with every engineer working on the project or every product manager working on the project. They need to be focused on writing all of those things down, organizing them. As I said, putting them into a Gant charter, Excel spreadsheet, those are just tools, but making sure that everybody knows what’s going on. 

Realated Read: Tips to Master Writing for Technical Program Managers

So communication will be the second skill. And then third, and I don’t know why maybe I should have put it first, but they need some technical chops. People say, oh, they need to be able to call BS on the engineers. I don’t think that’s actually true because engineers aren’t trying to put one over on you. 

Mario Gerard: I think, especially this day and age. I think maybe if you’d said that to me, like 10, 15 years ago, I might have a agreed a little bit, but I think our engineers are so well motivated these days that you don’t, they’re not gonna like give you incorrect information.

David Glick: Yeah. And you know, they need to be able to challenge the engineers and say, have you thought of other ways, are there better ways to do this? Can we front load the API that another team needs and so on, so they need to be technical enough. 

David Glick: And they have to have sort of instinct or intuition, which sounds like magic, but it comes from scars, right?

Mario Gerard: Yeah. Battle scars.

David Glick: Battle scars of, oh yeah, I didn’t ask this question last time. One of the fun things I found that I’m always challenged with is I’m a trusting person. And so if someone says, I’m gonna deliver this, don’t worry about it. I tend to trust them, especially if I know them and known them for a long time. And, and so it always feels like you’re distrusting them when you ask more deeper questions. 

But what I found over the years is you have to ask more deeper questions because you have more experience. And because you may have thought of things that they haven’t.

Mario Gerard: Yeah. And I think that’s what great managers bring in so much of insight. When I think about the managers who i’ve worked with, always people who either they’re pushing the boundaries a little bit and trying to make you think outside the box, or they have such a rich experience of working in similar types of problems or in the same problem space that they know exactly like what you’re gonna encounter before you even go and encounter it. So it’s like fascinating.

David Glick: Yeah. I like to tell this story. When I took over Amazon fulfillment technologies we were coming up on the Christmas peak or the holiday peak and like the year before they had lots of Sev 1 and Sev 2s. Lots of operational problems. And I was a director. I was trying to get promoted to VP. And so I said, I’m not going to get, not promoted because we had holiday problems. 

And so I made the team go through and put together a template and we went through sort of soup to nuts, all of this things that could break. And a lot of those were on configuration. A lot of it were on scaling, you know, and the team hated it. They’re like, oh, this is bureaucracy. We’re wasting time. And then it was probably 40 documents. And so I spent 40 hours with myself and my directs reading each one of these and giving feedback. And it could have been like on JDBC timeouts or the number threads versus the number of connections and a load balancer and all those details. 

And for every team, even the most senior and the smartest, we were able to give them some feedback on things to do better. And what happened is we reduced our number of sub two tickets by like 90% year over year During that time.

Mario Gerard: So you did this every year. Is this like routine process that you try to catch it before things happen?

David Glick: Yeah. And so this was, we called Q4 prep and that first year, and the second year I did that personally, because what I did is built trust with the team and the people who stuck around and survived Christmas. And so on said like, Hey, this was, we thought this was bullshit. And what we found was this was actually really effective. And we appreciate that You took the time and you built trust with us by taking the time to read all these. 

Then over time as the team went from, you know, 200 people in the dev organization to 300 to 500, we were able to decentralize that. And so the people who were my directs, they did those with their teams. So I didn’t have to be involved in everyone.

Communication skills and the tech aspect

Mario Gerard: That’s very interesting, you know, how that worked out. So recapping the most important skill sets or traits, which a TPM should have, you said detail-oriented, needs intuition, has to be organized, good communication skills and the tech aspect, right? So that’s kinda sum it up.

David Glick: Yeah. And I would add one more sort of just general leadership called gravitas or whatever. One of the things that when I started as a TPM all these years ago, I was always like, Hey, could you do this for me? And kind of meek. And over time people were like, no, no, no, no. Like people should, scurry out of the hallway to their desks when you walk down the hall, right. You are the one who’s leading this project and they’re all accountable to you. 

And so you need to be telling them what to do. It needs to be a two-way communication, but you need to be, I don’t think fear is the right term.

Mario Gerard: Is firm the right word.

David Glick: Yeah. I think you have to be firm and you have to challenge people.

Mario Gerard: Yeah. And hold them accountable. I think that’s the key there. Right. Holding them accountable, ensuring that they’re meeting the commitments and those kind of things. And that should ideally fit into the whole leadership bracket, which you were talking about. Good points. 

Do you think there are like certain particular characteristic for rockstar TPMS, like TPMS are like, hit it out of the park. Are there anything, are they exceptional in any one of these skills or how do you look at that? Like what do you think are like exceptional TPMS? Like what do they have like that’s special.

David Glick: Yeah. That’s a great question. I’m trying to think of a great answer to that. The biggest thing probably is they need to have backbone and trust, but verify, you know, I think there’s a skill that you can build, but I couldn’t teach you, you know, you can’t sort of lay things out, but you know, the best tpms I have, Matt are people who can yell at their people, hold them accountable. Maybe not yell is the right word, but they can push people, but still have the love. Still be loved. 

And so we did an integration with a company we bought and we hired the best TPM, he is director level, best TPM in the company we had him internally transferred to us and he would go out every week or, you know, spend at least half the month out in Boston, helping with the integration. And he would push those guys pretty hard, but they still say, Hey, when can Jim come back? When can Jim come back? And so being able to have tough conversations and Ask great questions while still being respected and loved is I think one of the things that sets people apart.

Mario Gerard: Yeah. That’s definitely an innate quality. I feel so. Not every has it. Sometimes it’s something which maybe you can grow and tinker a little bit, but it’s something which you have as a characteristic within yourself, right? How about like, things like being able to deal with like super ambiguous problems? 

I feel like TPMS who are generally when I look at rockstar tpms, that’s one thing that they’re really good at.

David Glick: Yeah. And I would say simplifying, we had a leadership principal to Amazon called invent and simplify and like bringing clarity. Clarity is sort of the opposite of ambiguity. One way you bring clarity is by simplifying things. And so if you can bring clarity, you know, because everybody has these different languages. When are you gonna be done with this? Or i’ll be done Friday. And that’s like, well, when do you mean by done? Code complete. And so you have to say, okay, when I say done, I mean, this other team can call your API. 

Will they be able to call your API on Friday? Oh no, no, no. That’s like three weeks from Tuesday because I have to put in the test and it’s only a private API and all these things. And so being able to bring clarity as to what we mean when communicating across teams or between teams is important and then agreeing on sort of the technical design, because team A may want to do one thing and team B may want another. 

Another way of simplifying that is to decouple it as much as possible.

And we had this term decoupling which meant removing dependencies. And so the idea is that, like the thing that kills these big projects is the cross team communication, the cross company communication, or at least at Amazon, that’s how we were set up is everybody was their own captain and had their own projects. 

And so you do a big cross team, cross company project, like launching up country, which took 400 teams. The things that killed it were that the dependencies on each other. And so if you can remove or reduce those dependencies, that’s great. At Amazon, we worked very hard to do that. At flex We continue to try to reduce cross team dependencies, but we’re at a much earlier stage. We have a, you know, a single binary that many of the people on the team work in. 

Many of the projects take two to three to five teams to build this feature. And so if you can get to a place where you’re relatively decoupled, you’re going to be much more effective.

Impact a TPM has on his or her organization

Mario Gerard: That’s a good point. So clarity, focusing a little bit more on tech design, having a backbone, all those kinda core skills like, you know, rockstar TPMS can have. That’s fantastic. How as tpms, like run programs and deliver programs, how do you think they can assess how impactful they’re like, what’s your take on like the impact a TPM has on his or her organization?

David Glick: That’s a good, but hard question. The number one thing is do their projects deliver. Do their programs deliver. And then you get in that sort of externally it’s non metric. I mean, in some ways it’s metrics based, did you launch this thing on time for a customer.

Mario Gerard: Is that like the most fundamental, like, if you’re thinking about it in a binary fashion, that’s the most fundamental thing, did what you say launch when it was supposed to launch?

David Glick: I mean, I think that’s the most important thing, especially to the people who are writing your performance review, right. The upward, and then there’s a secondary item, which is like, did you leave dead bodies behind? Yeah. Like, how did you deliver, did you end up with everybody working over the weekend because you didn’t think of something, did we have lots of bumps in the road after you launched? And so, you know, those are like the best tpms, you know, they’re gonna deliver on time. You know, they’re not gonna burn the team more than necessary. 

You know, that once it’s launched, it’ll be launched and you won’t have to go back and clean it up. 

Mario Gerard: You don’t have too much cleanup. That’s true.

David Glick: And you understand exactly as a customer, you understand exactly what you’re going to get when this person delivers or when this team delivers.

Mario Gerard: That makes a lot of sense. I feel especially the dead bodies aspect. I feel, I know tpms, or I know certain even organizations, sometimes they kill the whole workforce in delivering something, which is super critical. Absolutely understand that it’s a make or break, but at the same time, it’s at an incredible expense of burning everybody out. Those are, I think, fantastic ways to like measure how impactful you are, focus on the delivery aspect. You go ahead.

David Glick: Yeah. I wanna make one more thing clear is like, people broadly the time of a, a project don’t mind necessarily working really hard. Like I call these crucible moments, right. You’re working hard. You’re under pressure. This is when you learn in many ways, this is the most fun. So the TPM I was referencing before calls this type two fun where it’s not actually fun when you’re doing it. But when you look back when you’ve achieved something, you’re proud of it. And that was fun. And so many people like to have that kind of fun. 

What they don’t like is having to do work two times or three times. Having to work over weekend. Yeah. And so when we talk about burning people out, that’s what burning people out. Like working hard to create something out of nothing to engineer something, to build something like you can’t do that, you can’t work 60 hours a week all the time. But if you have a project that goes for six weeks or eight weeks, and it’s super important and you’re working with people you like, and it’s well run, you’ve got great TPM. 

Like those are the most exciting time, at least in my career. And what you find is that road, when it happens, it’s a great thing, but it doesn’t always happen.

Mario Gerard: It’s a great feeling. It’s a great sense of accomplishment and a lot of team spirit and comradery, right? When you go through this altogether, and that’s a very valid point, that time is well utilized and you’re not mismanaging People or their time while you’re going through a hard program or project like that. That’s a good point. 

The end of part one of the three part series, with David Glick. If you like that, definitely share with your friends, like the podcast on the podcast app and leave us a review. See you in part two.