TPM Podcast With David Glick – Part II

Mario Gerard: Hello, and welcome to the TPM podcast with your host, Mario Gerard. This is part two of the three part series with David Glick. If you haven’t listened to part one, definitely go and listen to that. I hope you enjoy this. 

Another question I had for you, David is TPMs Generally don’t have people reporting to them, right? So they always have to influence without authority. What would be your key guidance on building this skillset or give like a playbook for us? How do you influence without authority?

David Glick: A lot of that comes from the organization as much as from the TPM, you know, I’ve led projects and call it PM or TPM or director or VP or whatever. I’ve led projects, where everybody was aligned. You know, Jeff Bezos is like, this is the most important thing. And Dave Clark and Jeff Wilke, those are very easy projects to TPM. 

Mario Gerard: When you have that executive backing

David Glick: Yeah. And you can influence without authority. And then if this is a project that some junior person came up with and asked you, Hey, go do this thing. That’s much less fun and it’s harder to influence without authority. 

So one way to do it is by picking the right projects because everybody’s bought into those and maybe that’s delegated authority or sort of reference authority. 

Mario Gerard: I completely what you’re saying, I see that you are riding on somebody else’s authority or you’re riding on a combined single vision. The organizational vision.

David Glick: Yeah. And in getting the way to influence without authority is too early on get agreement and buy in from all the people you need. Again, that’s easy if it’s tap down mandate to some extent, but bottoms up mandates are better broadly. If everybody, all the engineers are bought in and excited about building something from nothing or building this new feature or growing the revenue or all those things. 

And so I think it’s a skill to get people excited and get them bought in before you ever start writing code.

Responsibility – Product manages / TPM / Dev Manager

Mario Gerard: And the skill to being brought in and get excited is definitely like a very valuable skill we need to have in today’s environment. Is that more of a product manager’s responsibility you’d think? Or is it like a TPM responsibility or is it a dev managers responsibility?

David Glick: The answer is always all, all the above, but most of my time at Amazon, we didn’t have product managers.

Mario Gerard: Oh, really? Back in the day, just because it was like AFT and tickets. You were like very young organizations.

David Glick: Yeah. I mean all the way back to pricing, you know, I led the pricing team in 2005 and 2006, 2007, I think. And there was no product manager. Jeff B was kind of the product manager. He told us what to do, but like I was the person who operationalized what we were going to do from the product.

Mario Gerard: That’s so interesting.

David Glick: And this was the idea that two pizza teams. Is you don’t need a separate organization of product. And we did that for a long time and it was sort of the [03:00 inaudible], the glory days of development, because you didn’t have multiple organizations making decisions together. You had your subject matter expert or customer who was asking you to do something. And then as the dev leader, I was doing that for them. And so in many ways that was great. 

But we also built a lot of crappy software back then, you know, poor usability, didn’t take into account edge cases, all those things, because we didn’t have the skill of the product manager. Many of my friends tell me, oh, you hate product managers, which is not true. But I do remember when we introduced product managers and that was around the time we started building devices, like Kindle hardware is much harder to build than software. 

Mario Gerard: And once it goes out into the world, there is nothing you can do about it. 

David Glick: Yeah. And so product managers came in and said, oh, you know, we control the roadmap. And I was always on the technical side and said, well, no, you know, my engineers are the ones who checking in code. And so they control the roadmap in the end. And so nobody was right or wrong. It just caused conflict. And so managing conflict and bringing clarity became the job. 

Cause you had more to stakeholders rather than you being a benevolent Monarch or dictator. But my thought is both PMs and TPM, both product managers and technical program managers do three things. They ideate, they prioritize, they execute, but there’s a slider of how much each one in those does. So product manager may do like 60% Ideate, 30% prioritized, 10% execute. I’m just making that up. Whereas a TPM maybe do 10% Ideate, 30% prioritize and 60% execute. And so that’s how I think of the difference between PMs and TPMS.

 

The idea of a Single threaded leader

Mario Gerard: Can you add one more for the dev manager? Like how would you see that? And in the same scale.

David Glick: They’re probably somewhere in between, but they also have this fourth bucket, which is like, Manage and counsel and give feedback and hire and fire and all the things managers do. And so oftentimes we will take a manager who may have been a TPM previously and say, Hey, you know, you’re the TPM for this, but it breaks our rule. The idea of a single threaded leader. 

The great thing about a TPM is they can be the single threaded leader, the captain of a project or something where their job is very simple. They deliver this feature or they deliver this program or they deliver this project and they don’t have to worry about performance management of their team. They don’t have to worry about hiring. There’s a lot of things that they don’t have to worry about. And so it’s very pure that they’re out there as an individual contributor and their job is to drag this thing over the line.

Mario Gerard: Yeah. That has been my last four years at Oracle where I’ve had several opportunities probably to lead teams, to build teams. And I’ve always been like, no, I just want to be a single threaded leader. That’s what I’m good at. And not worry about all the rest that comes with it. 

If I need like four more TPMS, I can get four more TPMs to come and solve this problem. But my only problem is to solve that one problem for you. And it gives you, so much of focus and clarity and time that that problem really actually needs, which you can’t do when have 20 other competing priorities. 

David Glick: Totally. And our job as leaders are to simplify people’s lives. I had a guy who was on my team, who we played world of Warcraft together. And I hope some of your viewers or your listeners get this. And like I was a warlock and as long as I just had to throw, what are they called? Fire bolts or witch bolt something and stand in the back and just throw, throw, throw. I was a really good warlock. 

But if I had to like cast fear over here and then run around in a circle to avoid getting hit and then cast my spell and then do this thing and that thing, I was terrible. And that’s what we make our employees do. I worked a lot with the buyers at Amazon, the retail buyers.

Mario Gerard: Third party Retail buyers.

David Glick: First party retail buyers. Like the internal buyers. And we built lots of tools for them, but they had to upload things to the catalog and they had to order inventory and they had to set prices and they had to negotiate with them. They had all of this stuff they had to do. And of course, no one could ever do all of those things. 

And so what we started doing is chipping away at that and saying, what, if you didn’t have to set prices that would give you an hour back of your day and more importantly, reduce the mental load on your mind. And then what if you didn’t have to order inventory? That’s another thing you just don’t have to worry about. We’ll take care of that with the system. 

And so as we reduced the number, the breadth of domains they need to be involved in, they were A, able to be more successful and we could bring in lower level folks to do those jobs because they were simpler.

Mario Gerard: Yeah. That makes so much sense. I think we started with single thread leader and we had a whole story around it. That’s super cool. I think I have maybe one or two questions in this side of the first part of the podcast. I think you covered this a little bit as a CTO of flex. How do you envision TPMs helping you make your organization most successful? I think we spoke a little bit about this, but I don’t know if you want to cover it again.

David Glick: I have another analogy. My career has been listening to people smarter than me. I’m writing down the things and copying the things that they do and say, this one isn’t from Amazon, nor from tech in general, but it’s from there’s guy called Al Davis who is general manager of the Oakland Raiders. John Madden worked for him and he said, the most important thing is to hire great cornerbacks. 

And the cornerbacks are the ones who cover the best wide receiver. And so basically, you know, football’s an 11 to 11 game, but if you can take a wide receiver and say, that person is just completely covered because I have the best cornerback, if I’ve got Dion Sanders, right. That may age me, but whoever the best cornerback is today, I never have to worry about that. And then I’m strategizing for a 10 on 10. And then if I’ve got a great cornerback on the other side, then I’m doing nine on nine and then that just simplifies my life. 

And so if I say, look, we have a project for our biggest retail customer or our biggest brand biggest CPG, but I know that Julia’s working on it. So I never have to be involved because I know it’s going to get done.

Mario Gerard: And then she’ll come to me, if there’s anything right. If she needs my help. 

David Glick: Yeah. And it’s my job to provide clarity, the team that this is the most important project Julia’s working on it, you will do what she says and Bob’s your uncle. And that’s a very simple direction as opposed to, how do I prioritize between these six different things that I need to do, by the way that leads into what is the right ratio of TPMS or, or even product managers, PMs.

Mario Gerard: Oh yeah. That’s interesting question item right down. Yeah.

David Glick: Because we, if you don’t have enough PMs, you’ll never go into new business lines. [09:16 inaudible] new ideas. If you have too many for the number of engineers that you have, you’re going to spin the engineers around because all the PMs are going to want their…

Mario Gerard: It Becomes really overengineered and very piecemealed. 

David Glick: And so again, if we can simplify lives for the engineers, that’s the best thing we can do as leaders. And I’m not best at that because, if I’ve got too much time oh, we could do this. Or why don’t we do that? You know, sometimes it’s better to just let the thing run.

Hiring different types of TPMs – Amazon vs Flex

Mario Gerard: And then focused right on getting through your vision for the year, whatever that particular goal is. Fantastic. So would you hire different types of TPMs while you were at Amazon versus a startup Like Flex?

David Glick: Maybe, my initial answer is no, but as I think about more at Amazon, we would hire what we call general Amazon athletes or general athletes, and you can move people around. They can do whatever job. What we found at flex over the last three years is that we need more domain expertise, domain Experience.

Mario Gerard: As a TPM?

David Glick: As anybody, but as a TPM and a product manager especially. Because at Amazon, we had this idea of two pizza teams who are narrowly focused on one thing. And so, yeah, two pizza team that was on picking, but not picking just the algorithm for picking or just the UI for picking. And so a TPM who’s responsible for the picking algorithm can get very deep into that. And there’s lots of scaffolding built. Lots of tools. At flex, There’s no tools. The domain is broad, you have responsibility. And so if you’ve never set foot in a warehouse, that is a huge disadvantage and vice versa. We can probably live with engineers who are not domain experts. 

If we have PM and TPMs who are domain experts and who can think about what happens if take a pragmatic side of, oh, we think it’s important to scan every item as it comes into the building. It’s like, okay, well on a truck, you know, a truck of 10,000 items, the nickel, an item, that’s a lot of cost to scan every item. So can we scan at the pallet level or at the case level? And so those are the pragmatic questions that someone with domain experience will ask early in the project.

Domain Experience

Mario Gerard: That’s interesting. And do you think that would be fairly similar for most startups? That domain experience definitely becomes handy or is almost like a requirement? 

David Glick: I think it is much more important in startups than it is. And the enterprise companies like Amazon. I think in particular things that deal with lots of humans need more domain expertise. And so like I’ve made most of my career from melting enterprise software, most of was internal to Amazon, but now it’s being shown to associates and managers. And so it’s enterprise software. And I described that compared to consumer software and in particular enterprise software, we’re removing protons and neutrons. 

Jeff Wilke famously said, and he may have copied it from somewhere. I don’t know. It’s much easier to move electrons and this move protons and neutrons. And so people may argue with me, but payments, if you’re building a payment, you’re moving bits from here to there. And so maybe just being able to build scalable systems, you can do that. Whether you’ve had payments experience or personalization experience or whatever. Whereas in fulfillment and logistics, it’s like, well, how long does a truck driver have to wait? Or, you know, what happens if you get an error message for this associated or what happens if there’s a missing item that’s not in the bin where you thought it would be. 

All of those physical processes and all those things where humans are injecting errors into the system, all of those you have to work around. And I think it’s very important to have some level of domain expertise for that.

Mario Gerard: Very interesting. That’s a very interesting way to think about it. Maybe if you have a very experienced product management team, you could help there, but I definitely understand where you’re coming from. That kind of an experience, especially in a startup where there are so few people as well, right. So everybody’s kind of wearing multiple hats. Everybody’s like covering for everybody else. 

So having that kind of domain experience definitely comes in handy and just to give our audience a little bit of more insight, like how big is flex right now? Very approximately.

David Glick: Yeah. You know, we’re about 350 people.

Mario Gerard: Yeah. So it’s tiny, right? It’s literally small team, running six of the ten of the largest retailers in the United States. Significant.

David Glick: No, it’s very leveraged, and you know, we run at any one time, we may have 200 reservations going on, 200 instances going on. And like, if you think about the number of people who run 200 fulfillment operations or 200 buildings, obviously there’s Amazon, well, I don’t think Walmart runs 200 logistics or buildings, you know, they have lots of stores. But in terms of the fulfillment, logistic, Walmart target, those folks don’t do that. 

And I picked those because they’re like the best companies in the world. The biggest companies in the world.

Mario Gerard: The biggest brand names we know about. 

David Glick: And you go to DHL or XPO, they probably run several hundred buildings, maybe 300, 400 or 500 buildings, but with huge companies and huge market caps and huge organizations. And so our model where we work with 3PLS, it’s sort of a marketplace model, or we work with 3PL to provide the labor and space. 

And then we provide the technology. And the demand is very leverage, which allow us with a relatively small team, although it’s like four times as big as it was two years ago. So it’s not as small as it used to be. But with a relatively small team, we can around hundreds of instances on any given day. And I think that’s pretty impressive.

Biggest challenges you face as an organization

Mario Gerard: Yeah. That’s extremely impressive. So as flex has grown in the last couple of years, like, what are the biggest growing challenges that you face as an organization, I am asking you as a tech leader. What do you like, What worries you, or as especially when this rocket ship growth?

David Glick: I think there’s probably two pieces of that. One is how do we balance and prioritize, getting big fast with getting our house in order. When I started Amazon in 98, it was get big fast, get big fast. And so there was lots of operational overhead and all those things and continues to be like the duck is paddling very hard under the water, although it looks smooth and same is true. 

Mario Gerard: That’s such a nice analogy,

David Glick: Same as true with flex. Like our goal is for our customers to not see the churn and ideally, you know, being operationally excellent on all those things. But if we need to prioritize growth is what drives our valuation and revenue is what drives our valuation. And so I’m laser focused on how do we grow? So that’s one of the challenges is how do we grow versus get our house in order?

Second is, as you bring more leaders on, they all have to find their place. And, you know, we work very hard to be, not an empire building company and all the people we aren’t hiring empire builders, you know, at Amazon, for me, it was like, oh my God, I’m a senior manager. I want to be a director. Oh, I need more stuff. I’m a director. I want to be a VP. I want more stuff. And so I can speak to myself personally. It was kind of an empire builder. At flex, Well, first of all, for me, I, there’s no more promotions for me, so I don’t need to…

Mario Gerard: Unfortunate. 

David Glick: I don’t need to try to build an empire. I’ve got everything I need.

Mario Gerard: You’re the empire. 

David Glick: But every time you add a new leader, it’s how do they integrate? How do they onboard and be that a chief product officer or a senior manager or a TPM, getting everybody to readjust and adapt to the new situation is challenging. And again, this comes down to, I think I mentioned the book, people wear most projects, don’t fail because of hardware. 

They don’t fail because of software. They fail because of people. And so getting the right people on the bus, getting the wrong people off the bus is probably the thing I spend most of my time thinking about.

Mario Gerard: Interesting. I think that’s the last question we have for the first part. So we’ll move to this second part. So the second part is a very interesting question, which I wanted ask David was high level leaders like David, you were talking about, you have 350 people. At Amazon, you probably had a people working in your organization. How do you figure out well the right type of people are on the right set of problems and the reason I’m asking this is because I feel like TPMS are conduit of information and they know what’s happening. They’re either writing the reports or things like that. So let me just start with the first question. The first question is like, how do you know the right people are working on the right problems.

David Glick: The biggest team I manage at Amazon was about 3000 people, and half of that was in the development organization. And half of that was in operations out in the fields. And not that the second half isn’t important, but most of what we’ve been talking about is the first half, which is the engineering organization, the development organization. And one of the guy, I was interviewing someone for a role as my direct report. And he is super competent, technically deep, all these things. 

But I had question about trust about, could I trust him? And one of the guys who worked for me said, Dave, at your level trust can never be a question. You have to absolutely trust the people around you because you’re not able to audit every single piece of down to the individual engineer. So the tools for a VP or for a CTO are different than the tools for the dev manager. 

But my number one tool was we called it OLR or calibration or talent review where we get together and sort of talk about who are our best people who are not so good people and who is in the middle. So I spent a lot of time and arguably too much or too little on the other half, but I spent a lot of time on figuring out how do we get the right people on the bus. Are they in the right seats on the bus? How are we organized, you know, deploying human capital and cash capital to the right projects, making sure our best leaders were on the things that my bosses were most interested in, so that we were making progress. Jeff Wilkey who ran an organization of a million people. I heard him speak many times. 

And so I’ll capture some of his wisdom, which was, he would find a position of leverage, which was somewhat homogeneous where he, it was big enough that they had significant sway and leverage, but there are small enough number of those that he could know them each individually. So he picked general managers in the warehouses when he was in ops and then category leaders in retail. 

And the number that he could know is about 50. And so when we had 50 buildings, he knew all 50 GMs of those buildings. And we had 50 categories. He knew all the 50 directors. And so, and again, I copied this from him is we’re going to do talent reviews. And so we’re going to spend a lot of time. We spend three days, twice a year I am going through all the people on the team. And you know, when I started, when you have a reasonable size team, you can start at junior engineers, SD ones and work your way up. Over time as you get more layers and you get more team members, you have to delegate sort of the SD ones and the SD twos to your staff. Senior manager and directors. 

But I continue to evaluate like personally be in the discussion of product managers, TPMS, senior engineers, principals, designers. And by the way, all the PMs and TPMS are either senior principal. We rarely have, folks who are not senior principal in those roles. And so I spend my time on those folks who have more leverage and more scope in the organization and make sure we have the right people and they’re competent. And I challenge, I try to read as much of the peer feedback as I can or listen to. 

And then I challenge folks to making sure they’re making hard decisions, but also that they’re promoting the growth of their best people.

Mario Gerard: So you put in so much time after energy into putting the right people in the right place and also ensuring that they’re well rewarded for the work they’re doing. And we are calibrating them appropriately.

David Glick: Totally. 

Mario Gerard: It is combination of calibration, appreciation and giving them the right set of challenges.

David Glick: Yeah. Because most great people, most great employees want to continuously be challenged. They want to learn and earn, I read something on LinkedIn that said you’re either earning or learning. And so at some point you’re earlier in your career, you’re learning, learning, learning. You want to get leaders who you can learn from, you want to be on projects which are big enough that you learn something new. And then over time that leads to promotions that leads to higher pay and so on. 

But over a time you potentially learn less because you know more and yeah, I’m sure [21:19 inaudible]. 

Mario Gerard: Interestingly, that is true. That is true. That’s very true.

David Glick: You hear Satya Nadella talk about growth mindset and learning mindset. We’re always learning. And so I aspire to be always learning, but I also am potentially less open to learning new things. Cause I’ve been doing things the way I do things for a long time.

Mario Gerard: That makes sense. That makes sense. So how do you ensure that people are working on the right set of problems and they don’t get sidetracked or pulled into things which probably, you know, they shouldn’t be doing.

David Glick: This is super hard and a great question because you can have a mental model of, oh, I’ve got a whole team working on that. With six to eight people. And so I should be making a ton of progress and great, I’ve done my job for the day. I’ve assigned people their work I’m going to go to Disneyland. 

And what we find is that there’s always side things that are getting them pulled off and things that we don’t know about that doesn’t rise to the director or the VP or CTO. You don’t have visibility to that.

Mario Gerard: And there’s always some kind operational overhead or security, you know, patching all the other things which happen, which kind of eat away at that.

David Glick: Yeah. Even if those things only take five minutes a day, every context switch, every five minutes actually cost you like an hour. Cause you don’t ever get into deep work. And one of the things we learned at Amazon early, you know, there was, we launched big project called apparel, basically a marketplace in 2003 or so. And then the next project we were launching, wasn’t going well. And the leader said, we need to hire a consultant to tell us why it’s not going well. 

And we, as many people do aren’t really high on consultants. But anyway, we hired this guy named Steve McConnell who wrote the book code complete and worked at Microsoft for a long time. And he came in and said, well, the leading indicator of getting things done is actually people working on them. And so are your people working on this project?

Oh yeah, yeah, of course they are. We’ve got all these resources dedicated. So he said, do an experiment for me, for three weeks I want to have your engineers fill out what they worked on that week. They’re like, oh, time sheet, its bureaucratic. We don’t want to do that. But we sort of brow beat everybody into doing it. And what we found is that the engineers weren’t working on any of the things we thought they were working on. And there was the TPM running this project, we thought had six engineers on it. And one of them got called by her friend to fix a ticket. And one of them had to do, like you said, a security patch and so on and so on. 

And so that’s one of the things that I say frequently is the leading indicator of getting things done is people working on them and everybody’s like, ha ha ha. But it’s true. And we had a project actually a few weeks ago, a few months ago that wasn’t going well. And so we asked the team to write down what they were doing and it wasn’t time sheets. It’s just like, you know, of the 40 to 50 hours a week you’re spending working, break those down in four or five buckets. 

We found that nobody was working on the project, which is disappointing in myself because I knew that lesson. I’m learning it again. And so I would recommend to anybody who feels like their engineering team isn’t delivering things that they have them write down what they did that week for a couple weeks. And then there’s more sophisticated tools that, that one might use. There’s one called up level and they have some editors that I don’t remember the name.

Mario Gerard: What does it do?

David Glick: It hooks into the company’s slack, Gmail, calendar, git. Basically gives you telemetry on, did this person check in anything last week? Are they being bombarded by slack messages? Did they have deep work time, is their calendar all full half an hour on half an hour off. And with those four or five inputs, you can get a pretty good picture and it’s not for performance managing the engineers. Like it’s not, oh man, you didn’t check anything today. You’re going to be fired. It’s how do we help the engineers be more productive by removing distractions from them.

Mario Gerard: And randomizing them less.

David Glick: Yeah. And this how I idea and I just heard the term in the last year or two is called deep work.

Mario Gerard: Yeah. There is a book about it.

David Glick: I’m sure that’s what has brought it to the front is like, how can you get four hours with no distraction? And part of that is us doing better to not schedule. We have like no meeting Thursdays, for example. But also the engineers need to turn off slack sometimes. Yeah. And not do email and not distract themselves in a world where there’s a thousand slack channels. Some of them are social there’s pet calendars, there’s all kinds of stuff. Everything to distract the engineers. How do we keep them focused?

Mario Gerard: That’s also one of the jobs of the TPM, right. Is to randomize your engineers lesser and ensure that they have enough time. They’re not getting called and pulled into different meetings or different things that other teams need.

David Glick: Totally and I mean, that’s the job of the TPM, the director, the manager, the CTO, what, in many ways less the job of the CTO because you can’t sort of remotely manage a hundred engineers. But the TPM is definitely one where a great TPM will say in the example, back in the day you used to always be, oh, we’ll bring them lunch or bring them dinner or whatever. I don’t think that’s the right thing. But the TPM should be keeping things off of their plate and intercepting inbound requests and helping the engineer offend themselves from that.

Health of a team

Mario Gerard: Yeah. I think that’s a pretty big part of the role itself and the general health of the team as well. So we’re talking about it. Just understanding how is my team feeling. Are they burnt out? Are they excited? Are they happy? Are they sad? And just having a pulse on that that really helps with TPM go a little about and beyond and get stuff done. 

David Glick: One of the things that strongly held belief for me is that if you have the right people, they are happy when they’re getting stuff done.

Mario Gerard: I’m just thinking about it, that Makes perfect.

David Glick: And people like to achieve things. And as I said, this is type two fun. You know, obviously you can’t be working them a hundred hours a week full time, unless you’re like Elon Musk, you can’t do that. It’s our job as leaders to modulate heat, you modulate it up. And modulate it down. And you need to be, as you said, sensitive to when the engineers and the others on the team are going to burn out. 

We went once to a warehouse where things weren’t going well, we flew out with a team and it was like my second week. And there was a dev manager there with me. He was great. And his team, they wouldn’t go home. They wouldn’t go back to the hotel and sleep. So they were up late and early and they were like coding away. And he’s like, you guys and gals, you got to go home. Like, I’m going to drag you out to the car, drive you over to the hotel and leave you there. And without a car. So you can’t get back. 

Because they were so excited about being part of this and being, yeah. Getting things done. They didn’t want to miss out. They wanted to achieve and all those things. And so it is part of our job to both, Hey, recognize and sort of leverage this excitement, but also to recognize when it’s too much.

Mario Gerard: Yeah. Especially now like with burnout and so many people working from home and it’s a different type of environment. You don’t have a lot of social interaction, real physical, social interaction like you used to. I think it’s a little harder to get a sense of the health of your team, but I think it is on all of us as leaders to ensure that the teams healthy and that they’re getting what they need.

David Glick: Yes, for sure. And I like to say that nothing’s more important than your physical or mental health. And because we do have people who drive themselves so hard that they’re stressed out all the time. And so we ask them to take vacation and they end up yelling at other people, including myself. When I don’t take vacation, I’ll end up yelling at people and not being a fun person to be around. 

So sometimes it takes someone outside of yourself to recognize that, and it’s our job as leaders to recognize that in the team.

Speaker 1: And that my friends is the end of part two of the three part series with David Glick. If you enjoy the podcast, definitely like and share with your friends and write us a review on [29:01 inaudible]. Thank you so much for listening.