TPM Podcast With David Glick – Part III

Mario Gerard: Welcome to the TPM podcast with your host Marion Gerard. This is part three of the three part series with David Glick. If you start here, I would definitely recommend going and listening to part one and two. 

How do you ensure that information flows to you and other leaders within the organization?

Yeah, well said.  The other the question I had David was when you’re running these larger organizations, 300 is fairly large, 3000 at Amazon, which we’re early talking about that’s also fairly large, right? Extremely large. How do you ensure that information flows to you and other leaders within the organization? How do you ensure that you kind of get a sense of where are my resources utilized? How are my programs running? 

What’s the health of my team. Like you want to know so many things. And how do you ensure that kind of information flows to you and other leaders with the organization?

David Glick: This one’s very hard for me. When I was growing up. When I was originally at TPM in like 1999, my skip skip skip level was Charlie Bell. He was the VP. He’s pretty famous Now, he was the number two at AWS. He just went to Microsoft, but he would get all the managers and TPMs in a room. And at the time it was about 20 people in his organization. And he’d have a project list, which was managed by the manager of projects, manager of TPM or whatever. 

We’d go through red, yellow, and green, and he’d ask questions and we’d sit there for like two hours. And these things always expand in the number of people, the amount of time you spend. And over time, it became sort of normal for everybody to sit there and type on their laptops while the meeting was going on. And so you’d have this background noise of keys chattering, and Charlie was really good at it.

And he could hold the attention to the room. I was just never good at it. And so it was like pulling teeth for me and everybody else who was there, hated it because they had to be there. And they’d talk about their one project. And then they’d sit there for another hour and a half. 

Mario Gerard: It’s an expensive meeting. 

David Glick: It’s a very expensive meeting. AWS is famous. They scaled that up to operational review meeting of three hours every week, which Charlie ran. And what I found is the bigger the meeting, the bigger a leader you need. And Charlie was the biggest leader I know after Jeff Wilkey and Jeff Bezos. So maybe Dave Clark. 

And so he was able to keep the attention in the room and he would teach. And so it was expensive, but it was valuable for everybody to learn from the lessons of others and learn from Charlie’s wisdom.

I was never as good at that as others. 

And I never liked to have this idea of a central PMO, because what it meant was every time it was a big project, someone would come to me and ask me to sign a TPM or a PM or someone to the project. So then it put more stuff on my desk. You always had a limited number of these TPMS. And so I had spent all my time doing resource management rather than focus on people. 

I don’t know what the right answer is. The best thing I’d found is like status reports. I think two things. One is written status reports that go out every Friday. This was again, Kim McMillen was my old boss. Who’s best TPM ever. She would say, if you only report the news, when it’s good news or bad news, then people see it as good news or bad news. You need to report the news every week. And then it’s just news. 

This thing slipped or this thing launched or whatever, you want to have a cadence of, I’m getting my news today, every Friday or every Monday, I get my news.

Mario Gerard: And that’s across the entire organization. It’s an organizational standard that every Friday news is going to come out and probably news is going to be available at this. Or there’s a posted place where everybody’s updating within certain guidelines of how it needs to be updated. And what’s captured.

Emails – the highlights and the lowlights

David Glick: A lot of it’s done through email. 

Mario Gerard: Oh, really? Interesting. 

David Glick: Because I’m not going to go into confluence or whatever, read every single project thing. So I get an email. It should have like highlights and lowlights. What has changed this week and then a link to the project plan if I want to go deeper. So I think that one’s very powerful and our operations team actually does a better job than the tech team. I guess.

Mario Gerard: Somehow I do feel that ops are always very good at because that’s their job I feel. They’re really good at number crunching. They’re really good at producing very accurate reports, kudos to all the ops teams. 

David Glick: And so every Friday my email fills up and I read all the status reports and it takes me 20 to 30 minutes in the evening on Friday night, which by the way, doing it Friday afternoon is not necessarily good because then I read them at Friday night and send emails Friday night, asking questions. Cause I think people deserve to have questions asked. 

Like you send these things out into the ether. You never hear anything. You don’t know if it’s good use of time. So I try very hard to read all of them and send questions out. But the problem is it ends up landing in people’s box on Saturday morning. And so they think they need to reply over the weekend, which is a problem. We do want people to take their time off because, they’ll get cranky if they don’t. 

Mario Gerard: It is hard though. Maybe you should send it in a delayed timer.

David Glick: Yeah. You know, there’s a schedule send function in Google.

Mario Gerard: Yeah. In Google and in outlook as well. You could probably do that because if I receive an email from you, David, I would want to reply to it. 

David Glick: Yeah. And it’s a problem, especially because many of us who rise up to senior levels like to work, I don’t want to say workaholic. And I like to drink, but I’m not an alcoholic. I like to work. I don’t think I’m a workaholic. Fun for me is sitting around reading my email and finding out what happened this week. And so we want to make sure that we’re not burning people out and we want to make sure that everybody has the right prescription and dose of what they need. And that’s different for every person.

Mario Gerard: Absolutely. How about like NBRs, QBR, weekly business reviews, monthly business review and those kind of things. Do those help in assimilating information, especially when you’re a larger team.

David Glick: We did monthly business reviews on my team, which was like a deep dive, six pager on everything that’s gone on that month. I found them pretty helpful.

Mario Gerard: That’s every director, every product line. How do you build that? 

David Glick: At the time I had three directors and so each of them would write one. 

Mario Gerard: Got it. 

David Glick: I’ve been not diligent in pushing people. And the team would often be like, oh, you know, we’re really busy this month. Can we skip this month? Okay. And then we have a companywide NBR, which is less detailed, but broader. And so we see the high level, red, yellow, green for okrs, but it is area of improvement for me. So I guess the best thing I can say is I hire people who I trust. 

Who are better at that than me and who are more in the details than me and I have to audit that they continue to be, and I need to hold them accountable. But again, trust is so important, especially with these senior level roles which have high blast radius. 

Mario Gerard: That’s true. Yeah. I think also like having done so many mbrs and QBR and all these business reviews, I feel it’s a lot of effort. It’s a tremendous amount of effort to put a monthly business review together. I’ve done it for a team of, I think 600, 700 people. And it’s incredibly, unless you have of all the mechanics of how to do it, and you’re doing it at a fairly regular basis. And you know, all this data is going to come from so and so report, all this is going to come from HR. 

If you’re doing hiring, if we had outages, like you need to have all these things in place and you probably have one person who’s dedicating 50% of their time collecting all this information and putting it all together for you. This is a lot of effort.

David Glick: Yeah. And those people are usually the PMO leaders. And so I always had cognitive dissonance that, so, you know, what does that guy do is his job, or what does that gal do is her job to Collate all this stuff? Is that really what we want? Or, you know, it ends up being like a senior manager or director level person. Like our most senior people are spending their time collating it information. And so I never liked that there was a guy who worked for me who built his own PMO. And my boss loved that. 

Cause he was like, oh, I have all the, you know, tick and tied, who’s working on this and who’s working on that. And he is like, can we expand this to your whole organization? Part of me, he is like, I sort of philosophically don’t like it, the pragmatic part of me, he is like, well, my boss likes it and it makes him happy, which will make my life better. So let’s do that. This is one that I struggle with continuously. 

Mario Gerard: I think sometimes you need a little bit of both. Ideally you don’t have a very large PMO. I think PMO, this is my personal opinion is that they become a little bloated sometimes as long as you keeping them in check and they’re not more than like five or six people and they have a very set goal and a very set function, they could exist, but you definitely want to have your TPMS within your dev teams or integrated within your dev organizations very deeply. So that the answer to different masters, what they’re looking for is a little different. I think they’re different types of personalities as well.

David Glick: Totally, senior level, like a director level person who could be a dev director or could be like a senior principal TPM or could be a PMO leader are three completely different people. And my general feeling, and this is a generalization, so I hate to say it, but I’m going to do it anyway. So with appropriate disclaimer is that those people who want to lead PMOs, there are some good ones. There are many not so good ones.

Mario Gerard: I completely agree with that. I think it’s the personality type and it’s how you’re supporting the organization. And whether it’s for the betterment of the organization or betterment for the team. I think that’s the delineation. Sometimes PMOs become so big and have too many processes, too many gates, too many checks and balances where you don’t probably need that kind of heavy weight process. And it’s trying to find the balance between the two.

David Glick: They want to control the roadmap. Cause of course, all the dev managers hate, we had a process called NPI at Amazon new product initiative or introduction or something. That was a bunch of principal TPMS in a PMO. And as we added product managers, more requests came in and engineers, it became bigger and bigger think. And they had these spreadsheet, which they used like a platter. To print out the grant chart. 

Mario Gerard: The six feet, seven feet.

David Glick: And they were trying to allocate engineers from, you know, a hundred different dev teams across 300 different projects and it just became unwieldy. And that’s when I think we talked about decoupling earlier. That’s when we said we have to simplify this, we have to decouple because the bottleneck was always the same was in the ordering and the payments and the platform teams. 

And so we went back to the platform teams and said, you guys hate this as much as we do. We need to give you as an organization, the ability to decouple yourself, to remove yourself as a bottleneck for this thing. And eventually that program got dismantled because we said we are decoupled enough that we don’t need these TPMs running around trying to fit everything into a square bag. 

Mario Gerard: It’s too much of an orchestration work and it doesn’t really add too much value of this extreme, extreme amount of coupling. I think when microservices originally came about, every team went ahead and built their own microservice in their own world. And then integrating between every microservice then became a very significant problem. 

I think teams that are fairly good now where it’s like, oh, we have an API. You can use it. You can do whatever you want with it. If you need any changes, if we need any additions to it, then we can do that. Or you can do that for us and on our code base. And we’ll just review it and approve the change or something like that. So I think teams have gotten better around handling this. 

It’s kind of interesting to see how that evolution has kind of occurred. 

So one final last question, totally off topic. I have been kind of like of understand myself, like personally what’s the right time to join a pre IPO startup? I feel like I am getting like very conflicting different type of answers from people. [11:17 inaudible] get your take because flex is a pre IPO startup and you’re hiring a lot of people. Like how do you evaluate that?

David Glick: Yeah, I’m sure you’re getting a lot of diverging opinions because it’s a very Ambiguous space. I left Amazon independent of joining flex. I retired and I spent a year off. And so it wasn’t so much like, should I leave a big company to go to a pre IPO start. Some of the things to think about are financial. I was financially independent when I joined flex. And so you can do quite well at a pre IPO startup. You can make millions and millions of dollars, but it’s all delayed gratification and it’s uncertain. And you know, people define this as risk and maybe that’s the right term. Maybe it isn’t. 

And so oftentimes we’ll have people who join, who have a spouse, either husband or wife who are working at Facebook or Amazon or someplace, or, you know, we have senior people who’ve retired and want to do stuff. Cause that’s the financial piece of it. 

Mario Gerard: You would most likely have to be financially independent because the base salary is lower than you’re probably going to be used to.

David Glick: Yeah. And you know, if you’re a senior manager at Amazon, you may be making 700,000 or more. You know, and startups, and this has changed to some extent, I think, especially in the bay area, in these well-funded startups, but broadly I think startups, your liquid compensation. Cause it’s not even base. Cause Amazon’s base is a, like 160, right? But the rest is in stock, but it’s liquid. Your base maybe 200 to 250. 

So you’re taking a 66% liquid pay cut with the promise of riches in the future. And this is more true for more senior people yeah. Than for an SE one. So that’s one piece. The second, I would say these big mega corpses are places to learn. And as long as you are in upward trajectory in getting new challenges and continuing to learn, and you’re making a bunch of money, that is a perfectly valid choice.

And I would encourage you to do that once you top out and everybody will. I tapped out at VP and I saw like, my trajectory was no longer rising. I went from a 3000 person team to the a hundred person team and which is all fine and good. Then you’re like, okay, well, you know, I’ve been learning for the last 20 years. Yeah. I’m not learning so much anymore. Let me go either apply what I know or learn something different. 

What the number one reason I find people going to startups are, is they find it hard to build at these big companies. 

The speed

Mario Gerard: Or the speed at which you’re building, isn’t fast enough. 

David Glick: Yeah. It’s hard to achieve things. It’s hard to get things done. It used to be, you get five engineers and you can go build a pricing system. And now like you can’t do anything with less than a hundred engineers. So what I found, the people who are going to startups want to build. 

Like I used to build, but now that I’ve managing 500,000, 3000 people, all I do is move the chess board around. And so I want to get back into the details again. So those are some of the reasons why people leave and come to startups. And then the other thing is over time and it’s not just Amazon, it’s any big company. And I think Amazon did better than anyone else at pushing this off for longer. Is that at any big company, you’re just going to have more layers. 

You’re more stakeholders and it’s more dependencies. More dependencies, less independence. And so that wears on you. And one of the big leaders there told me stress does not come from hard work. Stress comes from having a real or perceived lack of control. And so as a VP managing 3000 people, I had less autonomy and control. And I did as a TPM managing myself in the early days. 

Mario Gerard: Cause everything is so far away. 

David Glick: Yeah. Right. So I talk to people from all different places that I meet on LinkedIn randomly I’ll talk to them for half an hour and everybody has the same question. I was like, when’s the right time to leave the big secure startup, the big secure Mega Corp, be it Proctor and gamble or Walmart or target or Amazon or Microsoft or Google. And these are always the same frustrations they have. 

The answer’s always like is, is a perfectly valid choice to stay and make a lot of money at these big, it is also a perfectly valid choice to go chart your way elsewhere. And it’s not a one way door. If you’re a good performer. You can go back to a mega Corp, either the same one you were at or a different one and make even more money. Yeah. And so it’s parameterizing the risk and understanding like one of the things that I read in some book was always write down what is the worst thing that can happen.

Mario Gerard: Absolutely. 

David Glick: If I never find a job again, what would I do? Or, you know, if I leave Microsoft and then I hate my new job and I can’t go back, what would I do? And once you’ve written it down, it becomes less scary. And once you’ve written down a mitigation strategy for whatever, the worst thing that can happen is it becomes even less scary, especially people who are TPMS, sorry if I am talking too much, but especially for people who have achieved success at the Microsoft’s Googles and Amazons, you’re probably going to have many choices and they’re probably all going to be good. 

And so make the choice, go with your gut, make the choice you think. And if it’s the wrong choice, make a different choice.

Evaluating which startup to join

Mario Gerard: Coming back. How do you like evaluate which startup to join from a series funding perspective?

David Glick: I can tell you what I did. It’s not right or wrong. It’s just what I did and know flex had just raised their series B when I joined. And I said, you know, series B is early enough that there’s still outside, but it’s late enough that it’s probably not going to go out of business. Another friend of mine who ended up being a founder, he said, he talked to lots of VC and lots of people. And they said, you should either be a founder or go late stage series D or E.

Mario Gerard: What’s upside with D or E?

David Glick: Well, you’re closer to liquidity. And so maybe you’re a year or two, away from IPO or, you know, a liquidity event. You know, I’ve been at flex two and a half, two and two thirds years. And we’re still, you know, years away from a liquidity event. I’ve got friends who’ve been there five, six years, have been making startup salary for five or six years, they’ve got a bunch of stock, which they can’t do anything with. And that’s a long time to be subsidizing. 

Mario Gerard: That’s hard work. Because you’re putting your heart and soul into it and you don’t completely know the outcome, you believe in the outcome, but you don’t actually know what the outcomes going to be until it happens.

David Glick: Yeah. We as humans I think are hardwired not to quit and hardwired, not to fail. And certainly many companies conflate quitting with failing and we do as humans. And so I encourage people. Probably the biggest thing that I’ve done too slowly in my career is to leave a job that I didn’t like or leave a job that had grown beyond me, or I never say, leave a job and go to a different one. 

Most of those leaves were at Amazon. Most of those changes were there. I never transferred and said, I should have waited six months. I’ve always said, yeah, I should’ve gone six months early.

Mario Gerard: It’s always like that. I feel like it’s probably like we as individuals coming to terms with it and accepting it. It just takes us more time as individuals I think. I think that was my last question, David, thank you so much for joining us today and for sharing your thoughts on everything TPM and so many other things we spoke about, it was such a pleasure of having you for our listeners. Thank you so much, David. 

David Glick: Yeah. Thanks for having me. And it was a fun chat. 

Three Part series with David Glick. I really hope you enjoy that because this is such an enlightening conversation. Definitely follow the TPM podcast on your favorite podcast app. Leave a review if you like. See on the other side, bye.