Episode 12 | Scaling Engineering Organizations with Erik Bernhardsson

[00:00:00] Eiso: Welcome to developing leadership. The podcast for I Eiso Kant, and my cohost, Jason Warner, talk about lessons learned in engineering leadership throughout the years. Today, we have Erik Bernhardsson on the podcast. Erik was at Spotify in its early days, managing the analytics and machine learning teams. And until recently was the CTO of better.com, where he built the engineering org from zero to 300 engineers. Today, Erik is the founder of a yet-to-be-announced startup.

[00:00:25] Erik joins us to talk about what he learned on how to recruit and scale an engineering organization, including sharing his tactics on finding and bringing great engineers on board. We also shared our views on team mentalities, skunkworks projects, and much more as we try to answer the question, what is success in engineering?

[00:00:45] Hi, everyone, we're back again with developing leadership. Jason and I have a guest with us today, Erik. Eric was until recently the CTO of Better, where he grew the engineering team from one person to over 300. And before that spent, in a previous life, quite a few years at Spotify. I first found out about Erik years ago, actually through Twitter and particularly through your ability to share opinionated points of view on, at the time it was machine learning. And Jason and I independently got to know Erik a little bit over the years and connect. And so the idea today is to hear a little bit about Erik's journey, I'll let you maybe kick it off, Erik, with a bit of a, an introduction in your own words. And then we go from there.

[00:01:30] Erik: Hi, it's fun to be here. so I, I 'll give you like a super quick introduction. I'm currently sort of unemployed slash creating a company, and I've been doing that for about a year. I was at Better for almost six years as mentioned, I built a tech team of above 300 people. But my background is a little bit weird. I studied physics, I got really into like competitive programming when I was in school. Then after school, like there was this random obscure music streaming company in Sweden called Spotify, where a lot of my friends went to. I ended up joining, I think, you know, it was one of those like lucky things in my career in hindsight, but I ended up spending seven years there and was a part of growing from sort of obscure Swedish, why should people just like, hacking that stuff to, you know, now a publicly-traded company in 200 countries or whatever. So that's fantastic. I decided at some point I wanted to move on and do that journey again. So I ended up at Better, which is a mortgage lender. As mentioned, I grew that team, did all kinds of CTO stuff, building teams, and thinking about recruiting processes, ran a fair amount of code. I always try to code a little bit like in my spare time and a little bit at work too. And then about a year ago, I decided I wanted to do something new and now I'm working for something in the data infrastructure space. Yet to be announced, we don't even have a name or a website or anything.

[00:02:47] Eiso: Fantastic. We'll have to find out that name as, as soon as it's out.

[00:02:50] So, Eric, you, you mentioned you joined Better and you were the first person there. What does day one look like, and kind of subsequently, how did that journey evolve and what are some of the things that you learned scaling what became a very high-performance engineering organization?

[00:03:06] Erik: It's actually kind of funny, because like day one, like literally like in the first two hours, we've talked about like name for the company, we didn't have a name for Better either at that point, and then I was like, "wait a minute, like better.com just came up for sale." And like, I was able to convince the CEO we should buy it for like an insane amount of money. So that was like literally in my, like first two hours at the company. But yeah, I mean, I think, you know, like what I started after that was like, I just, this has a lot of potential, like we're going to have to build up a team. I'm going to start to have to, you know, I'm going to have to hire, I'm going to have to hire a lot. I'm going to have to, you know, we didn't even have a website back then so, first thing I built some janky WordPress website and registered like better.mg, I think, which was like Madagascar.

[00:03:49] Later there was like a coup in Madagascar, and the website went down or something like that. But anyway, I basically spent my first year just like hiring and hiring hiring. And it was like super hard, cause like early-stage startups, like people are like, "uh, like mortgages, like why would I want to work with that?" And you know, it was like nothing really. And so I think, you know, in the next couple of years, like I sort of spent a little bit less time recruiting them from probably like 80% to like 45% recruiting. But that was always like something I did a ton of.

[00:04:16] Eiso: And so recruiting, being the kind of key thing you spent several years on, today, 2021, the, the market for talent is, is, is nuts again, or maybe it has just gotten more intense over all these years. What are some of the things that you take away, very tactically for advice people today in the early stage, on the recruiting side? And on the other side, talk to us a little bit about how intentional you were about hiring in those early days. Intentional about the people, the culture that you were trying to build.

[00:04:47] Erik: I think recruiting has always been hard. It's gotten harder over time, and you know, like everyone, I mean, like, you know, it's kind of always complaining about recruiting. And I think the difference is like, some people are like, " Yeah, like, it's so hard to recruit" and then I like ask them, like "how much time you spend in recruiting?" and they're like, "ah, maybe like 5% of my time." Like, okay. Of course, like it's not going to be easy to hire people. And so, you know, I, I think that the first thing is just like, it's kind of a numbers game, you just have to put it in time.

[00:05:11] And so, you know, unless you're spending like 40, 50%, of your time, you know, don't tell me it's like hard to recruit just do more of it. To me, that's like the number one lesson just like recruiting is you just have to put in a lot of time. And I think it's like justifiable. Like I was talking about like my comparative advantage as a CTO, I think in many cases at Better in the early days was to lend credibility to the company and like use that to like hire good people. But I also feel like, you know, if you look at a startup and you go to the root cause of like everything, that's good and bad of that startup, it's going to be people. And so, you know, you kind of have to hire like good people in order to be successful. That's something I saw so clearly a Spotify. Like the quality of that early team was just like phenomenal. Tech Team. You know, and maybe I'm biased as CTO, but like, to me, there's no larger determinant than like the quality of the early-stage tech team to predict success.

[00:06:03] And so, you know, the Delta, you can create there as a CTO I think it's just like outstanding, like, you know, really, really focusing on like, let's build up an amazing team from scratch, which, you know, I was fortunate to do at Better, cause I came in with a clean slate.

[00:06:15] Jason: This is one of the topics that I could go on for days about, which is, you know, Hey, in the engineering side of the world, we should have our own ABC, which is always be closing candidates type of deal. We should be hiring, we should be recruiting, CTOs, I mean that the job functions, that should be it for a major percentage of our lives. CEO's too. I've said before on this podcast, and I keep saying it. Which is basically there's four fundamental things in the universe that constrain us to build big businesses, it's ideas, time, money and talent. And ideas, money and time, they're all basically relatively constant things. Like there's a lot of ideas. There's a lot of money in the market. Time is constant for everybody. So it's about the people and the talent and who we can get to do all those things with us. And we focus too much on other things. We focus on- processes important, yes, and, uh, certain things, other things in the business are important, but they're like a step down from having people to execute and people to bring all these things to life. 

[00:07:11] Erik: Totally. I was doing so many interviews in my first year at Better. I mean, like, you know, 30, 40 every week, like, you know, at some point I had my wedding and I was talking to so much over the phone that I got an ear infection that week. I was like on Percoset at my wedding, cause I had like a terrible ear infection. So I was just like talking to candidates, like all the fucking time over the phone. I don't recommend going that far, but like, I think it was just, you know, looking back at that time like, it was what I had to do. And, and, you know, looking back, it was kind of miserable, but, but, uh, you know, I think it also led the foundation for Better. And I think, you know, for many startups that's reality in the first year or two.

[00:07:47] Jason: I think that's a job in some way too. I met someone, asked me a while back about Twitter and something. And I don't particularly like to use Twitter, and I've not actually hid that, but it is an incredibly good funnel for a certain set of things. And how I engage with is every person who I end up talking to, I actually ask the question, " I'm slowly recruiting this person. What are they excellent at?" Nearly every single person I interact with, that's how I think. You know, "I'm slowly recruiting this person. What are they excellent at? Let me figure out about, about them a little bit more," because it's a wide funnel. You have a big aperture to see who, who is out there in the world. And it may not, I may never hire that person. We may never work together, but that's kind of how you have to look at life and when you're interacting with people.

[00:08:26] Erik: Absolutely. I actually think that's like a luxury now of being at a very early stage company again, and like hiring very slowly, is that it's not maybe necessarily that I spend, like, you know, especially less time, I'm still spending a lot of time on it, but like I can spend a lot longer in the sort of pre, like kind of building up relationships with people. And, you know, and, and these are people that I might hire in a year or two, but like right now, like I don't mind at all, like, just like talking to smart people. Even if I think it's like 1% in the future, I might be able to hire them. I have that patience right now.

[00:08:56] Jason: This goes to another mindset thing. So like let's just bucket under recruiting that we both, or all three of us kind of widely agree, but you and I, Erik very, very deeply agree at CTOs that have been through recruiting. I think about this as interactions with people in the world, in general, I know this a long time ago that I was interacting with someone who was much further along in their career in life. And they interacted with me in such a way that it was obvious that they were looking, more down, if that, if that would, how I would say that on me. It was like, "Hey, why are you taking up my time? This way? I'm important. You're not. I'm powerful, you're not." type of deal. But in general, like if you view it as, "Hey, I'm talking to a person who, at some point in the future, I'm likely going to work with, recruit or engage with in some way, meaningfully let's figure out what they're good at and what they're, what they're amazing at and all that sort of stuff." It changes your outlook.

[00:09:44] A good example of this is, there are two people that I randomly met, in various gyms in the world. One was in Oak Bay Rec Center, where I live right now, I met him as a high schooler. And another one was I met in a random hotel gym in San Francisco. Both of them have gone on eight years later in some cases, in one case to start companies, both of which, I would have loved to have been in. And one of them, I'm still trying to get into. The other one sold his company early. The point is that like, if you engage with people, think about what they're going to go do in life and what they're going to be excellent at. This is like my secret unlock to recruiting, is you don't look at a person as a static entity. You look at what they can grow into.

[00:10:21] Erik: Yeah, I think that's right. Yeah, for sure.

[00:10:24] Eiso: And I've known you long enough Jason, to know that the way you tackle this, and I think all of us in this call will agree is you need to do it with a genuine interest in that person. And you need to have that in your character. It's not a transactional thing as in like, "oh, I'm speaking to this person now because in four years I might be able to hire them. And, and that's all I care about." I think where it really works overtime is when there's a genuine interest in that person, and you build up a relationship over time that isn't just entirely transactional. To this point, I wanted to ask you something, Eric, when you were talking about the hiring of the early days of Better, and now the hiring of your team today, you know, you spoke about good quality better. So to say, what was it at the time that you were optimizing for, what you're looking for in people. And now, what is it, 6, 7 years down the road, do you look for the same things? Are there things that you've learned about what great people at the early stage should look like?

[00:11:14] Erik: Yeah, and that's super hard. And I think, you know, there's so much like weird advice. Like, you know, you shouldn't hire people who do this you shouldn't hire people who do that or whatever. And, and, you know, the sort of second most important lesson I've learned after like, just, you know, number one is like spend a lot of time on it. Number two is like, it's very hard to forecast, like how someone is actually going to do, like in a year down the road. So there is no like shortcut, like I don't really think there's like a one obvious signal you can sort of, you know here's a binary tree. You need to reverse it. And that's like, you know, 99% correlated with their future business validate it, great.

[00:11:50] Any such strong line of like 1% correlation. And so, so I looked for a combination of a lot of different signals. In terms of like interview structure ,I, you know, you have to look for so many different things, like, you know, system design and writing code, reading code, but also like talking to people. Like, are they interested in technology? And I think, you know, what was the most important thing at Better, I think was really just like does this person have like, sort of what I think of as like a commercial mindset. And is this person a generalist? That's maybe where like it's a little bit different, like hiring for startup versus hiring for big companies. At a startup, A, like you can't really, you know, you kind of need people to hit the ground running, B you can't really afford too much specialization.

[00:12:33] So what I found for at least like the first few years at Better, like the people that did it the best when I look back at like what were the things that stood out, when I met them, was like, they're just, they're just like super commercial. Like, they'll do whatever it takes to make the startup successful. They're not like married to a particular technology. They don't have any sort of like deep expertise in anything particularly. But they're like, you know, pretty happy to hack into a little bit of everything. Like they don't have any like deep attachment to like any particular language, they do whatever it takes. They want to be a part of building something. They want to be a part of seeing a startup be successful. They, they like to understand like how investors think about it and in all those building blocks, so that's like maybe like, you know, particular for startups, like, the one thing that I think, you know, maybe it isn't always the same way, how we look at candidates, but for me it was very important in those early days.

[00:13:21] Eiso: So if you take those early days of Better, versus the hiring or the slow hiring that you're starting right now, what do you look at differently today in terms of maybe those variables that you're looking for versus back then? Has your Delta changed or your growth given you new insights into the kind of people you want to bring on board in those early days?

[00:13:41] Erik: It's roughly the same. I think, you know, this idea of like looking for people with a deep commercial mindset. I think it's very, very important. And I think why it matters is that as a, as a manager and as a management style, I think what works the best at startups it's like, you almost want to create sort of aspirational culture to people coming in every morning and just asking themselves, like, what can I do for the business? And just like self-organize and do that. And so you want those people who have that ability to sort of take very abstract, sort of goals for the business and translate it into like, "what code can I write today?"

[00:14:13] I think, you know, specifically what the difference between Better and what I'm doing right now. I am building something that's like far more technically complex, and so, you know, there are a couple of sub-problems that like, do look like quite algorithmic, so, you know, I've, I've sort of pursuing, you know, a little bit of like people with a background that are programming. There's also other parts of the problem that are very sort of data centric and needs a little bit of like background in that space. So I, you know, I don't want to like pick those people compromising on sort of commercial side of it, but I think, you know, it's one of those cases where it is, you know, it does carry an advantage to come with a little bit of domain expertise. Unlike Better, where like, I didn't really care about domain expertise at all. Like I, I just I just wanted to hire people who wanted to be a part of building a startup.

[00:14:57] Eiso: So Jason, you and I have spoken about this notion of commercial expertise, usually in the, in the context of engineers understanding the why, you know, why are we building, what are the goals for what we're building. I'm curious from your experience, Jason, and maybe also from you, Erik, once you know, Better was at the stage of several hundred engineers. How relevant is this still? How do you bring this into a team? Because that culture is valuable almost at any stage of a business.

[00:15:23] Jason: So I'll say, I think it's, it's always important, the further distance you get from that, I think the easier it is to kind of fall into let's just call them ruts or, the average or mediocre, or, you know, business from when customers actually expect products to look like. But it's also, as a leader, it's frustrating sometimes if you have folks who aren't, you know, business-oriented or maybe customer-oriented, because then you constantly have to reorient them around the mission and vision. And I don't say this as saying, I don't ever think it's not my responsibility to keep getting the mission and vision and the why out there. It's just that the distance becomes much greater if you don't have folks who constantly ask that question themselves.

[00:16:02] So I think it's incredibly important. I think as much, much, more important early, because you have to be mission-driven early as you get larger, as you're allowed certain inefficiencies, just because that's the way big companies tend to be. I don't think we should accept that, but we have accepted it, but in the early days, it's you don't have an option. You can't, you can't do that.

[00:16:22] Erik: I mean, I would add to that though. Like, you know, if you look at like, sort of, you know, the other side of the spectrum . Look at something like Google, insane amount of extremely talented engineers at Google, who probably don't really care about ad revenue, frankly, like they're in it for like solely part technical problems. Like, you know, they're like, "yeah, I'm going to make this like boring scheduler faster at booting containers and, you know, whatever it is.

[00:16:43] And, and like, that's fine. I think at a very large company, you know, where you, you can afford those like very, very deep sort of technical rabbit holes and, you know, making it a fulfilling, you know, team mission out of it. But I think so it doesn't make the commercial thing, not important, but in general, I think there's like a certain type of startup in a certain type of stage where it's not just like quite important. It's actually like critical. And then there's a sliding scale on the other side of the spectrum.

[00:17:09] Jason: I think that point, right, and for what it's worth, when I talk about Google or Microsoft or others, I would say it's more customer, not commercial and internal teams have to view their inter or, or teams who are focused on internal operations, have to view their customers and have a conversation around that. And so I still think of it as a mindset switch, which is like those deep technical teams should think about internally. "My customers here demand that we get some millisecond latency on the system and we don't have sub-millisecond latency." I tend to think that they would be better off if they at least have that mindset, as opposed to deep technical rabbit hole. That said, I do understand and do get to like you don't, you don't make your own silica at times. If you're super commercial oriented. You're like, "you know, I want him to go do this because this is a geeky problem. And we've raised $250 million and I'm allowed to go do this." You get some, some outlay over that, but I don't think a 10 person team is allowed that luxury.

[00:18:01] Erik: Yeah, no, I think that's a really good point. And that's maybe a separate conversation on how do you make platform teams successful and, and I totally agree. You almost need some sort of internal NPS survey or something to like hold people accountable. That's like a completely different competition. I agree in that sense.

[00:18:15] Eiso: So to go a little bit further on success, you know, earlier Erik, you said "you get good at hiring, but still you just have to see in that first year, if someone lives up to what you thought they would." What are some of the the things that you have seen, or tools or processes that you've used and maybe even very tactically in those early days to make sure that the people you hired were the right people along the ways. And this may be just comes to the question of what is success in engineering and how do you, how do you look at that?

[00:18:42] Erik: In a way it's like, what is success in business and how do you measure that and you know, and how do you apply that to engineers? it's almost impossible to quantify it, right? Like, you know, it's this sort of freedom and point of view, which is like, "oh, it's like shareholder value." So like, you know, if you accept that as like some sort of like proxy, like how much shareholder value do you create? Like, you know, and, and how do we attribute it to you? And maybe you could do it like theoretically, I was reading something about Shapley Value which is super interesting.

[00:19:06] But like, you can't do it in practice, and so. But I think that's the question you should ask, ask yourselves. Right? And what I find fascinating about that is like, when I look at like people that I work with and how they added value, it comes from so many different ways, right? Like, you know. I managed this guy at Spotify, you know, 10, 12 years ago, and. Like, I was like, you know, and that whole, like, "we have all this like stuff we get to do it." And he's like, "no, no, no, I don't want to do that. I'm going to build this other thing." I'm like, "I don't know. Like, should you really do that? Like, we got a lot of stuff in the back." He's like," no, no, no, no. Like, trust me, like, it's going to be really, really good."

[00:19:39] And like, I had a lot of trust with him, so like, I let him do that. And then like, you know, like three months later I was like, "how's that going? Like, and he's like, "no, no, give me like a couple more months." And then like, you know, two months later he like presented his like internal, like framework for running data pipelines in Scala. It made the whole team, like three times more productive suddenly.

[00:19:55] And so Neville, he didn't pick up a single task in our JIRA backlog in like six months. But like he probably added more value than anyone else in the team because he did something that he identified. And that's, you know, just one anecdote. I see so many other things, you know, people doing like skunkworks, like crazy stuff and coming up with new ideas or whatever it is. And so it just goes to say that, like, you know, you can look at it as like, "okay, how many like of code did you write? Or like, whatever," but like adding value, like comes in so many shapes and forms.

[00:20:26] And that's actually kind of like at the core of it, like what, that's your job as a manager. To identify that and like rewarded or punish it if people don't do it well. And I don't think there's like a thing you can look at and say, you know, maybe like similar to recruiting, like there's maybe, you know, something that explains like 10% of the variation, but like nothing that explains like, you know, 90% of the variation in productivity.

[00:20:48] Eiso: So, so you touched on the skunkworks projects, the engineer who wants to go off for six months and because he has a great idea. How do you create a culture and environment in which you both make sure those things can still happen? And that kind of let's call it, you know, extraordinary size value comes out, while at the same time having a culture there where things actually get shipped because there's a backlog and, and there are tickets to be done.

[00:21:11] How do you look at that today as you're back at the early stage and, and maybe how did you look at that once Better was, you know, 50 or a hundred or 150 engineers, like how do you still enable them?

[00:21:20] Erik: Yeah, I think there's this sort of idealistic, you know, aspirational view of that, which is like,"I'm just going to hire smart people and tell them your job is to, you know, create business value. And then I don't care what they do and just let them self-organize. And at the end of the day, you know, like I, I measure people by what contributions they make. Whether they pick up tasks or didn't pick up tasks, and, and, and like view it from that point of view, like the whole idea of like, Google has like a 20% prod- why not make it a hundred percent project why don't just tell engineers, like, you can spend a hundred percent of your time, like doing whatever you want, all the time, and just like, I don't care, like, you know.

[00:21:53] That's like, not always like the, the sort of ideal way to manage everyone because a lot of people are not going to know. And so kind of being a little bit more like realistic, like I think a lot of it has to do with like framing it the right way and like letting people first, you know, show that they can work autonomously and then earn the trust.

[00:22:10] And so, I think as a manager, I always like, kind of, you know, my principal's always been, like, I never say no. If people have a strong feeling that, you know, their little pet project is going to be incredibly valuable for the company, usually my reaction is like, " are you? Are you sure. It's going to be more valuable than anything that's currently in the backlogs? We have a lot of stuff in the backlog." But, but if like people really, really are like, "yeah, Erik, I think this is going to be like, game-changing," then I'll be like, "Okay, prove it to me. But you know, in six months, if you built something that's useless, I'm not going to be happy. But if you have like a strong feeling that this is like very, very good for the company, like I totally support that."

[00:22:48]  And, and, you know, and I've seen that many times where people actually end up building something that's fantastic, and I think that's great. But yeah, it's tricky, like, I don't know, like, you know, you obviously have to do it with some sort of control and make sure people aren't building crazy stuff that has like zero business value. But like, if you like frame the right thing, like here's what the business needs to do, and at the end of the day, you're responsible for showing me that it generated value. Like, I think you can make some amount of that work.

[00:23:11] Jason: I take a view on this that is largely, depending on where you are in the life cycle of your company too, so you can take on a couple of different roles, but at some point you become almost like a coach and a trainer to a degree. And one of them is I want to help people grow into the next stage of their career, but also I want to show them how I might think about this. So I ask a very simple, simple question: "how fast could you prove or disprove that this thing is valuable?" And if the answer is "six months," I'm like, "ok what could you show me in two weeks? What could you answer in a month? What could you, and then you try to shave it down to the point where you don't have to do build the biggest thing, but there's some provable elements." And there always is, there always is somewhere along the way, something that would indicate like "we're definitely not."

[00:23:59] I tell people all the time that every time, at some point in my life cycle at every company in every job, someone's going to come to me and say, "We should make a database." And 90% of the time, you should never make that database, but there is a certain set of times when you should make that database. And LinkedIn is a great example of this because a lot of great database things have popped out of them. But there's an 80% of a database is actually really simple to build, and the last 20% is hard, so you've got to get to the point where you de-risk this thing and why you're building it. You're just trying to show them how to think about what they're actually doing. Not the fun part. The crappy part, the hard part, the risky part. And if you can get through in that way, there's a lot that you can give. 

[00:24:40] And Erik's point about trust is critical. It's not like somebody who has underperformed for two straight years comes to you with the most brilliant idea in the world, you're going to hear it. It's almost impossible for you as a human in that situation, to hear the most brilliant idea from someone who's chronically underperformed. Whether it's not it's their fault or not, maybe it's the org's problem, but it just is.

[00:25:01] Eiso: I find it interesting how we've landed today, actually on the topic of it's called the skunkworks project. It's one where, I'm pretty sure there's engineering leaders listening to this episode going "I know who those engineers are in my company. I know the ones that have earned my trust over the years, but they're not coming to me with ideas anymore right now. They're not actually the, we haven't created the environment. We, it's all about shipping, you know, features I'm working on the backlog."

[00:25:25] Erik, as Better scaled, how did you manage this? There's those crazy ideas to make things better still coming up when you were a hundred or 200 engineers? How did you instill a culture where, not just you, but other engineering leaders were encouraging this? And did you have any visibility into this and how did you reward it in the org? I'd love to dig a bit further into this, because I think this is a topic that there's a lot of hidden value in a lot of companies right now, and it's sitting in the mind of some engineer who has a great idea, but maybe not the environment or the culture where it actually gets exposed.

[00:25:54] Erik: My blunt answer is like, I don't know. I don't know if I ever created that at like a hundred, 200 people. I think that was certainly like a challenging thing. Once we got to that scale at Better to like balance, like, "okay, we have all this stuff we have to ship," versus "okay, what are some like crazy ideas we should spend time on. I think we had that more, I would say when we were like 20 to 50. And in that case, I think a lot of it had to do with just like designing a less rigid planning process. Where I think, you know, like early on at a, at a startup and then maybe later on too, like I think, there's a little bit of a spectrum of like, you know, how, how should you think about planning and like, you know.

[00:26:32] And maybe this is like what we talked about this earlier, but like, this is a sort of Tayloristic approach. Like, do you have like a sort of, well-defined like replicable tasks, where you can like, you know, estimate how much time they're going to take, and like you just, like, you just want to make a giant chart and like bang them out. Or on the other side of the spectrum, are you doing some like crazy, you know, Bell Labs type research, where you have like, no idea how long nothing is going to take. I think like roughly speaking, you kind of need to identify, like which side of your spectrum you are. Startups tend to be on the other stuff. Startups tend to build like crazy research all the time. But not always. Like sometimes startups are also doing, you know, like very like practicable things.

[00:27:06] I sort of look at it as like, okay, like you think something going to take one day? How long is it actually going to take? And it has this like weird sort of, I think like a log-normal distribution of like how long it actually takes, roughly, it's like one way to think about it. But what is the uncertainty? Right? Sometimes, you know, a project can blow up by a factor of a thousand. You're like, actually it turns out we ran into a Kernel bug, and we have to like patch it, you know, whatever it is.

[00:27:33] When you have those types of like crazy problems, like it's very, very hard to plan. And it's like very, very hard to design, sort of like a very, you know, Kind of Tayloristic approach where you like, you know, have this a gap chart and like, you sort of compute story points and burnouts. And you just have to like throw that out the window and focus more on like resource allocation and like, are we like, you know, putting in resources on the right things? And are we like, you know, giving up problems that turn out to be hard?

[00:28:02] That's another thing I think is like super important when you're in that late research mode, is like, "oh, like you started working on something and you thought it was gonna take a day, but now you've been working on it for like three weeks." And like, clearly this is the much bigger problem they thought, okay, maybe we shouldn't do it. And so I, I think, you know, part of it is also like, kind of going back to your question is like, I think you need to figure out, like, is this work things that is more like research? Or is it something that looks more like shipping, like very like well-known features.

[00:28:29] Eiso: I think that's a great way of looking at it. Jason, you and I have spoken about planning in the past. At what point in your journey and at GitHub, did you have to balance from, you know, extremely rigid planning for the next four quarters to, "Hey, this is where we are going to really just go and roll with the feedback that's coming from users?"

[00:28:47] Jason: GitHub and Heroku were slightly different. So you specifically asked about GitHub's mindset. When I got to GitHub, there was no planning whatsoever anywhere in the company. No, no plans, no quarters, no years, no roadmaps, no mission, vision, nothing structurally. So we had to put some stuff in place. So I would say we put some stuff in place and it got a little bit too rigid because you're trying to like, organize the things. And then you have to back off of it. I would say Erik's point the Kernel bug, it's one that's always been the bane of my existence. I feel like whenever you're doing this planning, you always run into. Heroku is a good example of where we ran into Kernel bugs a lot. Cause you're building dynos and things of that nature.

[00:29:26] But the one takeaway from an engineering leader or even CEO, I think too is you have to understand that there's that old saying, which is "the plan is not the valuable part, the planning process is the valuable part." And if you actually understand and take that to heart, what you will understand is that plans will change and you have to roll with them, and that's okay. Which is also why I think that people who don't understand the purpose of OKRs can find themselves in a spot where they look at an OKR done on Jan one, and then they're trying to understand why at the end of the quarter or something else, but they've not, they've not readjusted OKRs along the way, because the plan had changed because they've surfaced new information.

[00:30:10] So I would say that most organizations, when I see them do planning, they tend to say, "we need planning." They put planning in place. It's quite rigid to start because everyone has to actually understand what an O what a K and what an R is, and they get pedantic about it. And then X, Y, and Z have to fall into place. And then they realize, it's not serving us. So they back off a little bit and they get less rigid, more malleable, more flexible, and there will become a point in time when they will like that process more or less. Truthfully, I feel like most organizations, all the way through, from a planning perspective, we've talked about this in the past too, which is most of the quarter plans should be able to fit on a one-page and it should be, it's a high level mission and vision. You get mission to get vision, you have goals and priorities, and they get broken down into tasks. Most of the work that happens on a day to day basis is at the task level. That's not captured all the way at the company level, but it rolls up, but it really the goals and the priorities and where you are going to spend almost all your time, if you have the mission and vision lined up, and if that's the case, most of that can fit into about a one-pager, maybe two.

[00:31:14] Erik: I think that's a really good point. And there's been a bunch of blog posts in the last few days for some reason about OKRs and like criticizing them and, and also like metrics and they're all of them. And I think, I think the way I think about it, and I think you captured it, is like, I think thunder, right? Like it's kind of a delegation mechanism and like done poorly. It's just like complicated, like dilution of like having control. And like when I've seen it, like metrics that work really well it's but you know, it's, it's, it's used as a way to like, I'm not gonna like, create this like super complex chart of what you're going to do, but here's what you should focus on. Like here's the metric I want you to care about. And then let people actually do whatever they want to like, you know, focus on.

[00:31:52] Jason: The delegation mechanism point is actually, I think really, the really important one here, because at some level it always seems that there's a conversation about like, well, who owns the entire quarter for the company spreadsheet. You're like, "whoa, whoa, whoa, hang on a second. Are you asking me," literally a CEO asked me to create a spreadsheet of every engineer in the organization's work that they were working on tasks and roll it up to a spreadsheet. That was a, that was a pull the big red line in the bus moment, which is, let me walk you through why that's a really bad idea. That's not the purpose of any of these planning tools. If that's the case, then we are just becoming a planning organization. We don't become an output organization at that point.

[00:32:29] And, if you understand what Eric just said about delegation, that is the critical, critical moment. What am I, what am I going to track? What am I going to project out? And what are they going to take in from that to go work on? Because they know best, but to go work on, to move that metric in all likelihood. Or if they don't, they should go find out.

[00:32:44] Erik: We talked a little bit about people earlier in hiring, and you mentioned something, Jason, that like you think people is so much more important than everything else .I'm curious to hear how you would rank people versus like, basically like in my head, like, I feel like people is the most important thing then like after that is probably like culture. And then after that is probably like process. And then like, after that, it's like planning. And I'm curious to hear your point of view. It's like, I feel like sometimes, like companies like mess this up where like, they kind of screw up people, they screw up culture, they screw up process, and then they're trying to fix all that on the planning side. And like, you know, without sort of addressing these underlying things, for sure. Like, you know, in my opinion, like 10, if not a hundred times more important. And so I'm sure it's like, if you think this is like, you know, something you would agree with or if there's a nuance to this.

[00:33:29] Jason: Culture is a funny word to use.

[00:33:31] Erik: Fair enough, it's a little overloaded.

[00:33:33] Jason: It is because yeah, it can mean so many different things. But I will say this. It is number one, people. Number two, probably like, I wouldn't say philosophies. I I'm going to go back to sports metaphors here, but like, are we a, are we a running gun football team or basketball team? Or are we a defense-first, football or basketball team? Are we a gritty, are we a high-flying type of high scoring type of thing, but like, if you know what I mean by that, like philosophy and culture. All wrapped in as the, as the number one. If you put up, if I had to force rank it, people. Process is somewhere down, way down the list and process, because I'm using big P process. I hate it. I hate big P process.

[00:34:13] And this is one of my big changes for when I was in my twenties, which I was an engineer coming up. I thought I could organize the company. And you can't, you can't organize the company. Like you think you could. And so I think it's people, all the other things that just said process way down the list. Then I go after people, culture, philosophy, I'm going to go mission, vision, making sure all that stuff is done. But if you don't have the people, nothing else matters. If you don't have the culture to support the people, you'll get them, then they'll leave. And if you don't have the philosophy. You largely don't know if you've got the right people to engage with it because you could have a defense oriented entire group, but you're trying to implement an offensive high-flying oriented system, and it doesn't matter at that point. You got the wrong mismatch of people for the system. 

[00:34:55] Erik: I think that's right. Maybe when I say process, like maybe, what I think of it as like more like, you know, what is the workflow? Who makes decisions? Who decides like, what has to get done? How's it like, release processes. How often are you releasing to production?

[00:35:09] What's your like, you know, infrastructure on like testing, but also like things like are the product manager and the tech lead working together? Or like, is there someone over here making decisions? Who's looking at data like, like the sort of, you know, the workflow of idea to code and like, you know, that, that feedback. That's maybe what I think of as processes.

[00:35:26] Jason: Yeah, so we're talking, we're using different processes in different, different ways here. I'm talking about like, OKRs and V2moms, and that sort of thing. And I think you're talking about more like organizational philosophies and work. You said idea to something, what does it take to get a thing out from your head onto a whiteboard and out to a customer. And that right there, actually, I don't have a word for it, but let's just adopt the process for the sake of this is probably second to people, culture, philosophy, because that is how you, that is the implementation to it. So my process, the one I said, somewhere, wait down the list .Your process is actually really far or really close to the top, primarily because you're trying to figure out the shortest pathway to a customer.

[00:36:10] Erik: Yeah, no, I okay, it sounds like you were on the same page and it's something I've had very strong feelings about. For instance, at Better, like one of the first things I did was like, "we're gonna do continuous deployment." Like we're gonna, like, you know, set up like a fully automated testing pipeline and like get everything out.

[00:36:24] And then, you know, and that's something else I started doing later. It was like, we're going to start AB testing things, and we're going to start instrumenting things, and we're going to know what's actually happening. And like, we're going to be like very reactive about it. And then, like, we're gonna have like a growth team. And we're going to have a PM and a data person and you know, a bunch of engineers working together and just like iterating. And I think, that to me is like, you know, where I feel like this is so much more value to be on unlocked, then, like maybe getting into minutia about, you know, the OKRs and the, and all of that stuff.

[00:36:52] Jason: To use a concrete example, for the listeners on this one, I talk about a number of releases quite a bit when I'm talking about a number of releases per day, as an example. Why do you get hung up on that? It's like, not because I care about a number of releases per day, but I care that like the number of releases you can do indicates that you've taken care of a whole bunch of other systems, a whole bunch of other things.

[00:37:12] If you can do 2000 or a thousand releases per day, as opposed to one release a quarter, that's what you are doing. There's a high correlation to like all these other things that are going to be in place, like better, better systems, better workflows, all that sort of stuff. As opposed to, if you get pedantic over what an O is and what a K is, what R is and what is being written on this sheet of paper as you're "oh, that's not structured that's an objective. It's structured as a key result and we got to reword that," you're like, "oh my God, kill me right now. We're never actually going to talk about what's out there for the customers."

[00:37:45] It's not the specifics, it's the spirit of each one of these things, and what it kind of demonstrates. But it's also why I think a lot of people who have worked with me in the past, like as, from an engineering perspective might get frustrated because they're like, "just tell me what to go do." And I'm like, all right, like now we got to get into the nuts and bolts, but like, we got to get to the spirit of these things so we can teach people to fish too.

[00:38:03] Erik: I think that's it. I mean, one of the things I thought when we started Better, is that there's literally like a thousand or 10,000 whatever, like other mortgage vendors out there. And some of them might have like a thousand engineers. What do we have that they don't have is like, they probably make a release every three months. Like if we build this super quick, super time, like feedback loop, we instrument the shit out of like every single user interaction with our . Page.

[00:38:26] We, we like really care about building an amazing user experience. We can literally do like, you know, iterate like a thousand times more often than they do and build a much, much better user experience than they can. And that's ultimately how we're going to win against, you know, the, the big, you know, mortgage vets out there. And so, that to me was something I was extremely adamant about for the first few years.

[00:38:46] Jason: I have a pinned tweet on my profile, it's from DJ Patil, and it was written on a sheet of paper, it says The White House on top, and it's broken into three sections, and we're just gonna read it off, cause I think about this quite often. So dream in year, plan in months, evaluate in weeks, ship daily. Prototype for 1x, build for 10x, engineer for 100x. What's required to cut the timeline in half, and what's needed to be done to double the impact. It's a pretty simple distillation of a lot of different things across the organization.

[00:39:19] If you've ever worked in a place that had a three month release cycle, you understand how terrible that could possibly be. And if you have one that doesn't quite understand what it means to cut a timeline and half, and you're always going to constantly be adding time to it, again, you don't know. And you know, Elon just had that tweet that said, "if you give yourself 30 days to clean your room, it'll take you 30 days. But if you give yourself two hours, it'll take you two hours." That's, you know what he's saying. And he's not he's right about that. That's what, that's what organizations are. Sometimes you got to put those, those parameters in place.

[00:39:47] Erik: Except I wouldn't ship daily. I would ship every minute if I could.

[00:39:51] Jason: Every minute. Yes.

[00:39:54] Eiso: This is a great place today, to end today's episode, because I think we we've gone from people being the most important part. Erik, you have to spend insane amounts of time, and I think it's important for people to realize the amount of time it takes in the early days to hire that team. To, to really going through, like, how do we actually end up with that culture where value gets delivered frequently? And I think we can all agree that an indicator of that happening is seeing things go to production really, really frequently. And so I think this was a fantastic discussion. And so I want to thank you very much, Erik. Is there anything else you want to add to today's talk?

[00:40:30] Erik: I think we didn't talk about culture and we could probably talk about that for like months, if we want it to. But that's the other thing where I think it's like, how do you create... Culture to me is just like, almost like game-theoretical equilibrium where it's like, people are sort of second-guessing how other people perceive their own pro-. Like, it's this like complicated thing where like, if you do it right, you create this like really cool environment where people are like, "oh, like I thought about, you know, this thing where we're like working on over this weekend and how I have a really cool idea of how to solve it." And the other person's like "I don't think that's possible," but the first person's like, "I'm going to prove you're wrong."

[00:41:03] And then you have this like really cool, like sort of almost like competitive, but like mutually respectful climate of people always trying to like do better than each other. And I think that's like, the other thing that I think is so critical for success is like, how do you, how do you create that? Like, how do you, that's one aspect of culture, but probably the most important one is how do you, how do you create that thing?

[00:41:22] Eiso: So, this is interesting because I speak to a lot of people about engineering culture. And I think you're the first person who talks about it in the notion of this almost challenging each other, but in a, in a culturally positive way. I wonder how much that stems from your early days as a, as a competitive programmer. Can you dig a little bit further, Erik into you saying, "Hey, the importance of creating a culture where you challenge each other in a, in a positive way."

[00:41:46] Erik: There's a lot of engineers I've talked to, and they're like, you know, "I just want to be promoted so people listen to me, and like, they don't challenge me." And like when I hear that thing, or like when I hear, you know, people say, you know, "we argue too much." Or like, whatever. To me, you know, I understand the problem, but the solution is not to get rid of the arguments The solution is not to get rid of people challenging each other.

[00:42:08] The solution is to make people actually trust each other and like, you know, mutually respect each other. And if you do that well, like people should argue like all the time because they, like, they care about like building something fantastic together. And when you have that, I mean, I can just imagine like, you know, whatever, like John Coltrane and Miles Davis, like jamming off and stuff, and they're like, "you know, like I think you can play this solo much better. Like you want to give it another shot?" They know they can do that, 'cause there's so much mutual trust for each other, and, you know, and I think, you know, if you get that working for high, then you can truly create like this, like high-functioning high-performing team that challenges each other to get better all the time.

[00:42:43] Jason: We should make that a topic, Erik, you should come back, we should have another one of those. Again, I like to talk about sports quite a bit, and those are the high functioning sports teams, the ones where there is such a base level of mutual trust and respect that they're allowed to challenge each other in a way that they can sharpen each other. If you don't have either one of those and you start to go into the sharpening and trying to challenge each other, it erodes very quickly. It's this work over here, the trust and respect that you need to do. I would love to dive deep with you on that one.

[00:43:10] Eiso: Let's do it. Let's make sure we get you back one for that, Eric. And I think it it's a topic we can go quite deep in. Let's let's leave it there, guys. This was super interesting, Erik. Thank you so much. Funny how we ended up actually, even without thinking about it so much on, on this notion of "what can we do to give engineers more trust?" And like this agency kind of trust model, like how do you build culture very high trust and give tons of agency all the way to six months skunkworks projects. Which by the way, sounds like a very daring decision that you made over at Spotify to let someone go off for six months. But this was really cool. I really enjoyed it.

[00:43:44] Erik: Yeah, it's fun.

‍