.jpg)
Speed: Moving Fast Towards What Matters
Some leaders think speed is simply about working harder or moving faster. It isn’t. The speed that matters is Mission Speed: the rate at which your mission advances in the direction you’ve chosen.
As teams scale, that speed can quietly erode. Decisions pile up, energy becomes diffused, and everyone stays busy, yet less gets done than it should.
In this limited-series podcast, Keith Lucas—former Roblox CPO/CTO, author, and startup advisor—unpacks how the best operators move fast. Guests include the founders of Roblox, Instrumental, Vera, Divi, Splendid Games, and Blue Rose Research.
Speed: Moving Fast Towards What Matters
Speed Is a Vector: Yaniv Bernstein on Moving Fast in the Right Direction
In this episode of Speed, host Keith Lucas talks with Yaniv Bernstein about what's actually changed for founders building with AI, why taking on technical debt aggressively is often the right call, how Vera balances speed with the trust required to help families navigate care for aging parents, and his go-to method for turning around a team that's gotten stuck.
Speed: Moving Fast Towards What Matters is a six-episode limited series featuring six startup founders and operators who exemplify personal speed and have wrestled with it organizationally — exploring the systematic principles of speed and the critical tactics that make it sustainable as you scale.
In this episode
- 0:00 — Welcome, and introducing Yaniv Bernstein
- 1:45 — Speed today vs. a year ago: the 5-10x jump from agentic coding
- 6:50 — What Yaniv wishes every startup leader understood about speed — and why technical debt is often "good debt"
- 14:05 — Delivering speed and trust together at Vera
- 18:05 — How to turn around a team that's stuck — and why more process usually isn't the fix
- 24:04 — Recovery: using AI as a thought partner to get unstuck
The Guest: Yaniv Bernstein
Yaniv Bernstein is the Founder & CTO of Vera, an early-stage startup devoted to supporting people who are looking after aging parents. He's spent nearly 20 years in tech, including a decade as a software engineer and engineering leader at Google, followed by roles as a scale-up VP of Engineering and COO. A two-time founder, Yaniv has invested in and advised numerous startups, and co-hosts The Startup Podcast.
Connect with Yaniv:
The Host: Keith Lucas
Keith Lucas joined Roblox as employee #7 and later served as CPO and CTO, leading product, engineering, and operations as the company scaled. He went on to serve as COO of Instrumental and now advises leaders across AI, gaming, creator platforms, and enterprise technology. He is also the author of IMPACT and host of Speed.
Connect with Keith:
Get the book: Impact — https://keithvlucas.com/impact/
Contact us: speed@keithvlucas.com
CREDITS
Produced by : Leah Barnum
Social Media: Julia Guagliardi - www.stillwaters-creative.com
Editor: Jon Keur - www.wayfarerecording.com
Content Designer: Natalie Leroux - www.studioeightyseven.com
Studio lighting/Setup - www.175productions.com
The mental framework that I have with Agenic AI for development is it doesn't create new capabilities for an engineer. What it does is it massively changes the cost of doing something. And when you massively change the cost of doing something, then all the trade-offs that used to make sense, you've changed the trade-off surface. Right? So before electricity was invented, light was very expensive. I've seen this amazing graph of, you know, cost per lumen of light. You needed to be very frugal with light. You needed to think, do I really need to light this candle? Uh, because it's an expensive candle. Now you don't have to think about it. And it would be a waste of your time and energy to think about should I be turning this light on?
SPEAKER_01Hello, and welcome to Speed, a podcast for startup leaders who want to move fast towards what matters. I'm your host, Keith Lucas, and I've spent almost 30 years in tech building teams and advising companies. I've also written Impact, a book for startup leaders who want to transform their teams from scrappy to scale. It is my pleasure to welcome Yuniv Bernstein. Yuniv started his career at Google as a software engineer. He then held engineering and operational leadership roles and a handful of startups on his way to becoming a serial founder. Tanay YNIV is founder and CTO of Vera, a co-host of the Startup Podcast, and a startup advisor. He's also a friend. I met Yuniv as a guest on his podcast and have since invested in and advise Vera. I have been thrilled to get a front row seat to his rapid adoption of agentic coding, and I am constantly amazed at the progress he makes with an engineering team of one. When it's not just speed, it's innovation. I've seen YNIV rapidly deliver on bigger and bigger projects, giving Zera multiple competitive advantages very quickly. Yuniv is a great guest because not only can he speak about speed at companies large and small, he's also on the front lines of agenda coding. YNIV, welcome and thanks for being here.
SPEAKER_02Oh, thanks for having me, Keith. I'm excited for this conversation.
SPEAKER_01All right, why don't we jump in and get started with my first question, which is given that you are right in the middle of the AI coding transformation, both as Vera CTO and as a podcast host, how do you think of SPEAME today versus a year ago? And are you able to estimate in any way how much faster things are moving today?
SPEAKER_02Yeah, it's interesting. Uh you mentioned you you're an investor in Vera, and that was probably about a year ago when we did our raise. And there's this amazing silver lining to the fact that we we raised from fantastic investors such as yourself, but we didn't get to our target amount. And the shortfall was approximately the amount of money we needed to hire our first founding engineer. And so about a year ago, I think that was the era of let's see, I don't know, Sonnet 3.5 in coded in um Clawed Code. And I, as you mentioned in the introduction, in the very kind introduction, I I am an engineer by background. And so I I realized I was just going to have to do it myself. Uh, and that these agentic coding tools were going to make it possible. At least that was the bet which is which has come very true. And I I'm now at the point where it genuinely seems like it was a blessing that I did not hire somebody earlier on, because uh I think, especially at this early stage, the ability to go from concept to execution without having that human communication overhead has been immensely valuable. And I uh hand on heart, for for the last year, if somebody had offered me a talented founding engineer for free, I I would have had to think very carefully about whether I took that person on simply because of the ability to move very quickly. So I I estimate to answer your question directly, uh, at this very early stage, and I do think that the speed up varies by stage, uh, amongst other things, but uh I would say it's easily a five to ten X speed up in the ability to go from concept to delivery of production software.
SPEAKER_01So do you think that you're when you when you make that first engineering hire?
SPEAKER_02Yes.
SPEAKER_01Will it have the same reason that you've made it before? It's a resource constraint. You're even you with Claude or running out of the throughput you want, you need to bring on someone else, or or has that also changed in a way?
SPEAKER_02Uh I think it will be a resource constraint, but I think what's happened is that the horizon has moved out quite a lot uh because I've got this much broader span of control. But it also means that when the time comes to hire that first engineer, the profile I'll be looking for will be quite different uh in in a number of different ways. I I think obviously the ability to leverage AI agents uh at a at a very sophisticated level will be table stakes for the person I hire. But bigger span of control also means you move quite quickly beyond the technical aspect of engineering and much more aggressively into product, into design. Now, I I think every engineer really needs to be able to do that. And there's this sort of sense that you hire now these product builders, nearly right, who are a bit more entrepreneurial. And so the point at which I I would make that hire, Keith, which I I I still don't want to do it, but I I'm starting to see it, it's come over the horizon now. I'm like, I can now see the day, the point at which I would like to make a hire. And it is when there is enough complexity in the system that I want somebody to own a big piece of it and be able to go deep and be the expert on that thing. Uh, because right now I'm like, okay, I've I've been able to go to I guess you know, when you're working with agentic tools, you you end up at a medium level of depth, right? I don't know every line of code in my code base. Uh and we're now starting to build some deep enough technical sophistication in what we're doing that I'm like, I can see a time soon when a person could work full-time, for example, on developing and refining our uh voice capability, for example. And then I would have somebody to own that. When I talk about that entrepreneurial bent as well, I I think because you can close the loop so quickly, I would want somebody who I can trust to a very high level to iterate on this thing without checking in with me, right? Because we we've moved very quickly to that point where the human in the loop uh is the bottleneck, and two humans in the loop is is a much bigger bottleneck. Uh so we we really need to have that that radical autonomy now.
SPEAKER_01Right. So so so handling complexity or when the complexity reaches a certain scale, you need to uh bring on someone else, looking for someone entrepreneurial, looking for AI native programming, all of those things. I want to move on to other things relating to speed. Given what you've learned not only as a founder in this era, but also through your podcast, what are one or two things you wish all startup leaders understood about building speed on a team, either generically, like in in terms of traits and and and skills and mindsets and all of that, but also possibly as it relates to technology in the day?
SPEAKER_02So there won't be anything original in what I say here, Keith. A lot of these are, I guess you could say, truisms, but it doesn't make them less true. And I think the first one that that I guess particularly is one that I've had to learn over and over again, and I think it's partly to do with the shape of my career, which as you mentioned, I started at big tech and then progressed down through scale-ups all the way to my early stage startup, is that you want to, and this might seem counterintuitive, but you you want to be taking on technical debt quite aggressively. And what do I mean by that? Um I I I like the technical debt analogy. I think it it is it has some real validity to how financial debt works. And you know, when they say with debt, there's good debt and there's bad debt. And generally, if you are at an early stage and you have access to a credit facility, you would be crazy not to use it. Because what you're trying to do when you're building a startup is to create something from nothing and you have very limited resources, and by far the biggest risk is that you just never get off the launch pad. And so if you can borrow from your own future in order to get off the launch pad, that is a deal you should be taking all day long. And so, what does that mean? Is you still have to do the basics, right? And you you still want you don't want to take out predatory high interest debt if to continue the analogy. But if you are over-engineering, and I think for someone who comes from an engineering background or a big big tech background, over-engineering is actually quite a big risk, right? And what you want to do is but the biggest odds with any particular thing you build, any particular feature or whatnot, is it will not be successful. And so you want to have a very experimental mindset, a hypothesis-driven mindset. Uh, build the thing, don't take on unnecessary debt, but take on good debt so you can build the thing quickly, learn quickly, and iterate quickly. So I I think that's a a really big thing that I just need to keep reminding myself. Uh, sometimes you get the ick. Uh you want to be respectful of your customer data and security, but you don't want to build for scale, because if you do that, then you'll probably never reach scale. You'll just sit you'll simply be moving too slowly.
SPEAKER_01Yeah, I think about, and this is not an original statement, but I I think about AI as an amplifier in many ways. And in in this way, it amplifies what was true before, whether whether it's a year ago or 10 years ago or 20 years ago. How fast you get to iteration, that time to your first iterative step, how fast you get to a custom, a real customer in your audience, and you're iterating alongside of them, that is really imperative, and that's where you have to take on technical debt. One of the things I've seen in that as a way of knowing where to take on the debt and maybe where not to, and I'm just wondering what you think about this. I've often thought about it as take on the debt everywhere that is not your core intellectual property. But if if there's a piece that is so core to your different differentiated valued in what you are doing, then that's where you put all your attention. Not that you wouldn't take on debt there, but you might be more sensitive to it there. What do you think about that kind of um a way of determining where to spend your resources? Or can you have another approach you like?
SPEAKER_02Yeah, I mean, even that I'm not sure about. So the the mental framework that I have with with agentique AI for development is it doesn't create new capabilities uh for an engineer. What it does is it massively changes the cost of doing something. And when you massively change the cost of doing something, then all the trade-offs that used to make sense, you you've changed the trade-off surface, right? So before electricity was invented, light was very expensive. I've seen this amazing graph of you know cost per lumen of light. You needed to be very frugal with light. You needed to think, do I really need to light this candle? Uh, because it's an expensive candle. Now you don't have to think about it. And it would be a waste of your time and energy to think about should I be turning this light on uh within limits, right? Um, and so it's it's a little bit the same now because one of the things that the cost has gone down on with AI is is refactoring as well. So even with core technical capabilities, what I found is uh it makes sense to kind of build it, see how it works, figure out what's not working, and iterate it. And when you eventually hit a wall where it's too messy, you just kind of rebuild it with everything that you've learned. And so I think the idea of the major refactor or the major rebuild as being something to be avoided, uh, especially in early stages, I I don't think is true anymore. Because and again, you know, the the capability of the agents keeps improving at the time of recording, uh Fable 5 is now available. It is very capable of rebuilding things with with minimal to no input from the engineer. Another mental framework that I found really valuable in in this agentic era, and again, it's to do with the fact that uh costs have changed, Keith, is that uh Gary Tan, who is the the CEO of Y Combinator, uh he introduced this concept of boiling the lake, which I really love because you know there's this there's this term to boil the ocean, which is uh a negative thing, right? The idea that you're trying to solve a problem, but because you're not focused, because you're not saying, I'm going to do this one thing, you try to boil the ocean, which of course is impossible, and so you get nowhere, right? Uh so boiling the lake is saying, well, you still don't want to boil the ocean, but you don't have to be so focused now. You can build the fuller version of what you're trying to build straight away rather than building like a real minimum viable slice of it. So don't boil the ocean, but boil the lake. And I find myself actually telling my agents quite often when they start making engineering trade-offs as if they were a human. I say, no, boil the lake. Do this thing, right? And so, yes, that takes on technical debt, but it really gives you a higher fidelity experiment to see if users actually like what you're building.
SPEAKER_01Yeah, and I've seen you do some of that at Vera, and it's really a great mindset and very impressive the results. You touched upon quality. I want to come back to that. Um Vera is not just moving fast, it's also building a platform for to help families navigate late-stage health and care for loved ones, so it requires a lot of trust. And so, how are you delivering both speed and the quality that your end users need or in order to build trust?
SPEAKER_02Yeah, it's it's an interesting question, and and I've thought about this, and and there are a couple of parts to the answer, uh, because there are there are multiple levels of trust. I think there are pieces of trust that are unbreakable that are to do with how we handle customer data and security and so on, uh, which I think is is still absolutely not negotiable, um, which is as an aside, why I I still worry about not engineers vibe coding products. Vebecoding has become a lot more viable, uh, but some of these things, the the gotchas uh around security and privacy are where sometimes having those engineering instincts or the engineering experience to know what's right and what's wrong becomes more important. Um But nonetheless, I I think that is absolutely imperative. Now, for other layers, I guess I'll say something mildly controversial, I think, which is that in a in a lot of areas, including our own, there is a type of conservatism uh where we say, well, because we're working in a sensitive area, we need to move very slowly and very carefully. Uh whereas I I guess I try to take a more utilitarian view without being a cowboy to say, well, if the expected value of what we're doing is positive, then that is a good thing, right? Again, the the biggest risk is that nobody uses it. Yeah. Right? Like that's true of any early stage product. And so if there are a couple of rough edges, I try to avoid them, we can fix forward. Uh where we also care a lot about quality is in the quality of the actual advice that we give. Because again, uh, although we're not dealing with clinical healthcare information, we are adjacent to that. Uh, and so for that, uh, we actually have a kind of a philosophy and a framework where we say we don't use, we use AI extensively in product. So far, we've talked about using AI to build the product. We also use AI extensively in product. But the principle is AI is there to listen and synthesize, it is not there to dispense advice. At the point at which we're dispensing advice, we use human-authored, human-curated content. So that's one of the ways that we we try to maintain quality and trust of the core value of what we do, which is the quality of the guidance that we give. Uh, and you know, I do think one of the things I've enjoyed doing as I've built Vera is thinking about design, thinking about what are the design principles and the user interface principles that apply to an AI tool. And I think this is actually, to me, this reinvigorates the whole domain of design because it's not anymore about not that it ever was, but I think it was somewhat captured by how do the pixels look on the screen and how do we lay out the screen and what's the sort of you know workflow. Where I think real design goes so much deeper than that. And because we have this new domain, we are learning as we go what is the best, what are the best design approaches to this.
SPEAKER_01Thank you, Yanim. I wanna I want to also talk a little bit about when you have to turn around a situation, which maybe you've done with your personal projects, or maybe you've done it as a leader, or maybe you're walking into some situation where the team is bogged down. It's it's the opposite of speed. Nothing is really happening. When you face these moments, sometimes you not only have to turn things around, you have to turn turn things around quickly. And again, it's not just things you walk into, it might be things that you're doing yourself, things that you're managing on your own projects. What is the first thing you do to jumpstart a change when you notice things are moving slowly? And and what do you follow up on?
SPEAKER_02Yeah. So the first thing I do is try to understand why. Why are things moving slowly? And uh I think you know that that root cause analysis and you could say some first principles thinking is really important. Understand the reason that things are moving slowly, and then act aggressively and rapidly to attack that root cause. Um, and you know, that the the causes can be many and various. So, for example, uh one of my touchstone stories, people who listen to me on other podcasts will have heard this story before. But I I came into a scale-up company where the engineering team had become too slow, uh, was the general sentiment uh in and around the company. And when I looked at the issue there, uh it was really a a lot of process slowness, right? Where you're like you had a startup that had moved into a scale-up, but the processes hadn't kept up. And things that allowed you to move quickly when you were small were no longer allowing you to move quickly when you're big. And at the same time, some of the safety nets, for example, uh they were still using manual QA before every release. Now, this was quite a few years ago now, coming on 10 years, but even back then that was not good. So my first move was I simply eliminated the manual QA gate. I didn't fire the QA people, but what I said is it is no longer their job to make sure that the release is okay. It is the engineers' job. The QA team are now here to consult and advise and do some of that more in-depth exploratory testing. You engineers, it is your job to ship quality. And what that meant is first of all, it became a forcing function to invest in testing. Secondly, it meant we could increase the frequency of our releases. Uh, and it's yeah, I I guess it's it's nearly like finding that that fulcrum, that leverage point where you say if if I change something here, it starts to cascade through the system because it it sort of creates a forcing function for other things to change. Uh, and then uh another thing that that's worth mentioning, uh, you know, sometimes less comfortable, is usually when a team is bogged down and slow, it is at least partly a personnel issue. Uh what it means is you've got an organization that has become uh through revealed preference comfortable with being slow. And so generally it's difficult to change the speed of an organization while keeping all of the existing people in place. And uh, you know, that can be an uncomfortable conversation, but I found it to be true.
SPEAKER_01Yeah, I I've seen that as well. And I I'm I the way that you describe the first part about that with the finding the lever is you are in problem solving mode, like any. Other problem. A lack of speed is a problem to solve and to think about it as the biggest lever you can find based on root cause. I think it's a great, great way of thinking about it.
SPEAKER_02And I can tell you what what I found doesn't work, Keith, if that's of interest. Yeah, no, that's because I think as an instinct, uh, especially with uh, I guess, non-technical leaders, non-technical CEOs or or whatnot pushing, is to add more of the wrong kind of process, right? Which is like, okay, things are moving too slowly, so let's add additional layers of planning, let's add more KPIs that are not particularly well thought out. And so then what you have is this sort of layers of gloop over the top that distract the team further, it's more meetings, it's more thinking that's going into reporting, but you haven't actually changed the underlying engine. So it doesn't move things faster. But what it does is it makes everybody, uh at least at that senior level, feel like something is being done. So it's nearly like speed theater. It's like, well, if we have enough OKRs and if we have enough cross-functional syncs, and if we have oh, you know, even if we're like, hey, let's let's create a you know a financial bonus incentive structure, then the team will move faster. But it's like, no, like if the engine isn't in good condition, it doesn't matter how hard you mash the accelerator. So uh I'm and for that reason I'm I'm always very wary and skeptical of metrics, which is not because I don't think that metrics and even KPIs can be valuable, but that because they tend to be the tool that is reached for first by the executive level, and usually, not always, but usually they are not the solution to the root cause problem.
SPEAKER_01Yeah, it's one of my one of my metrics though, is if I walk into a room and there's one individual contributor and seven people managing that person, I usually feel like we've gone too far. But I I am totally with you. I wanna I want to wrap this with, and this has been an excellent conversation. I want to wrap it with a question I'm asking everyone because I think it's so important. I've seen it really make a difference. And that is that recovery is one of the key traits of great leaders, the ability to have a bad day and to come in fresh the next morning with optimism and energy. So I want to know how do you recover?
SPEAKER_02I will let you know when I figure it out. It is it it's definitely a work in progress. I I I would not call myself a a recovery guru, but I I think that there are a few things that I think about. Uh one is how I manage my own energy. I've never been a performative grinder, and that's not not a sort of a moral position I've taken. I I simply don't have the stamina to look like I'm working 14 hours a day. Um I say look like because my belief is there are very few people who are actually capable of working 14 hours a day, but there are people who are capable of 14 hours of activity, work-like activity every day. Um, and so I I try to manage the work I do to my energy level. If I am not in the right headspace to do a certain type of task, it it generally doesn't help to force myself to do it because I will be inefficient at that task. Uh so that's one thing, is just being a little bit more forgiving with myself, um, and saying, well, you know, the aim here, and and it becomes particularly true when you are building your own thing, because you know, there's there's no there's nobody who you who you're sort of trying to impress. The the results are the only things that matter, right? And so doing low-value work is is particularly pointless. Um, but the other thing is, again, you know, going back to I guess first principles thinking, which is something I I really try to do, is to say to ask myself, like, why have we got bogged down? Why do I feel that things are not going well? And what can we change about that? Like, what assumption that we've made seems to no longer be correct? And actually, coming back to AI, because that's obviously a big theme here, I I found that tremendously valuable. Uh, and this is perhaps personal, people have different temperaments, but one of the things that happens to me when things are not going well is I have a worry that we've done something the wrong way and that I'm just averting my eyes from it. I'm like, oh, we've made a fundamental error in how we're thinking about this business, oh God, right? And then that can sort of that becomes a kind of gunk in the in the works because you you're trying to build, but you've lost a certain degree of conviction that you're going in the right direction. Because one of the things that we didn't talk about earlier with speed, Keith, is speed is a I mean, speed is a scalar, but what we're really talking about is a vector here, right? You want to be moving fast in the right direction. And if you're not convinced you're going in the right direction, it it tends to play on your mind. Uh so where I found AI really useful is nearly as a thought partner and as a a confidant, where I can say, hey, like I've realized I'm worried that we're doing that we've made a wrong turn here, that this is the wrong decision. And help me ideate my way out of this. And I found that really valuable, both because it is a non-judgmental thought partner, but also going back to the fact that AI allows you to build things very quickly, is it kind of unblocks me where I realize, oh, this thing that I've been carrying that I think was the wrong architectural decision, say, or the wrong business decision, I can spend the next few hours with my clawed code agent and just do it the way that I think it should be done now. Right? So again, coming back to that sort of refactoring question, you can you can refactor your business a lot more quickly. Uh you can refactor your code base a lot more quickly. And so to me, it's it's nearly like a version of writer's block that you solve by just not having an empty page anymore. As I go, I go to my agent and say, here's the thing that's on my mind, help me solve it or help me think it through. And that tends to actually be not only practically useful, but that it it tends to take an emotional weight off of me and help me stop feeling blocked and in that sense, help me recover and and go at the next phase of what we're doing once more.
SPEAKER_01Yeah, and the connection to what you said previously is it's again problem solving your way out of it, is in your case, what what I see the pattern is. Well, you nib, this has been an outstanding conversation. I really appreciate it. I think it's really I've learned a lot, and I I think it's just gonna be fantastic for everyone. Thank you so much for participating.
SPEAKER_02Well, thank you, Kate. It's been an honor being on your show, so I really enjoyed the conversation.
SPEAKER_00Next time, on speed. This becomes like a more important challenge in some way of thinking through in this age of large language models, strong AI, very fast coding agents, and these other sorts of things, how you define and distill the expertise in the organization and both hold that as a cultural value and ensure that that is then reflected and pulled through in the products and the services that you're providing to organizations.
.jpg)