Speed Is a Vector: Yaniv Bernstein on Moving Fast in the Right Direction

Right.

So handling complexity, or when the complexity reaches a certain scale, you need to 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 terms of traits and skills and mindsets and all of that, but also possibly as it relates to technology today?

So 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 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 start-up.

is that you want to, and this might seem counterintuitive, but you want to be taking on technical debt quite aggressively.

And what do I mean by that? I like the technical debt analogy.

I think it has some real validity to how financial debt works.

And 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 don't want to take out predatory high-interest debt, to continue the analogy.

But if you are over-engineering – and I think for someone who comes from an engineering background or a 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.

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 think that's a really big thing that I just need to keep reminding myself.

Sometimes you get the ick.

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 simply be moving too slowly.