Go back

The Five Pillars of Strategic Leadership: Lessons from Paul Cormier, Red Hat’s Chairman

32m 31s

The Five Pillars of Strategic Leadership: Lessons from Paul Cormier, Red Hat’s Chairman

Paul Kormey, former CEO of Red Hat, shares strategic leadership pillars learned from scaling the company from 50 million to 4 billion in revenue and from 150 to 22,000 employees. He emphasizes that a real strategy must be executable, not just an aspiration. Red Hat's effective strategy was "helping enterprises consume open source," which guided engineering, marketing, sales, and partnerships. The four pillars are: having an executable strategy, developing a supporting plan, aligning all functions on that plan, and communicating constantly. The CEO must own the strategy and continuously test alignment by asking, "What problem are we trying to solve?" This prevents teams from diverging into unrelated areas. Paul illustrates this with Red Hat's bold decision to stop its popular retail Linux version to avoid confusion with the enterprise product. Regarding culture, he argues it is defined by what leadership lives daily, not by written rules. Open culture means transparent communication and decision-making, not that everyone gets a vote. On delegation, Paul believes people management is not a pure science separate from domain knowledge; the CEO should ideally have deep understanding of the technology and business to drive strategy effectively, especially in fast-moving tech sectors.

Transcription

6291 Words, 34207 Characters

English
It's about strategy and strategy is a very much overused term, but from a company perspective you can't imagine how many times I work with companies that really don't have a strategy. We think about when I first joined Red Hat, the strategy so they thought was that they were going to be the open source leader in the world. And that's not a strategy, that's an aspiration. Hello everyone and welcome to Built Not Born, the startup Go To Market podcast by Venture Guides. We're in page 9 and around here we believe that great companies are built not born, one smart decision at a time. Each week we take you through real conversations with founders, investors and Go To Market experts on what it really takes to land customers and scale your startup. Now let's get to work. Hello and welcome to Built Not Born, the podcast where we dive into real stories behind startup execution, venture capital and Go To Market strategy. I'm Sage Nye, venture partner at Venture Guides. And today we are joined by Paul Kormey, chairman and former CEO of Red Hat, the world's leading provider of enterprise open source solutions. Over the last 24 years, Paul played a pivotal role in scaling Red Hat from a scrappy, small Linux distributor to a multi billion dollar enterprise software leader. He spearheaded the launch of Red Hat Enterprise Linux, led game changing acquisitions like Ansible and Core OS and ultimately guided the company to one of the largest software acquisitions in history by IBM. What makes Paul's story especially powerful for founders is this Red Hat wasn't just about building great technology. It was about building a great business and great teams and real outcome. Paul spent decades hiring, managing and scaling talent across engineering, Go To Market and leadership teams. In this episode, we're breaking down what Paul learned from scaling a business from 50 billion to 4 billion in revenue and a team from 150 to 22,000 as he's transitioned from EVP of engineering to president to president and CEO, leading the company through rapid growth and change. Today, Paul will share his Paul's pillars of strategic leadership that helped him achieve the success, but can also be learned and applied to companies of all sizes and stages. Paul, welcome to the show. Thank you Sage. Pleasure to be here. We are so honored to have you on the show and excited for all the learnings that you'll be sharing with founders. One of the things we would love to start with is a little bit about your background and beginning at Red Hat. So the last 25 or so years, probably a long time. I mean, a lot of people's minds. I've been associated with Red Hat. Prior to that, I've spent 40 plus years in the tech space. I was in software before it was really even considered software. So started my career early on at deck, which many of you may or may not know and did a couple of startups, couple of mid-sized. And actually, it was with a mid-sized company when I went to Red Hat back in 2000 and I went back to almost a startup, even though it was a public company. As I said, I was employing 130 or 40 or something like that. So it's sort of been around the horn on technology always based here in Massachusetts. And one of the things that we've talked about before today was the importance of strategic leadership. And we've started coining them as Paul's pillars of strategic leadership because that's what helped you think about taking it from that really scrappy startup to the largest acquisition in tech history. And so I'd love to have the audience hear what those pillars are and how you thought about them. It's interesting because I've sort of stepped back a bit from Red Hat. I'm still involved a little bit with Red Hat, but I now work as a senior operating partner with Adventure firm and we help companies, not we help management teams. And those strategic pillars are still very much in use. And when we talk about, I mean, you almost might think it's common sense, but you'd be surprised how often they're just not practiced. It's about strategy and strategy is a very much overused term. But from a company perspective, you can't imagine how many times I work with companies that really don't have a strategy. The first one is have a strategy that you can execute too. The second point in support of that is really develop a plan supporting that strategy that can be executed to across the organization. And that's not a strategy. That's an aspiration. And one of the things that we did was we really tweaked that a bit and we put a strategy as we really got to our strategy being we're going to help enterprises consume open source. And so that really is really something you can execute to it because at that point, you go through from an engineering perspective. In our case, it was Linux. If you're going to develop Linux to be consumed by the enterprise, then you have to make it stable. You have to make it secure. You have to make it supportable. You have to have a life cycle around it. From a marketing perspective, you've got a market to the enterprise. From a sales and go to market perspective, you've got to sell in a way that the enterprise consumes. You have to have partners that are also associated with the enterprise. So those first two bullets, I mean, really, you see how much they can change once you really get into a real strategy. The third pillar really is get all in the company across all functions on the same strategy and plan. It's really important. You know, if you've got one part of the company thinking that they're enterprise and another card thinking that their consumer, it's just not going to click. The fourth pillar is communicate, communicate and communicate. You can't imagine how often you have to communicate the strategy. You have to test every time when people come into you with a plan. How does this fit into the strategy? During COVID, for example, pre-COVID, for example, as the CEO, I used to do a quarterly all-hands meeting, even when we were 22,000 people. When we went into COVID, we did every two weeks all-hands Zoom call. We would talk about strategy. We'd bring in various parts of the organization that would really talk about wins that they did that really lined up with that strategy, etc. And then finally, it's constant leadership, synchronization and reinforcement from the top on that strategy and plan. As I said with Red Hat, we grew it from when I started 140 or something, people like that to 22,000 when we were required by IBM. You can imagine when you're growing at that rate, you can only imagine you're bringing people in from all different walks of life with all different experiences, what are people like to do? They like to go to the place where they've been in the past and they're used to. You've got to continue to readjust with that strategy and retest that strategy and it's got to come from the top. It just has to come from the top. The CEO of the company has to own the strategy and has to ensure that the strategy is being implemented across the entire company. And in times, has to tweak and change the strategy as you get more information, things change, etc. So really, it's a long-winded version of the four pillars, sort of what some examples of how you execute to them. I think that makes a lot of sense. And particularly with early companies, one of the things that resonates a lot with us is a lot of times founders have built incredible technology so much so that they've had inbound sales and people coming to them. And then the next step is building the outbound, owning more of your destiny, being able to take the message to customers. But that can be a really scary transition because you're coming from something to your point, something that you know to something that you don't. And so it's one thing for the CEO to build up his or her own courage to go take that step. It's another thing to get that message across the whole company and make sure that everyone is aligned. I don't know. Do you have any ideas or suggestions for CEOs that are trying to build that courage and get everyone aligned to shift towards outbound? I think that goes to number four. Communicate, communicate, communicate. In test, we had a little thing with projects when I ran Red Hat of, you know, bringing projects to my team, sort of green lighting, especially new projects or even existing projects. They come into the sweat watch. And what that was is present to us and it's always a test. How does that align with the strategy? How does that help your customers? What problem is that going to solve? The most often asked question of my 25 years at Red Hat in meetings was, what problem are we trying to solve? Because you can't imagine how many times people go off into the weeds and really go down into the weeds. And sometimes it just takes someone and the leader to bring it back up and get everybody re-synchronized on what problem we try to solve. So it's that constant communication and testing of how things really fit. That's why I think so much it has to come from the top. Yeah, I think we see that a lot as well. We talk about in order of priority, it's the customer and then the team and then yourself at the bottom. And the problem that we solve, if you don't solve a problem for the customer, then what's the point? Why does anybody justify building these businesses and existing? Exactly. Great. And I think one other question as we're thinking about this that we talked about is you mentioned there's sort of the overarching strategy, which the CEO owns and is responsible for. And the team has sort of sub strategies and service of that main goal. How do you think about empowering them to come up with their own strategy? We'll also make you sure that they're aligned with the overarching mission. I mean, I think that's the fine balance of the CEO. For example, we really refined it to say, our strategy is going to be helping enterprise consume in this case Linux. From a go-to-market perspective, we bring in a sales leader. It's up to that person to really put together the plan. Is that going to be a direct sales force in just certain customer aspects, you know, the top of the pyramid? Are we going to get to the middle of the market? Is that going to be partners? Is that going to be resellers? You have to let them execute to that portion. But having said that, I'll give you another example. In same logic. is that early on in Red Hat, we had some sales leaders that felt we absolutely had to go into the commercial or retail world with Linux. So to have them go off and start to look at resellers or partners etc. that are servicing the retail market, that's when you as the CEO have to question that and pull that back. So that's really a way to give enough leeway out there for the experts to execute to this, but also continue to resynchronize and come back and pull back or at least ask, how does that fit into this on a constant basis? My opinion, it is the largest focus for the CEO to keep the company on a coordinated strategy across all aspects of the company. It's a more than full-time job. I hear you on that one and I think we're touching on so many different themes that we talk about with companies as well to your point about going into the commercial. There's a question of, okay, who is your ICP and how do you define them? And is it the sort of retail market where you're selling to the individuals or is it more of this enterprise motion? And I would be curious as you think about defining and owning the ICP, how much of that do you think is the ultimate? I mean, everything ends up being the CEO's responsibility, but how much of that is really the CEO's final decision responsibility for versus getting input from sales who is talking to customers every day or marketing or product? Well, it's 100% the CEO's responsibility, but getting input from sales in customers is really important. Frankly, I personally feel, and I probably wouldn't have said this when I was running the company because I would have upset people, I put more stock in hearing from customers than I do from sales. I got to listen to both, but I mean, sales in my time at Red Hat, at least 10 times I batted down doing a retail-based operating system. In fact, we stopped it when we decided to go to the enterprise with Red Hat Enterprise Linux. We were the leading retail Linux on the shelf at the time it was Bach's product on the shelf. We literally stopped Red Hat Linux. That's how drastic we really executed to the strategy. Think about this. You know, I said we were 50 million in revenue. We were actually a public company at the time. We knew that when we came out and focused on the enterprise with Red Hat Enterprise Linux, that if we had both side by side, they would always be confused. They were different pricing models. They were different licensing models, everything, but they would always be confused. We actually took a bold, bold move and stopped the retail version. Red Hat Linux, we end of life did. We took a ton of heat for that because at the time we were the most popular, hobbyist, operating system out there. That's how drastic we went with picking a strategy, taking a bet on that strategy and executing to that strategy. So was the CEO's responsibility to make that decision to stop it, but it was the sales and go-to-market organization to put together a plan to execute on that. Fantastic. I'd love to spend some time on myth busters, particularly I think myths that founders hear a lot from people that essentially don't know the business as well, but are giving the buzz-worthy snapshot or tidbit. And I'd love to hear your perspective on all of them, particularly as you've built these incredible companies and seen a lot of founders in your current role. So the first one is that when you're hiring, culture fit is the most important criteria for deciding on an employee. I would love to hear what your thoughts are on that as someone who has hired many, many people. And then how do you balance culture versus culture fit with the current culture, culture ad, or potentially just raw talent? Well, it's really interesting because I think culture is really, really, really important. And before I got to Red Hat, they didn't even have a business model before I got to Red Hat. So it was just open. Everything was open. They really didn't have a strategy and a model on how they were going to monetize it. It was free software. It was 29, they put it in a box. It was 29.95 for the box and you could use it as much as you want it. We weren't going to make a billion dollar company on that. But the culture was always open. And so one of the things we kept from an open perspective was a culture was open communication. And so with that, we even drifted for a while from a culture perspective as we grew so rapidly. Lots of people that were there from the beginning and coming in really confused that open software development model with open free. And so we really had to reset that a lot. I mean, there was many times as the CEO, I stood up in front of the pumpkin, said people would say, well, you're going down this path and we don't agree. So we should get a vote on that. No, open didn't mean that everybody got a vote on everything. I had to explain what the culture was and the culture was by open what we mean is, somebody is going to make a decision. Even in the open source community, you have maintainers out there. They make the technical decision on where that stream is going to go. Somebody's going to make a decision. But what open means is as the leader, you have to communicate what that decision is, you have to care people's input on it. You have to tell people why you got to that decision and you have to just keep open communication about that. That's what the culture was. And so we set that culture. And another thing on culture too, as I said, lots of people came from different places. There were so many people as we grew that wanted to put task forces together on what the culture was and things like that. No, that culture of open communication is something you have to live every day. When you see people coming, especially other managers coming that came from organizations that weren't maybe that open and you start to see them doing things with their own organizations that just don't live up to that. That's when you go in and give the example. You hit it. So I'll give an example, even inside of our own organizations, I travel to the field all the time to our field offices. And maybe some of the managers out there weren't as open with the people in those offices that were further away from the mothership here. And I'd go out, I'd do all hands in person in their lunchrooms, ask me any question and I'll go through it. You set that example for the leaders in other parts of the organization and they quickly come around to it. But the culture really is of an organization really comes from what the leadership lives every single day. It's really hard to write down. Here's our culture and think that everyone's going to adhere to that. And coming back to your strategic pillars, what leadership flows every day and continue to reinforce and communicate and drive throughout the organization makes a lot of sense. All right. Well, so the second myth is closely tied to this. And again, as someone who has hired many people, I'd be curious about your thoughts here. But we've heard multiple people mention that founders should delegate the people management early so that they can stay focused on the product. And I think there's arguments on both sides of the statement, but I'd love to hear your perspective on what the risks and the opportunities with this are. And then also I imagine it depends a little bit on the company and the founder and all of that as well. It totally depends on the company and the founder. In a perfect world, the founder, in my opinion, keeps going with it in a perfect world. But some founders, especially in small startups, the brilliant engineers, they don't want to deal with the people management. It's just not in their nature to be that open, to be that you have to kind of be an outward personality to be able to communicate, communicate, communicate, right? And some founders just, it's just not in one of their skill sets. It's not in one of their desires. In that case, it is good to find someone to be the people manager. But even bringing in a people manager, I mean, I think especially in the tech world today, if you haven't noticed, all the big tech companies are run by X product people. They're run by people that came up to the most part through the technical world. And I think in today's world, that's even more important in the technology space because tech is moving so fast, it's so complex, it's so intertwined. And having not come from that world, how are you even a people manager in a company? Because at the end of the day, whether the CEO of the company is, quote, as you said, a people manager or the founder who came up with the technology, at the end of the day, you have all the way back to my principles. That CEO is the keeper of the strategy. And so they have to drive that. So you have to understand where it's going. So there is not a one size fits all, but in a perfect world, I don't agree that management is a science unto itself. I have an undergrad in computer science and management. And I also have masters and software engineering. But my management classes, there used to be two halves to the room that, you know, management is a science unto itself. And you can either manage a Dunkin Donuts or a nuclear reactor. And the other side of the room is people that say, like me, let's say you have to have some knowledge and experience in the place that you're running your company. I'm on that half. So I don't think does any such thing as just pure people managers. I think it comes hand in hand with a company, but you've got to get the right person for the right role as well. Well, and I think to that point, so much of enterprise technology so much of the world today is about understanding the nuance and understanding the unique solution that you offer customers. And so you need to be able to build a team that articulates that maybe the person who was a perfect product person at one business doesn't fit well in another one. Maybe they do. I'll give you a great example because it just hit me. When I joined Red Hat, they hadn't decided to go to the enterprise. It was just out there. There was probably at the time, 25 engineers in Red Hat when I joined. None of them, they were all open source giants. They were all, many were leanest to revolve us was the founder of Linux. Many of them were his lieutenant's, the engineer that did the network and system work for Red Hat, the engineer that ran the kernel work for Red Hat. I mean, all these different places. but none of them had done commercial software. When we decided to go to the enterprise, one of the first things I did was I came from DAC which many people, especially your younger guys don't know, was at one time they were the second largest computer company in the world to IBM. They had done multiple operating systems, et cetera. I hired a whole crew of engineers that came from the Eltricks Unix World, from the Unix World, it was very close to Linux. None of them had ever done open source software. I put those together with the open source people because the combination was we wanted open source developed software for the enterprise world. And so that's how we hit that culture point, was really pick people's talents and use those talents and leverage those talents in the right places. So that's how you have to really look at culture and really how it runs into the whole fabric of the company. So the previous question, that's why culture is everything. But you have to build that culture and live it every day. - I think that makes a lot of sense. I do think it's worth calling out the thing that we keep coming back to is build it and live it and keep reinforcing it and keep communicating it. It just shows how critical the role the CEO is on building the strategy, living the strategy, reinforcing the strategy, maintaining it, measuring it, all of that. The final myth that I am so curious about your perspective on having been now on both sides of the table is that investors are only meant for access to capital and potentially access to future rounds. What are your expectations for an investor in an ideal world? What advice would you give to founders on that? And if we think about what the ideal is, what do you think is also advice we give to someone in terms of their expectations in a realistic world? - It depends. I think in the VC world and maybe even in the PE world it's one thing, I think in the public company world, it's a different thing. So investors, I think in the VC world, I think they're also there for advice. Investors are seeing many, many different companies, they're investing in many, many different companies. They see what works in one place and might not work in another place, et cetera. I mean, I'm on five boards of directors right now. I've been on boards, both public and private boards for 20 years, 25 years. I'd like to think that as a board member, our job is not in which we're investors. The boards I'm on, we're investors in. As a board member, I'm not there to micro manage the go-to-market organization, the engineering organization, or even the company as a whole. But I think we can give advice to the management team, take it or leave it, right? We can give advice of what we've seen as work well in some areas and not work well in other areas. And I think that's a really important part of an investor. I think the other important part of the investor is confidence. The investor having confidence in the management team is I think gives everyone to go ahead to do what they feel is right for the company. When you lose confidence on either side, it's either, you know, it's time for change. And you know, change on the management side or change on the investor side, usually on the management side. So I think that confidence from an investor to the management team, and the attitude from an investor that they're there to make the management team successful. And I think that's really important to a management team to know that they have the confidence in their investor base. - Would you stretch that advice to independent board members as well of the really critical piece is having the confidence and being able to bring experience and advice, or are there other criteria that you would suggest people look for? - No, I think when independent board members I think it's the same thing. I mean, I think when you build a board, you try to add people to your board that bring diversity to the board. It'll have, they have different experiences and different areas of the company, right? And so I think it's important to get those diverse opinions and guidance from the various board members. And so either diversity in what they've seen or been or lived in life or diversity and what they've seen and been and lived in various pieces of other companies. So I think all board members are there. Like I said, I've been on multiple boards I am right now. I don't see being a board member or an investor as being to police the company. I see them as being a resource to the company to ensure their success. So that's how I sort of approach the board areas that I'm on. - All right, now we'll switch gears and hit some rapid fire execution scenarios, which are meant to be tactical high stake situations that founders are probably facing frequently. And we'd love to hear your quick thoughts and perspective on them. So hiring your first go-to-market leader as you have been advising technical founders who need to hire their first go-to-market leader. How do you think about the screening process and non-negotiable traits that they should look for? - I think the screening process, I mean, assuming you have the rest of the management team built out, a big part of the screening process is the rest of the management team as well. 'Cause that's gonna be a team. You've got to ensure that you've got the right qualities that gel as a team there. So that's certainly part of it. The second major part of the screening process goes back to what we talked to, wait is that person, what do they think of your strategy? The strategy that you're working on and at executing as a company. And so understanding their either experiences or where they feel, what they think about it or where you think they'd lead within that strategy is I think really important. So that's a big screen forward of how do you think that they fit and feel and would execute to the strategy that you're on? And I think the third piece that I think is really important is sort of goes back to jelling with the rest of the management team is how you think that that person would sort of respect the guardrails of, where their responsibility starts and where it ends. And so so many times just since the beginning of mankind that the sales leader typically argues with the product leader on why a product's not selling. So what kind of collaborative person do you think you're bringing in here? So when you do have a situation where products not hitting the market, in the market, you have a collaborative team that can go in a room with open minds to figure out why. So I think those are some of the screening in areas that I would look for in bringing in the first go to market leader. - And that sets us up very nicely for the next question as well, which is if there is dysfunction leadership team and you realize either your team is misaligned or underperforming, what's your first move to try to fix it? - The first move, and I just dealt with this, just one of the companies that I'm on the board of, the first move was to really, you see that misalignment. So you go, you have a one-on-one, you go to lunch with each of the management team members and you sort of see where their heads are at, where they think the issues are, et cetera. And then you get them all in a room together and see if you can work through it that way. And if that doesn't work, then you look at changes. But it's up to you as the CEO to really figure that out. We just had this situation in one of the companies I'm on the board of and the product team was going down one path, the marketing team was going down another path, and the operations team seemed to be going down a different path. And I talked to the CEO, I said, look, it's your job to pull the strings here. You own the strategy, you've got to figure out, if they're all going down different paths, obviously one of them, where multiple, are going down the wrong path, it's up to you to figure out which ones and pull it together. So you heat it individually and then you try to bring them together for them and then have them come back with an integrated plan and if that doesn't work, then you've got to figure out where those changes need to be made. But I don't take making changes lightly, but also as the CEO, you've got to be prepared to do that. And sometimes it's on a regular basis. - And since, and I think again, that leads nicely into the next question, which is, as you think about a remote first world, and all of the ways where communication can break down and culture can break down and people can become misaligned, how do you think about scaling that culture? And frankly, how do you think about remote work or work from home compared to being in the office and being together? - This is a really hard one that all companies are struggling with right now. There's no question in my mind. I mean, Red Hat had been a hybrid environment, even way before COVID, so we had a lot of remote people, et cetera. And there's a lot of pros and cons on both sides. It depends on the role. We had many engineers, especially the open source engineers. Over the years, I've never, I'd never met because we just never seen them. So I think if you're someone that's working on a contained piece and you can sort of communicate to the pieces that surround you through email and other ways, I think that's doable. But as you start to get further up and the groups are larger and it work together and really defining and driving the strategy, getting together on a regular basis, there's just no substitute for that. I mean, pre-COVID, I spent a big part of my day on a whiteboard with other people. And even in just every conversation turns into a block diagram. So it really is that balance. I mean, personally, I think some part of the company, I think a hybrid approach, whether it's three days a week in one place or whatever is very beneficial. But I don't think it's hard and fast across every position. There are some positions that could be at 100% remote. I think you've got to take it on the position and really execute it that way. I think it gets more and more difficult as the company gets bigger and larger and moving faster where the people that are trying to execute on that strategy tweak that strategy, make moves and changes on a regular basis with them not being in the same room on some period of time, whether it's even a few days a month, I think that's difficult that way. So it's a really hard problem and I think everybody's grappling with right now. - Yeah, I think every single one of the young companies that we're seeing is trying to figure out that question. and all of the benefits, but then also potentially the impacts to particularly young new additions to the teams learning curve and the culture and to your point of communication and strategy. Yeah, I mean, especially the younger workers and how you get that experience from talking to someone over the wall on something you're working on, there's just no substitute for that. So I don't know how you even intern in a fully remote way. We did it through COVID, but I don't know that it's optimal. I agree, and I think it's a great point. Even if you're just setting 15 minutes Zoom meetings to check in, there's something that feels so formal about a Zoom meeting. And so you missed those informal little tidbits that get shared and information and catch ups. Absolutely. Couldn't agree more. Well, thank you, Paul. This has been an incredibly valuable conversation. And breaking down your experiences has been so fascinating for us. I know our listeners are going to agree as well. Paul, where can people learn more about you and your work at Francisco Partners and Red Hat? A big part of what we did all along YouTube. I mean, one of the big things we used to have, we still do on a regular basis was the Red Hat summits. And so we typically pre-COVID is there again now. We'd have anywhere from 10 to 15,000 people in attendance. So all of those, I'd always do a talk there so that they're all on YouTube. So that's a place. And many of our companies are out there that we that we manage with Francisco Partners, but I'm not believe it or not. And I'll show my age on this. I'm not a huge social media poster. Fantastic. Well, again, thank you. We really, really appreciate your time. And I'm excited for our listeners to hear all of your insights. And to our listeners, thank you for joining us on Built Not Born, the podcast where we break down real stories of startup execution. If you enjoyed this conversation with Paul, be sure to subscribe and leave a review. Thank you very much. Built Not Born, the startup Go To Market podcast is brought to you by VentureGuides. To find out more about VentureGuides and how our Venture Capital Plus guiding model helps early stage startups build scalable GoToMarket strategies and grow faster. Visit VentureGuides.com. And then make sure to search for Built Not Born in Apple Podcasts, Spotify, YouTube Podcasts, or anywhere else that you listen. Hit Subscribe so you don't miss any future episodes. And we look forward to building with you. On behalf of the team here at VentureGuides, thanks for listening. Until next time, keep building.

Podcast Summary

Key Points:

  1. A real strategy must be executable, not just an aspiration like "being the open source leader." Red Hat's effective strategy was "helping enterprises consume open source."
  2. The four pillars of strategic leadership are
  3. The CEO must own the strategy and constantly test alignment by asking, "What problem are we trying to solve?" — this prevents teams from diverging into unrelated areas.
  4. When shifting from inbound to outbound sales, constant communication and testing against the strategy is crucial for building courage and alignment across the company.
  5. Culture is defined by what leadership lives daily, not by written rules. Open culture means transparent communication and decision-making, not that everyone gets a vote.
  6. People management should not be seen as a pure science separate from domain knowledge; the CEO should ideally have deep understanding of the technology and business to drive strategy effectively.

Summary:

Paul Kormey, former CEO of Red Hat, shares strategic leadership pillars learned from scaling the company from 50 million to 4 billion in revenue and from 150 to 22,000 employees. He emphasizes that a real strategy must be executable, not just an aspiration. Red Hat's effective strategy was "helping enterprises consume open source," which guided engineering, marketing, sales, and partnerships.

The four pillars are: having an executable strategy, developing a supporting plan, aligning all functions on that plan, and communicating constantly. " This prevents teams from diverging into unrelated areas. Paul illustrates this with Red Hat's bold decision to stop its popular retail Linux version to avoid confusion with the enterprise product.

Regarding culture, he argues it is defined by what leadership lives daily, not by written rules. Open culture means transparent communication and decision-making, not that everyone gets a vote. On delegation, Paul believes people management is not a pure science separate from domain knowledge; the CEO should ideally have deep understanding of the technology and business to drive strategy effectively, especially in fast-moving tech sectors.

FAQs

Have a strategy that you can execute to, not just an aspiration like 'being the open source leader.'

They shifted from 'being the open source leader' to 'helping enterprises consume open source,' which guided engineering, marketing, sales, and partnerships.

Constant communication ensures everyone stays aligned on the strategy; Paul held quarterly all-hands meetings and bi-weekly Zoom calls during COVID to reinforce it.

The CEO should ask, 'What problem are we trying to solve?' and test how the project aligns with the strategy, pulling it back if needed.

It's 100% the CEO's responsibility, but they should input from customers and sales; Paul valued customer input over sales feedback.

Culture is critical, but it's defined by leadership's daily actions, not written rules. Paul emphasized open communication over rigid cultural definitions.

Chat with AI

Loading...

Pro features

Go deeper with this episode

Unlock creator-grade tools that turn any transcript into show notes and subtitle files.