Subscribe
Share
Share
Embed
What if the real runway isn't money but learning speed? Anders Fredriksson has spent 20 years building startups and watching teams fail the same way: big plans, slow feedback, zero learning. Named Sweden's most prominent internet entrepreneur in 2007, he's now writing the book on what he calls the Speed methodology — Optimising Startups For Speed Of Iteration.
In this episode, we dig into why backlogs are dead weight, why pull requests are your biggest bottleneck, and why end-to-end ownership changes everything. Anders shares how his team went from deploying every two weeks to 30 deploys per day, why the one metric that matters replaces your entire planning process, and what happens when AI agents take over the coding while engineers build the machine that builds the machine.
GUEST
Anders Fredriksson - Serial Entrepreneur & Author of "Speed: Optimizing Startups for Speed of Iteration"
Anders has 20+ years of startup experience, from being named Sweden's most prominent internet entrepreneur in 2007 to now building Staer.ai, where the team writes virtually no code by hand. He's spent his career figuring out why startups move too slow and what to do about it.
Find Anders:
LinkedIn: https://www.linkedin.com/in/andersfredriksson/
TIMESTAMPS
00:00 Introduction and Guest Welcome
01:00 The Speed Hypothesis: Small Steps Beat Big Plans
05:00 Implementing Speed at Ansen
09:00 No Backlog, No Sprints — Daily Experiments Instead
11:00 From Two-Week Sprints to 30 Deploys Per Day
14:00 When Speed Doesn't Apply: Known vs Unknown Solutions
19:00 Runway Is Learning Speed, Not Money
25:00 Generalists Win in the Age of AI
30:30 What's Left for Engineers When AI Writes the Code
36:00 Agents Working Toward Outcomes, Not Just Outputs
39:00 The Biggest Pushback: Killing Pull Requests
47:00 Top Tools and Practices: Monorepo, TypeScript, CI/CD
54:00 From Crashed Startups to Writing the Book on Speed
59:00 One Thing You Can Do Tomorrow Morning
KEY TAKEAWAYS
1. Optimize for learning speed, not runway — if you're not learning fast enough, money won't save you. The build-measure-learn loop is only as good as your cycle time.
2. Replace backlogs with a One Metric That Matters (OMTM) — a living, short-term metric that every person in the company can impact daily. Change it frequently as you learn.
3. End-to-end ownership means engineers own the full loop — from understanding the customer problem to shipping to production and measuring impact. No handoffs to product managers.
4. Pull requests are your biggest bottleneck — asynchronous code reviews kill deployment speed. Replace them with synchronous pair programming or, with senior teams, skip reviews entirely.
5. The engineer's new job is building the machine that builds the machine — maintaining agent infrastructure, removing friction, and ensuring AI can verify its own work.
6. Do the bottleneck workshop — map every step from feature idea to production, multiply frequency by time, and fix the biggest number first.
RESOURCES MENTIONED
- "Speed: Optimizing Startups for Speed of Iteration" by Anders Fredriksson (upcoming book)
- Lean Startup by Eric Ries (build-measure-learn loop)
- Nx (monorepo orchestration tool)
- Blacksmith (fast CI runner)
- Kubernetes (container orchestration)
CONNECT WITH PRODUCT ENGINEERS
Host: Peppe Silletti
Website: https://productengineers.com
LinkedIn: https://www.linkedin.com/company/product-engineers
SUPPORT THE SHOW
If this episode made you rethink how fast your team actually moves, share it with a founder or engineer who's stuck in two-week sprint cycles. Drop a comment below with your biggest takeaway.
This is a public episode. If you would like to discuss this with other subscribers or get access to bonus episodes, visit
Product Engineers is the podcast about the convergence of product and engineering in the AI era: what's breaking, what's working, and the craft of doing both well.
What are startups missing out by not following this methodology? You'll still run out of money, but what you're really doing is that you're running out of learning. You're not learning fast enough.
There is no backlog anymore. Every day, instead of talking about features, you talk about experiments. What do we have to experiment about today? What's our hypothesis?
In- instead of planning all the things that you need to do, it's better to not plan the whole way and just plan the next step, and then check, like, "Oh, did we get closer?"
We went from, like, one, one deploy every two weeks to production to having 30 deploys per day. If 98% of the code is written by AI, what, what's left of me? What I'm going to do now?
We're not doing basically any coding at all ourselves. It's 100% with AI. Welcome to the Product Engineers podcast, where I'm unpacking the convergence of product and engineering roles in tech.
Anders Fredriksson has been building startups for over 20 years.
He scaled Arrival Guides to 50 million monthly visitors, had his AI company X acquired, and was named Sweden's most prominent internet entrepreneur back in 2007.
We get into this idea of the iteration factory, that the real job of an engineering team isn't really building the product, but building the machine that builds the product. Once you see it that way, everything changes.
Planning goes out of the window, replaced by daily experiments. The backlog disappears, and the question stops being, "What should we build next?" and becomes, "What do we need to learn next?"
Now, take that mindset and add AI agents to the mix, and things get really, really interesting. His team at Stare AI wrote zero code themselves. It's all agents, which honestly, I'm still kind of processing.
He also walks you through a simple exercise to find the first bottleneck in your own machine. By the end, you'll either want to delete your backlog, or you'll find we lost our minds. Maybe both. Enjoy.
Welcome to the show, Anders. I'm glad to have you here. Thank you so much for having me.
So you've been working in, in the inst- industry, been building startups for the last 20 years, and you're also in the process of writing a book called Speed: Optimizing Startups for Speed of Iteration, uh, where you're really dumping everything that you learn and the, this new methodology that we're gonna talk about today.
And now you're working at a startup called Stare.ai, where I think most engineering teams would find it either inspiring or terrifying the way you work in there.
But I want to start before any of that, before the book, before Stare.ai. Really take me back to that moment that triggered you to think startups are doing it all wrong.
Yeah, so it really started with a lot of frustrating moments with, uh, past team members. I couldn't really explain to people why I thought something needed to be done a certain way.
Um, it was because I didn't have the terminology for the things that I thought were, were important.
But so the theory behind what I've sought to figure out was this, that, you know, if you have a known problem with a best
possible unknown solution, like there is an unknown solution somewhere, but you don't know where it is or, or what it is. You just have an idea of like, "Okay, yeah, it's somewhere over there."
So the hypothesis with speed is that in- instead of planning all the things that you need to do to get to that unknown place,
it's actually better to not plan the whole way and just plan the next step, and then check like, "Oh, did we get closer?" And then plan the next step, "Oh, did we d- get closer?" So like you do...
A- a- and the faster that you can do those small, small steps, the higher the likelihood is that you actually end up finding the, the best solution.
So instead of like thinking of a s- single solution that you think, "Okay, this is what we need to do," you essentially create a system or you create a machine that allows you to try all, test all possible combinations of solutions.
And then if there's only one left, then that must be the best one.
But so to answer your question, the, the problems that I ran into was like, you know, I was having discussions with colleagues in my, in my companies and, you know, they were asking me like, "Oh, why do I need to build this?"
And back then, my answer was like, "Ah, shut up, just do it." And obviously not a very good way of, of communicating. Um, so that led to a lot of frustration with the p- people working with me.
It led to frustrations from, from me and, and so on. So yeah, so that...
There were a lot of those situations that just kept on coming back and back, and I, when I couldn't explain to people why s- why doing something a certain way was important because when you-- Maybe if you just looked at the actual thing that I was suggesting that we, that we do, like in the small context of that, it doesn't really make sense.
But then when you, if you think about it from a speed of iteration perspective, then it, it does make sense. Yeah. So what are startups missing out by not following this methodology?
I think they're missing out on a lot of opportunities to figuring out, like, if there's actually a product or, uh, there is a business for the given thing that you want to solve.
Like figuring that out quickly will mean less time wasted, less money burned, and, and so on.
And also creating the opportunities of actually finding where that, where, where the business is i- in the thing that you're trying to do. So if you, if you start with a
big plan of like, "We're going to build this specific thing,"
then it might be that you shoot yourself in the foot and end up wasting a lot of time building that full thing end, end to end where it works, and then like, oh...
I mean, this is all, like, pretty basic stuff if, if you... Or comes back to the whole, you know, Eric Ries lean startup approach where, you know, you just need to know the next...
Like, there, there's a build, measure, learn loop, and you need to measure and you need to learn. And like, the faster you can go around that cycle, the, the faster you will succeed or fail. Could you describe, like,
what a day looked like in, in one of the companies that you worked on in where did you manage to kind of bring this methodology in? Hmm.
With my other startup that I'm working with called Ansend, we implemented the methodology from the start of the company essentially, and it, it really helps to focus the team
on a particular way of working, and you can really solve problems much, much quicker, um, than what you would with a sort of normal standardized approach to, to, like, how you build companies. One of the core
principles in this methodology is that everybody in the company owns end to end. And what that means is that you don't have a super hierarchical organization where, you know, you have a...
Somebody decides, you know, "Oh yeah, we have to build this," and then there's a product manager that says, "Okay, that will be implemented with the, these five features."
And then you have code monk engineers just implementing those features and they're like, "Oh yep, I, I did the thing." So the opposite is instead that you, you define so what's called a one metric that matters that
aligns the direction of everybody in the company. So and, and the direction in this context is so you can view people in a company, you can view them as a... Everybody in the company could be seen as a vector.
So you have both a, a direction and magnitude, and the, the total vector for the, for the business is that you just add up all the vectors of all the individual contributors in the company.
And like, if the direction is not aligned of those, then, like, your net, uh, vector becomes zero.
Or like you have somebody that is, you know, pulling in the complete opposite direction, then it doesn't matter if everybody else is aligned, then that becomes a problem.
So the, the one metric that matters becomes the compass directing the company to like, "Yeah, we believe that the best solution that we're trying to find is in this direction."
And the connection to the end-to-end responsibility is that everybody in the company can then come up with ideas that they believe will move that metric and, and they have the authority to implement that end to end.
It's like you implement it end to end, and you push that code to production, and it runs, and you measure, and you see did it move in the right direction or not?
If it doesn't, then you roll it back, or you improve it, or, you know, whatever. But you, you really focus on, on getting it out there in the hands of the customers as quickly as possible. Um, so yeah.
And, and it could also be like a, a, a very, very basic things like instead of implementing a feature, um,
one time and then pushing it out to the co- to production and then testing it there, like having customers test it, there's also a lot of iterations that can happen locally.
It's like as a developer is developing, if you own end to end, you have to understand, like, what is the customer's need? Um, what is, what is the benefit of this thing that you're, you're trying to do?
You work on your developer machine and you, um, experience the pains that a user would experience. So there's a, there's a lot of things in there that, like, it, it
doesn't necessarily, like, solve the, the problem itself. It's, it's just a, it's just a way of, like, how you build the, the machine that builds the machine in a way. Like,
I remember from the conversation I had with Kevin, who is the CEO of Ansend, so he can- he kind of described the, what are the practices that, uh, happen day, day by day.
So for example, he told me that there is no backlog anymore, so the b- they removed comp- the backlog completely. Every day, instead of talking about features, you talk about experiments.
So you meet in the morning, try to understand, "Okay, what do we have to experiment about today? What, what's our hypothesis that we need to test?" And then you ship some, some to production and see how it works out.
There are no sprints in terms of like a Scrum, so no Scrum. And actually, there was one thing that stuck with me wa- which was the concept of daily sprints. Yeah. So that was very interesting.
So, you know, someone listening right now may think maybe even like a software engineer can, can think there is no structure at all. Like, there's no process. Everything seems a bit more like a left to, to,
to chance a bit, right? Yeah. 'Cause you're kind of bet- betting about what's gonna work or not. What would you say to, to these people?
Yeah, I mean, it is true in, in some sense, and it-- I mean, this end-to-end responsibility definitely puts a lot more weight on, on each developer's shoulder, that now you have to do the scary thing and actually talk to the customer yourself.
Like, you can't just have the salespeople talk to the customer or the product manager talk to the customer. Like, you should be doing that too. Um, but I, I think, like, one, maybe one example that could
help explain a little bit the, the difference, 'cause there's still sort of structure in terms of that you're-- you, you-- about the thing that you want to improve. So with Ansen, so when we...
Or actually, so, so before Ansen, there was-- I worked with Kevin at a, at his, at the previous company called Zaplify. Um,
and when I started working with them, that's really where I s- I first applied the, the methodology, and they're a pretty big team. Um,
they were d- they were doing, like, you know, classic two-week sprints with a, you know, backlog and, and, and so on. And after the two weeks, they did a deploy and, you know, so on.
Pretty, pretty standard Scrum, uh, Scrum approach.
They also had, like, a separate, like, the, the repo, the, the code repo was separate, so, like, there's, there was a lot of things that w- that were slow to develop and, and so on.
Um, but I mean, still, they were, they were releasing, like, you know, they were releasing to production every once every two weeks. So the...
And after the change, and I mean, it, the, it's a lot, a lot of the methodology is actually of, like, how you change your whole coding setup, um, to be able to have a full end-to-end replica of production on each developer's machine.
So you run the full system on your machine, and
then we don't do PRs, we don't do code reviews, or I should say we don't do asynchronous code reviews, which a PR is, where you, like, have to interrupt somebody else's flow and so on, because it's actually much slower.
Um, so after everything was implemented there, we... So we went from, like, one, one deploy every two weeks to production to having 30 deploys per day. Whoa. And
the-- Some people might be scared about like, "Oh, shit, like, what? How does that work? Like, that's crazy. Like, how can you do... How can you verify that everything works?" And, uh, and so on.
And the interesting thing is that when, when you get there and you have continuous deployment, the cost of an error becomes directly proportional to how fast it is to roll back. So, like,
if you can roll back or, like, if you can fix a bug in production in seconds, like, does it really matter if you accidentally push a bug? Like, maybe not.
I mean, as, as long as you can detect that there actually was a bug, of course.
But, so, like, this whole approach with, um, with this is also dependent on, like, the, the type of system that you're building and really looking at the, the cost impact of a bug reaching production.
Like, if you have a...
I, I worked with another client that did, like, a, um, solar power plant, like the operating system for a solar power plant, where developers would need to have-- they, they would have to go out to the actual physical plant to the little computer that was there with a USB stick and then install the update of the code.
Having bug in that code is extremely expensive. So it's, it's all relative, right? But then if you think about doing this type of approach, then that can define your architecture.
So what we did with the solar power plant, we, was that we, we changed the way that they would deploy code to be able to have so that the, the, the power plant was able to automatically update if there was new code.
Still, I mean, it, it wouldn't be 30 deploys per day for that type of system, but it was... I mean, they did, like, one deploy per six months there, and we got it down to, I think, one deploy every one to three days.
So the n- the number of improvements or the number of possible solutions that you can test to see that if it solves your problem, like, it increases by the, by your speed of deployment. Is there
one situation in your mind where you would never use this methodology? If you have a
known solution that you just need to implement, then there's really not a lot of need for this approach. It's more about when you're working with the unknown.
So, like, you have a hypothesis of something that maybe solves the problem, but you're not sure, then it's a, a good fit. But I mean, there's a, there's a lot of things that are already solved.
Like, you don't need to experiment your way of how to have a database functioning in your system. Like, you don't...
I mean, maybe you could experiment having different types of databases, like if you wanna optimize for performance or, or whatever.
But, like, for those types of problems, like, it, it, I, I don't think it makes a lot of sense. I think all of this has changed dramatically in just the past couple of months. When,
when you think about, like, oh, what does this look like if humans are not doing the actual coding? Then it becomes even more important that you have a clear direction, because now code doesn't cost anything.
Like, you can write hundreds of thousands of lines of code without blinking, which means that you can essentially run super, super fast in the potentially wrong direction.
So when you say that this is not a, like a-- It wouldn't work with known solutions. So I think in that case, probably we don't even need to, like, building something from scratch, right?
Because you already have some, maybe some products, some libraries that do the job very well, have been tested. So i-in that case, it's just about integrating those solutions into the system.
And for, for what I'm understanding, this approach will be always useful when you are facing, let's say, product problems or, I mean, or, or even technical problems that can affect the, the product in some way.
Does that make sense? Yeah. So like, if you have a user-facing system and you don't know how the user is going to behave,
like you may understand their pain, you may understand their problem, um, but you don't know if the-- your solution to the problem actually helps them. 'Cause they're-- I mean, it's a pretty classical thing.
I've made this mistake so many times where like, "Oh, I have this perfect system that, like, literally solves the problem that they've defined,"
but it still doesn't work because the users don't understand how to use the product.
So I think in tho-in those scenarios, that's when it really, really helps to have a super quick feedback loop from, you know, you, you build something, you test a version of like whatever, have the users actually use it,
and then you test again. You've always had like UX researchers trying to do like, "Okay, what is a faster way of doing this?"
Like, "Oh, maybe we just have these written play cards," where you like ha- sit down with the user doing user interviews, and you have them like, "Oh, click here," and then you just show them a new paper board of, of what happens when they click there.
So like you do this kind of thing, but now that it's-- it, it-- That, that model was sort of defined when code was expensive and like building the thing was expensive and took time.
Now you can build all that like in a minute or two minutes or like... It, it-- It's very, very easy to like actually just build the thing that you want to test. So do startups
are wrong about focusing on their runaway, in this case, in this case, like how much money they have left? So, I mean, we-- If you, if you move slow or you, you have this plan and you execute that plan,
and if you don't learn anything during that, during the path of like building whatever it is you're building, and you deploy it, and it doesn't work,
then like you're gonna run out of money, and like you're not gonna be able to solve the problem, and your company dies. But there's another way of, of, of looking at it, is that
i-in order to solve your problem, you need to learn y- as fast as possible. So you need to optimize for, for your learning speed, and startups today, instead of like...
I mean, technically you'll still run out of mo-out of money, but what you're really d-really is doing is that you're, you're running out of your l- or, or the learning, so you're not learning fast enough.
I, I think that that's a very
interesting way of seeing it, 'cause yeah, when you think about learning and not just the money side, then you can focus on building all your, let's say, processes or practices around learning faster and not like being scared about like this, this deadline, the future.
Another thing I was thinking is that, so going back a bit to the, to the practical side of speed, when you are releasing so many times a day and you're experimenting so much every day, how, how do you measure impact?
So it start, it really starts with the one metric that matters, and if you have that metric and it, it, it... The way I define it is that it needs to be something that is im-impactable in a sort of daily or hourly basis.
So it can't be like something like, you know, revenue or, you know, some, some lagging metric. It needs to be a very short-term metric. So
as a developer, when you sit and, and think about, "Okay, so what should I do now?" You look at the metric, you look at your system, and you're like, "Okay, what can I do?" Like, "Oh, maybe I can...
You know, if I, if I change, uh, this thing," or like, "Oh, if, if I make this button green, then I think that people will click on it, and I think that that will impact the, the metric," whatever it is.
Like, let's say it's, you know, conversion rate or, I don't know, so something like that. Then
if-- When you ask yourself, "Will this thing that I'm about to do, will this, will this either impact our one metric that matters or improve the speed of iteration of our system?"
If the question is yes to either of those, then you do it.
If it's no, then for the, for the first question, like with the will this impact the one metric that matters, so if the answer is no, then you have, uh, two options again.
Either you don't do the thing, or you can also change the metric. So like it, the, the one metric that matters is something that is a living thing. You don't...
I mean, in the perfect world, you will, you would define the absolute perfect metric, and you just use that forever.
But that is very, very difficult to do, and it's much better to have a bad metric to start with and change it frequently as you learn. Like, "Oh, this didn't really help."
Like, or we've-- At Ansen, we've done that like 100 times, in just changing what, what it is to where, what, what our one metric is. So it's really that... I mean, it, it becomes a lot simpler in a way from a
developer perspective. Instead of like picking a task from a backlog, you can just come up with ideas yourself.
Or if you don't have ideas, then maybe in the, like Kevin was talking about with the daily sprint or like an i-ideas meeting where you generate a bunch of ideas for the team, um, then you can share, and then that sparks new ideas from each of the developers or each of the people in the company, um, and so on.
So then like you, you can get input that way as well if you, if you don't, if you're not super creative. How do you scale this kind of experimentation as the company grow? Well, since the
employee owns end-to-end, it's up to the employee to track the things that they have, that they are doing, that it has the impact that it's supposed to have.
Uh, in a few of the places where I've implemented this, we, we tried to, to have like a super structured experiment dashboard with, you know, tracking the experiments over time and like having this, you know, statistical probability of that it was actually this experiment that did it.
What I found is that it's, it doesn't actually matter what contributed e-exactly to the metric improving if it's improving.
If you then change something and you're like, "Oh, let's delete this thing that I don't think anybody uses that," then you'll see directly that, oh shit, now our, our metric dropped. Like, "Oh, maybe what did we do?"
Like, "Oh, we... I removed this thing. Could that be it?" And then you put it back and you're like, "Oh, now it goes up again."
I already hear some people thinking, "Yes, but this in my company wouldn't work because I have like 100 engineers. If everyone is doing this, then it's gonna be complete chaos, right?" So
how do you think this is gonna work when company also grow in size and there is more coordination, and how, how this can look like?
Or do you think this is something that it's only, let's say, useful for, for startups that leap in-into the unknown? I don't think this is easily applicable for every company. Absolutely not.
Especially if you already have an organizational structure where you have separate teams doing separate things, working on completely separate stuff.
It could still work like within that separate group doing this approach internally. So you can have like the same approach internally within that team.
But if you really want to have this sort of full impact way, then you have to design the whole organization around it. So it determines who, who do you hire.
Like, you shouldn't hire somebody that only knows how to code Android apps. Like, you shouldn't hire somebody that's super specialized. So this approach goes well in hand with the trends with AI as well, is that
we're-- We've been in, for a very long time, we've been in a world of specialists where like companies hire specialists of somebody that is super good at this one thing.
I think we're going away from that and moving into a world where generalists are gonna win because a generalist can fill in any gap they have with AI.
And like, if you really wanted to move to this methodology from a existing company where you have super structured, uh, teams that only do specific things, then I'd recommend to sort of have everybody start slowly to move to full stack by adding AI as sort of the fill in the gap layer.
Yeah. It makes me think about what people usually say, usually people that go a bit against AI, that AI can only take you 80% of the way, and that it's only 20% that counts where you actually can make a difference.
But to be honest, if we can, if we can get 80% in a lot of our activities and we can give 100% in one, I think it's still, still good, right? Yeah. It's not so...
I think a generalist can get to 80% pretty quickly right now. But I mean, like, yeah, no, totally. Like now in, in Atstare, the, the, the new startup, we're not doing basically any coding at all ourselves.
Like it's 100% with AI, and it's like, it's mind-boggling even to me. Like I've been coding my whole life, and like I'm pretty good at it, I like to think.
Um, but with the experience of a, of an experienced team or an experienced engineer, then you can direct it to say like, "Oh, use-- When you solve the problem, use this, this, and this, and this, and this."
And like, "And use them in this way."
And I like, "Oh, maybe could we like if, if we, if we do this and this thing in some other way, like can we-- Maybe that can be a, a new possible solution to how, how to solve a given problem."
And that's what we've been doing with Atstare now, and it's, it's just incredible how fast we can move. Do you have a team of generalists mainly? The team is-
Consists of very experienced startup founders, where everybody in the company pretty much has founded and sold companies previously.
So everybody knows that in a startup, especially early stages of a startup, even though you may have your own sort of core expertise, in a startup when you're like, I mean, we're 11 people now.
A company that size, you just do what needs to get done. Like, there's no role, there's no, like, like, you, you just- there's something that needs to get done, then somebody gets on it. It's like you, you...
I think the expe- experience comes from that, so even though in our team now we have a lot of really, like, super, super talented computer vision specialists,
but they're also very good general engineers, and like super good at math. They're, they're math PhDs and, and so on. Um, but they just know how to solve problems.
So it's like you- most of the things, like with experience, you can apply it as a generalist.
And then especially with the assistance of having a second brain with an AI that does have all the specialist knowledge in the world of everything, then you,
you just go ahead and, and build what it is that you need to build. And the benefit of not being a specialist of, like when you're building something, like let's say you- if you were a front-end engineer specialist,
then when you're asking the AI to do something, you're gonna have opinions on like, "Oh no, you have to use this specific package for this specific thing," because I mean, we have opinions. But does it really matter now?
Like if you're not gonna look at the code, if you're not gonna do it, like, does it matter how the- what front-end package is used, what, like programming language is, is used for, for, for a particular thing?
Yeah, maybe not. I mean, the- there are some speed implications of like in terms of getting the AI to making it easier for the AI to get it right. But like besides that, uh, I don't think it, it matters as much anymore.
When you don't look at code anymore, how do you make sure that the internal quality is still good?
I don't think it's fully solved yet, but, um, the, the current approach that we're using now is that you ensure that the AI can always, or the agent can always validate and verify that the thing they were supposed to solve was solved.
So the whole process as a, as a developer working or like as an engineer
person in a startup working, it becomes much more about defining the, uh, like the PRD or like, you know, de- defining the, the thing, what it's supposed to do, and
giving the, uh, setting up your system in a way so that the agent can actually verify that it was done in that particular way or like that it actually solved the problem. 'Cause I mean, I do that.
I still have that problem daily, whereas the agent comes back, you know, like, "No, yeah, everything's done now. It works." And then I test it 'cause I'm still responsible front to end.
Like even though my agent is coding it, I'm still responsible, so I test the actual thing. I don't have to look at the code, but I test the thing, and then something doesn't work.
Then you come back to the agent like, "Oh, what do you mean, like it doesn't work?" And then it says the classic like, "Oh, you're absolutely right. I- my mistake."
[chuckles] So still happens a lot, but I think we're getting better and better, especially in terms of tooling, to be able to make the agent able to figure out that it made a mistake.
I'm thinking an, an engineer listening to this may think, "Well, now if 98% of the code is written by AI, w- what's left of me? Am, am I becoming a, like a prompt engineer? What I'm going to do now?" I don't really
know, but the way I'm thinking of it is that there's still a lot of plumbing to do. So I sort of think that the job of the engineers becomes to maintain and build the machine that builds the machine.
So your agents becomes the machine, and your engineers are the ones that oil the cogwheels, so to say, and removing bottlenecks and friction points for the agents so that they can operate properly.
And one of those things is being able to verify that the thing they were working on actually worked. It's like what- how do they do that? Like is there- what is it they're building? Can they actually see the thing?
Like, uh, is it possible that they see it? Can they have a fully running lab in the cloud that they can run in if you don't wanna run it on your local host?
Like, can they run everything in your full system to be able to val- validate that it works end to end? So I, I think there's still a lot of work to be done for that. Like you can compare it with Tesla, for instance.
So Tesla, they have 100,000 people working. Um, a lot of them, they have their own chores, but they, they...
As I was doing research for the book, it turned out that they actually, both Tesla and SpaceX and all the Musk companies already operate with a very similar model to this, uh, where they're extremely metrics driven.
There's a super flat organization. Anybody in the team can work on anything they, they want. You still have your chores that needs to get done, um, but they work in, in this particular way.
And at Tesla, they have like 100,000 people in their different factories, but it's robots that are building all the cars.
But what they're doing every day is that they're going, not everybody, but like a lot of people, what they're doing is that they- Go look at a monitor in the morning to see, like, okay, what is our current bottleneck?
Like, this is our metric, and their AI tells them that, you know, there's a possibility to increase the, the paint mixing time for the red color for this thing. And then, you know, a- they go as mobs, so they don't...
Sort of like pair programming, but with, say, four people or so. They go to that monitor at a particular station, and somebody says, "Oh, I have an idea for how we could do to implement a faster color mixing."
What they then do is that they actually go to the physical robot, take that robot offline, reprograms it with the new color mixing procedure that they came up with,
deploy it back into the production pipeline, and they see the results, measurements like, oh, was it faster? Was it better? And so on.
If it was better, then it's automatically d- deployed to all the other robots doing the same thing. If it wasn't, then they pull it back. So it's a very, very similar approach, and,
and I think this is the, this is the type of tasks that, at least for now, that we engineers can still h- help out a lot with. And then for every abstraction layer, like, the stuff you can do expands.
So I sort of see it as that, where like, sure, we might not be doing the exact same things, like writing the same lines of code, but this is just another abstraction layer, and I'm, I'm very convinced that it will just continue in the same path, that it will sort of explode the possibilities of what we can do.
I mean, if Tesla is doing it with hardware, I think we have no excuse not to do it with software- Exactly... which is so cheap to do it now, right?
And I, I remember from our previous conversation, you mentioned something on the line that you also use agents into Stairs.ai in your startups where you get a building now
to also work towards outcomes, not only to build the, the outputs of, of the system, right? So you have these metrics, and you're working with agents to work to- towards these metrics. So how does that look like?
Yeah, I mean, we haven't fully implemented everything [chuckles] around that yet, but I think it's definitely a possibility of, like, when you have a,
when you have a structured system such as agents are, even though they're probabilistic, they're relatively structured. If you could have a way to show
the OMTM in a good way to the agents, then they can themselves run a, you know, Ralph loop or [chuckles] whatever.
You know, they run some kind of loop where they can check the metric, they can come up with ideas, implement all of them,
and try them all in parallel perhaps, or like one at a time and see like, oh, which one was best, what worked, what didn't work,
and then just reason around that, and then there could be like a self-improving, self-improving thing for the, for the, for the product.
I think we're not quite there yet in terms of autonomy, but I mean, if you look at OpenClaw and things like that, I, I don't think we're very far off.
I just saw an interview with the Stripe CEO, and he was saying that, yeah, we're, we're, we're in the singularity now, and I can't believe that. Like, I, I think that
sort of in the same way as that when a war starts, like when, when a war starts, it's not defined until after the war has ended.
It's like when you're in it, like the, the start date is not set, and I think it's a similar way for like singularity, where
I think there's a high probability that we're in the singularity, s- start of singularity right now. Which is very crazy and exciting and scary at the same time.
[chuckles] I-- Like I, I have kids, and I really don't know like when they're gonna grow. Now they are two years old. But when they're gonna be like teenagers, I don't know things are gonna look like, right?
It's, it's, it's very weird. Like for the first time, before me it was like, "Oh yeah, I can become a doctor or a lawyer," you know, all the-- maybe an astronaut. May- maybe astronauts will be still useful for something.
[chuckles] Yeah. But yeah, it's ex- it's exciting for sure. Like, I'm having so much fun right now with AI compared to the pre-AI e- era. But yeah, for, for the future, it's, it's a complete unknown. Like, who knows?
Yeah. No, I, I definitely have those thoughts as well. But ag- again, like if we look at history, for every major shift that has happened, like it, it will come with change,
but it has always-- So far in history, it's always created more opportunities. So it's scary now because we don't know what those opportunities are because they have not yet been defined.
But like, if you're, if you're willing to sort of hang on to that feeling of not knowing and being excited about that, then, then I think the, the future is super bright. So another thing I was thinking is
speed, this methodology. If you could remember one conversation with someone that really pushed back towards this using it. I would say the biggest hurdle
is probably when I tell them that you are no longer going to use pull requests. The way I look at pull requests is that it's a, um, I mean, as it is, it's a r- code review process
But from an efficiency standpoint, it's an asynchronous code review process. So what that means is that developer A does the work, they create the PR,
and then they gotta forget about what they were doing, and they switch to a new task, um, wait for somebody, or they assign somebody to, like developer B, to review it.
That developer is busy with something else, so they wait for quite some time to... Let's say they wait, uh, you know, best case scenario, they wait 15 minutes until they see it, and then they go review it.
More likely it would be like a day or, you know, in, in most organizations, there's a lot of PRs waiting to be approved. Um, but they would go there and check out developer A's work.
Developer A has now started working on something else, um, and so on. Uh, developer B makes some comments on like, "Oh, why did we do it this?" Or, "You should change this and that," and blah, blah, blah.
Or there's a review agent or whatever doing the, the reviewing. But so i- in the manual human approach, the...
Not only does developer B gets interrupted in their work, developer A also has to do the sort of mental load of switching between th- two things.
I guess both, both people do- need to do the, the context switching, which is expensive. Like it's cognitively expensive for the human. There's a time delay of when this code actually gets into production,
and so on. And like, I'm not at all against code reviews, but there's a better way of doing it, and the better way of doing code reviews is synchronous code reviews, where essentially you do pair programming. So
when you're doing pair programming, you're reviewing the code as you go. So you're two people sitting there doing it, and then when you're done, you're like, "Okay, great. This is good." Then you can push it.
So there's... And like the, the main pushback comes like, "Oh, why would you do... That's like so inefficient to have two people sitting on the same thing."
But like if you look at the stats of, you know, people that are doing this, the, the quality of the output is a lot better. If you have a senior team, like maybe you don't need to pair program all the time.
But like if you have... But in the same way, like if you have a senior team, you don't need code reviews. So like why do you keep the PRs if you don't, don't want the other thing?
And, and at the root of it, it goes back to the whole approach of the thing of where you, like, you want to optimize the time it takes from coming up with a feature until that feature is in production.
And if you want to minimize that time, it turns out that pull requests is one of the biggest bottlenecks in that process. So I, I...
One of the things that I also do with the teams when, when they have objections around this is that I've done a workshop where we do a, a bottleneck workshop for that exact process.
And this is something the listeners can, can do for themselves. You can create a, a simple spreadsheet, um, and you think about the process of coming up with a feature idea
to having that idea in the hands of a customer in production. Like what are all the steps that need to happen in there? And then, so you have like... You write down all the steps as rows,
and then for each of the different steps, you write, um, how frequently, uh, like how many times does this step need to happen, and then how long does this step take,
and then how many, like how many developers do you have in your team, and how many of them would, would do this, do this thing times the frequency of, of what is done.
So for instance, as an example, you can have like the, uh, I don't know, save to see latency is something that I talk about sometimes, where a developer saves... Wri- writes a code change in a file,
and you, you save the file. Like how long does it take until you can see that change? Like if it's a web app, you can see that change in the web app. Most modern development, you'd have a hot road...
h- hot reload dev server that makes it instant. But like in some teams that I've worked with, you know, they have a...
They don't have a monorepo, so they have, uh, separate Git repositories with PR processes, which means that if a developer makes a file change in a, um, in a library, in a separate repo
that they then need to import to the, like to the main product or whatever, like the, the time from s- save to see the change w- is like days, which is insane. Yeah.
Going through that thought exercise or just writing it down with the bottlenecks that you have and calculating the frequency, i- instead of thinking that the bottleneck is the four-hour build
that is just massive, but if that is one thing that only happens once every X number of, I don't know, you know, days, then maybe that's not a big bottleneck.
Whereas you have something like improving the time it takes, make the file change to see the change, changing that from 30 seconds to 100 milliseconds Has an enormous impact.
Because if you do that 100 times per day and you have 100 developers, the amount of time that you save is just enormous. Now with AI, you can
write code very fast, so that's even code is the bottleneck, so all the previous bottlenecks is like a, a multiplier, right? Yeah.
So if you're, you're spitting out PRs so fast and then it takes so long to review all of them, and I think it's completely madness, you know? Yeah.
But e- but even so in like the, in the sort of save to see latency problem, if you apply that to agents, it's even more so, I think.
Because the agents don't have eyes in the same way that we do where we, you know, or not all of them at least, where you have a browser window that's open that using hot reload that they, that you can see directly a- and so on.
So you need to optimize for that. Like, when they make a code change, how quickly can they see they made a mistake? And that's where, like, things like, you know, okay, what language do we choose to develop in?
Like, what language should the model use? 'Cause, like, do you have type safety? Can you do type checking that is, makes the agent be really fast at discovering they made a mistake? So all of...
Like, once you start defining, like, what it is that you're trying to optimize for, it, it becomes sort of self-explanatory of what, what you need to work on to fix.
Cursor just released a new feature where they can try things on the browser and make videos of explaining what the change was or- Oh, yeah. Yeah...
so I think c- maybe this could be like a step towards what you say, like even making it- Totally, yeah... making the process even better. Cool. So just staying in, in, in, into topic about tooling and practices,
what are the, let's say, top five tools and practices that you like to use to make the speed methodology work? So if you would've asked me four months ago,
my answers would've been, like, super strict of, like, "You have to do exactly this." Now it's like, uh, I'm not so sure anymore it matters. But l- if we... The, the,
the thing that I still think matters is having all of your code in a monorepo. It doesn't matter too much, I think, about, like, the, like, your choice of a monorepo tool. I've always previously recommended to use Nx,
which I think is a, it's an incredible, uh, incredible orchestration tool for monorepos of, like, get where you get the, the whole dependency graph. They've, they've sort of solved that.
But lately with agents, um, it's not as commonly used, so agents often make mistakes of, like, not implementing the thing properly for Nx and so on. Maybe that's solved now with, like, skills and stuff.
But, um, so that's, but that's one. But, but something in your... You should have a monorepo.
You should have something in your monorepo that helps you easily execute tasks or stuff across all your different apps and libraries. Having separate libraries for things is, I think, super, super useful.
But you shouldn't have to build stuff in order t- for to use it in your app.
So, like, the whole dependency of, like, being able to do that in a, in a, in a fast, efficient way during development I think is very important. I, I think TypeScript is still a very good choice of a...
Like, if you wanna select a particular framework for a part- particular language or, or so, I think TypeScript is a very strong contender. But again, like, now with agents, maybe it doesn't matter.
There, there are certain things that I still think matters, like selecting something where it's very easy to have full stack type safety I think makes it easier for the agents to make fewer mistakes.
Something like a tRPC, those frameworks there. Yeah, tRPC or, like, I've been using Convex, um, lately. Okay. But I think there's a lot of different ways that, that you can do it.
But at the same time now with Stair, 'cause we're doing, you know, some pretty broad and advanced stuff running on machines or, like, small NVIDIA Jetson machines in
warehouses, on robots or whatever, it doesn't really matter. So there we have code in TypeScript, in Go, in C++,
and, like, whatever it is that we n- or, and Python of course, and, like, whatever it is that solves the problem the best. So I think that, that should always come first, like use the best tool for the job,
but then take into consideration of, like, okay, how does this impact agents or humans making it easier for themselves to discover problems early?
Um- And most of the times this, the, the, the answer is very similar, right? Yeah. What works for humans works for agents, right? Now I've been thinking a lot about, like, agents as a junior developer.
Like, how, how do you, how do you help a junior developer be as efficient as possible and make as few mistakes as possible?
Like, if you can i- if it's clear to them when they have succeeded, and when it's clear to them when they have failed or, like, the, if something is wrong, then that developer will be more likely to be successful.
So you said monorepos, TypeScripts. Anything else in terms of like, you know, like techniques, processes? I've been using Blacksmith lately for a CI runner, and it's incredibly fast.
It's, like, much, much faster than standard GitHub workers, and it's very simple to, to implement. But I, I think having, like, a, a good proper CI/CD in place is very important. You should not-
I, I don't think you should build, do builds on your local machines because then that creates problems. So CI should be responsible for building images or whatever it is. I think Docker is fantastic, like having your--
like having full parity between prod and development is very, very crucial so that you don't like have some custom way things is set up in, in prod.
Um, with the difference being that, you know, in dev you want to run dev servers. So there's some people that still promote using Docker containers in dev.
I think it makes sense to have the Docker containers for, for your infra in dev, but not the actual... Like if you're running a dev server, like why spin up a dev container with a... Or like a container
running a dev server. Like that, that doesn't make a lot of sense, to me at least. So I think that the, um, yeah, having, having CI/CD is, is very important and ensuring that it's fast is very important.
And then as you get further down the line, like how, how do you roll back? 'Cause if you're, if you no longer care about the, you know... If you, if you no longer care about reviewing the code that gets pushed,
stuff will break. And if you're not fast, then you-- If you're not fast at recovering from something being broken, then that determine, that becomes your bottleneck.
So like making it easy from the start to like roll back, I think is super important. The, the way that we do it now is, for instance, we just have a,
we have Kubernetes clusters, so that's not for, not for the faint heart, um, hearted. But uh, I think it's great if you, if you know how it works.
It's, it's a very good way to have a standardized environment that can work across multiple clusters.
You can set up your own local dev cluster if you wanna have a prod equivalent in your, on your local machine to be able to verify that everything works, you know.
You can set up labs, you can do a, a bunch of stuff with that. Um, and then if you have something that automatically updates your, the image that is running in a pod,
I think then you just have a new image built in CI, and then everything updates automatically.
And then if you want to roll back, you tag the li- the image that sh- it should be rolled back to, and then it just updates itself. [chuckles] Yeah. Thanks for the tips. I think, yeah, listeners will find them useful.
So Anders, you were named Sweden's most prominent internet entrepreneur in 2007. Yeah. Way back when. And it was like, yeah, 20 years ago. [chuckles] So it's a long time.
And is it fair to ask, what would 2007 Anders think of what you're building now, what, what you're doing right now? I've always been super creative and, and like
wanting to create stuff and so on, but it was until like I was 24 or like something like that, or 20, 23, that I thought the word entrepreneur meant a, like a building contractor.
Because in Swedish the, it's the same word for the building contractor- Right... as entrepreneur. So I, I didn't even know there was a thing that you could be that was an entrepreneur, which is like you start companies.
But then when, if I look back at, you know, even when I was, I don't know, 15, 16 or 17, I was, you know, playing around with the super early, uh, internet stuff. This is like late '90s. Um,
I was creating all these things and I didn't realize that I was essentially creating companies, but I did- just didn't know it at the time. So
I think that the 2007 version of me would think, look at my career and see that it's, it's quite cool.
[chuckles] Yeah, it was, it's, it was a, it's been a very wild ride and like, and even, but I mean, the, the first startup that I-- that's the startup that I got n-named that for by Internet World, it, it basically crashed and burned.
Um, and then I had like a, I had a... Way back there was this... Do you remember SlideShare? Yeah. So- Yeah... um, before it got acquired by LinkedIn, so I had a, after I, my startup failed, I wrote a
presentation called "10 Mistakes You Will Make As a Startup Entrepreneur." And that got pretty viral and so got a lot of publicity from, from that as well.
Um, and I think that that was sort of the, maybe that was even the, the embryo to the stuff that I'm thinking about now, 'cause the lessons I learned there, they were so painful.
I mean, back then this was like just when Web 2.0 was starting and the way you were, you built companies, it's completely different. There was no... I mean, cloud barely existed.
I mean, it started to exist and, and, and so on. But yeah, maybe it didn't even exist, I can't remember now. But there was a, there's a lot of big changes there. But the, the time I started off and I was the CEO,
I didn't know anything about like, what does a startup CEO do? And then, you know, there was like, "Oh, you write the business plan."
So I spent all my time writing business plans, which is, you know, basically the complete opposite of what I suggest now.
And even in that, like the "10 Mistakes You Will Make As a Startup Entrepreneur" presentation, the, one of the mistakes in there was about like- Writing a business plan or planning
too far into the future, which is sort of the same, same idea here as here Yeah. I mean, I think when you
even try to be an entrepreneur or build, build a company, it, I think it's an experience that really leaves a lot in your knowledge baggage. Yeah. And it's, I think it then is very difficult to see any
single activity in, into product development like software development or even discovery design, like in isolation.
Everything becomes like a system of interconnected activities because when you are building something, you have to take care of everything and you see the big picture. So yeah, that's a, that's a good story.
And I mean, are you even a real entrepreneur if you don't crash and burn [laughs] at a startup? So No, I mean, I've done this crash and burn so many times.
[laughs] But yeah, no, it's, uh, now that, now you men- now that you said it, it made me think about like how, how we're training neural nets today, like how we're training the AI models.
It's just a bunch of, you know, numbers in a massive, massive matrix that shift around essentially. So in a way, that's human experience.
Like what we're doing when we're failing and adjusting, failing, adjusting is like we're, we're adjusting the weights in our neural network that, that become and defines our experience in a way. [laughs] Cool.
So before we, we wrap up, could you
give me one thing, like one simple thing an engineer or a founder could do tomorrow morning to find the first p- piece of ti- of friction in, into their own, let's say, iteration machine?
It's probably what we mentioned briefly earlier where with the doing that sort of bottlenecks workshop. Okay.
Define in detail like all the steps it takes to go from feature idea to having it in production, and like really go into the more detail you do it, the better. So like go into like, oh, you write code
in project A, like save the file. Like, okay, what happens then?
And then, you know, or you commit or you create a PR, like wh- whatever it is that you have in your current process, I think if you define that, then you're gonna see like, and get ideas of how to improve each one.
Or like just take one, like do the workshop and then take the one that where you multiply the frequency by the time and see like, okay, what is the biggest number? And then you, you fix that,
and then you keep on working and you can do the workshop again. Or like you do the process. Okay, what does it look like now? Like, okay, got it. Great.
We got it down to this and this, and then you take the next one, and then you just work on the top bottleneck every day until like it's, you're, the reward is not [laughs] big enough, then start working on actually building.
But no, d- don't forget about also actually building the product. Like if you're just, uh, creating a machine, then that, if that machine doesn't produce anything, then, you know, it sort of doesn't matter. So yeah.
I think this is at the, the perfect place to end the conversation today. And surely this exercise will, will, will stick with me. I'll, I'll, I'll make it my own.
So Anders, where can people find you if they want to get in touch with you, ask you questions about what we talk about today, or just they want to connect with you?
You can connect with me on LinkedIn, on linkedin.com/in/andersfredriksson. You can find me on X. Uh, X is probably where I'm most active, and my username is @andefred, so A-N-D-E.
So four, four first letters of my first name and last name. And, yeah, I think th- that's, those are the best places. Don't- Okay...
look, l- I don't read email, so I don't, I think that would be a bad, bad way to approach. Right. I'll make sure to add the links into the description. Great. All right.
So yeah, thank you very much, Anders, for your time today. It was great to get to know you and about your speed methodology and how you're applying it to Staire AI, but also in the past. It was very interesting.
Thank you very much for being on the show. Yeah, thanks a lot. Product Engineer's Podcast. Wow.