Episode 4 | Rethinking Your Role as a Leader with Emil Eifrem from Neo4j

[00:00:43] Eiso: Hi, everyone. Welcome to another episode of developing leadership. As always, you have Jason and myself here, but today we also have our guests Emil. Before we get to introducing Emil, Jason, you've gone ahead and completely changed up, your role. You've gone from CTO of GitHub to now MD at Red Point. Tell us a little bit about what happened.

[00:01:06] Jason: Well, I figured I was going to make the very natural transition from engineering leadership to growth stage investing on the VC side seems like a very well-trodden path. Just joking. I think I might be one of the second or third, you know, high-level CTO is to make that, but it's a stage of my life, where I've realized what I, I like to do, what I'm good at, and what I was getting a lot of energy out of these days.

[00:01:29] And I love working with startups is what I've been doing for 20 years of my career. And when I started angel investing about 18 months ago, pretty rigorously. And I just enjoyed working with the founders again, and I felt I got a ton of energy from it. So I love it so far. I'm two weeks in asking me what I'm 10 years in, and then I'll, I'll have a different answer, but we'll see.

[00:01:50] Eiso: No, that sounds amazing. And, uh, I think there's a wealth of knowledge that a lot of founders are going to really appreciate from you having been a CTO before. And I think that's a great segment into introducing you Emil because you're the founder of Neo4j one of the most interesting database companies that have been built in the last few decades. And you actually just went and raised a very large round of funding. So I can imagine that you know, in your earlier days you probably would have enjoyed having a board member and investor who really knew what was happening on the tech side.

[00:02:20] Emil: Yeah, totally. Jason, what took you so long?

[00:02:23] Eiso: So Emil for those who don't know you or Neo4j can you give us a couple of minutes about who you are? And then we can dive right into today's topics.

[00:02:31] Emil: Sure. Yeah. So I'm Emil Eifrem and I'm one of the co-founders of Neo4j, and I've been the CEO from, from day one. I guess we'll talk a little bit about what that means. CEO day one and CEO today means two different things. I was also originally the kernel programmer and then API designer and then the documentation author and then slowly but surely my commit rights got revoked, and you know all that good stuff right. Then I transitioned from kind of building the product to building the organization, that builds the product then stops there. I think we'll, we'll spend some time on today, and the product is a graph database, and I think they'll probably be familiar, the category might be familiar to, to listeners of this podcast. I would imagine.

[00:03:18] We actually coined the term, we put the word graph and database together for the first time. And so one way of summarizing the previous decade is that I basically have evangelized graph databases to the world. Defined what they are, we've articulated the benefits, when to use them importantly, when not to use them. And really with the small asterisk at the end saying " hey, if you like these concepts feel free to use Neo4j you know, we're not going to be offended, but you don't have to, dear developer who does not want to be sold to. That don't, don't feel like you're being sold to, but feel free to check out Neo4j. And today we are, I guess it depends on when the podcast is being released as we're growing fast, about 500 people now. Uh, as mentioned, we just raised a big series round of over $300 million, which we just talked about as the biggest round in database history and feel really, really good about. We defined graph databases together with, you know, other vendors graph database vendors in the previous decade, and this decade is really where we feel like it's our moment to shine and bring graph databases to the world.

[00:04:24] Eiso: That's super interesting, and you mentioned something, and we had a little chat before this, before we started the podcast around, you know, you've gone from CEO and solo contributor pretty much on day one. You know, the first I think you told me in the past, the first 400-kilobyte jar file, if I remember correctly, you know, was, uh, was version 0.01, to, uh, having to go from, from being an engineer, to actually being a CEO, and Jason, I know you have some interesting things to share on that as well. I'd love to hear a little bit from you, Emil. Like, what was that journey like?

[00:04:57] Emil: Yeah, it happened really organically, honestly. Right. It was one of those things where I feel like I was always focused on, well, I was always really interested, genuinely interested in what I perceive to be the biggest blocker for our success, right? And of course, initially, it was riding the kernel. Right. And so together with my co-founder, that's what we focused on. How can you get like connect the data, right, operations and connect the data to perform, back in the days of spinning desks and completely different ratios between Ram and Disk. It was actually a pretty hard problem to make that work.

[00:05:33] So that was kind of the initial. And then it was like, all right, how can we make this easy to use for developers? Right. So that kind of the API design. And then afterward I was like, well, okay, we need to start hiring people. We need to raise money. We need to get the word out there. And so I always was kind of intrinsically interested in whatever I perceived, right or wrong, perceived to be the biggest block or the biggest kind of thing that could unlock the next level, uh, for the company. So I always had that interest and that drive, but certainly, it's shifted a lot. Like even how I look at how I thought of my success for myself, what is success? It used to be, I always had a team view. Like I always thought of engineering as a team sport. Right. So it used to be like, how can I make the team successful as an individual developer? Like, I'm going to try to write clean code, you know, and, and, and things like that. And that's actually probably wrong. I probably like, as a teenager, I didn't look at it as a team sport. Then, then my, the success was like, I can write this fastest putpixel, right. Like any assembly on x86 architecture. Right. And it's a somewhat mature program, but that's how I looked at it.

[00:06:40] And then it kind of transitioned to, okay, as a manager, as an engineering manager, kind of that moment when I actually was the role that this podcast is targeted to, right. Then it's like, how can I, how can I unblock the team? How can I hire? How can we collaborate well? Like what does success look like for the team? How can I enable others to be successful, with no kind of a stream of work for myself. And then of course, now that I've transitioned into a CEO and executive, it's changed again, right. Where it's much more about the overall company, how's that successful and you know, what are the broader components? How can I fund the company appropriately? What is the division between the two and, and things like that.

[00:07:20] Eiso: That's super interesting. And so you talked, you kinda started touching upon something, right? The change in role that you have now means you, you have engineering leaders as part of your executive team. What do you ask for them? What are some of the things that, you know, what does it look like for your interactions? And I'm curious, Jason, from, from hearing from you. Because you've also been in a unique role in the last couple of years, at GitHub and gone through some transitions. And kind of hear from you both about, you know, what does, in your opinion, a well-run executive-level look like between the interactions between the CEO and the engineering leaders?

[00:07:54] Jason: I can take this one. So, as you mentioned, pretty unique position. We've touched on this in the past on a couple of the podcasts, but I joined GitHub as, well we call that SVP of technology. So ran product engineering, security data, infras, or a lot, a lot of other functions. And in fact, what it was is between myself, the Head of Finance and the Head of Sales, we basically had this little shadow CEO thing going on because GitHub was going through a CEO transition at the time. And it was just, um, had that void at the top. And interestingly, you experienced different sets of things when someone is not in role, and it gives you an appreciation for certain things.

[00:08:34] Um, so similarly, like if you have a CEO, but no CTO, you start to very much appreciate what happens inside the engineering organization and vice versa. And so, you know, one of the things that I, I always talk about with organizations as they grow and scale is that engineering is in a very interesting spot. For the early years of the company, engineering becomes one of the, is the prime focus, like, you're building out the product, you're building out the organization, but it's a tight knit group of people, typically that's 10 people, then 20 people, 50 people, but it's really, really tight knit. Then you have success. Somewhere along that way you have some major success and you start to scale up and you realize you need to have marketing or product or other functions, all that sort of thing. And what happens is engineering at some point goes from being the main driver of the organization to one of the main points where everyone starts fighting over, and I use fighting and air quotes, you can't see it on a podcast, fighting over priority. "Hey, we need to get X done for marketing. We need to get Y done for sales. We need to get Z done for compliance and finance or security". And it kind of all funnels to engineer. So one of my thoughts 10 years ago was, I thought we'd see more rise of CEOs who had been VPs of engineering CTOs because they end up having to juggle most of the prioritization in the company. It hasn't quite borne itself out in the market that way, but I still think it will, we'll have more of an effect, you know, next 10 years possibly.

[00:10:02] But my main thought here is just that when you start to look at the engineering organization, you start to realize where and how. Most of the priorities in the entire company come down to getting prioritized and moved about and thought about, and if you don't fully recognize that, then you're in for a bad time because your, your expectations won't be met. But if you do understand that, you start to really have empathy for the engineering execution side of the world, because they have to figure out how to juggle a lot of these, these things. So I'm actually quite curious from your perspective, as someone who kind of grew up through those ranks and became a CEO.

[00:10:35] Emil: Yeah. I really agree with that. And honestly, I think we've just seen, it's the early innings of a very long game here, because I think the rise of, let's call it PLG "Product Led Growth", or kind of self-serve first companies. I think that's here to stay. That is here. And when I, when I say that, I mean, I'm sure people are familiar with it, but just to level set on terminology. Like a product where the individual practitioner, the user of the product can self onboard onto the product, they can try it out maybe for free initially, swipe their credit card, kind of proverbially, right, and pay, expand usage, or like delete their account, right, like all of that without having to involve another human being. Right. And I just think that, that is a superior way of building most products. I'm sure not all, I'm sure there are exceptions, but by and large just a big fan of that approach because I think it aligns with the modern customer journey. I think that's how most people want to consume that and buy products, in particular developer facing products, like the stuff that we do. Right. But if you look at kind of companies at scale, SaaS companies, that scale, it's now been proven that they're growing on average about 10 points faster than companies that have a sales led first approach. Right. So it's also, it's more like financially successful, right? That approach is here to stay. And with that approach, all of a sudden, it becomes an even higher pressure on engineering because it is PLG. It is product led growth, right? So literally everything comes down to, not everything, most things come down to doing things in the most leveraged way, leveraged investments, is doing it in the software itself. Right. So it's even, even a higher degree I think over time, there's going to be that those priorities come down to the engineering org.

[00:12:31] Eiso: So, Emil, within Neo4j, what do you look for in the engineering leader? Since there's so much, like you said, it's no longer the same as it was 10, 15 years ago. What are you looking for in the engineering leaders that are both at the top, but also the ones that are growing through the levels in your organization?

[00:12:48] Emil: Ship software faster, more, better, stronger, faster, and secure.

[00:12:58] Well, I mean, it's a good question. There's a number of kind of individual qualities that we look for. Right. And, and certainly this actually comes back to, let me bring it back to that. And then come back to the specific question you asked, which is how I evaluated people, right? In that, in those kinds of the three phases of individual developer, some kind of an engineering manager, and then as an executive. Like in the early days, and it's really hard on basically smart people who can ship software. Like smart and get shit done. Right.

[00:13:30] So that is kind of the first thing. Right. And then as I started building a team, I probably started valuing things like kind of team cohesion and collaboration and those kinds of things higher than I did before, while still valuing smart and shipping software, of course. Right. And then as an executive, right, I'm starting to feel like, man, I value those things, but like the index and the premium for me on decisiveness, things like constructive conflict resolution, that's just much, much higher. And a little bit, kind of disappointingly, I found almost an inverse correlation between those first skills that I talked about. Not causality, but like between kind of someone who's smart and has super nuanced perspectives and high degree of empathy. There's almost an inverse correlation between that and, and decisiveness and constructive conflict resolution.

[00:14:29] Again, not causality, they exist, you can have both, it's not impossible to have both, but I've found that, man, more often than not, If I, if I stereotype the sales executive, I mean, if you go into the platitude and kind of the jock who grew up as fantastic at high-fiving and is an enterprise sales executive. Right. But then grew up to become like a real executive. They're not bothered with nuance. Right. And so they've just, they just point them in direction and people march. Whereas that super thoughtful engineer can see all perspectives. Can sometimes get stuck in that. Right. And so that's not something that I find myself that as I've gone through kind of this journey, I've started valuing those characteristics much more higher than, than before. I don't know if that answered your question Eiso.

[00:15:15] Eiso: I think you said things that can set the internet on fire. But I like how you ended it because it touches upon a topic that Jason and I have discussed a lot about, is about System Thinkers. Right? And I think one of the things that you, you were saying what comes from an engineering background often more naturally than from other functions, although it exists everywhere, is this notion that you're used to thinking about complex systems. And so you come with this nuance of like, "Hey, I can see it from all different angles and know that they're not just linear causal relationships". I'm not sure if I'd agree on the conflict resolution side, but I maybe more curious to hear how you look at this, Jason.

[00:15:56] Jason: So, this is one of those proverbial, I'm going to say it as engineering leader, "complex topics", but actually what I think, I agree quite a bit with them, I would say, but I will say differently, which is this, as an engineer, I grew up this way. You never wanted to be perceived as not knowing something or, um, being able to understand or grasp like these large concepts. So, it was interesting. So whenever someone brought up a topic you would say all of the possibilities that exist in a, in a, in a universe of the problem set. And that is what academia teaches us to a degree, when you go into do these. The difference between a CEO running a 10,000 person organization and an academic, when they're having that discussion is the CEO doesn't know the answer to the question. They need to know that you know the answer to the question and they're going to proxy their comfort with your answer, with your conviction on the answer, not your understanding of it.

[00:16:53] So I call this the competence, confidence spectrum. Most engineers are going to grow up, trying to show their competence. Most high-level executives don't understand the competence, so they need to proxy your confidence to competence. This is why sales leaders in my opinion make wonderful or have in the past made wonderful, high-level executives because, to the jock mentality, they're like, "shit, yeah, we got this". And the CEO is like, "they got this, they'll figure this out. I'm confident". But when you walk into a room and iterate 15 different ways, something could go wrong, the CEO's like, "I don't know what to do with this information". So the trick I found is to blend those into the competence confidence argument, which is like "lead with confidence, show a little bit of competence, and end with confidence again". And that will give you the headway where, as an engineering leader, you don't feel like you're doing something you don't want to go do, and you can express risk, but you can never leave it ambiguous. That is one of the worst things you can do as an engineering leader for a CEO, in my opinion, or vice versa, whoever you're talking to is leaving ambiguous. You never want them to write the wrong story, somebody else to write the story for you, you want them to read the story you're telling.

[00:18:07] Emil: I love that. I think that was, uh, that was way better said than I did. Well, it's one of those things about scale, right? Like when you're, when you're small, you can afford to have, like, a huge amount of nuance. But as the organization grows in size, we're still a small company, we're 500 people. One of my favorite quotes from this is from a guy called Steve Mills, who ran all of the software for IBM, kind of the legendary software chief at IBM, through kind of the glory days of IBM. And someone asked him once, like, "what's the what's, what's kind of the hardest part of your job?". And like he thought for a moment, and then he said "the difference between what's in my head and what I say and what people hear and what they then do". And it's like, you can just hear the layers, of translation there. And for sure, that's like so true for me. Like between one and two, I have like a 10% conversion. Like I lost, I lose like 90% of the information because I'm not a crisp enough thinker and definitely not a crisp enough communicator. Right. And then from what you say to what, what people then do, and that's where kind of that confidence, like the confidence piece comes in I think at scale.

[00:19:18] Jason: Um, interesting thing that you just said there too, but also to kind of go back to the other side of it is, I think we too often conflate issues, uh, at the same time, like, what a startup was doing at 10 people will never be the same at 50 or be a same at 125, 500, a thousand, et cetera. And the roles change dramatically along that way, too. As you mentioned, you were the API designer at one point, but now there's people to API design for you and they have whole teams doing that.

[00:19:47] And so I find that part of the jump from engineering leader early to engineering later stages of scale, is actually about building all the different systems inside there so that you can get the information out or do those layers of translation. That's essentially the job. You're organizing things, you're communicating, you're building things so that those translation layers, it can be as lossless as possible, and if they do you have feedback loops that allow you to circle back on them. Not long cycle feedback loops where like, oh, two years later, "oh, you've heard that differently than I intended". Great. Now.

[00:20:19] And again, going back to that confidence competence thing, all of this plays into the same game, which is there's gonna be things inside GitHub,when I was running GitHub engineering and product, that I had no idea how to get done, but I knew enough to kind of parameterize it. And so you have to have different techniques. One of those techniques is, "here are things I care about as long as you do all of the things that you know how to do, but you, I hit the set of things I care about. Then we're in a good spot.", or, "I know enough about this. And here's where I have concerns". So you raise your concerns and they must be addressed, then the project can move on that way. But a whole bunch of small techniques like that will allow you to, to navigate this. But you can't have just one. And you also can't just be completely like, I don't know, Montessori School when it comes to engineering.

[00:21:04] Eiso: I like that.

[00:21:05] Emil: I like that, like, basically you're talking about raising the level of abstraction in your communication can commensurate with you going up in the organization or like spanning abroad or part of the organization or something like that. Like, were you just using it to be more goal oriented and less about kind of how to get to the goal, for example.

[00:21:24] Jason: There are times, and I have apologized in meetings too. So a good example, is GitHub Actions or Copilot, which are two of the things that I drove. GitHub Actions was a prime one. I said 80% of this product is well enough understood, but I'm gonna apologize ahead of time, I have very specific opinions on two subsystems here, so, we will have deeper discussions on those two areas.

[00:21:49] Eiso: And so for you Emil, what are some of the techniques that you're using when you're, you're meeting with your engineering leadership, and what does that look like for you right now? Are you, are you still, you know, meeting on a weekly basis? Who do you meet with, is that your CTO and VP of Engineering? And, and where do the abstractions lie for you at the moment of being a 500 person org you're still in that middle spot, right? You're not very large yet, but you're also not small anymore.

[00:22:11] Emil: Yeah, that's a good question. So I have weekly one-on-ones with all my executives, including the VP of Engineering and we, VP of engineering reports to me and VP of Product reports to me. Right. And then we have a joint meeting, the three of us, myself, and the VP of Engineering and Product, I'm optional on that one and probably attend, maybe half of them probably slightly more than, than half of them. And then we have regular ops reviews, right? So these are kind of quarterly operations reviews, which are, you know, we follow the, where we're such an enterprise software, you know, business, we follow kind of this quarterly thing, right. Even though part of it is shifting into more of an MRR type thing, because we just launched a cloud product. I say we just launched, it was a year and a half ago, but it's still early and embryonic compared to our tried and true improvement on-prem motion.

[00:22:56] And so, so we have quarterly ops reviews where we go through every thing in the, in the business. Right. And it's very "metricie" oriented for MQLs and SQLs and you know, stuff like that on the marketing, marketing, qualified leads, sales, qualified leads, like all that kind of stuff. Right. The ARR. And then on the, on the product and engineering side, it's, it's much more qualitative, right. And so it's like, what's going well, what's not going well. And then we have a very simple kind of, we look over the entirety of the product roadmap with just red, yellow, green, right. And kind of what we're trying to achieve as in the absence of ARR and how are we forecasting to plan? And how's our leads tracking and like all of that cash collection, all that kind of stuff, right?

[00:23:43] What we're trying to do is kind of this beer with Magnus is what I'm trying to do. And Magnus is our VP of engineering and kind of the output should be "what if we go and sit down with Magnus, we grab a beer and we say, alright, dude, how are things really going?" Right? Then he's going to use some kid of algo to, to produce like it's going well or not. And that's based on something, right. We want to try to get that out in kind of red, yellow, green, on, on a few slides. And it's actually really useful to keep the entire executive team aligned, because you have to choose the level of abstraction correctly on the product roadmap, right? Because we're a database, right? So there's a lot of, kind of the graph store obstruction and the storage and then the multi-version, concurrency growth, like stuff that doesn't really make sense to the rest of the e-staff team outside of like the product person and so on and so forth.

[00:24:34] So you have to choose your level of abstraction, but they're typically good with connecting back to their function, right. "Oh, okay. Wait, like I have a bunch of deals that I'm blocked on X, Y, Z, and X, Y Z is now yellow". So then they know how to ask questions about that. Right. So that's kind of our quarterly cadence. And then we have a light mid-quarter version of it every six weeks. Not every six weeks, like in the middle of the quarter, just a light version of that. And so that's kind of the interface between me and engineering and engineering and the rest of the, of the executive team.

[00:25:06] Jason: You touched two things that I love there, and I want to reinforce this. So one of the striking things that I, or one, I guess, one of the more, I don't know how to say this in a way that would not maybe set the world on fire too. If I want to look for a well run well functioning organization, there's one key that will tell me if the place is either going to be incredibly dysfunctional and toxic, or if it's, if it's going to trend towards just kind of rally around each other and the company can have success. And it's really about the exec team and almost everything else is a derivative of this one next point. Is whether they view themselves as a member of the exec team first, you know, company exec team, or if they say "I am a sales leader, or I'm an engineering leader and I'm on the exec team".

[00:25:51] Emil: First team mentality.

[00:25:53] Jason: Yep. First team mentality, that's 100% it. I have always told folks, I'm a member of GitHub exec who happens to run engineering and product. And that was a very weird way to say it, but it's intentional when I'm inside the organization, because obviously even as the organization grows, my role is going to change too. But if you view it a certain way, you can have a conversation about sales. I noticed this about myself when I was very early in my career, in my first exec role sales starts talking, I would tune out. Then I realized like, what the hell am I doing? Sales, you know, that's it. But when I start talking, you know, as an engineering leader, finance starts tuning out or something like, no, no, no, no. Hang on a second. It's all a machine that has to work together to a degree to do this. And so that mindset shift helped me a ton, but I know that when I was looking for organizations, if you find one of those, and Heroku had one of those when I was there, where it was that first team mentality, it is magical. It is magical. And if you don't, it will literally send you to become a VC.

[00:26:55] But it's, it's critically important. And I want CEOs, Founder CEOs to hear this a lot, which is, this is the type of stuff, the small little things that will make or break your organization overtime.

[00:27:12] Emil: I really agree with that. I, I guess I have two comments on that, both related to my own mentality and how it's shifted, which is a little bit the initial kind of framing of the conversation. Right. Which is, there's actually a really good book about this, called "The Five Dysfunctions of a Team", which is exactly the kind of book that, when I actually read it like 10, 15 years ago and I didn't hate it, but like, I just thought it was completely stupid. First of all, I just looked at that team the way it's been described right. In that book, and I said "what, what losers like this is, this is like, when you have like a non-people oriented CEO, myself, I'm such a people person, so I'll never allow it to get to this point". Right. That was the first thing. And then the second was kind of just intellectual snobbism. It's written as a fable. It's not supported by evidence. It's like, it's the least rigorous book you'll ever read and so on and so forth. Then about 10 years later, a few years ago, right back to the "let's have a real conversation on the podcast and a vulnerable conversation", I re-read that book and felt that it was a description of myself and Neo4j. I was like, holy shit, this is me. This is us. This sucks. And then we started working on this, it's like super salient, there's no kind of academic rigor behind that this should work, but it did work for us. And anecdotally, there are so many CEOs that I speak to that they pray to this book or, you know, whatever, like they re they really like it.

[00:28:43] So I think that's, it's an interesting kind of how my view shifted from, you know, being much more of a perfectionist, detail-oriented more intellectually kind of, not honest, I hope to be still intellectually honest but had a higher intellectual bar back then versus now, it's like "well, maybe this is doesn't tick all the fancy boxes, but it works". Right. So I really recommend that book.

[00:29:07] Jason: Interestingly. So I'm glad you brought up The Advantage and his follow-up, it's Patrick Lencioni I think is the author of that one, he wrote The Advantage as well, I think is a great book. So interestingly, that was one of the books that kind of turned me to this side too. So I have two worlds, two lives: Engineering Leadership for startups for quite some time, also love team sports. And interestingly, I find the overlap between running a highly skilled, highly competitive well-run team sport, to what we do as startups to be very, very overlapping. I know sometimes I'm popular for bringing sport metaphors into this, but I, you can't ignore this. And "The Advantage" and "The Five Dysfunctions of a Team" in the sports world is so well known and understood that people live by this it's the culture, it's the team. And so all that sort of stuff, it's the locker room. They talk about the locker room all the time and you have to have that. And they even talk about it with the front office, and the players too, because there's a different mentality that you have to have when you're in one role versus another. Coach, versus GM, versus owner, is a very different mode. But when you're the team, they talk about this, the locker room is sacrosanct. You can't break the locker room. And once you start applying some of those things to the open, sorry, the, um, startup or open-source or even corporate world, you start to understand why they were so important. Because at the end of the day, we're all humans, and humans have a set of things that we can do and manipulate and foster and enrage. And so like we're all dopamine and serotonin receptors. Is that what we are essentially?

[00:30:41] Eiso: It's funny. You, you mentioned this because actually, I've never told you this, Jason, but for me it wasn't a book. It was actually many years ago meeting you who put me on that mindset of thinking about this, this "team sports", because I actually don't come from, I mean, I spent my teenage years behind a computer. Some of our listeners did as well, and when I finally picked up a sport I was a scroungy kid who walked into a boxing gym and I was like, I don't think I can hit anything, teach me. So for me, like, so I didn't come from that background at all. But I came from a background where like it's family and friendships, being a close-knit group was something that was very important.

[00:31:19] And it was, you who actually put me, many years ago when we first met, on this kind of mindset of like, "Hey, look at it really as a team and how a team functions like you see within sports" and kind of having gone down that path and actually reading some of the books that both of you have mentioned, it makes me now really value this concept. Like actually, if you look at the leaders that we're bringing into Athenian right now, the last one, you know, was actually a former basketball coach and like an athlete. And it's the things that actually, when you come from an engineering background, the intersection between having played a lot of team sports when you were younger and having written code is probably not as large as, you know, sales and such

[00:31:56] And funny that my Head of Engineering comes from a basketball background, my VP of Sales that comes from a basketball background, uh, and so, and it really makes a difference and it really changes that mindset. And I wish we could have that be something that everybody gets to experience, even if it's later on in their lives or through books. I mean, when I've reached out to you for this podcast, Jason was after I watched the TV show, Ted Lasso, and I was like, Jason's Ted, like we got to do this podcast.

[00:32:29] Jason: I, um, by the way, I, I showed that text that you sent me to my wife, because I was like one of the nicest things anyone's ever said about me. Uh, interestingly, so to your point about team sports, I just want to point back to this one, one more time. So I think that it's so well understood that team sports for certain functions, so like they, they talk about sales all the time in that sort of way. And in fact, like when I was very early in my career. I wasn't an early athlete, I just liked team sports. And I started playing as I got older, like in college and post-college, one of the first times ever was running engineering, was at a startup company, and the CEO started a company in Scottsdale, Arizona doing fraud stuff. And the CEO at the time there pulled me aside and said, "Hey, I think you're better suited to run sales. And I think what we should do is move you over to sales, to learn sales and eventually become the Head of Sales, at some point that will be your path. I don't think that like, you know, I don't think marketing would be it, cause you don't like this side of it, but probably sales. And then that would be your path to CEO someday". And I asked him very specifically "why?" and he said, "well, your mentality is perfect. It's like, you got this team-oriented mentality. You got this, you hold people accountable, you've got expectations. You're very charismatic. You know, you're present well in front of customers. That's your path. That's not like, that's not what we need out of engineering leaders". And it was, I respected the hell out of this guy. And I was like, nah, this is like the exact opposite of what you should be telling, in my opinion, someone liked me, And I found it to be really interesting in, you know, obviously here we are 15 years later, or so, I think about that conversation a lot.

[00:34:02] Eiso: Well, you probably would have been a CEO by now Jason.

[00:34:05] Emil: And instead you're just a VC. I mean...

[00:34:13] Eiso: We're very lucky with that. Actually. I, I, now there's finally someone who I know I can send engineering founders to and be like, you know, "You can rest peacefully in this conversation, like you can feel good".

[00:34:26] Emil: So I have a question for the two of you, which is piggybacking, I guess, I think back to your question Eiso around my interactions with engineering as, as a function and kind of the ops review and stuff like that, what have you seen as kind of "best in class" in terms of the outside-in view of engineering from the rest of the, of the executive team? And then the other question is kind of the, for me, eternal the question around engineering velocity, cause it's like notably missing from any of this is any kind of quantifiable metrics like red, yellow, green, and yes, we do put the kind of hiring and whatever in there, but that's not the thing. Right. And so, so there's very little metrics and this is not, I want the listeners to know, I'm not trying to make this a plug for Athenian, so both of those, those things, I'd love to hear your thoughts on.

[00:35:20] Eiso: So yeah, go ahead, Jason, kick it off

[00:35:22] Jason: Do you want to split this one? It sounds like we can actually, uh, we can split this one perfectly.

[00:35:28] So I would say this, both situations with Heroku and GitHub, I was an outside coming in- outsider coming in, and I was running Engineering. They were slightly different. Heroku was in much better footing than GitHub was from an internal culture perspective and a bunch of other things in terms of releasing products. So, from that regard, there were different scales of problems there. But both of them were the same. One is I went in and I did, basically I did the rounds internally and externally. I was like, "Hey, what do you think of Heroku Engineering? What do you think of GitHub Engineering? And product and all that sort of stuff?

[00:35:58] I got to understand, like I fully understand where the trust level is first and foremost. And on the outside, it's more of a meta on the brand. Like, how is Heroku treating you as a customer? How are they, are we being responsive? All of those sorts of things. So I'm trying to get, find signal in that. And I say trust intentionally, because internally if your, let's call them client organizations essentially, but your partner organizations, sales, most importantly, doesn't trust you to deliver. Doesn't trust what you say. You're in a really bad spot and trust gives you so much, not just credibility, but conversation-wise if, if you know, the Head of Sales and the Head of Engineering and Product trust each other, they can start to have downstream conversations. The way, the priorities are lining up does it look good for sales, but you can also talk about what that's going to mean and why and all that sort of stuff. But if you have no trust, it doesn't, you never even get to that conversation level. You just say "engineering's at it again or product's not delivering".

[00:36:53] And it's the, I think it's the single most important thing that an engineering or anyone in the organization should do is: make sure that everyone else around trusts them, which goes to that first team mentality. If you don't have that you're in for a bad day. My best friend at GitHub was the Head of Sales. We got that close over the first two years and then post-acquisition. He ended up leaving, but that's my best friend at GitHub, he's the Head of Sales.

[00:37:16] Eiso: So I think it's super interesting what you say, Jason, like, I think about we might have talked about this before, I'm not sure if it was on the podcast or not, but I, everyone who knows me knows me that I very commonly say "all problems in the company are communication problems and all communication problems root from lack of trust". And I know that's an exaggeration to an extent, but the, this notion of like, you know, you see this, even within your personal relationships, you need very few words where you can even say the wrong words, but if your basis of trust between two people or two groups of people is strong, then you assume the best intentions you, you go to the next step. And so I think that as the foundation of, of best in class probably couldn't have been said better. I see a lot of engineering orgs, and I spent a lot of time with a lot of different engineering leaders. I mean, just today, I got to spend time with three high growth engineering orgs, two in Europe, one in one in the valley. And what I kind of consistently see about best-in-class at the executive level, because I think there, there definitely is differences in best-in-class, throughout the different parts of the organization. To your question, Emil it's first and foremost, what Jason mentions it's engineering leaders who do not, uh, treat their role as a silo. They see it as part of a team. I started the, you mentioned this in our last podcast Jason. And I started asking this to most of our customers and VPs of Engineering. Like "how often do you meet with the VP of Marketing, the VP of Sales, the CMO. And it was very, very indicative between what kind of organizations they were". And it was more than once where I heard "why?". And, and I'm also glad to say that I've seen people actually gone and done this right, right afterwards, because the "why" is very obvious, right? So there's lots of rituals and processes that people hold in place that you could say is more best-in-class than others.

[00:39:01] But to your question around data metrics, like I think the, the organizations that really run the best are the ones where you have high trust from what comes out of every single executive in the team, and the way sales or the way marketing, you know, builds that trust is often with data, is often supporting their arguments with, "Hey, this is actually what our sales funnel looks like. This is where we're at in terms of number of opportunities". And for engineering, like to your earlier point, that really has been the "Red, Yellow, Green" as kind of a standard till date. And, I think what happened is that a lot of engineering leaders over the years have toyed with this idea of, "Hey, I can pull data out of my GitHub and JIRA on my different tools. And by pulling data out, I can start bringing some numbers to these meetings". And what actually has happened is that at some point about, I'd say 10, 15 years ago, and it happened again, 5, 6 years ago, a bunch of companies said, "oh, great, let's build products for that", and those products all centered around, "let's start looking at individuals with metrics and data", and it just poisoned the well. All of a sudden, like every single like engineer who had been exposed to that either in the nineties, early 2000's, again in the last five years, saw, "you know what? We don't want to look at metrics and data at any level because it's 1984". I see a lot of heads nodding and laughing here.

[00:40:23] Jason: Yeah. Interesting. Cause this goes back to "any system that can be measured, will be gamed". And once you understand what you're measuring, you might not want it to be gamed, or you might be okay with it being gamed. And so this is the, this is the big difference I think is that, if you're going to reward pure scores and basketball, and that's who we're going to pay, you're going to get a lot more pure scores starting to play. And that's what, you know, you slant towards. So every organization's going to be slightly different. So I think what we did is we applied Sales, sorta mentalities and metrics, gathering to Engineering, but it's a different organization, it has to be felt differently. And I, I agree. I think like you don't want a game at the individual level you want to game at the team level or the organization level, and that's because what you're after is the cooperative nature of these things happening together. And to Emil's point earlier, I do believe that velocity is a healthy metric, but some derivative of not individual, but overall organizational velocity that leads to health.

[00:41:21] That's a large, we've had this conversation in the past, too large, a metric to be that useful and it gets granular and broken down, but what you're actually after is this idea that everyone's kind of rowing the entire organization in the same direction, and then you can start to understand, okay, so what is happening in the rest of the organization in various parts and overall, and get, get a sense for it. But I never want to know how long an individual I expect. I, particularly as a CTO, don't want to know the individual level. I want the engineering manager to understand their team. And understand when their team is blocked by things that I can't measure. That's like part of having- in a team sport you have a coach, and you know, position, position coaches, then you have individual coaches and those individual coaches are supposed to know those things, not the overall coach.

[00:42:07] This is where I think like overall and in like the engineering landscape and corporations in general, we tend to not fully understand how the roles are supposed to be broken down.

[00:42:16] Eiso: And, and I think you said something very valuable like we've looked at metrics and engineering from this sales mindset or marketing mindset where there is such a thing as good or bad metrics across an entire sales team. Right. It's pretty straightforward. We have a funnel at the top of leads, and at the end, we have sales that happen. And what we've really seen, what makes the difference in mindset about using data and using data at your exec meetings or the director meetings or EM meetings is that context matters and every single team of your organization is not going to have the same metric to look at.

[00:42:48] And it pretty much comes down to, as an engineering org or as an engineering leader. I always like the bucket it in five types of insights that people need to look at: 1. Organization Insights, like how healthy are we as a team, are the engineers happy, what's our onboarding time attrition. 2. Velocity, which is actually to your question, like how fast do we ship software and where are the bottlenecks? 3. Quality, like, what's the actual quality of the software we deliver to the end-user, and how do we respond to quality issues. 4. Outcome, like where are we choosing to allocate and invest efforts across initiatives, across teams, across products. And then 5. Impact like, can we actually show the impact of engineering to the actual business metrics, revenue, or retention they could lookup. But what we actually do at every level of the engineering org. Based on what the business tells us is we give trade-offs to each of these. We say, you know what, we're going to ship lots of features really fast, but we're okay with quality suffering for awhile. Sorry, Jason, go ahead. I see you.

[00:43:44] Jason: This is like such, I mean we should probably dedicate an episode to this topic because this is actually the difference. So let me use sports again. Sunday or Monday, you're watching a football game, you have this thing called Monday Morning Quarterback. It's like people like me and this thing called Monday Morning Quarterbacks, which is basically people that don't, but they will criticize the team on the field for this. Now, if you ever listened to a quarterback break down a play or a game, you will understand right away that you have no idea what's happening in the field. None whatsoever. But, for whatever reason, we all feel emboldened to have an opinion and a criticism of those people on the field. Now in engineering, this is where the art comes into a lot of this, which is, "Hey, your engineering velocity is slowing down". And what you, it's not that the engineering philosophy is slowing down, you have to actually dig down. In one you might realize is that, you know, we have a couple of subsystems that are blocking this and infrastructure is blocked on X, Y and Z component that has not been updated, blah, blah, blah. And you start to like, understand that it's like this one little bottleneck somewhere, but it's a whole bunch of questions. That'll get you through the root of this. But again, it goes to, like, most of the organization doesn't understand what that would be. And that's fine. I don't understand how sales funnels work or how marketing funnels tend to work, or like, you know what, SOC 2 compliance looks like from a financial perspective, or something like that. But I have to have trust that they know how to do that. And I, as an engineering leader, have to be able to go answer those questions, but it's not as easy as just like, "this metric will show how fast we are". This metric is an indicator of a lot of trailing systems that have been put into place or a leading indicator of something that's about to go wrong too. So if you start to see the philosophy go down, a whole bunch of questions just need to be asked.

[00:45:37] Eiso: And, and you touch upon it. Like the data helps you ask the right questions. And that's really where it needs to be used. And it's this fine balance between yes, at certain levels, you might want some level of target setting and even some slight level of gamification. Like there's very, you know, things that we can all agree on, like CI time. You want the engineers to work on bringing CI time down as low as possible within reason because it's going to make everyone in the organization faster. But if you go and say," Hey, velocity is the one metric we care about, and everybody has to optimize for that", you're going to have unintended consequences. But like Jason says, if you see velocity slowing down, and your release frequency slowing down, quality issues going up in the time to respond to bugs, you know, that raises interesting questions and those questions actually, they get answered 80% with qualitative information, not with quantitative information.

[00:46:27] Jason: And I don't want to cut you off. I want to say one thing real quickly because the CEO is, so this is the way it should go.

[00:46:36] It's critically important that engineering leaders hear on this podcast, too, that velocity is their responsibility. That's part of what an engineering leader is supposed to do. Now the challenge is going to be, going back to my earlier comment, about where the prioritization happens. And so this is where the CEO empathy does have to come into this. And I'm glad, Emil, you've had that too, which is you have to be able to articulate why a set of things are happening or prioritization. You have to get everyone on board with that. You do have to socialize that, and you do have to let people understand why you're making certain decisions and trade-offs. And then your job is, is to get, is to ship software, to ship high-quality software. And realistically, you're supposed to get better as you grow, faster as you grow. And this is actually the counterexample. Most organizations get slower, more bureaucratic, more whatever, but the point of adding more people is that you can go faster, do more things and do it in scale. So you should be able to find a way to keep your, your velocity or even go up as you scale. Most people don't.

[00:47:37] Emil: So, I agree with that, but I think it's one, I think what you spoke about earlier Eiso, that kind of the diagnostic part of this, right? It doesn't give you the answers. It kind of clues you in to ask the right questions and then the answers will be qualitative in nature. That rings very true for me, but I think what I end up looking for alot, if I'm playing kind of the CEO role in the conversation, is, " so that's great for diagnostics, but for planning though, right? I need to have, some kind of overall sense of velocity in order to figure out- to take a hypothetical example.

[00:48:15] I've just raised $325 million. I want to deploy that towards a business to make it go faster. I can choose to deploy it, to go to market. I can buy the CEO a really big yacht, you know, or I can pour it into the R&D organization. And the question is, I tend to go for us as a company, we're so product-centric and it's such a technology game. So we invest as much as we absolutely can. But at some point I got to know like, if let's say that I believe that in three years, the window of opportunity will be closed. Let's say there's a platform shift, right? Let's say it's in the nineties and I'm building software for the Palm pilot or something like that. Right. You know, it's like, like it's an actual window of opportunity. Without getting an overall sense of the velocity of the function, it's very hard to plan kind of the overall company allocation, ultimately with funds. Right. And so, so that's the one where I think it's, I feel is missing sometimes.

[00:49:14] Eiso: But I think. Well, I mean, this is it's my bread and butter. So I almost feel a bit bad talking about it on the podcast because I also don't want to plug what we do. But, but at the end of the day, I think if you look at- Jason says something that holds true for a lot of our customers and companies that we see is that, organizations that are growing in head count and raise tons of money or their businesses growing. They tend to trend towards being less productive and slowing down, not to actually accelerating and productivity. And figuring that part out is something that you can really see from your data. You can instantly, you can look at your data and say, "Hey, in the last quarter or the last six months, what is the trend that we're going on?"

[00:49:56] And if you're trying to plan for your next quarter or your next year next doubling and hiring, you can actually look at these trends and say, "okay, if we keep going down this road, what is that going to mean in terms of, very, you know, like what are the initiatives we're going to ship, epics we're going to ship, how many pull requests can we roughly get out? Things like that are definitely at an aggregate level, very accurate. And the individual level they're not. And I really cannot stress enough, never look at metrics from data at the individual level, it's draconian, and it's not going to help you. But at an aggregate level, organizations are really predictable. For that planning side. It's definitely useful. And it's definitely possible to start using these things and looking at the right, like abstractions of it. But you really, I think to be honest at an executive level, it's those trends that you need to be spending time on. And that's really where you need to be like, "Hey, are we heading in a direction where we're going to be able to scale?"

[00:50:45] Jason: I think of this in two different ways. One is going back to the sales side of the world, or let's just call it from, a board-level perspective. "Hey, we know how to go to market. And we know what our CAC looks like. Therefore, if we just add more, we understand what the impact to the business would be. In engineering, we don't have that same level of ability to articulate to that degree, and I, and I think like if you. Take any other function, some of them, I don't know if they're as accurate, as we would like to hope they would be, you know, I say marketing funnels and all that sort of stuff, but there is at least some sort of measurable way that they can quantitatively do this. And I think that given the engineering's one loan function that hasn't fully been able to break that. And I, and I say this as someone who doesn't really want us to get fully to that level as an engineering leader, I think what's missing is that all the other functions round table have some ability to articulate that for the growing of the business, in terms of like methodical measurable sort of way, and engineering, doesn't.

[00:51:43] The closest analogous I think is infrastructure, which is basically saying the cost of doing businesses, if we add 10% more customer base, given our projections, this is how much our infrastructure cost is going to go up, and our headcount, we need know five more, SR- or X more SRE's and Y more database administrators and Z more cloud infra engineers and all that sort of stuff. But when it comes to application engineering, we've kind of not gone that path.

[00:52:07] And by the way, I think this is an organizational challenge, not a measurable challenge, because I think most organizations are trying to go for the perfect engineering organizational structure when in fact what they need is like teams of five to 10 people to attack problem sets and understand what the velocity of each one of those team structures looks like so that they can understand largely how many more squads or pods or like loose-knit feature, full feature teams. They would have to add to go after a certain set of problems. Again, it comes down to, I think it comes down to a host of things that we're just not ready to do engineering just yet.

[00:52:40] Emil: I mean, it's interesting, right? Because you can see how you end up, kind of talking your way as a, as a board, as a CEO, as an executive team, the path of least resistance, once you achieved some amount of scale, let's just arbitrarily say 50 million of ARR or a hundred million of revenue, something like that. Like you then have an engine up and running, right, on the commercial side. And then it's so easy, you see the dollars you put in and you're going to see in some amount of time, you're going to get that dollar back. And then the only debate is how, how deep do you want the curve to dip, right, which is related to how much money you've been able to raise, and that's going to control how fast you grow. Right. And I just look at myself self- so I come from the product side or the engineering side. My CFO is very unusual. Has a CS degree from Berkeley, and he came into the company and just looked at this and said, this is a product-first company. This is a technology company. We're always going to fund engineering as much as humanly possible. Right?

[00:53:42] If it weren't for the two of us with some amount of strategic rationale, but mostly on gut feeling saying we're going to fund engineering as much as possible. And what's capping our investment in engineering is our ability to hire. It's me coming to the VP of engineering saying, "hire more, hire more". And he's saying, "no, I can't, not without jeopardizing quality or ramp time, it's going to bog everything down". But the budget is not the constraint for us like we've just spent as much as you can just take it. Right. But that's only because we already believe that to be the right case. If we were in a way kind of on the, on the fence, all the quantifiable arguments, the ROI arguments of the go-to-market would probably have swayed us much more in that direction.

[00:54:27] Jason: I mean, look at, look at the column efficiencies, sales efficiencies, and marketing efficiencies and all of that. And then you, you see comparables and you start to see it, like, what are your contemporaries in the space? So when you see Atlassian's R&D investment to marketing and sales spend versus, you know, and you start to do this. And what is lacking inside of a, of a lot of those is just the overall understanding of the deep, the business. Atlassian's go-to-market looks very different than the XYZ's of go-to-market, but also how they actually serve customers too. And I think like this is where, you know, engineering, as I mentioned earlier in the podcast, too, engineering leaders becoming CEOs, I think would be a good trend in a space, particularly if you're serving developers, if you're serving developers and you're not an ex-engineer, it's a difficult one. But even high-growth SaaS companies would benefit from these, but it's understanding that unfortunately, you're not going to get a great answer out of that from your engineering organization at the moment. But if you understand roughly the spirit of where the business is at the moment where it can go, you understand how it makes those investments and

[00:55:27] I'll turn it back around to the CTOs and the VPs of Engineering again, saying that I bet 90% of velocity problems are two things inside organizations: One is it's an organizational problem. You're trying to architect your org chart to perfectly. Stop, particularly on the application engineering side of the world, think about feature teams more. And the other is that you likely have tried to incentivize the entire engineering organization with the exact same incentives. And I don't believe that to be the case. I think that as you grow and scale, particularly as you approach like a thousand people, your infrastructure side should be about safety. Your security side of the world should be all about keeping me out of prison. Your application engineering side of the world should be all about it. And the three of them have to come together and you have to understand how they're going to come together. And this is where a lot of internal tools teams get built these days, is to satisfy the requirements of those three. But if you've aligned everyone around speed, because you need it out of application engineering, you're going to compromise a whole bunch of things. But if you said we want pure safety because we need to be selling to the highest degree of competence customers, you're going to slow down the velocity in that. This is why sometimes engineering teams, uh, engineering leaders who run all those functions, have a really difficult time because they want harmony, but it's not harmony you're after you're, after our efficiencies and productivity and productivity means winning the game. And sometimes that means like disagreeing on the sidelines by the play.

[00:56:52] Eiso: Because I think that's a really great note to end it on today because I can see us spend two or three more hours talking about this. And I think first and foremost, Emil, we're just going to have to get you to come back on. Yeah, this is a, I think this is a definitely a trend, Jason, we keep wanting to talk, uh, which is great why we have this. I think this was really valuable guys. There are a lot of topics that we touched upon today that should just be discussed more. And by, you know, besides the two or three books that are out there that might cover parts of this, it's just a lot of it is not generally known yet, and we are in the young territory when it comes to engineering in itself. So I'm really glad to have had you here with us Emil, would love to make sure that you come back and, uh, yeah, we're gonna have to do this more often.

[00:57:38] Jason: Emil, fun to have you, man this was great.

[00:57:41] Emil: Yeah. Awesome. I really enjoyed this conversation.

‍