BUILD

SUCCEED

David DeRemer: Hi Eric, how's it going? I'm uh, Really happy to have you here. I am frankly honored really, um, to have you here, you know, you and I've known each other. I was thinking about this before today, like seven years, over seven years now, you know, from back there pre, before most people knew about Flutter and stuff way back then, I think our fates have kind of been intertwined over those years.

You know, obviously mine very, very much so based on your creation with Flutter. And so I just wanted to start by saying, thanks. It's a, it's a privilege to be able to get a chance to chat with you and just to know you over the last seven years. So, um, Um, really appreciate that. So one thing, um, as we were prepping for this, one thing I learned about you that I didn't know was that you've kind of been like everywhere, you know, something like 10 different States and, and, uh, lived in Austria at one point.

And I was just wondering how that travel, that background maybe influenced you over the years.

Eric Seidel: Yeah, I, my parents moved around a lot, um, and yeah, I spent a couple years in Austria and, uh, I don't know how it influenced me. I, uh, I guess I got to see, you know, a little bit of, of America at least. Um, I get to learn how different, uh, other parts of the world are from, you know, California where I live now.

Um, but yeah, I, uh, it, it's, you know, it just, it's been a part of me for forever.

David DeRemer: Well, and on the theme of everywhere, I also learned something I didn't know about you, which was, um, you literally, your name is everywhere. Um, probably far more than people think. Right. You want to tell us a little bit about that?

Eric Seidel: Yeah, there are quirks about things like the BSD license. Um, and there was a time when I was working on WebKit, when I was not working for Apple and not working for Google, and so my name, as an individual, uh, is in every install of WebKit everywhere, and WebKit is basically on every digital device, including those that go into space these days.

Um, and so, yeah, my, my name and, you know, obviously hundreds and thousands of others, uh, is, is everywhere.

David DeRemer: That's, that's pretty awesome. Name in space and name in every smartphone everywhere. Um, and probably, uh, more and more these days in terms of apps. Right. Cause I don't know if the, you know, obviously you had a big, big, uh, big influence, uh, at Google and with Flutter and a lot of the things you worked on there.

So, and you were at Google for what, over 14 years, is that right? Something like that.

Eric Seidel: Yeah, something like that. I, uh, I had a company a long time ago, and then I, um, After that dissolved, I went to Google and I worked on Chrome, the original Chrome team. And then when we shipped Chrome, I helped fork WebKit to make Google's engine Blink, which now runs Chrome. And then we forked Blink again to make Flutter, which is what you and I, you know, have interacted with over the years.

David DeRemer: Yeah, I wanted to go back to that, um, company you mentioned before all that, because I think, uh, you know, someone who, who just met you and you worked at Google for 14 years, you might think, oh, here's a, you know, big tech guy, but I think you're an entrepreneur at heart. Right. Cause going way back, I mean, what was it?

2006 you were in Y Combinator. Is that right? Something like that.

Eric Seidel: I think that's right, summer 2006.

David DeRemer: Yeah, I

Eric Seidel: I had a

David DeRemer: pretty early. That's wild. You know,

Eric Seidel: Yeah, we were the second or third class, something like that. I, uh Yeah, I had a, you know, a little no name company in high school, um, you know, doing sort of consulting y stuff. And then I, I just, I long thought I wanted to be an entrepreneur and I stumbled into Y Combinator. Um, what, what ended up being early for Y Combinator's journey.

And then after that failed, uh, you know, after that startup failed, as most do, um, you know, I took some time off. I hiked the Appalachian Trail as part of my continuing traveling the world, and then ended up at Google.

David DeRemer: nice. Did you, did you learn anything from as an early, early person in the tech community there? Like, did you learn anything from that YC experience?

Eric Seidel: It's interesting looking back to see how much I feel like both we learned from Y Combinator and how much Y Combinator learned from us. Um, it's been interesting to watch Y Combinator refine their pitch, you know, over time. Uh, and obviously, as I said, my, my company failed. Uh, and I exited. Uh, you know, sort of divorced from my co founder and it wasn't the cleanest in the world.

Um, and I think that Y Combinator learned a lot from that experience, uh, of, you know, several others in our class, you know, breaking up in that same way. And, um, yeah, it, it, it's, uh, it's hard, it turns out to start things and you, uh, you got to learn a lot.

David DeRemer: A hundred percent. And that's, that's what this is all about. You know, it's a, it is really hard. It's really hard not only to start things, but then it's hard through every single part of the phase, right? So it's hard to start it. It's hard to get something that has value to begin with. And then you don't even get me started on scaling.

Right. And like getting to something big. And so I think that's another thing, like you've obviously built some products in your career. Um, you're probably best known as the creator of. Uh, of Flutter, which of course, I just want to pause here again to say, thank you, um, you know, uh, for doing that. And I think not only VGV wouldn't be here where we are today without Flutter, um, but probably a lot of other companies and a lot of other teams out there.

So pretty, pretty incredible impact there. And so, you know, um, you kind of caught us up on that story a little bit before and WebKit and Chrome and then into Flutter. Um, and I was wondering if you could maybe just fill in the rest of the gaps of your experience there. Like, what did you learn along the way and maybe get us up to where you are now.

Eric Seidel: Yeah. Okay. So, so filling in some of the gaps. So I got into this journey. Oh my goodness, probably at least 15, almost 20 years ago, as part of getting onto the web. And I think I got addicted pretty early on to the problem of helping the world stop writing everything twice. And I tried really hard with the web.

I spent a decade of my life trying to make the web good enough to do that. One of the very interesting learning experiences after we had forked Blink, we felt free. So Blink was Google's fork of WebKit. We were suddenly free to fix all the bugs that Google needed fixed, or we felt some of that at least.

And we worked really closely with a bunch of teams. Uh, including Gmail and search and all just like try and finally make these, uh, apps really good on the web. Uh, and we found that we just couldn't, uh, at least couldn't to the level of standards that we wanted. We actually had an effort where we took, um, the Android calculator and the Android calc uh, calendar and we tried to replicate them perfectly on the web.

And you couldn't do it. You couldn't get the drawer animation exactly right. You couldn't get the, you know, the rounded corners exactly perfect. And just, uh, that taught us and that, that is why we ended up, you know, creating Flutter. Um, and so, yeah, that journey for me has just long been, I look out into the world and there's this crazy thing that all businesses.

Write things twice or three times or four times and that's just silly like that just shouldn't happen We should spend more time with our families and our kids and go home earlier because we didn't have to write the the same bug twice and so that has been this journey and I See things like flutter as being inevitable not because flutter is specifically the implementation that will win, but the Idea that we should be able to write a product for our customers once and have that meet the customer wherever they choose to consume it is I think a very just basic idea And the only reason we're not there is because of the incentives created in the industry

That uh pull us towards single platform development rather than you know customer development

David DeRemer: Yeah, and it's interesting how you're positioning that too, where I think a lot of people think about it as a cost savings, right? Like, oh, if we can just write it one time, we can have cost savings. But I love that point. It's also about time. You know, it's like, get, hey, I can spend more time with my family or more, more time on a feature that matters.

Like, not writing that same bug twice. It's, it's not just about sort of the. Economic capitalist side of things of like, how do we do, you know, more with less? It's also just like how do we do more with what we've got? You know, so love that. Um And tell us about what you're doing now

Eric Seidel: Yeah, so I, uh, left Google a couple years ago, um, to start a company around Flutter. It's called Shorebird, and we're solving problems for businesses using Flutter, and the product we've developed first is CodePush for Flutter. Uh, so CodePush is this idea that all, honestly, the big apps use today, uh, that you should be able to update your app immediately in production.

And this is how all the big apps operate. So the YouTubes, the TikToks, the Facebooks, etc. of the world, when they have a critical bug, they push a critical fix right now. And all users get it right now, um, instead of waiting for, you know, any update trains or, you know, people to click install, etc. And this problem had been solved at Google for some of Google's Flutter apps, but there wasn't a public solution for it.

And so we developed a new novel public solution. for doing CodePush, uh, that I think works great. And we're about a year and a half into the journey now and have a whole bunch of customers. And, uh,

yeah, we're mostly just trying to keep up with them.

David DeRemer: Yeah, it's awesome. I know it's a big need and people surfaced a lot and compared a lot to other solutions out there is needing this. And I think it ties into what you're saying to about time, you know, um, being able to not be beholden to some release train or some approval process or something like that, that just why wait for two weeks to get that fixed to your users or that new feature.

Uh, because you're just waiting for an Apple or, or some approver to like tell you, it's okay to release it, you know, just push it, push your fix, you know, get it out there. Um, so it's awesome. I'm really excited to see what you guys do. I know you've got a roadmap and if people are interested in, maybe we'll drop a link here and, um, you know, see what you guys are up to.

Um, I also wanted to, you know, I want to really dig into like just the overall experience you've had in your career, because like we said, look, Y Combinator, I know you started your career at, at Apple. Um, you worked at Google for all this time and you're back to doing a startup now. And so one of the things I really wanted to just try to unpack here is like with all that experience and the impact and the things that you've seen and touched the impact you've had on the, you know, sending your name into space because of the things you worked on and, um, and helping to create flutter and making an impact on, on the web with web kit and other things.

You've been exposed to big companies, small companies, you know, Apple, long time ago, Y's combinator, long time ago, Google, wrong timeline. What are some of the things you've learned? You know, like when you contrast your startup experience to your experience at Apple or Google, what are some of the big things that you've kind of learned along the way that you think influence how you approach product development now?

Eric Seidel: Yeah. I think each of these, I think of sort of as separate phases. Um, and I learned different things. Like, I think one of the biggest takeaways that I learned from the Y Combinator experience was a belief in. As they put it, and I think they're correct, you know, making something people want. I think that this is a step that, uh, honestly, most teams skip over.

Uh, we skipped over in my company when I was doing a Y, a Y Combinator. We built a thing that, um, nobody ever wanted because we just never talked to our customers. And, um, Yeah, so I learned a lot about building something people want from the Y combinator phase, and it wasn't even the the during, it was the after.

It was the that we had failed to do that. I think I learned a lot about focus from the Apple phase. I actually worked on a few different products at Apple, but I remember one of my earliest experiences at Apple was I was an intern. That was how I came. So I came as an intern, decided I liked the place, converted in the fall.

Um, But as part of the intern series, the executives would come and talk to us. And I had come late because my school let out late and I only showed up for the last executive conversation, which was Steve Jobs. And Jobs came and talked to all the interns and his whole point the entire time was that life is all about saying no.

And I'm sure he's talked about this before. He said there's, there's plenty of, plenty of things. It's always easy to say yes to more things. It's all about saying no. It's all about focus. And you saw that embodied in Apple. That Apple was very good at focus. And I, again, I didn't really learn it while I was at Apple.

I learned it while I was at Google. Um, Google is good at many, many, many things. I would not list focus on that list. Um, and. I think that I learned that in contrast in the same way that I learned, you know, watching the companies that were successful with Y Combinator versus ours in that they had talked to their customers relentlessly and just focused on trying to build a thing that people want.

And it's funny actually feeling it this time around. So I feel like we've done a pretty good job of building something people want. And it just the experience feels completely different. The experience I see many. So one of the problems that we see companies having and many startups having, and we had before, was one of constantly going to find customers.

And obviously I have a bunch of privileges and past successes that make some of that easy, but I think also some of it is that we've built a thing that people want. And so finding customers has never been our problem. Customers have been beating down our door since we started this venture, you know, 15 months ago.

And our problem is all about how to deliver on the really difficult technical things that we're doing.

David DeRemer: I think a lot of early, especially early stage companies, or, you know, if you're just want to start a company or something, you feel like you've got this entrepreneurial drive. I think some people just look, where's their business opportunity, you know, where's there a market to exploit or something, or how do I get on this gold rush, you know, of AI or whatever it is, you know, and it's sort of like ideas with some pie in the sky idea of success without a real motivation.

And I think also people like think about product market fit. Right. And it's like what, like, I think some people think about that as, okay, we got to go and just keep refining until we find the thing that someone wants. But yeah, like, I think what you're saying is, isn't it easier just to start by really identifying what people actually want, you know, um, and, uh, and, and maybe start there.

So I think people start with the product and try to find the fit as opposed to try to. Work through the fit and figure out what the product might be.

Eric Seidel: I think there's so many of these platitudes that, you know, smarter people than I have come up with. Um, you know, but one of them is that it's, it's, it's about, you know, falling in love with the problem rather than the solution. And I think that, you know, in many of my past. phases, I fall in love with the solution rather than the problem.

And I feel like with this, you know, with Flutter and with CodePush, it's all about falling in love with the problem. Like I want to solve this problem. It just, it offends me that the world still writes everything twice or three times or four times. And, you know, again, back to your comment about, uh, you know, it's more than just saving money.

We all work on a budget. Right. And whether that budget is your years on the earth, or the time that you're going to put on this, on this, this project that you're on, or, or the money in your bank account, right? But we all work on a budget. And when you find ways to do things better and more efficiently, you can do, you can, you can stretch your budget, you can, you can go so much further.

Um, and that's what I think we're trying to do. 

David DeRemer: makes sense. That makes sense. I, and I think also like one of the challenges we might face with tools like flutter and shorebird and things where we can move faster is that I think then that creates more people still need to have that focus on their idea, like to your point of build something that people want.

If the tools become easy where it's faster to iterate, faster to get something out, that doesn't mean you can just skip that step, you know, you have to make sure you're still thinking about what the product is and does it have a reason to exist just because you can make it go faster or, or put something out quicker.

I think, um, you know, there's, we see this all the time, like in our work, it's sometimes there's a business who there's, it's almost driven by a business need or like, we have to have this not. Really going that next step of like, well, what do our customers actually want? Um, uh, another thing I've seen that's kind of interesting where Flutter creates this replatforming opportunity for people.

And so I've had some people say, Hey, this is actually an interesting time to rethink, like, what is our business today? Not let's not build something based on the premise of the business we started 10 years ago, but you know, let's go back and like, let's rethink who is our customer. Like, what do they need?

If we were going to start today, what would we do differently? And now we have this tool that allows us to move a lot faster to get there. Um, so it's really cool. Um, the focus thing is really interesting to me too. You know, um, I think so many companies are really not great at focus. Is there something that you guys or that you've, you've done or been seen successful to help a team narrow down some of that focus?

Um, it's really hard, right? Especially in a big company, I would imagine to navigate the politics and figure out like, what is the thing that we should do and how do I say no to somebody if it's not the right priority? Just curious if you've developed any strategies over the years.

Eric Seidel: I don't know that I have like scalable strategies, uh, other than, you know, through cultural immersion, but I, but I do have like patterns that I, that tricks that I play for myself. Uh, so one of them is, is I, I often question when offered a problem, is this a problem of success, right? Is this a problem that we only get.

After some other unlock, right? And problems of success are good problems to have, but they're not good problems to solve before you have them. Right? So if it's a problem of success, like great, let's have that problem. Let's get there. You know, let's have the servers fall over because we have a million customers hitting them.

Then we have a million customers. That's a great problem to have, right? You know, I think another trick that I use, um, was a habit that I started when I, when I worked with my, uh, I have a very close collaborator. We started Flutter together. We worked on WebKit together. Um, And, uh, you know, when, when we've worked in the past together, we're not working on this company together.

But when we worked in the past together, one of the habits we've had is that we have the same conversation every day. Which is, what is the most important thing to be working on? And it's a little silly to have it every day, but I think it's actually been really interesting. important and impactful to me, because it can change.

And I think just that general review of like, are we actually working on the most important thing has been important. And maybe it's mostly important in like doing new things rather than doing a thing you've been doing for 30 years or whatever. Um, but I tend to do a lot of, of new things. Um, but I think it's really easy to get distracted by the, the third most important problem or the 18th most important problem.

And if we aren't working on the. First most important problem? Like, what are we doing? Like, we're, we're, we're just wasting time.

David DeRemer: And some of those, I think part of the challenge is sometimes those first most important problems, they're hard. They're, they're unclear, right? And so I think. Um, especially in today's world where we have all these tools, like, you know, to, to manage your productivity and task lists and all these things.

And a lot of people buying, it's very easy to go down to the third or fourth thing because you can see the solution kind of easier and you can like, oh, okay, I can fix that today. And I can push that code and fix that bug or whatever, and get a little dopamine hit because I accomplished something. And if you just keep doing those, it feels like you're making progress.

But if you keep like that first, most important problem. Hangs out forever. Well, may maybe you've like stunted your business by five years by not like doing that for three months, you know?

Eric Seidel: so those dopamine hits are important, and doing the little cleanup stuff is important. And those are the things that I often do as warmups. Like I, I, I do a lot of mentorship of, of, of engineers, but like, one of the things that I do when I'm coming into a new problem space or a new, uh, code base is to do the little cleanup stuff to do those dopamine hits, right?

Because then you build momentum and stuff. But the, you know, going back to tricks, right? So another trick that I have is that I keep a log, sort of an accountability log. It's like a journal, effectively, of like the stuff that I do. It's my to do list slash journal, right? And so the, but the advantage of that is that I'm like constantly writing at the top of it, okay, what are the most important things to be working on?

And I can see how those change over time. I can, I can watch them drop off. And like, it's okay if I go work on the dopamine hits. That's good. But like, at least I know, like, once I'm revved up, like, what is the, the most important thing? And again, and I'm reviewing it and Yeah, but to your point, right? There aren't 8,000 things to do.

There are five things to do. And figuring out what those five are, and going and doing them, that's the important part.

David DeRemer: Yeah. But it's not easy. And I think that's, I I have a quick question. Is that a, uh, is that a physical notebook? Like do you write it down on, on paper or is it a, a digital notebook?

Eric Seidel: You could not read my handwriting, you know, with a handwriting expert. Like, I have an impossible chicken scratch, so no. Um, I actually use a, uh, a digital Word document or a Google Docs document.

David DeRemer: Yeah. No, I was just curious like, um, I, I'm kind of interested in how people kind of keep track 'cause it's so, like these days you got. Slack, and Notion, and Notes, and, and all these like, you know, methodologies and stuff, like Pomodoro and things, and all these, and, you know, it's funny, I personally have gone back to Sticky Notes, like, if you could see my desk right now, it's just literally glittered with Sticky Notes, and that's how I kind of track stuff, but, just curious, it's kind of, kind of an interesting thing, but, I mean, those are extremely, you know, fascinating insights, and thanks for sharing those, um, I really, really love that thinking, and, um, Uh, I think you're right.

A lot of people, I love that idea, especially about starting off with some of those small things. Don't get, don't get, um, too worried about the fact that maybe you haven't tackled that hard problem, as long as you are mindful, like you said, to use it as a warmup and then get you to a point where you can tackle sort of a trickier thing.

I like 

Eric Seidel: We're human, right? Like this is a thing that I think I forgot when I was in my 20s doing my, you know, first startup, right? Is that I think I forgot how human we all are. And like, you need to play the dopamine hits and you need to go take a walk and you need to like, go get exercise and take care of yourself.

I think trying to just grind it out. That's what we did in, you know, in my first startup. And I just burned out after, you know, 15 months of it. And, uh, you know, working hard is important, but, uh, you also have to remember you're a human and take care of yourself and including letting yourself do the little things.

David DeRemer: Well, that kind of dovetails into culture a bit, right? Because, um, you know, a lot of companies out there have this like grind mentality, like, Hey, where you have to just work at an absolutely insane pace. We have crazy deadlines to hit. Um, if we don't get this out, somebody is going to beat us to it. Um, but I think culture, as we think about it within a team.

Is super vital. And I think I've heard, you know, you talk about this before. And I certainly see important to me and our team at VGV as well around, you know, the culture of how you approach a problem is also important, like spending time and actually being mindful and letting people have some of that space.

Sometimes you get more speed, uh, in the long run by letting people be slower in the near term, you know, um, there's that phrase I like, like, Slow is smooth and smooth is fast. I don't know if you ever heard that one. It's like a, like a special ops kind of phrase. And I've always liked that where it's like sometimes being like thoughtful and methodical, you kind of work through stuff.

Um, but I think that comes to culture and, um, you know, when you think about building products and what makes teams successful doing that, what, what, what kind of influences culture have in your mind and what are some hallmarks of. successful cultures 

Eric Seidel: I think culture is very important. Um, I don't know that I could define it super well. I guess I think of culture as being sort of shared values. Um, I think about it with the word incentives much more than culture. So I'm very driven by understanding the incentives in the world around me. Um, I think this is another thing that I learned early on.

So actually, uh, much of my learning is not, uh, formal learning like from books or it's, it's from books vicariously. Uh, so like my father was learning to be a manager when I was a teenager. And so he listened to. countless, you know, self help manager books in the car where we would be driving around. And so I don't, I have not read them, but I've listened to some of them when I was a teenager.

And, uh, one of the things that I remember him talking about is incentives and incentives are, uh, are important because you're not always in the room. And I have come to learn, and so you want to understand, like, what's going to happen when you're not in the room, right? What, what, what incentives are, what are you encouraging people to do, discouraging people to do?

Um, I've learned you're basically never in the room, and so incentives govern the whole thing, and culture, I think, is like at the, at the base level, like, what do we value, um, what do we, but anyway, so how does that impact on a team? Um, I think that the, the, The biggest impact I have seen is less from sort of the positive side of culture and more from the negative side, and that the, the, uh, gardening of culture is important.

It's much more important in my view to make sure you aren't doing bad things in your culture than worry about doing great, amazing things. And some of that comes in terms of making sure that folks who, you know, aren't working out, you know, help them find their, their next place to be, uh, help make sure that like, again, you talked about the grind question, like make sure people aren't killing themselves, you know, in a way that, uh, it is going to just burn people out.

Um, yeah, I don't know that I answered your question, but, but that's, that's where my thoughts run.

David DeRemer: no, it's, it's, it's, it's there and I think one of the things you, uh, have mentioned to me in the past is the concept of like culture debt as well. Um, and I think people hear the phrase technical debt and in the engineering space, at least we kind of have some idea of what that means, like the choices we've made are going to create like issues and slowness and things we're going to have to Payback with interest later. Um, and you, you, I, I hadn't heard anyone really phrase that before, like this notion of culture debt, that some of the choices you make on your team, like, what does that do in the long run? Um, so yeah, I think maybe that's a little bit of where you're getting at here too. It's like the choices you make and some of those negatives that you can instill in a company, they can be really costly if you're not

careful, if you, yeah.

Eric Seidel: Oh, I think this is a particular with people, right? I think one of the things that I have learned through managing. relatively large teams, um, is that the cost of having someone who's not working out is not the individual person. Right? Even if you're getting 1 percent of what you should out of that person, the much bigger cost is on the team.

Because it's on the changing of expectations for those around it, it's on the cost of people having to help them, it's on the cost of people wondering, oh, you know, Joe isn't, isn't doing anything. Why am I doing something? Or, oh, I gotta go clean up after Joe again. You know, it's just like, the costs are all, uh, externalized.

Um, and I think that was a, that was a big learning from, from having to manage a large team.

David DeRemer: And that's incredibly difficult to fix too. If you one day wake up as a manager and you're like, Oh, we're doing this. Like we, we have this problem around our team. Now you're kind of trapped as well too. If you don't have processes in place early on to make sure that you, uh. people to achieve if they can get some assistance or coaching or guidance or maybe just coaching out, you know, or whatever it is.

Um, uh, by the time you realize it's a problem, it's, it's probably too late and even more expensive to fix. Um, and reset that culture. So I wanted to ask you, uh, another flutter question if you don't mind. Um, because I think, obviously I think it's such a, Successful framework, you know, um, uh, the man, by all accounts, I think at least the most popular multi platform framework out there these days.

Um, and, uh, had a huge impact on the industry and the community. And so I think we have a tendency to talk about all the great things and all the benefits. And I was just wondering, what are some of the mistakes, you know, if you could go back and look at that journey. What were some of the things you and the team did over time that maybe if you could go back and talk to yourself five years ago or, or however many years ago and say, Hey, maybe do this a little bit different.

Was there, was there anything else that comes to mind in terms of how you could have, uh, or, or how to help drive a product team, um, drive to that success? A little better.

Eric Seidel: I think one of the mistakes that we specifically made with Flutter, was that Flutter focused too long on Greenfield. And by Greenfield, I mean new applications. Um, and I think that if you look at it today, 90 percent of the top applications using Flutter are all Brownfield. Despite here we are 10 years in, and we've known about this problem for at least five years.

Uh, Flutter doesn't. make it easy, at least in terms of docs and examples, et cetera, for you to add a little bit of Flutter, sprinkle a little bit of Flutter into your otherwise large app that you wrote 10 years ago. Um, or at least we were too late to do that. Uh, or we could have been earlier about that.

Um, so I, I don't know that I have a lot of, uh, regrets. I think another mistake that I made, um, was doing impeller too late. Um, so impeller is Flutter's, uh, rewrite of the graphics stack. And so. Flutter started as Chrome. We took Chrome and we, we, we initially did not plan to build Flutter. We didn't want to build Flutter.

We were trying to build a fast version of the web. Imagine if you could just have like a duct type fast at the top and then like turned off 90 percent of the web but the remaining 10 percent was super fast. That was what we were trying to do. Uh, and we did that very successfully I think for a while. We made it really fast.

Um, like 20 times faster on benchmarks. Um, The problem came was that eventually we had to add something. And the moment you add something, you are not the web, or at least you're three years away from being the web. And the reality is that it won't be exactly what you added, you know, once it gets through standard processor.

Yeah, so we started from Chrome, right? And we stripped it all the way down. But one of the few things that we kept and shared with Chrome was the Graphics Library Skia. And Skia's great. But it's designed for long running processes that are going to render arbitrary content, which is not what mobile apps do.

Mobile app processes need to start up quick, and often get shut down quick, and they don't have very much memory to run in, and they're only going to render the five circles that are in that app, or the ten buttons in that app, right? And so, Impeller was moving in the same way that we moved, so, you may not know this, but the original three versions of Flutter were all in JavaScript.

We eventually rewrote, uh, we eventually rewrote Flutter in Dart when we moved to Dart. It wasn't called Flutter then, it

was called 

Sky, 

David DeRemer: You could, hear the collective shrieking of every Dart Flutter engineer there for a second, right?

Eric Seidel: Well, we moved off of JavaScript because it took 12 seconds to start an app on iOS. 12 seconds. Like obviously we couldn't ship that. And that was because there is no, or I don't know if this is still true today, but there wasn't at the time a JIT for, uh, JavaScript on iOS. Um, and even if there was a JIT, you'd still be compiling the app while you launched it, which is just silly.

Anyway, so we moved to Dart, which had an AOT, an ahead of time compiled mode. And Impeller is the same idea. Impeller is moving from just in time compiled graphics code to ahead of time compiled graphics code, which is exactly what you want for a mobile app. You want to be able to precompile your 12 circles you're going to draw in your app into super fast graphics code and just include it in your app.

That's it. You're done. Anyways, we should have done that two years earlier. The learning, the leadership learning, is that I was presented with a menu of options of the small, medium, and large. And I chose the medium. And one of the learnings that I've had over years is that often when you're presented with an option set of options like that, they all cost the same because the cost is not in the complexity of building the thing.

It's the, it's the team change and it's the process change and the, and so we should just, should just should have started impeller two years earlier and you know, the world would have been two years further along.

David DeRemer: point. I mean, you have the team, you have the time. And, uh, and so it's going to cost time and team no matter what. So it's prioritizing which things you're going to get to. And this tracks with a lot of the things you've been saying about sort of prior, you know, prioritizing focus, choosing the, the tier one problem, that first order problem.

Right. Um, You know, and, but there's so many incentives in our lives and in our workplaces to make other choices, make that cheap choice or make that middle tier choice and leave the big thorny one. Right. And, you know, we got a product manager who wants to ship a bunch of features and, but we got this one thing and that's going to consume the entire team for a long time or something.

And it's really hard to fend off against that. But having these stories, having these, this insight, right. Helps you as a leader, as a manager to, um. To tell that story and say, maybe next time around, no, no, no. We gotta, we gotta get on this faster because long run, this is going to help our, our exponential growth curve way faster than these smaller things.

So, yeah, I mean, you know, in terms of success, right. In general, as, as you think about your. on in the past and now where you are today, where you're building a new company and having a lot of customers and, and, um, great team. And, um, how has like your sort of definition of success changed over the years? Um, and now as you're, uh, you know, uh, kind of, a founder again, um, but with this huge body of work and experience behind you, you know, how do you think you're, how has that shifted for you from early Eric to 2024 Eric?

Eric Seidel: Yeah. I think early on it was all about money. It was all about, uh, you know, feeling financially secure. I grew up, uh, again, my father earned significantly more than his, his parents had because he was a doctor. And I looked at, you know, how we lived growing up in Kansas, you know, whatever. And I was like, how the hell am I going to ever afford this this, right? And so I think for a long time, success was money for me. Um, and I think I definitely went through a phase where success was, was, was time was like freedom to do family and such. And I think that was in part of my Google phase. Um, and then I think over time, as I've gotten back into building bigger and things was, success is defined by impact.

How many people am I touching and reaching? You know, in my budget on this Earth, you know, in my time on this Earth, um, how much good can I leave?

David DeRemer: And when you, when you, how do you evaluate that? Like the people that you can impact, right? Like how do you kind of, Cause I mean, I think a lot of people who are trying to figure out something to do or an entrepreneurial venture, they might be driven by things they read in social or in a book or like, Oh, you got to identify some huge addressable market.

And I think the risk there is someone might end up doing something that doesn't play to their strengths or it's not something they're passionate about. You know, how do you, um, zero in on. I don't know, like where, what, what, what impact is for you? You know, what is the right impact to pursue given your experiences and your, your sort of advantages?

Eric Seidel: Yeah. I mean, this was actually another lesson that I recently learned, um, was in leaving Google, I thought I was walking away from Flutter, because it was, it was a long process, honestly, to walk away from your baby in that way, um, as I did, um, but I um, I Was talking with a bunch of venture capitalists, and one of the lessons that I learned from them was the importance of founder market fit, you know, founder product fit, and I did a little bit of sort of dipping my toes back into the Flutter world, and it was just obvious how much leverage I had, and so I think that was a lesson in leverage, and I think this this journey has been a lesson of leverage, and so you were asking, you know, how do you choose what to work on?

Well, again, how do you It needs to matter to someone. It needs to be an important problem, you know, make something that people want and that those people can be you. And then also work on something that like you have some prayer of working on, right? Like don't, you know, probably pick something that was completely outside of your experience or if you do expect to spend a year learning it.

David DeRemer: Yeah, that's very, uh, wise advice. And I think something that you learn over there over a career like yours, and it'd be very easy for you to get pulled into a lot of different directions and to have that kind of clarity, um, founder market fit is something that's, or, or, you know, that's, that's pretty cool.

That's a, an interesting way to think about it and even high leverage, right? I think. What can we do to be more successful, whether it's with our own careers or the tools we choose or the things we go after that idea of leverage, I think is something that's really important. Um, I think for instance, flutter is a high leverage tool, for example, like any engineer who picks it up, they have so much more leverage than somebody else who's just building for one of those experiences like you were talking about.

And so. You know, tying into the, some of those things, um, well, this is awesome. Um, I really appreciate this. Um, uh, we can kind of wrap up here. I wanted to see like any other, any other words of wisdom or, or anything you'd kind of impart on all the founders and chief product officers and, you know, engineering managers and stuff out there, anything else that you kind of drop on them as, as key learnings.

You've got a ton of them here, so we don't need any more. I think I've, uh, we've got like 20, 30 awesome things. We could have like, uh, had to done a whole, whole other episode just on like any number of the insights that we've talked about here. Um, there was one thing I wanted to ask you about if, uh, if you don't mind is we kind of, um, you, you mentioned something, um, uh, in one of our earlier conversations about, uh, this idea of a challenge network.

And I wanted to just like unpack that a little bit more and kind of what is that? I mean, it's not something I'd heard of. I hear about, you know, executive coaches and getting a peer group and stuff like that, but a challenge network seems like an interesting perspective.

Eric Seidel: So this is from my wife, from one of the books that she's reading. Um, my wife is a voracious reader and is currently reading through all the business books she can find. Um, and I don't know which one it was from. Uh, but I really, I liked the idea. Um, because I think otherwise the term, uh, you know, like peer coaching or mentor, they, they, they, they have this hierarchy.

involved in them, which that's not what mentorship is about for me. I have learned so much from other people who I think of as mentors and often those mentors are even my reports, right? Like, which is, I just, I feel like there's so many people to learn from who have different life experiences than you have.

Uh, and so I think I'd like the idea of a challenge network, which is just a network of people who you are seeking out, you know, challenge from. You are seeking them to to learn things from them. And I, I guess I sort of have that and I seek people who will challenge me and that I can learn from.

David DeRemer: Well, and in this ecosystem, there's that notion of like go out and fail, right? Like go out and like, like through failure is how you learn. Um, and I think in a lot of our day to day interactions with our peers or coworkers, our boss, our direct reports, you know, people are, I think, I believe at least that humans are generally nice, you know, despite what you read on the news, I think generally like most people are good people and they want to help each other.

And they also may sometimes maybe don't want to like, Say that truth telling that is maybe a little bit critical or, or challenging, right? Um, but I think it's so important because if we're saying on one hand, Hey, you got to put a product out there and see if it, if it works and, you know, fail and move on.

But in our day to day interactions with our peers and our trusted advisors, if we're also not setting, like creating situations where our ideas can fail, right. Or like, you can ask me a question. I can fail to answer it because I don't know the answer yet. Um, that's the, that's kind of what stuck with me is the relationship there of like that idea of challenging with someone is like a nice way of saying, I'm going to encourage you to fail with your ideas kind of right.

But in a way that's like friendly, not confrontational or something. Um, and I think that's kind of interesting as a, as a interpersonal way to learnings from failure into your day to day life without feeling like a failure all the time. So. Well, this is

Eric Seidel: I could probably spend another hour talking about failure, because I think failure is super important. And I think it's a thing that we forget how to do as adults. If you ever watched a small child learn to walk, you know, or learn to do anything, right? They just go out and fail constantly.

And they fail so many, many, many, many, many, many times. And I think we adults are trained by whatever societal forces, et cetera, to, you know, try something once and then avoid the failures that need to happen in order for us to learn.

David DeRemer: Totally. My example of this is, uh, Super Mario Bros. The fir very first one. You you put that controller in the hands I did this with my kids when I think my my daughter was five, and the youngest one was like three, and I got the little NES Classic, and I I booted up Super Mario Bros., and what's the thing that most people do?

The first time they ever play the original Nintendo Entertainment System Super Mario, they run straight into that goomba. You know? They just like run straight into it, and within like two seconds, they're dead. But you know what? My three year old? My first one did it ran right in the Goomba. Second one, pick up the controller, jumped and squashed the Goomba, you know?

And so it's just like, if you don't have that failure, you're not going to learn. You're not going to learn how to squash the Goomba. Um, so you need that. Um, well, Eric, this is awesome. I really appreciate your time. I definitely agree. We could have a whole thing about just failure or about any number of topics in this conversation.

So I definitely think I'm going to take some notes and go back and maybe zero in Maybe, uh, ask you to do this again sometime. Um, but, uh, can't thank you enough. And, uh, again, just can't thank you seriously from bottom of my heart, from my team, my family, everybody, you know, obviously, uh, I think you've had a huge impact on the world and certainly on, on BGV and, and on me personally with your, your work and your effort, and it's just a pleasure to know you and, uh, thanks so much for doing this.

Eric Seidel: for having me.

David DeRemer: All right. So we'll just hang on for a sec. Aiden, you out there.