Martin Casado is a general partner at the venture capital firm Andreessen Horowitz where he focuses on enterprise investing. He was previously the cofounder and chief technology officer at Nicira, which was acquired by VMware for $1.26 billion in 2012. While at VMware, Martin served as senior vice president and general manager of the Networking and Security Business Unit, which he scaled to a $600 million run-rate business by the time he left VMware in 2016. Martin started his career at Lawrence Livermore National Laboratory where he worked on large-scale simulations for the Department of Defense before moving over to work with the intelligence community on networking and cybersecurity.
"In my experience over a number of engineering leaders is whether or not they're a good engineer is totally orthogonal to the actual role. And in fact, someone that's deeply passionate about a particular architecture technology or approach can be very damaging because you have a power asymmetry in the team."
- Martin Casado
These experiences inspired his work at Stanford where he created the software-defined networking (SDN) movement, leading to a new paradigm of network virtualization. While at Stanford he also cofounded Illuminics Systems, an IP analytics company, which was acquired by Quova Inc. in 2006. For his work, Martin was awarded both the ACM Grace Murray Hopper award and the NEC C&C award, and he’s an inductee of the Lawrence Livermore Lab’s Entrepreneur’s Hall of Fame. He holds both a PhD and Masters degree in Computer Science from Stanford University. Martin serves on the board of the following Andreessen Horowitz portfolio companies: ActionIQ, Astranis, DeepMap, Imply, Kong, Pindrop Security, RapidAPI, SigOpt, and Yubico.
Sonal Chokshi is Editor in Chief at Andreessen Horowitz, aka "a16z", which she joined 5 years ago to build and run the editorial operation. Among many other things, this includes building and showrunning the popular a16z Podcast; assigning and editing pieces such as "When One App Rules Them All" on the case study of WeChat and China, which was selected in the New York Times' Sidney Awards 2015 as one of the best long-form essays (for "brilliantly marrying psychology, intellect and technology"); leading production of the a16z Crypto Canon; and many more.Before joining a16z, Sonal was a Senior Editor at Wired, where she built up the previously flailing expert opinion and ideas section into one of the leading sections there. She was one of the first mainstream editors to feature then-emerging trends such as ethereum, e-sports, the 'sharing economy', and others. Her work also started or shaped important conversations around the future of the internet, in some cases even influencing tech policy (such as software patent reform).
Prior to that, Sonal was responsible for content and community at Xerox PARC, where she briefly covered bitcoin in early 2011 and went deep on domains such as automation, bioinformatics, cleantech, flexible electronics, natural language, networking, optoelectronics, ubiquitous computing, and many more. Before moving back to California from NYC, Sonal was doing graduate work in developmental and cognitive psychology at Columbia University's school of education, and worked as a researcher "ethnographer" on NSF grants around teacher professional development and early numeracy. She studied English and Psychology at UCLA, where she also briefly worked with autistic children and later worked in classrooms. She loves reading, arts of all kinds, and traveling between worlds, and can be found on Twitter at @smc90.
Sonal Chokshi: welcome everyone. Thanks for doing this and for being here and thank you for that introduction. That was really fun.
our session is supposed to focus on hiring a VP of Engineering at startups. But I wanted to throw a big framing caveat out there, which is that I think the phrase startups is really broad, obviously these days that applies to a company that could be a year old... to eight years old, it could be a company that is small to large enterprise size. So it's not just size or how long it's been around.
I think maybe a useful way to think about it. And this is good context for the conversation, especially given Martín's background... is a company that's being built under conditions of high uncertainty.
So before finding product-market fit or pre chasm, as Martín likes to say, he's actually written a lot about this topic riffing on the Jeffrey Moore concept of "crossing the chasm" and startups that are pre crossing the chasm, some important framing context for this conversation.
And one more thing before we get started, the introduction was amazing.
The big thing to also think about is that Martín has seen this from both sides of the table. So someone who has hired VPs of engineers, as well as sits on a lot of startup boards and oversees how they scale their engineering organizations, which is something a VP of engineer does. So that's the vantage point and we'll bring that into the house and I'm going to just get started with the first question.
Martín Casado: Perfect.
Hiring misconceptions and why VPs of Engineering are so valuable
Sonal Chokshi: It's, this is about hiring engineering management, but we're focusing obviously on hiring a VP of engineer, but regardless of what we call it, cause in a startup, it might take a while to hire a VP of engineer. What's the number one misconception that you've seen when it comes to people, either hiring a VP of engineer or how they think about it or how to add value as a VP of engineer.
Martín Casado: so from a startup perspective, so I sit on about 12 boards. Now I've done two startups. involved in probably 25.
I think the number one mistake, and probably if you're going to take one thing away from this entire talk is not taking it seriously...
Sonal Chokshi: not taking the VP of Engineering job seriously,
Martín Casado: Not taking, not taking the role seriously.
And then let me put maybe just, a little bit more of a, of nuance on that,
which is listen. Yeah. Sonal and I know each other, we've known each other for a long time and we're going to riff on a bunch of stuff and we have a bunch of opinions and some of it's right. And some of it, and some of it applies to you.
We're always right. And a lot of it won't apply to you, but that's okay. And that's one perspective. And one thing I've learned over the years is listen, There's not one organizational model that works. There's not one definition of VP of Engineering that works. And the point of this is not to say any of that.
We're going to tell you kind of like how we viewed it and what we've experienced. It's not meant to be categorical.
Sonal Chokshi: Yeah.
Martín Casado: But one thing that I will be categorical on is... it is so often that startups view the VP of Engineering as kind of an overhead role. And they don't take it seriously and they don't define it. And there is no split between, what is this CTO? What is VP of Engineering? What's a difference between an engineering manager. What's an engineering leader.
And that I will say categorically, maybe one of the few things I'll say categorically... is a recipe for disaster.
So if you take one thing away from this talk is, if you're starting a company, if you're in an early company, having a VP of Engineering, there is very important. A good definition of the role is incredibly important.
Sonal Chokshi: Yeah. So then on that note, given that is the one categorical thing, you will say, let's dive a little deeper on that.
So if it's perceived as overhead, if a lot of the people in the room are not already VP of engineers and when to add value as a VP of engineer, what is a way to do it?
Because honestly, when I hear you say that, like if I were a founder at a startup, I'd be like, why do I need to hire a VP of Engineering? And just crowdsource all the estimates for when this is going to run from all the engineers in the room? Like, why do I need to add another layerof management. So how do you prove the case that this is the value that these people in the room are going to bring,
Martín Casado: I'm going to approach that question from what normally happens in a startup and then we'll back into it.
So what normally happens is, listen, take my example. Like I, I pop out of Stanford. All I've done is technology. I'm kind of a poorly dressed PhD student and I'm like, Oh, okay. Like I know technology, therefore I know how to like, run an engineering shop. I hire some engineers. We do some work, it gets a total mess and Oh, maybe somebody needs to be a leader.
So we kind of look around the room and I'm like, Hey, this person seems to have leaderly qualities and like you're now VP of Engineering...
and then that person doesn't know what they're doing. They don't know how to recruit. They don't know how to hire, And then you've got a steaming mess, after about a year and a half.
So one thing to think about a VP of Engineering with your existing VP of Engineering, whether you want to be one or you want to hire one, which is... it's very difficult as a startup to grow a VP of Engineering. It's very difficult. And it's certainly difficult to do it on your own dime. Especially if you don't know what you're doing.
So it's, What I would recommend. And I want to get back to what it means to be a good VP of Engineering. So at what I have seen worked very well is listen, there are these kind of stone, cold killer VP of Engineers that have shipped product know exactly what they're doing. And they learn that on somebody else's dime and made mistakes on somebody else's dime.
And your ability to get that and pull that in will change the nature of your company, because what do VP of Engineers do? They set process. And we're going to talk a little about a lot of this today, they hire. Hiring is incredibly difficult to build a cohesive team.
They set culture, they set deadlines. They make good trade offs. They do people management. Many things that actually engineers and certainly myself don't know how to do. So we will flush out kind of the role as we go today. But it's very important to realize like it's hard, certainly from a start up perspective to grow these things.
And you can. But I would say it's much better to bring this expertise. From outside.
Sonal Chokshi: So that's funny because that's like the build versus buy version of the question in technology, but we're talking about it with human talent here, and you're actually arguing to build, not build, but to buy, essentially bring it in from the outside.
Ideal experience and success criteria of a startup VPE
But I want to push back a little because in a startup in particular, and this is where our session is different from all the others, again, condition of high uncertainty. Sometimes someone who has that kind of experience, scar tissue can be a little bit of a naysayer.
And if the important job is setting culture, what if there's someone who isn't as flexible and has so much scar tissue that they don't know how to roll with the punches and this product that keeps changing?
Like how do you, deal with that? Yeah.
Martín Casado: So one of the most common questions I get from early founders is like, "how do I vet a VP of Engineer? what are the things... they're like, actually, I don't know the answer to that. Yeah, because so like every company is very different. Like some companies are militaries and some companies are communes and you don't want to get a military leader in a commune or something like the commune.
These are just like fundamental cultural things. But there are two things, two things that I look for.
One of those, I definitely know if you're looking for an engineering manager from the outside, it's way better to evaluate their team, then the person.
Sonal Chokshi: Oh, interesting.
Martín Casado: What can you really accomplish in a half hour interview? That's going to last for 10 years of a company. It's very difficult.
And so pretty much generally for executives and particularly for VP of Engineers... when we did our evaluation, we would actually talk to team members. We talked to the teams and we looked at the throughput of the team and much less about the skill of the specific VP of Engineering.
That's one thing I would say, you definitely as you're pulling somebody in, I think that's the right way to think about it because ultimately that's what you're buying as a team, not a person. I mean, ultimately.
The second thing is in my experience for a startup, the best VPs of Engineering, and there could be directors or something else, a different title. But when they come in, they have the following experience.
They have experience in a large company, meaning that they understand the processes, they've shipped a product. They've seen it happen before. They get it. But they also have experience in a startup.
And they have both of those... or if, for example, if you're looking to be VP of Engineering, you can get both of those. It's incredibly powerful. Because it's weird for someone like say at Cisco running 600 people to walk into a startup with five engineers and looking around the room and realize like that's, everything between them an unemployment.
And so to understand that cadence and understand that unpredictability and to know that they'll stay in the seat is very important.
Does a VPE need to be a good engineer?
Sonal Chokshi: That's actually very helpful. so then on that front, if you say the team is really important, because culture is important and they have the ability to attract and retain talent.
That's great. So you can evaluate the team. So now I have kind of a controversial question. Which is, does the VP of Engineer then me to actually be a good engineer? Can they be a crappy engineer and just a really good team leader?
Martín Casado: Here's where we're going to move more into opinion because I think many things work but I'll tell you my experience.
In my experience over a number of engineering leaders is whether or not they're a good engineer is totally orthogonal to the actual role. And in fact, someone that's deeply passionate about a particular architecture technology or approach can be very damaging because you have a power asymmetry in the team.
Sonal Chokshi: What do you mean by that?
Martín Casado: And what I mean, that is, let's say that I'm the VP of Engineering. And I think I know the way to architect the product. But listen, I'm not piped into the nervous system of the code base because I'm off doing VP of Engineering stuff, which involves PowerPoint and email and whatever.
Yet! I can't let go of the days when I was the architect. So the problem is, okay. So I go into the room, I'm like, okay, I'm going to enforce my will cause I'm like this great architect. It's very difficult for a team to say no to a direct boss.
I've worked with VPs of Engineers that were phenomenal engineers. I've worked with VP of Engineers that were terrible engineers. And they were both good.
But when it's gone wrong is when I've had a VP of Engineering in my experience where they were too opinionated about the actual technology choices without being piped into the nervous system of that.
And so in my experience, these two things are actually orthogonal. However, I do feel personally for the organizations that I run, it's very important that the VP of Engineering is not an architect. Is not an engineering leader or a strong engineer in their current capacity. Or at least is sufficiently self-aware to not create this asymmetery, which is so damaging to these types of teams.
Two key areas to evaluate VPEs
Sonal Chokshi: So beyond the asymmetry, and let's probe a little bit on the concept of architect. Cause I actually don't know what you mean by that. But I'm sure everyone in this room knows what you mean by that.
So design has become really top of mind for a lot of folks. Particularly, as we see this new wave of companies that are very design centric and design leads, and of course, engineers work with product management. We'll get to that in a minute, but should a VP of engineer really cultivate...
So if they don't have to be an architect, but how should they have a design perspective, like as being an architect, a bad thing? Like how is it a bad thing?
Martín Casado: Here's how, I always thought about VP of Engineering...
There's basically two things that you evaluate VPs of engineering on. The ability to ship code and like the ability to like, maintain a good team. I mean, that's kind of at the highest level. And these two things, can actually be at odds, right? Which is you can like drive a team really hard. Have really low morale have like high churn, you get something shipped, but then everything falls apart because everybody left.
On the other hand, it could be all bean bags and foosball tables and you never ship anything. And nobody cares, but everybody's really happy. Right. ..? And so
Sonal Chokshi: no company intended in that description.
Martín Casado: Right?
And I mean, it's interesting, especially for new managers that don't like having hard conversations that you have these teams where like, everybody's happy and they love like the leader, but they actually don't get a lot done or they don't make the hard decisions.
I think to first order. That is the job description. And we can talk about what that means. To second order. There are a lot of things that VP of Engineers can weigh in on, which I don't think is getting into the details. I think it's important things like tech debt, which we can talk about.
But another one that I've learned that very good engineering managers that have seen it before that actually have material impact at startups. They weigh in on the following discussion...
so in my experience and myself... engineers like building arches, arches, like actual like artists, because they're beautiful. And because they're probably the best for like weight bearing and it's the most elegant solution. But the problem with an arch it's only finished when you put it the Keystone in, right? So you like do all this work and then you've got this thing.
And I've found good engineering managers will bias processes towards boxes or Eichlers right. They're like, so it's not making an architectural decision per se, but when you see a trade off happening in the organism, they'll be like, you know what, it'd be nice. We could ship something in the next two months... as opposed to the next three years, we can get some material feedback and go forth whatever actually injecting practicality in the process.
And so I say to first order, it really is just about you ship code. You keep a team well, the code is good. To second order. There are areas where I think they should go in to talk about the architecture. I don't think you should be architecting the product. I do think you can weigh in on trade offs like that.
Sonal Chokshi: Interesting. So build boxes, not arches... build boxes. Cause I don't like
Eichlers are just very rectangular houses.
Martín Casado: Build Eichler's
not the Sistene Chapel.
How to balance product and engineering as a VPE
Sonal Chokshi: so then going back to sort of the design role of engineers. Just in the entire org, where do you see the ideal configuration and sort of balance between product sales and engineer?
It seems like these are constantly, in some kind of a constantly rotating orbit around each other. Where does the role bleed in? Where should it separate?
Martín Casado: So one thing I feel like I have learned over the years is that pretty much, most organizational structures work in companies, right? who reports to what and this and that. you can make most of those things work. But when it comes to product and engineering, there's kind of an exception. Which is... and this is particularly in vendor world, maybe less in like large consumer company.
But if you're shipping product, and especially product to B2B in the enterprise, product management as a role normally represents kind of the customer on in. Which is what features do we build to dislodge the next dollars and how do we prioritize?
And that's kind of the role of product management. And so it's a representative of the market. Where engineering is representative of the capacity to build and ship code.
And as we all in this room know, there's a natural law of engineering physics, right? It doesn't matter how much you will it ... it only take so long to build something.
And so that is an incredibly natural tension point in any product organization is between PM and engineering. One is representing the market. The market wants this, we should do this. Let's get it out. Here's the roadmap, here's the priority. And, Oh my goodness, we're overloaded! Engineers can't do this. We've have too much technical debt et cetera.
And if you don't have that tension point, really bad things can happen because you can have, basically, the Wolf watching the hen house, right? If it's, for example, if PM is running engineering, then of course, they're going to over promise in the field and assume code is magic, and everything's going to come out. On the other hand, if you have engineering, managing features androadmap, the opposite can happen, which is we will never ship anything because nothing's ever perfect.
And so in the organizations that I did, I made sure that tension point it existed in the organization.
and that one didn't have undue control of the other. Cause that's a very unhealthy asymmetry in a number of companies. If it's not managed correctly. Now that doesn't mean the same person can't be over it. I'm just talking about roles and responsibilities.
Sonal Chokshi: That's fascinating. It's actually like how people separate auditing and accounting, like you have to have yeah... the Wolf in the henhouse. That's great.
The hard issue of managing people
You mentioned morale and, I want to ask you a question about that because what if just as you're optimizing for a certain type of engineer who builds boxes, not arches, where do you stand on the spectrum of morale versus like output like productivity?
And I mean, I just you can't have everything in one person, so what do you optimize for and how should people in the room think about where they should play their hand as a skillset?
Martín Casado: Yeah.
yeah, I mean, I'm not actually not sure I've got a strong opinion on that. I mean, I think you want to optimize both and like depending on the context. I think, listen, if...
I mean, right now there's a massive negative unemployment rate in engineering, massively negative. And in certain areas it's 300%. I mean, it's just ridiculous the amount of open jobs versus the talent to do it. And so talent is such a premium that I actually think that more than I've ever seen it... is I've been in Silicon Valley for 20 years and involved in this stuff for 20 years. I've never seen it where like talent is so critical.
So I would say I would weight more towards actual team management before...
Sonal Chokshi: That's what I was going to guess too, because it's a very competitive environment. Oh, there's a but? I want to
Martín Casado: hear this
Well it's not a but, I think this is a good opportunity to make a point, which is I mean, Again, many of you work with VP of Engineers or are VPs of Engineers.
And so you understand this, I think it's just really good to highlight, why the role is so different than engineering with this question. Which is... so what's a hard thing of keeping morale high? Like I was joking about bean bags and whatever, but that's actually not what being a manager is, and that's not the hard issue of people management.
So what's the hard issue of people managment One of the hardest issues is actually people's expectations of themselves versus their abilities. Like a real manager will look at somebody who thinks that they can be a leader and say, you're not a leader. And keep that person. It's one of the hardest things about being a manager like that EQ that understanding, just tell people that actually, you know, that dream that you have, like you're not going to achieve it, but I'm gonna help you achieve the dream that you're good at.
Now, listen, am I good at doing something like that? No. But there are VP's of Engineering that are phenomenal at that. And like the skill set that can manage a team like that. Yeah. and maintain a team. these are classic things. I mean, that's what you should be optimizing for.
Sonal Chokshi: That's great. I would even argue that this is true beyond Silicon Valley because as every company becomes a tech company, essentially, which givens operating in the world, you know, one of our phrases, that's a really important consideration. I mean, that's the way the future is going.
So just to ask a couple of few quick last questions, cause I think we want to take some audience questions. Let me do these kinds of lightning round style. So I'm gonna ask you a quick question and then get you to give me like a short answer on it.
Why engineering analytics and conscious decisions are important to building great engineering orgs
So how should people in the room think about a specific. Secular trend, you know, you mentioned technical debt. How should aspiring VPs of engineer, VPs of engineers or people hiring VPs of engineer or working for VPs of engineer... where does technical debt come in to all this?
Martín Casado: this is going to be a little bit longer than a lightning answer, but I think it's a very important one.
Okay. So listen. I was a GM of a large organization, which means I had P&L, I had sales and marketing and R & D and post-sales and everything. Whatever it was. 1200 people in the organization. What do you think the majority of the L... the money went in?
The majority of the money went into R and D. The majority of this 1200 person organization. What do you think? I have the least visibility into?
R and D?
R and D! Right? It's crazy. I mean, sales, I've got Salesforce. Marketing. I've got Marketto. I knew every deal, every dollar. I mean, you know all of these things, if you're running an organization, I knew finance. I knew my bank account .
you know everything. but in R and D you're like, what do you guys doin? Ehhhh?
Yeah. You know... what are you working on? Ehh?
And So I would actually say step, and by the way, this is a whole, I think this is going to change in the next five years. But I think it's so incredibly important to have engineering analytics.
And so when things like tech debt, for example, and a lot of these other questions about how do you manage the engineering process?
Step one is literally having an accounting and understanding of what's going on so you can address the situation. The best run engineering organizations that I work with have an actually a relatively good understanding of what people are working on. And those that don't. And I think tech debt falls straight within that.
So like when they do it, it's a conscious decision and it's logged. But the broader thing to me is like engineering analytics, I think are actually a big deal and more and more we've got tools to manage these things.
Sonal Chokshi: I actually then want to just jump to some of the audience questions because one of a couple of them, actually, all of them go along this line of thinking, which is... couple of things.
Good KPIs and how to scale yourself as a VPE
What are the KPIs then or the key performance indicators for measuring the performance of a good VP of Engineering? Or, how does the experience of the VP of Engineer as it pertains to product engineering, like metrics, like, how does that sort of play into this engineering analytics thinking you're having?
Martín Casado: I mean, I know it's kind of a random question... yeah.
Tell me, I'm going to give a very high level answer, which I really think it is like ability to forecast, the ability to hit those deadlines and then the ability to ship quality code. And then of course maintain the team.
I will make the point that, after me Yanbing is going to be up here, which I think is like one of the best VPs of engineering, like in the history of technology. And I think you should ask her questions about being a great VP of Engineering and what KPIs she holds for VPs. I mean, she's a GM now. So I think that she would be in a much better position to answer that question.
and so tee that up.
But that's my favorite thing about you is that you say what you don't know and what you would want someone else to answer.
I just love that. I'm embarrassed talking about VPs of Engineering with Yanbing here... that. I love that.
Sonal Chokshi: So another question that the audience has, and this is related to one of the questions I wanted to ask you as well is, what are some of the ways, cause one of your really key areas of expertise given your own career arc is hiring and scaling. Like you went from a tiny two, three person startup to being like a huge general manager at a huge company with like a billion dollar run rate over a billion dollar run rate business. That's huge.
So how does the VP of Engineer scale themselves as the company grows?
Martín Casado: Yeah, I mean, this is a whole, this is a whole topic and I want to do it, but, I think very few people.
And it's also one, I think you should ask Yanbing if you get a chance too, because it's so difficult and it's so nuanced, which is that the question of middle-management with VPs of engineering. Or in engineering organization.
The simple answer is like, it is engineering management like below the VP of engineering, which is middle management, is an incredibly difficult thing to get, right.
Particularly because so many, I mean, normally you want to do this internally. And having engineers take the transition from IC to a manager is one of like the most unbelievably difficult Akido moves in all of life. And being able to manage that process is very important.
And so I do think that understanding that this is a real thing and you don't just kind of promote people as important. And this is a first class problem for you to think about.
When's the right time to become a VPE at a startup?
Sonal Chokshi: That's great. Well, that goes right to another question, which is... so again, when you think about scaling, when... and we wanted to talk about this as well... when should we bring in. Whether it's startup or when should someone in this room apply to a startup? Or pitch them? Like, I think I could be your VP of engineer. When is the right time?
Martín Casado: I mean, here's, my view is as soon as possible. I mean, like
Sonal Chokshi: you gotta give it something more than that.
Martín Casado: Okay. so what is the primary function of the VP of engineering?
The primary function of being VP of Engineering is to build a team. So if you can, truly, if you can basically hire in expertise to build a fantastic team, that's been trained on somebody else's dime and they've done it, and they've got a bunch of connections and they already have an amazing team. They know the great people, like why wouldn't you do that?
The problem is it's not always possible. You know, you may not have the comp structure or like you can't attract a good VP of engineering. But I would say if you have a good candidate and they are a good fit and they're willing to come. I would do it as soon as possible. Literally first, few employees, but they have to have the remit of, You build the team quickly. And there has to be enough funding in the company to do it.
If there's not enough funding to actually support it, which is more of an issue of funding than timing. Then of course you wait until you have the funding to do it. But for me, it's, you know, you get them in as quickly as possible. If you know what you're building.
Now, listen if you don't know what you're building...
Sonal Chokshi: condition of high uncertainty
Martín Casado: You don't have the money, you don't need a VP of engineering, but as soon as, it's time to scale,
What a VPE should NOT do
Sonal Chokshi: Yeah. On that note, we've talked a lot about what a VP of engineer does, hiring retention culture, managing deadlines, having conflicts with the product management.
What are the things they shouldn't be doing?
That's the question from the audience, by the way.
Martín Casado: I mean, I talked about some of those, so maybe I'll just reiterate it quickly. In my, again... this is from my arc. This is from my experience. I don't think a VP of engineer should be an architect. I don't think a VP of Engineer should be telling people how to write code. I don't think a VP of Engineering should necessarily be like, choosing language. I don't think a VP of Engineering should be deeply responsible for the product vision, right?
I mean, I think a VP of Engineering is primarily about the things that I said before. And it's so common that we see someone becoming a VP of Engineering because they've just basically been around the longest and they don't really think of that as a first class role. And I think that can be very damaging.
On the other hand, on the other hand... there's some phenomenal VPs of Engineering that are all of these, but they're sufficiently self-aware that they can manage the team great. And it can be a beautiful thing when that happens. But for your minds, your mental model should be that these are distinct roles.
Now if one person can carry them out, Fantastic. But that has to be a very special person.
Sonal Chokshi: That's great. one of the audience questions, and I want to actually push back on something you said, which is that you think the VP of Engineering shouldn't be responsible for product vision, but that's literally one of the questions is to what degree.
And I want to argue with you about it a little bit, because you said earlier that the VP of Engineer is more than just the logistics delivery person. They are responsible for being strategic and battling with the product manager and having that tension. So what degree of vision should they be involved? I mean, if they're a strategic person, they're not just like the hands and the CTO is the head.
Martín Casado: that would be obnoxious. Oh the CTO's the worst man. Forget the CTO.
Like eight years of CTO, man. Don't let the CTO do anything. I mean,
Sonal Chokshi: But then who is responsible because they're responsible for these deliverables. So to what degree should they play a role in the product vision?
Martín Casado: So I think at most, in most companies.
Okay, let me take it from my perspective. So very often people come to me and say, Oh, Martín, you see a lot of companies, like, do you think this product would do well or not?
And they're basically asking me about product market fit. And I'm always like, dude, I have no idea because the only way to find product market fit is you're piped into the nervous system of the market and the tech trends and the competitor trends and the customer.
And if you're piped in that nervous system and you're there for six months to a year to two years, maybe you'll find it. And then you'll actually know what to build and who wants it. I mean it is hard finding product market fit. It is hard. And if that's not a full time job, like your intuition isn't good enough.
Like very few people can just sit and intuit like what the world needs and what it wants. I mean, you basically throw yourself against a market to find it out. And so listen, I think anybody should have input on a product. Anybody! And a VP of Engineer is somebody, so they should have input. And they may even know the constituency.
if you're selling to developers, they're a developer. Are you selling to engineer manager? Is there an engineering manager? They should have input.
But unless that's your full time job? I don't think you can just conjure up what it means to have a product. And if you want to do that, make that your full time job.
And so listen, of course, you're an executive, of course you have an opinion. Of course, you're smart. Of course, you should have input. But it should not be weighted more than others who are actually responsible for doing this. Again, my opinion.
What's the role of the CTO and what's the best way to work with them?
Sonal Chokshi: That's fair. So then I have one last question, given that we started with your background as a CTO, and you basically just dumped on the CTO and the role and how they work with the VP of Engineer.
How should people in this room think about engaging with the CTO? What's the most constructive way to have a balance? Like what is the role of the CTO and what's the best way to work with the CTO as a VP of Engineering?
Martín Casado: So I like, I like making fun of CTOs cause I was CTO for so long.
But here's my issue with the title CTO is it doesn't mean anything.
I'm on 12 boards. Like I mentioned, involved in 20 startups, like the CTO it means something entirely different in each one of them. Sometimes it's an engineering manager. Sometimes it's a chief scientist. Sometimes it's someone internal focus. Sometimes it's the evangelist. Sometimes it's sales. Sometimes it is...
I mean, it's like, it's just such a hard thing of, of any title. I think. Any title across in technology, the CTO is the most diluted to basically uselessness. And this is from a CTO...
Sonal Chokshi: right?
Martín Casado: And so, and so, and so my view is listen, A) I think we should just dispense with the title altogether. Just get rid of it. I think they're just like, you should never say CTO. And I think we should actually provide a specific title on what people do this is an evangelist. This is PR this is like a super se, this is an architect. This is a true scientist.
And then once you do that, all of a sudden, you know how they should interact with the VP of Engineering.
Sonal Chokshi: That's the best controversial opinion you've had all night. I love it.
So well, thank you everyone for coming to this session and thank you.