Empowering Teams: Larry McDonough on Effective Leadership in Tech

‍

Larry McDonough is a highly-regarded technology leader with an extensive background in software and product development. Currently, as the Director of Product at Procore Technologies, Larry drives innovation and creates unparalleled solutions for the construction industry, while also serving as a Member of the Board of Advisors at the University of California Riverside. With prior experience as the Director of Product Management at VMWare and Engineering Group Manager at Sun Microsystems, Larry has consistently demonstrated his passion for user-centric, high-performance software and his ability to lead teams in developing groundbreaking solutions.

Throughout his career, Larry has been committed to fostering innovation and collaboration, leveraging his industry expertise to help shape the future of technology. His strong foundation in engineering, combined with his deep understanding of market trends, has made Larry a respected figure in the industry and a valuable asset to any organization. As a mentor and visionary, Larry McDonough continues to influence the next generation of tech leaders and contribute to the growth and success of the technology landscape.

‍

Host:
Hello, Larry. How are you?

Larry McDonough:
I'm great, how about you?

Host:
I'm alright. Uh, where is that by the way? That sounds like an interesting background.

Larry McDonough:
Oh, this is my man cave. Uh, no, yeah, I think it is. It's a garage but I got a pool table in here and a spin bike and darts and music.

Host:
A giant TV right behind you, which you can't see.

Larry McDonough:
So, it'll see. It sounds like basically every bar.

Host:
Yeah, I mean, it's a mix of bars.

Larry McDonough:
Oh, nice, really nice. Pool table and a ping pong top we can put on it. My son likes to play, uh, when he has his friends over here, they'll put the ping pong table out and do stuff with red cups. I'm not really fully aware...

Host:
Yeah, I have no idea about that.

Larry McDonough:
I have no idea. A lot of them for some reason in that game. I don't know, maybe it's a North American version of table tennis, who knows?

Host:
Probably. Popular in college.

Larry McDonough:
Uh, well, let me introduce you a bit. So, this is Larry McDonough, um, I'm on many things. Uh, he's been a software engineer. Uh, he's been a product... I think you've been at VMware. Uh, you've done a lot of, uh, sort of like visual programming and things of that nature. But right now, he is director of product at Procore Technologies.

Host:
So, I'm going to ask you a few questions, and, uh, the first one is, I guess, the most obvious, which is what does a director of product do?

Larry McDonough:
Oh, gosh, good question. Um, so I had this role in my last company as well, and the... and the... so it seems to be fairly consistent across high-tech companies. Um, but a director of product is responsible for probably, I would say, more of the strategy of the product necessarily than the implementation. So, um, reporting into the director of product, typically are a few product managers. Um, in my current role, I have three, uh, senior product managers. Actually, two of them are principal technical product managers, which is pretty high up in the PM role, right? And so, but for me, I'm responsible for overall strategy and, um, you know, I keep an eye on, uh, you know, how our product's moving along as well in terms of how well we're executing. I manage resources, um, budgeting, not as much I would say. It's been my experience that, you know, we get a budget, gotta work within it, but a lot of the financial budgeting stuff tends to happen, uh, you know, at the VP level.

Host:
Right, right. So, for each... you said you had, uh, is it three or two, uh, people?

Larry McDonough:
I have three.

Host:
Three, and two are technical, right?

Larry McDonough:
Two are very technical.

Host:
Yes. So, uh, for you, what do you see? Because I think you also came from more of a technical background into product. So where... what do you see as the, uh, sort of like difference in perspective between people who come from a technical background into product and people who don't?

Larry McDonough:
Oh, great question as well. So, um, a lot of it depends on the, uh, actual industry and product you're in. So, I've been staying in technical, uh, you know, with technical products and software products, and I would say that the technical product managers or the people that have experience with, you know, actually building code, um, the one advantage they bring is a deeper level of sympathy and understanding with the engineering team, right? So, um, you can also communicate better sometimes. Um, there's disadvantages, I'll get to those in a second. But another advantage is, um, that they, um, can also recognize. Um, you know if there's any particular, um, you know sandbagging going on or you know there's some, I've been very sandbagging. Oh, this is going to take us, you know, eight weeks to build this feature, you k. now, and if you're familiar with how things work, you go, um, you know, show me how. I want to see. I don't quite get that right now. Sometimes you could be, you know, they could be right and in most cases the companies I've been working with recently, I've worked with excellent Engineers, I've not had any of that. But it's always good to have someone that can kind of, you know, get back an estimate from engineering and kind of like have a way to logically recognize whether that makes sense and if there isn't, right, if something doesn't make sense, they can kind of drill in a little deeper, right?

In this context, effective leadership comes into play when you're able to ensure your team has the right resources, tools, and communication to succeed, all while managing expectations effectively. The ability to evaluate estimates critically is an essential part of effective leadership, ensuring that the team is moving in the right direction with realistic goals.

‍

Host: 

"The advantage of someone who is maybe not technical, um, is that if this, they have to have something else in addition, right? Um, you, it helps to understand technology to communicate of course, so there's a certain base level you need but if you don't have a technical background, you can bring other things to the table. So one of them is a really strong, um, you know ability to understand your customer, right, and um be able to, uh understand what they actually need in the product and do a really strong job of, you know, market analysis, customer analysis, competitive analysis, you know, and some of those things are a little foreign to someone who was a developer before, right?"

Larry McDonough: 

"Right. Um, so there's kind of some different advantages that each type of product manager can bring. I like having a mixture, right? So they can learn from each other. Um, I think that's important to have a team where each member of the team, you know, can be the sort of, you know, the expert in their area so they feel good about being able to add value but also be able to learn from the others and have an open mind to like, 'Oh, you know, this person's really strong at, you know, um doing customer, uh, you know, research or Discovery right now, I can learn from that' and vice versa, right?"

Host: 

"Is there, I mean, this might just be incidental, but is there any meaning in that in having two and one, one, two technical, one sort of, uh I guess more product-focused or more marketer and consumer-focused, or is it just happenstance, or is there, and basically is there when you lean towards more for one reason or another?"

Larry McDonough:

"Kind of depends on the job. Um, if the role is working closely with, um, well if the product is APIs, okay, so that's very close to engineering, you probably wouldn't want someone who doesn't have experience with actually building and writing APIs themselves, right?"

Host: 

"Right, so why is that important?"

Larry McDonough: 

"So why is it? Because at the end of the day, because so much of the product evolves around the tech, right? Uh, you know, yeah, there's a, there's a customer component as well. There's consumers, they're developers that are consuming APIs, so you have to understand them and that again helps to be, uh, uh technical. Now, on in my team, and this was true with at VMware as well but also at Procore, is, uh, we're responsible for our Marketplace, right? And our Marketplace is a, you know, uh, it's a web portal that contains solutions that customers can come to to, uh, to, uh, you know, browse and and acquire, and that Marketplace management isn't quite as technical as an API. In fact, you know, the Persona that a Marketplace targets is really the End customer, right? So you have to understand the customer side of it, not so much the developer side of it. So I would say that the need for technical background really aligns with the Persona of the product, right?"

‍

Host: 

Interesting, so if I move over more to the product side, um, sort of in terms of the skill set there, which is really interesting because sort of, I guess they've been to the podcast in general is quite techy, but, uh, you know, sort of, it's great to have that person who can sort of translate between, uh, you know, because of your experience and things like that, uh, you know, could you sort of explain what market analysis, product analysis, and competition analysis is and, like, specifically if it's someone who's in product?

Larry McDonough: 

So, let me see, so Market, competitive, and what was the third one? This product, product, yeah, okay. Uh, well, I mean market and competitive, I'd say are fairly similar, right? So, you know, there's, there's the market of opportunity for your product. You got to understand what is the size of that market, um, who are the players, you know, who are the potential customers, what's our opportunity?" Um, and then inside of that market, there is, you know, there’s competitors, right, that also want to eat at the same opportunity. So you have to kind of understand the relationship there. Um, you know, most companies I’ve worked for in the tech space have a dedicated, uh, competitive, you know, analysis team that you can lean on as a product manager. All right, so we’ve been fortunate to have that, but even there sometimes the area that we need competitive, um, information on is, um, is outside the, you know, the average or normal, you know, direction that when someone from, you know, your corporate competitive would go after because we’re looking at, you know, what are their Dev tools and, you know, how competitive is their developer environment and what’s their developer experience like, right? So we might need someone who understands the developer side of it, and that often will fall on the product manager in that space, uh, to go mess around, you know, with the competitors’ products if they’re open and, um, learn about what they do well, um, what they’re not doing well, what direction do they appear to be going in and do we care, you know, and how do we differentiate all those kinds of things. I’d say the market analysis is more about opportunity and understanding your customer and, you know, um, uh, you know, and that helps to, in that space, it helps similar to working with your internal competitive team. This really helps to work with your BD team, your sales team, your customer success team, right? So you can find out, we have, you know, we have, how are our current customers, um, you know, how do they feel about our product, right? So you want to know how they’re doing, um, but there’s, you know, companies that may have tried the product and left, like we want to know why, right? There may be companies we haven’t yet acquired that are in our sites, you know, and what is it that, um, you know, might make them come on board and there’s different elements in each for each of those different cases. There’s different teams for each of those different cases, you know, internally so you got to talk to them, right? Your customer success folks are the ones that are working with the customers just we just acquired.

To be successful in these situations, empowering tech teams is essential, as it ensures that everyone is aligned in understanding customer needs and market trends. Additionally, building collaborative teams is key in gathering insights from various departments, ensuring that product managers, developers, and sales teams work seamlessly together to leverage market opportunities. One effective way to foster this environment is by encouraging effective communication in teams, which can significantly enhance collaboration and problem-solving. Furthermore, adopting strategic leadership in tech team ensures that decisions are made with foresight and a deep understanding of both customer and competitive landscapes. Team empowerment techniques, such as cross-departmental collaboration, are vital in ensuring that all members have the resources and insights they need to make informed decisions.

 Right, the sales people know about the deals we lost and, you know, the BD teams, um, SC teams know about, you know, who we’re going after, so, right, you got to just take... I see teams being what BD? I think this is development business development, um, uh, sales engineering, right, so sales is out trying to, you know, get a client. They need to bring in some technical person to sort of, you know, explain the benefits to the technical side who is going to be sitting there thinking, you know, can we, you know, is this product going to solve our purposes? Right, the sales guy makes a beautiful pitch and it sounds everything’s rosy but, you know, they’ll bring in their technical team to kick the tires and then, you know, so our sales team brings in some a technical respond, um, and they, so they’ll often be the first to know what the product that we have, you know, where it’s failing or where it’s falling short, right? So they’ll be in conversations with them, and, uh, understand, um, you know, they can come back to us and say, you know, hey, you know, we’re losing deals because of this, this thing or this thing, right, and that’s important to know, right? So, I mean, sort of my summary of this is what people want, um, what you have and what other people think people want, basically, so the competition and, and whether they were successful at figuring that out or not, yeah."

Host: 

"So, with all these sort of, that, this like circle of concerns, is there, are there like, I guess, maybe questions or, uh, statements or considerations almost from a more fundamental level of things that you, uh, use to filter out and make decisions?"

Larry McDonough: 

"Um, these would be questions or things, um, that I would pose to the, uh, third parties or the external players here, or is it things that we’re looking at internally? That’s a good point. Um, in my mind, I’m thinking more about, uh, you’re trying to make a decision on what to do with your product and you have all these, um, considerations, right? You have, you have the market, you have the competition and, and you have the product, right? So one, something, one thing could be, hey, let’s just do what this person is doing because it’s working, right? Um, okay, yeah, right, or, or you could say, hey, like let’s not do that because they’ve eaten this much of the market, there’s no more market share here, uh, it’s just not, there’s no point, so position yourself at the exact opposite because the market on the inverse size no one has touched because you’ve done your market analysis and you know that this whole group that no one’s touching and it’s just sort of not obvious to other, to their competitors, wow, so there’s so many ways you can sort of slice up that, uh, Venn diagram, right?"

Host: 

"Yeah, so, so let's first start off with I'm a huge fan of the Steve Jobs philosophy of, you know, competitive information, which is, you know, I don’t give a, right? I don’t care what the..." Competitors are doing all right. Never look at them, don't care about them. If I look at them, they're going to lead me down the wrong way because they're all idiots. That's kind of how he was, right? But we can't all be geniuses like that, right, and know exactly where the sweet spot is. But there's a lot of important takeaways from that, which is you can over-rotate on what the competitors are doing. So I don't like to do that. I like to lightly know where they are, but I don't factor that in very strongly into what we're doing. Also, if there's a huge market of opportunity that is sitting there, that doesn't mean we should go get it either. Right? And that may sound odd at first, but sometimes it's much better to have a partner, a third-party partner, to go handle that, fill that gap, because you know where you're going.

So I think everything comes back to, you know, what’s the strategy that you have at the corporate level, where are you going, what do you want your product to be, and don't get distracted by these things along the side, right? Like competitors or other opportunities, stay focused on what you're going after. And you know, the way we do that is we, you know, first we got to identify where we want to go, and then, you know, keep your eye on the outcomes that you want to achieve. And then what are the kinds of metrics we can employ internally to measure whether we're on track with those, meeting those outcomes? And then, you know, obviously building the product that, you know, solves those use cases for the customer.

So I think the most important thing is identifying your overall strategy, right? Because everything should fall from that strategy, should be everything.

Host: 

So how do you know that? I mean, I guess there's obviously, you know, the idea that you must be very committed to this sort of line, right, that you're going towards. How do you build that confidence in, hey, this is the right direction I'm going? Is it because you're already—I mean, it depends if you're already on a ship that's already going in that direction, you just keep going in that direction, right? But how do you know that you're going down a path that's going to lead you towards a greater and better...?

Larry McDonough: 

You don't always know, right? That's the beauty of, I guess, product management, right? There's risk involved. I think, um, few of us are, you know, sitting at the wheel of the ship that you talked about, right, where we actually can just change the whole ship. Most of us, you know, especially in middle management or, you know, product management in a product-focused team, you know, have a North Star, you know, that the company is aligned around. Um, you know, hopefully, if you're a successful company and you're managed well, everyone's aligned around some North Star. And then the different product teams have different, um, sometimes different, you know... well, we got different products, right, to play different roles in us getting us there.

And at that product level, one product team might choose to, you know, attack, you know, by adding new features or something like that. Another team might say, we’re going to pull back and we’re going to build out our, you know, our foundation or our, um, you know, frameworks or whatever. Um, so those kind of decisions are the ones I work with, right? Is, you know, are we going to go after, you know, adding new features and, you know, making it easier for, say, developers to, uh, build on our platform? Or do we want to focus on, you know, something else and, um, you know, some other area that would help us still get to the end goal but might be more important to focus our resources on, on that, you know, in the near term?

So those are the kind of decisions we make. And, you know, you don’t always know if they’re right. Um, you, uh, do the best you can. Um, you gather data, you double-check that, you know, these are the things that customers care about, that you have the resources on, on, in your staff to, to solve it, um, that there are any dependencies that, uh, are going to, you know, block you in being successful. Or, and if there are, you know, figure out how to get through them and resolve them as soon as possible.

That's where empowering tech teams becomes critical—ensuring that your team has the autonomy to make decisions, solve problems, and move projects forward effectively. So that's what I find to be the most fun in the job I have, is crafting that, uh, strategic direction and then, you know, finding ways, uh, to get there. And of course, exciting, getting a team excited, keeping people motivated, um, giving, um, you know, young leaders opportunities to grow and, uh, and learn. This is where strategic leadership in tech team comes in—it’s about making tough decisions, motivating teams, and focusing on key priorities.

And sometimes that can mean, uh, you know, fail, right? So you, you, uh, you may have some, you know, hopefully small failures, but it's all part of the learning process, right? So... A critical part of effective communication in teams is understanding that failure is an opportunity for growth, as long as the team is supported, and the vision stays aligned with the broader company goals.

To succeed in this environment, it’s also important to focus on building collaborative teams. Encouraging collaboration ensures that every team member has a voice and that their skills and expertise are leveraged to drive the project forward. Finally, utilizing team empowerment techniques can ensure that every team member feels motivated and equipped to contribute effectively, especially when faced with challenges.

‍

Host: 

Right, I strongly encourage, um, you know, taking risks that are smart risks and, um, if you fail, then, you know...

Larry McDonough: 

Well, we only learn when we fail. We don't really learn when we succeed. So, if you do fail, it's a good opportunity to learn something.

Host: 

Let me ask you, basically, how you got into your field, where you transitioned from, and why you transitioned. How did you get into technology in general and end up here?

Larry McDonough: 

Yeah, well, I started out actually studying art—Visual Arts, painting and drawing. My mom was an artist growing up, so it's kind of what I gravitated toward. I was good in school at two things—drawing and sports—and I wasn't that bad at math, but I didn't apply myself in my younger years. As I went to college, I went for art, but I absolutely hated it. They wouldn't let me do what I wanted to do, so someone suggested computer science. I thought, okay, I'll try that, and I loved it.

Host: 

Why did you feel like you wanted to try that from art? There's not even an overlapping...

Larry McDonough: 

Well, sort of. It was new. Okay, so I'm an old guy, right? So this may seem strange, but it was a new field. People listening today might ask, "What are new fields right now?" You've got stuff like crypto, security, IoT, fintech—lots of cool things that are just growing like crazy. Also, AI and data are big right now. What's cool about getting into a field when it's really new is that you're all learning at the same time. It's not like, you know, studying physics or something. If you want to study physics today and go get a PhD, good luck. It's great, but there are so many PhDs in physics. It's just a little bit harder. My wife has a PhD in physics, so that's a bad example, perhaps. But the point is, any of the cool new things that come up, that's why I tried it. I just gave it a shot, and I ended up loving programming.

Host: 

What was it about programming that clicked with you?

Larry McDonough: 

For me, programming was like art. You had a blank editor, and you could come up with an idea in your head and then code it up. The cool thing about programming is that the computer tells you if you're right or wrong. It's this iterative process of trying to get to perfection. I'd often get syntax errors, or I'd see some funny results—like, "Why are my numbers not converging?" I'd dig through my code, find the bug, fix it, and keep iterating. I loved that process.

Host: 

It sounds like a bit of trial and error, but rewarding when you figure it out.

Larry McDonough: 

Exactly. It's just so satisfying. I had a lot of opportunities to work on some really cool things.

Host: 

Can you give me some examples?

Larry McDonough: 

Sure. The first job out of college, I got a BS in computer science from UC Riverside, and I worked for a company called Aerojet Electro Systems. They did infrared detectors. I wasn't there very long when I noticed a lab working on some experimental work with fault-tolerant detection and onboard processing. These are big terms, but the idea was to write code that would run on a satellite and do all the cool processing up there, then send down just a small stream of data. This was during the Cold War, so I got to work on a graphical visual interface with a math co-processor and graphics engine that was separate from the CPU. I was managing three different CPUs and writing code that was cutting edge at the time. It was awesome.

Host: 

That sounds like a pretty advanced project for the time. What did you do next?

Larry McDonough: 

After that, I went to the Rand Corporation, where I worked on building an animation system. I proposed it to the researchers there. I came in as a developer, and they asked me, "Can you write a program to take my data and visualize it on a map?" Sure, I did that. Then the next person asked the same thing, and I realized, I don't want to keep writing this over and over. So, I built a platform where anyone could just plug in their data and visualize it. This was a great example of empowering tech teams—creating a system where others could easily leverage the technology without needing deep coding knowledge. I ended up taking that system to the Pentagon and installing it for the Joint Chiefs of Staff. They used it for quite some time. I also moonlighted at JPL, where I worked on some cool stuff, doing code for a satellite. Just had all this awesome experience and yeah, at one point a friend of mine, he had a guy we worked with who had passed away in a car accident and he was running this user group. I decided I'm gonna pick it up and take it on, you know, carry the mantle for him. I loved that it was like this user group, all these tech people, we'd meet once a month, I'd bring in speakers. I had Michael Crichton come in one time because he wanted to hear the speaker I had talking about animal interfaces and stuff like that. This researcher from Apple, they came in and talked, and I found that I was enjoying, you know, sort of the not as much the code but like what the code could do and effective communication in teams—how you can use code as a tool to facilitate understanding and inspire innovation. Someone said, "Go back and get, you know, you need to go get a master's." So, I went to UCLA and looked at their master's program in computer science. I looked at the curriculum and it was like, you know, multi-processing, graphical systems, and compilers. So I built my own languages, I wrote my own animation language, and felt like, gosh, if I take the master's in computer science, my previous five years of working at Aerojet and Rand had covered all those topics already, so it was an incremental benefit. It reminded me of the time when someone randomly said, "Why don’t you go get an MBA?" At first, I didn’t really know what that meant. I had heard of it, but it was a new idea for me. So I went to UCLA and looked at their MBA program. It covered accounting, marketing, management, leadership, finance—things I hadn’t yet learned, and every single class was 100% value-add for me. I applied, got in, and the rest is history. It was clear that building collaborative teams and learning from diverse perspectives was a critical part of my growth. Straight into product.

‍

Host: 

It sounds like you got really good really fast in software because you never did it before, you did it in college for a few years, and you're writing your eyes... I was a real overachiever, and I was younger. So even when I was in college learning computers, you know, I worked part-time putting myself through school at a chemical plant. I went into the chemical plant and I told them that, you know, you guys should, you know, because they would give us these batch tickets to make this big recipe in these big bins, right? It was urethane foam, and I would say, "Why don't we just put all this on a computer?" And they're like, "You know, you could just kind of dial up the formula you want, hit a button, and it would print out the recipe sheet instead of someone, some chemist having to write it down every time and figure out, "Oh, this is a 2,000-pound batch versus a 3,000-pound batch, let me adjust for all the percentages," you know? So it's like, that's dumb. They would do that by hand. So it was really like, it's just screaming for an application to be built, an optimization. Yeah, and I was like two classes in, and I'm like, I can build that for you, and they're like, "Oh, okay." They were stupid enough to take a chance. They went and bought a... get this, they bought an Apple 3 computer. Nice! I had never programmed on Apple before. I was working on Unix machines at the university. So I said, "Apple 3? No problem. I can take, I can do it. Give me the manual." So I took the manual home on Friday and came back on Monday and started writing code in BASIC, and I built them a system. It was so... I just learned, you know, you just look for those opportunities.

Larry McDonough: 

Yeah, that was a good start because that was basically a calculator. So, yeah, you know, it was exactly, it's a nice little small program that you could, it was feasible. You weren't, you weren't completely out of them, uh, into another stratosphere with that. Yeah, so that's not bad.

Host: 

It wasn't too bad. Yeah, okay, okay, so, you know, obviously we've been in all these places and done all these, I think, personally pretty cool things I have to say, uh, and a lot of them are foundational to computer science, right? So, you know, now that you're a product, what's your perspective on innovation relative to sort of the goals of the organization from a profit point of view? Because you definitely understand the flip side where this is the fourth button we've built and I'm tired of that or whatever it is they're building versus, uh, you know, you do need to build this button because this button is a four million-dollar button right there.

Larry McDonough: 

Well, yeah, so go ahead and build it. Innovation is at the core of almost everything we do, right? I mean, it's right, um, if you're not innovating, you're not moving forward. Um, you're staying where you are, right? And based on just, you know, our economy, it's, uh, it's a capitalistic economy. I mean, you're... someone else wants your lunch, right? And that's the way it's gonna be. And, yeah, um, so, uh, whatever problems we're trying to solve, whatever, you know, um, ring we're trying to reach and grab, um, we're always asking ourselves, uh, this is true at every company I've worked with, especially in products, it's important. I, um, you know, encourage the product managers I work with too, you know, sometimes engineers might be inventing something new and they don't realize it. You know, "Oh, well, see, we got this really hard problem to solve." They go in a room with the architects, they figure out some solution, and they start to implement it, and they report on it, and the product manager's like, "Um..." Did you talk did anyone go over with legal whether you know to check in with legal to see if this is like this is innovative this is worthy of you know a patent right um so that's a really important muscle to flex okay um because innovation's happening all the time and some of it's um you know completely uh novel and um something that you want to protect okay so have you always had the opportunity to to sort of support that or have you always picked companies that were in that direction because it's not true everywhere

Well, it's true—it is true everywhere—that a company thinking about innovating and looking for those opportunities is going to do better than one that might be innovating but not trying to protect their innovations. I think that's a truism. I have worked for companies where we were innovating but not protecting our IP, and one particular startup I worked for, looking back at it now, I probably could have had half a dozen patents. But the company didn’t really have the culture at the time to do it, and we were small. Honestly, I didn’t think of it. This is something I look back on and think, "Why didn’t we do that many years ago?"

We were innovating on cell phones, doing 3D mobile characters, or mobile interactive emojis of yourself. You could record a funny message and send it to your friends. You could pick any character you wanted to say it. We built cool technology to capture facial motion from a regular digital camera, and our team did have patents around the engineering and the team empowerment techniques we used to make it happen. But we failed to patent some of the cool stuff we did with lip-syncing. It's all patented now, but I went back years after we did it, and we were the ones who did it first. This was a lesson learned: when you're doing something really cool, it's important to check and see if anyone has done this before.

We were improving the 3D morph targets and the way the 3D worked around the mouth. We weren’t just picking up motion visually. We recorded audio and knew that certain sounds and phonemes in the audio would correspond with specific mouth, tongue, and lip movements. This allowed us to adjust the 3D graphics accordingly, and it got so much better. It was more than just having the mouth flapping—it looked real. You could see the tongue moving, the lips pursing. This is where strategic leadership in tech teams really plays a role—aligning the technical aspects with the bigger vision. We were able to adapt on the fly, knowing our work had the potential to be revolutionary.

In hindsight, I realize that effective communication in teams was key. If the team had better communication around intellectual property and what we were creating, perhaps we would have protected our innovations better and been more strategic about building collaborative teams with a shared understanding of the value we were generating. This is something I’ll always take forward in my career.

‍

Host:

 So this is something you're working on yourself or whatever?

Larry McDonough: 

Yeah when we're doing that and uh we were doing it I don't know like five or six years before the patent servers showed up it wasn't patented when we were doing it

Host: So let me ask you what do you so you you did all this and you sort of felt like getting an MBA was was really valuable for you because it was sort of met new information just in principle before you started it so when you went through that process how did you feel after endearing uh before you moved on

Larry McDonough: 

Yeah, so you were asking me about, um, you know, how was that transition from in it becoming an engineer and getting an MBA and what's that like, right? And, um, you know, I had, um, here he was his engineer I had all this cool, you know, background. One of the stories I didn't tell you was I worked at this little startup where we did real-time full-body and facial motion capture at the same time I got my picture in National Geographic because, uh, we were doing such cool, innovative stuff. But when I got my MBA, um, I was actually kind of frightened, to be honest with you, because, uh, I felt, you know, you have that imposter syndrome people talk about, like, "I'm an MBA, you know, I'm supposed to know business and finance," right? But I felt like I could code like crazy, but I wasn't super, uh, confident yet in my ability to understand business concepts, right, you know, with just a few years of education. So, um, I, uh, had an opportunity to work at the time with this, like, the coolest company, Silicon Graphics. This is back in the early, well, mid-90s when I got my MBA, right? And, uh, they came to campus, and I, um, you know, as was the normal process, the students would put down bids for who they wanted to interview with. You got, like, 100 points you could put your 100 points and spread them out across, you know, Apple, HP, Silicon Graphics, whatever, right? I put all 100 points on Silicon Graphics. It was the coolest, hottest company, and plus, I, you know, I did all this visual 3D computer graphic stuff, so it was like a no-brainer. Anyway, they, um, when they got my interview time and they found that I put down all 100 points on it, they were like, you know, uh, you're the guy that put down 100 points because they had heard about it, because I only wanted to interview with one company. And, um, so that impressed them. And, and they said they had to impress them because it's just the commitment level. They're just like that. Effective leadership is about committing fully to your vision, just as I did with Silicon Graphics, where I gave all my attention to one opportunity. This kind of focus demonstrates strong leadership qualities that inspire confidence and results.

As I navigated this path, I began to realize that effective leadership isn't just about being technically skilled—it's about understanding how to communicate your commitment and vision to others. This became apparent when I saw how my dedication to the company stood out, and how that level of commitment was ultimately recognized.

‍

Host: 

Yeah, yeah. In fact, the secretary at the university was trying to tell me, like, Harry, the highest person that bid on SDI is like 40 points. You could put down 40 points and guarantee a spot and still interview with Apple. I was like, I don't want to work for Apple. I did, I'd probably be a millionaire today if I stayed with them, but yeah.

Larry McDonough: 

Anyway, I, um, I, you know, I wanted, I knew where I wanted to go, so I put 100 down against everyone's recommendation and that impressed them because they had somehow heard of it, uh, when my time came up. But also, with all my graphics experience, they, um, told me, "Look, Larry, you know, we came here with three job openings that are for product managers. And, um, each of the product directors in, you know, SGI for these openings, they all want to hire you, right?" So I said, "Oh, wow, that's fantastic." So they said, "Why don't you just tell us which one you want?" And I said, "Well, what are they?" The first one is, uh, the 3D graphics APIs. Okay, so I'm like, "Oh, that's my jam, right? Yeah, technology, graphics programming." Okay, the second one was virtual reality evangelist. I'm like, um, "It's okay, yeah, it's a brand new, this is the virtual reality, the first time it came around, you know, right, right, 30 years ago or whatever now." And, um, so it was kind of young, and, you know, not a lot of promise or, you know, a lot of hype, but not a lot of real business being made, money. And so I'm like, "Okay, what's the third option?" It's like, M&A, mergers and acquisitions. "We want to talk with you because, you know, you have insight into this, you know, cool startups and stuff that's going on and that could be valuable."

Host: 

And like the latter two were scary to me. I'm like, "Oh, you know, so I decided, you know what? I like that API one, you know, because that's, I can, I know I can kick ass there, right?" You know, um, so I, looking back at, you know, the M&A one might have also taken me on a different path, you know? Uh, it would have been interesting to see you on the M&A one now, but I've just loved technology so much. So I, I've always stayed in that space.

Larry McDonough: 

In fact, right, I've had two opportunities in my career to, um, you know, for VP roles and I turned them both down. Um, they were not at the right times in my life, you know, with little kids and stuff like that. But also, product or technology and product, but I really like staying close to the tech. I, I just, you know, being right with the engineers all the time, that's where I was most happy.

Host: 

Right, right. Well, that's, that's really interesting. So, for basically, you were able to gather those skills and basically take what you already have and just move forward with that, but with a bit more perspective. So it sounds like it just gave you a lot more perspective.

Larry McDonough: 

Yeah, yeah, it did. Yeah.

Host: 

So if you, uh, if you talk about specifically the role of director of product, uh, and you talk about, you know, what it is to sort of translate what you know to the people below you and the, uh, translate what you're hearing to yourself, so, uh, you're sort of in the middle there trying to understand, uh, you know, what the company needs and what direction you're going and things of that nature and then translating that message to people below you so that they can actually do their jobs and so they can do it in a way that they, you know, to some degree translate into a language that they understand because a lot of, you know, each tier has its own jargon, uh, that they do and don't use. So could you speak a little bit about that? How that, um, you know, how you do that or, you know, how, how you think that's best done?

Larry McDonough: 

Well, that's a good one. Um, yeah, I think that comes down to communication, right? And some of it depends a little bit on, you know, what the company culture is and, um, but you know, how does company culture affect that? Um, I've worked at companies that are more open than others in terms of, you know, inviting feedback on the strategy. Some might want to say, "This is where we're going," and, you know, don't ask me why or don't question my math, whereas other companies, especially Procore where I am now, are completely open. Effective communication in teams requires a transparent approach, where the flow of ideas and feedback is encouraged.

You know, this is where we're going, and if any of you have any, you know, comments or questions about it, you know, bring it on. Right? And people like the culture—here, we’re people who say, "I don't think this is right. Let's dive into it and push on it," right? So, it's very open that way. In fact, it's one of our corporate values: openness. Empowering tech teams is a key part of that openness, as leadership encourages team members to share their perspectives without fear of pushback. In strategic leadership in tech teams, it’s crucial to create an environment where team members feel empowered to voice their thoughts and contribute to shaping the direction forward. This creates space for team empowerment techniques to thrive, allowing everyone to take ownership and contribute meaningfully.

The ability to listen and act on feedback is essential for building collaborative teams. In an environment like ours, we ensure that communication flows freely between all levels, ensuring that ideas are respected and evaluated on their merits, not just top-down directives. When a team feels included in decision-making, it leads to more innovation and better overall results.

‍

Host: 

So, um, but there's other places where they're not quite that much. So I think that's, that's what I mean by that. But, you know, communicating up is really about understanding what the, you know, what the interests and needs are of that group, right? Um, it's, you know, it's budget, it's money...

Host: 

It's time. It's, you know, innovation, it's stuff like that, right? Often money.

Larry McDonough: 

You know, that's more the area, you know, it's still strategy but, you know, where are we investing? Um, is important. And then when you're talking to the team, you know, beneath you—uh, hierarchically I don't like to think of it beneath me but like, you know, in the hierarchy, the grain can file folks, like, you know, they're on the front lines. They're actually doing the real work, right? So, um, helping them understand why, you know, we're doing this or why we're not doing something that everyone wants to do. Um, the better you can communicate that, the more successful your teams are going to be. You know, like, um, sometimes an engineer... I've gotten this question once or twice in various interviews or whatever, but sometimes engineering will want to go build something and, um, you know, they'll be really excited about it. But there's like, there's zero market value for that, perhaps.

Host: 

Right.

Larry McDonough: 

You know, how do you handle that kind of, um, situation? And it's all about how—it's all about understanding what that other person wants and needs. Like, sometimes it's like they want to be free to innovate and create cool stuff. Well, that's great. But they all—I, I know that I've never met an engineer who didn't want their stock price to go up, right? So it's like, you know, you can just have logical conversations about, well, you know, we could go down this route but there's—there's no money there. And, um, yeah, maybe you could file a few patents but it's not an area we want to protect. And, uh, you know, if we go in this direction, I bet there's some creative problems you can solve, right? So I think, right, Engineers—especially most is true for most people, but I found, you know, really good engineers want to—want to keep learning and growing and innovating. So, you—you know, you got to find ways that they can do that in the direction that makes sense for the business.

Host: 

So how do you, uh, how do you, um, sort of have that conversation, right? Where, I mean, I guess this is a little bit of disappointment there and you may not always have something to trade where, uh, this is interesting, anything like this, but here's this, and it does what, and it gives you the, um, that kick you're looking for or increases your stock, like you're saying, like how do you, um, creativity?

Larry McDonough: 

You gotta be creative, right?

Host: 

Yeah, fair enough.

Larry McDonough: 

Yeah, it entails understanding, like, you know, what are the—where are the challenges in the current role that we have now? It could be the case that you have someone, you know, in the wrong role, right? And that can happen where there's no challenge you can present to them in this direction that's of any interest to them, and then that becomes more of a, you know, how do you manage them to be the most effective for your company? And if it's not the role they're in, um, you know, let's find a role that they can do where they can add a lot of value for the company, right? Um, so I'm all, you know, that—that's been my philosophy is, you know, throughout my whole career is, um, helping people, you know, deliver as much value as they can for the company, uh, as a whole. And sometimes that's outside of my team, you know, trying to transfer someone to somewhere else where they can really follow their dream. I think managers that, you know, say, nope, you got to do this job, you know, you know, like it or get out, you know, and people just end up, you know, they'll say, okay, okay, great, I'll do this job, and then they just start looking for another job and they leave, right? Um, and then all that institutional knowledge that they might have walks right out the door with them, and it takes you more years to build that up with someone else, right?

Host: 

Right. Well, speaking of following your dreams, where can people follow you?

Larry McDonough: 

Where can they find me? Yeah, where can they find me? They can find me, uh, well, I'm, I'm in the process of backing out of Twitter.

Host: 

Um, but, uh, if that's what you're talking about.

Larry McDonough: 

Um...

Host: 

Okay, well thank you, uh, thank you, Larry, for coming and, uh, it's great learning from me and great talking to you. Thank you.

Larry McDonough: 

This is a pleasure.

Host: 

Alright, take care, bye. 

‍