Sara Lindquist:
I'm Sara Lindquist from Fuse. We're an early-stage venture firm based right here in the Pacific Northwest. And just like the founders in our portfolio, we are just getting started. We believe that founders deserve more: more urgency, more community, more expertise, more reliability - more of everything. And we aim to deliver.
Today, we continue with our Operational Excellence series focused on the hiring journey. I'm joined again by FUSE Operating Partner, John Connors, to talk about hiring an early-stage technical leader. With learnings gathered throughout his time as a startup investor and advisor, and his past life as an operator, namely his time at Microsoft, he's going to have some tremendous wisdom to share.
Let's get started!
--------
Sara:
John, welcome! We're back again.
John:
Thank you, Sara. Great to be here.
Sara:
Well, thank you for taking the time and it's always just such a gift to have you here to share more great wisdom on the hiring journey. So, today, we're discussing the technology leader role, whether it's CTO, VP of Technology, or VP of engineering. The titles will obviously vary by company and stage, but I know you will have some great insights for us given the number of leaders you've worked with across your operational and investor experiences. And I imagine you'll also have some interesting stories from your CIO days at Microsoft perhaps. But to start things off, I was thinking it'd be great if we could define the role. So, John, how should a CEO or Founder think about the CTO / VP of Engineering role, especially in relation to the rest of the organization?
John:
It's such an important question for an early-stage CEO because this is the critical hire of the company, and the likelihood of success is really dependent on "how good is the initial team?". And I'm a big believer that nearly all consequential companies, it's because of the product and or service. And so, this hire is going to be critical to how you build a good product. It's a complicated role because it has to bridge both product as well as business. But in the very early stage, it's analogous to hiring the right general contractor for a complex custom home or complex commercial building. That's a good analogy.
Sara:
That's a great analogy.
John:
In that, this CTO / VP of Engineering, whatever title you arrive at for the role, in effect, you're really looking at the general contractor for the product. And this role needs to understand a lot of different things because there's multiple types of systems that have to be engineered in concert to bring together a finished product. There's complex infrastructure, there's complex networking, there's app models, data models, there's the UI work that has to happen. And analogous to a beautiful custom home, while the general contractor is not an expert in woodworking, in cement, in HVAC, in...on and on, the general contractor has to be knowledgeable enough about each to bring them all together under a schedule, but more importantly, identify when there's problems, shortcomings, or gaps in the subsystems that are going to lead to a suboptimum finished product.
The other thing that's unique about software versus physical products is that software is constantly being iterated and evolving to either new 1.0 versions or behind the dot versions. So, the project is never really done, it always continues in the software world. And so, that general contractor capability of being able to iterate and improve is a mindset that is very, very important in the hire that you're going to make to build your consequential company.
Sara:
That's great. That's a super valuable analogy. So, thank you for sharing that. Okay. So, now that we have a baseline understanding of the role, John, can you describe how the role, and the engineering landscape in general, how have they both changed over the years, and what would you say are the requirements of a modern technical leader?
John:
Oh my gosh, it's really an interesting question, Sara, because I think in some ways you could argue that the role of building software, the role of a leadership position - CTO / VP of Engineering - whichever you choose to call this position, in some ways you could argue, "Hey, it's gotten easier over time," in that the cloud provides a degree of service and finished infrastructure that in the past you had to build. Or you could argue that, "Well, there's a lot more components available that are ready to be used that makes it easier." On the other hand, the choices are so vast now in terms of cloud providers in their services, the plethora of open source technology that is available, the repositories of information software components and the information around them in GitHub and other places, and then just the awareness of how many different ways you can approach building software depending on the programming language you want to use, the type of process you want to use.
So, in some ways you could argue, "Oh, it's easier than it used to be because there's so much more enabling technology." On the other hand, it can be incredibly more difficult because there are so many choices and there are so many opinions the team will have. And so, I think in many ways, what it requires is that this role be very broad in their thinking, but able to bring the team down to reality of, "Hey, we have to make choices and we have to meet schedules." And so, you want a leader who is knowledgeable enough about all the choices, but strong enough as a leader and a technologist to know which available external tools and platforms to choose, i.e., what are the decisions we're going to make? And then secondly, be able to move the team along in the world of both the startup economy as well as the customer economy that expects high speed and lots of iteration.
And so, this role is super critical for leveraging modern services and fast iteration, but you have a plethora of choices and you have many different viewpoints on the team depending on where they're hired from, what their other projects were. And so, this modern engineering environment is a marvel, but it's also extremely complicated and it's very hard from a team management perspective. And so, this leader has to be a highly practical, technology-oriented person who thinks practically like a business person, and that's a broad and demanding role. And finding both a strong technologist with good business acumen is really critical because of all the choices they have to make.
Sara:
I think that's a really key component that you call out and a good framing for what I'm going to ask you next. So, thinking about all those skills that this person will need to straddle, what would you say are some of the key traits, digging in a bit deeper - now that we know that overarching responsibilities that they need to accomplish) - what are the key attributes to look for and for a great technology leader to lean into?
John:
If I think about what are a couple of key things that you would look for using the general contractor analogy is two things. First, they've got to be a master at estimating the task and scheduling the work and budgeting the work, i.e., how many people of what skills over what time is it going to take to meet the goal of where we are in the company today? Are we building the first proof of concept, are we building the MVP or are we building a V2 product? Are we re-platforming... What are the demands that the company's goals are putting on you? And how good are you at coming up with the plan and the budget to meet that product goal, for whatever stage the company's at?
Then the second thing is this person has to be really good at... I would call them a master optimizer and master estimator. So, a master optimizer is "how do I plan all of these different work streams that are part of a completed product and how do I ensure that each of these work streams in the individual processes are being done such that we come close to meeting the goals of the business?" And at the end of the day, what you really find in really great leaders of this function is that they're really good at working with the business side and the technology side to come up with both the plan, the schedule, and the deliverables.
Sara:
This may be obvious to some, but what do those key relationships look like within the business? On the business side, and obviously with the product team, but I just think that's an important thing to call out as well in terms of orchestrating those relationships as well.
John:
It just depends on the stage of the company. If it's very early stage and you're just building the project and the CEO is not a technical leader of the product, the CTO's going to be working very, very closely with the CEO. Maybe there's one or two salespeople, probably not, but you're going to be working very closely with the CEO, and mostly your team, in getting that initial prototype and the original MVP done. They're also going to be working very closely with what you target as the early lighthouse customers or early lighthouse users. How do you get trial and feedback to that initial MVP if you're at a later stage where you now have a product that can be either trialed, demoed, or sold? The CTO and/or VP of Engineering is going to be working very closely with the early GTM team, and some of your key engineers are also going to be working very, very closely with the GTM team, even if it's a very small seed team.
And that product organization has to be learning from the customer side of things. Did we hit the mark? Where did we miss? What features, functions, or performance capabilities are customers' demanding, or asking for, or wishful for, that then feed into the subsequent schedule of mandatory to deliver, to have product-market-fit, desired to have for future growth... And there's just a lot of trade offs that this leader is going to be having to make along with the CEO and the product team based on that feedback. So, they've got to be a very good listener and a very good learner. And one of the most important things is being able to sort out where is the vision for this company and its product versus where customers are at today. And generally, customers will give you good feedback on what they would like, what they expect, what they need, but oftentimes, you got to talk to quite a few customers to get that sorted out correctly, because what they're asking for may be aspirational that you deliver in version two, version three, particularly for larger, more complex organizations.
And so, this person has to be figuring out what can we do to get the product sold and have a value proposition today while we also build the product roadmap for the future for additional functionality and additional value to customers. So, while it's not a sales job, that is going to be a key part of what this early leader is going to be involved in. And they've got to be working very, very closely with the CEO and the go to market team to figure out what are the tradeoffs that we can meet, what are the tradeoffs we can't meet, and how do we explain that to customers and earn their trust that we will deliver what they're expecting over the long haul, but in the near term, we can deliver value that is worth paying for or worth using and trialing our product.
So, this leader will need to live both in the customer world and in the internal engineering and product world and really bridge that gap between the two. And I have found that the really great CTOs are very customer focused and customer obsessed, while also having a deep affinity for technology. But the end goal is to satisfy customer needs, not to build software that the team loves. And getting that, what the customer wants and needs and will pay for, understood by the team that that's the goal, is something that a really good business oriented technology leader does very well.
Sara:
Thank you. That was a really helpful answer. And I feel like you covered a lot, but were there any other key attributes or things you wanted to call out there?
John:
The key leader in the engineering function really has to drive for three key things, always demanding high quality from the engineering team. We've got to have quality. Secondly, we've got to move fast and we've got to innovate rapidly because if you don't, some other company... If you have figured out a market that is a large TAM and could support a really consequential software company, you're going to have lots of competition very fast. Once the investing world figures out there's a big market, there's a lot of competition being funded. So, you always have to insist on quality. That can never be a bar that is lowered. But you have to get a culture of rapid innovation, and you have to get a engineering culture to understand that cost matters, i.e., we have to be efficient in how we're using precious capital to deliver our product.
I think the other thing that is really key, particularly in this world that is now reality in building software is that the demand for high quality software engineers is vastly in excess of the supply. And that's due to both the large number of companies that are building software to sell to enterprises or consumers, as well as the fact that companies around the world that are not software companies are staffing their organizations with software engineers at a level we've never seen before as the world, the physical world and the business world, goes through this massive digital transformation. And so, the demand for talent vastly exceeds the supply. If you are not a strong leader, builder, and collaborator, the engineering team's going to feel that impact. And because they have so many options, you could be really good at a number of things, but if you can't attract, develop, and keep talent, you're probably not going to achieve your company's objective of building a great product that customers love. And so, it's a very demanding job and it's about as critical hire as any founding CEO will ever make.
Sara:
Yeah. Doing all those things all at once is definitely challenging, but are there any other key challenges that you'd want to call out?
John:
One of the things that I think is really key is, particularly for early stage companies, you just have to have absolute truth on where your product is at. And the market gives you really good feedback on where you're at. And as you start to attempt to get people to use or buy your software, people are very open to providing lots of input until they have to write checks. And the single most important signal your company's ever going to get is, will people pay for it? And if people aren't interested in paying for your product and/or they aren't interested in paying close to what you think the initial price point called for, you just got to realize, hey, the market is giving you the single most important signal of feedback you can possibly get. So, constantly having the team understand "where we really are versus what customers are saying".
And then the second thing is, where are we really versus the competition? And are we really as good as we're celebrating internally or are we paranoid that we're not that good, we have to constantly get better, and if customers aren't buying or aren't renewing, it's because we have built something that isn't nearly as great as we think it is and the market's telling us? So, a CTO who is very reality based and very open to getting feedback from the market is a really important trait and something that is really critical to get incorporated into your engineering teams. What I've seen in my 30 plus years of working in technology is, generally, companies when they're very early, are very good at listening to the customer voice and understanding what customers are saying, because they have to. Because if you don't deliver what they want, you don't raise more money because you're not growing sales.
And the market is really clear on up or down, is this thing something we're going to put more money in or not? And the signal is the customer. Well, as companies become successful and established, and the teams grow larger and larger on the sale side, in product management, in customer success, in engineering, it's very hard to keep that engineering team really customer focused when they get further and further abstracted away from customers. How this leader, whether it's the CTO or VP of Engineering title, that role is critical at keeping that customer connection and that customer understanding alive as the organization becomes larger, more complicated - and because of humans - just more bureaucratic. And that's a really critical trait and goal that is a mandatory for the leader of this organization.
Sara:
Yeah. John, thank you. That was a really great addition. Definitely, amazing opportunity and challenge at the same time. Okay. So, my next question for you, now that we know what matters for this role and what attributes to look for - if I'm a CEO or founder, how should I think about timing for this role? When would you say is usually the right time for a VP of Technology/Engineering or CTO to come in?
John:
At the very early stage for a CEO. The first question is, are you a technical CEO who has the germ of the idea for this product, or have you built products in the past? And if that's the case, if it's your idea or your co-founder's idea and you're both technical, you're both going to be very heavily involved in the early product and you probably don't need to hire a CTO. If you are not technical, but you have a great business idea and you've never built product or you've never run an engineering team, it's critical that you get this hire done very early and you make the right decision on that hire. And if that early decision isn't the right one, you better move fast because you're just not going to have a lot of time and money to recover from the wrong hire. So, technical, CEO, founder, you're probably not going to hire this role unless you are going to also spend a lot of time on the sales side and go to market side, and you know that you need someone critical to help build your vision.
But once you get past the pre-product-market-fit stage, you're going to need an engineering leader that can build the team and build the product and scale to the multiple demands of both building the product, keeping the talent on board in the engineering organization, and managing the customer feedback loop that begins to happen once you have product-market-fit. You're going to hire one pretty early on and making sure you understand what role it is you're looking for, are you looking for someone who's going to be visionary and help design what the product is? Or are you looking for a leader who - the vision set, the product scope is known, the frame, the architecture drawing is all done and signed off, and the budget is known - and you're going to hire a builder, someone who's going to hire and build the team to build the house. That's a different hire.
And so, understanding early - is it a visionary architect or am I looking more for a very strong execution leader who's going to build the plan? Understanding that you're going to hire one or the other very early on if you're starting to scale. I think then, as you get through the point where, let's say, you're past the 10 million stage of revenue, because if you survive from zero to 10, and you've done that with a reasonable degree of capital efficacy, you probably have something, you probably have a good shot at building something that at a minimum is going to get acquired in the optimistic scenario, is going to have a shot at becoming consequential. The skill sets will change over time as you grow. And often, the type of leader you'll need is someone who can manage multiple versions of products that can handle perhaps multiple team locations, that can handle multiple types of technology decisions you're having to make as you grow.
And that person is likely going to come from a background of more years of experience managing multiple teams and learning under multiple managers. It may mean that you'll be tested to see if your very early hire can scale, but you're very likely, as you scale, you're going to have to hire a more experienced person that has a broader set of experiences and has scaled engineering teams. And so, knowing then, "okay, is that the time that I have a CTO who is principally a visionary and an external evangelist, and I have a VP of engineering who is really running the factory of building these products?" is a key decision that will be made. But generally, as companies get 50 million or north, that's when they start making that decision. Beyond 100 to 200 million, almost always you start to see that separation and decision.
Sara:
Got it. Okay. That's great. That's really helpful. So, now we know what to look for, what matters, and when to think about hiring this role. What advice do you have for the screening and interview process? What are key things that a founder or CEO should look out for?
John:
I think the first thing is the demand for these roles is very high and the supply is constrained. So, the first thing that you really have to screen for is: will this person be a really effective business leader? Because it is such a key business role in addition to a technology role. And a disproportionate amount of your early funding is going to go to building the product. And so, you have to get value from that initial capital infusion on the product side because if you don't, there very likely is no V2 funding or the funding is an evaluation that is very disappointing and the team loses a bunch of ownership, whether they understand it or not through dilution.
And so, the first thing is, is this person a really solid business thinker in addition to being a really good technology leader? And you're going to find in a lot of cases - more than folks stop and think about - because of this demand-supply inequation that exists in our world today with software talent, you need to be sure you're hiring someone who is not going to hold the company hostage in terms of their points of view on hiring, their points of view on approach, their points of view on lots of things.
You're going to have to be sure you're hiring somebody who is aligned with you on the business opportunity and is aligned with you on "how much money is available to build what it is we have to build". That's a business discussion in addition to a technology discussion. So, making sure you're hiring a business person, who happens to be a really great technologist and software leader is the first decision. I think, secondly, you need to really explore, particularly if they've come from maybe a large company background, what are the examples they have of them using solutions from third parties or open source to deliver much more rapid development, and much more rapid innovation, and much more rapid iteration? Because there's so much available to get from zero to V1 that can come from the software services that the cloud providers enable - from open source, from low cost third party solutions - that making sure you don't have an engineering team that thinks that it is kind of a "not invented here" and "we have to build everything".
And I think, the other thing that you're going to have to question in this interview is, because there's so many choices and there are so many different points of view in the software world, how have they worked through reaching consensus and collaboration on teams once the decision on approach and the types of technologies that are going to be used has been made? So, how do you get the team on board in order to move forward when there's a lot of choices and a lot of different competing views? So, have they brokered collaboration and cooperation? I think it's really important to have discussions with this leader that could become part of your critical executive team on what are the instances where they made trade offs between cost, speed and quality? And it's very difficult to have all three of these all the time. It's very difficult to have low cost, high quality, high speed all the time.
So, what are the examples that they can explain to you in their work history where they've managed these tradeoffs, where they made mistakes, where they made the right decisions, where they made a decision and it had to be changed? How have they made those tradeoffs? I think the other thing that is really important is: where have they proven they can find economies of scale and efficacy in their teams? So, the way everything works is... Just an example, people ask for five heads when they need four. As you get bigger, they want 20 heads when they need 15. And you start adding these up across groups and all of a sudden you have a non-economic model in your headcount. And this is true in every function. And so, where are the examples where they've proven they could get scale and economies from teams without a revolt from the team or a major delay in deliverables.
The other thing I think that is really key is, this role has to excite the employees that work in this area. Engineers, they want builders, they want craftsmen, they want people that are excellent at the craft. So, really understanding, is this candidate a true builder? And ask them, if you're a non-technology CEO, what are they tinkering on? What are they building on the side? What's emerging that's really intriguing them? It's a great way for you to know, is their DNA curious, and exploratory, and bold? And will they be able to create great collaboration and great achievement goals with an engineering team? Engineers want to build things. They love the new thing that can change the world, that can change the industry, that can change the way people work and the way people live, and is that CTO that type of person that keeps both the spark of innovation alive because they're a tinkerer and a builder, or are they much more of a manager for execution? And you want somebody that has the capabilities of both.
Sara:
John, those are great. Thank you. That's really, really helpful advice. In closing, to tie this all to a bow, I was thinking it could be really helpful if you could share some examples or maybe some stories from along your journey of great technical leaders that you've encountered. Who are they and what makes them great?
John:
I just feel, boy, I've just been very fortunate. The experiences I've had over the years... I'll start with Microsoft, and I joined when it was pretty small in '89, and then when I left in 2005, it was not small. But one of the early jobs I had, I was the business manager for what was called the systems division. And the systems division was run by this guy Steve Ballmer. And so, I was his staff. Person is a great way to think about it. And at that time, Microsoft had the systems division and apps. And systems was DOS, Windows, OS/2 languages, hardware, then networking, and then databases. And apps was Excel, Word, PowerPoint, et cetera, et cetera. Well, the systems division had some amazing leaders, and two that really jumped out at me early that I learned a lot from were Brad Silverberg and Paul Maritz.
And I learned very early how unique software talent is in terms of individual value. And one of the ways I learned that is, there'd be a reorganization of Systems about every year, 18 months - of the divisions - because everybody was figuring out what the future of software was, and which groups needed funding, and which groups didn't, and which groups were new technologies - and there was all of these new startups. And so, nobody really knew where technology was going. It was like the Wild West. The way Steve would respond to a very dynamic unchartered environment is we would reorg frequently. And so, the way that would work is Steve would get the leaders in the room, Silverberg, Maritz, et cetera, and we would go through... I remember one time the spreadsheet had a thousand people, and we went through where these people were going in the new reorg.
And then it was my job to scribe and then do all the follow-up to make sure everybody ended up where in the meeting was agreed. And I got to listen to brilliant people like Brad Silverberg and Paul Maritz talk about individuals and why they needed to go to this project, or that project, or why they wanted this person or that person. And then I got to see the intermural fighting about which groups got which people. It was sort of like a big NFL draft being done without a draft. It's like, "Hey, here's all the players in the NFL. Where do you want them to go? And who wants which people?" Well, I would just say, "Tom Brady. He's a pretty valuable quarterback." And software's no different. Some people are just exceptionally talented. And so, I got to see that. But both Brad and Paul were so good at staying on top of having a vision for where the world was going, staying on top and learning from that.
They were incredibly good at taking input, but they were also unbelievable at holding their ground once they decided and decisions had been made, and then driving relentlessly towards delivery. So, those were two exceptional, exceptional examples.
Sara:
That's a great example.
John:
In the venture side, several people really jump out. The first is Erik Swan, one of the three co-founders of Splunk. And Eric was brilliant in many ways, but there were a couple of things that he did remarkably well. I think the first was, he worked so closely with Co-Founder Rob Das on iterating the product. And Eric was more out front than Rob, but they worked very closely together. Eric was also really good at... he was a talent magnet for finding and recruiting great talent. And then thirdly, he was as good as salesperson as the company could ever hire, because when he got up to talk about where the product was, how it was being used, and where it was going, he had a depth on the product side, but he had a customer love and empathy that was unbelievably authentic.
And so, he's really critical for the success of the company. And he was also not afraid to speak up about what were the issues that we were missing, what were the problems we had, and what needed to be done differently, and he would fight hard for that and really respected it. Another leader I'm just amazed at right now is the CEO of Carbon Robotics, Paul Mikesell. And very complicated from a product perspective what the team has built - not just the computer vision and AI modeling to be able to identify what you're going to kill with a laser and what you're not as a machine is moving across a field - but being able to bring software, mechanical, electrical, design skills together in a very short time with very low capital spend and to remain calm and resolute throughout, and his ability to attract talent and his ability to stay focused on what the customer needs, what the customer is saying, and adjust accordingly, just a really brilliant engineer who happens to be the CEO, but also happens to be an exceptional leader.
And so, in each of these examples, the common thread is, great leaders who attract great people, who set a bold vision, who fight like hell for that vision, they focus on customers, they adjust to reality. Common traits across all three of those, and that's what I would look for.
Sara:
Great examples. Thank you, John. Those stories were fun to hear. Well, that's all I have for you. As always, John, this is just such incredibly invaluable time. I always learn so much from you, and I know a lot of other people are going to learn a lot from you. So, thank you once again for paying it forward.
John:
Oh, absolutely, Sara. Thank you. I love these podcasts. Keep up the great work.
Sara:
We love them too. Thanks, John.
------
Sara:
Thanks again for joining us! Be sure to check out our next conversation on the hiring journey. Up in the queue is a discussion about how to find and hire a fantastic VP of People and Culture.
Thanks again, and we'll see you next time!