Harnessing Innovation To Shape the Future of Cross-Platform Development - podcast episode cover

Harnessing Innovation To Shape the Future of Cross-Platform Development

Jul 31, 202437 minSeason 1Ep. 1
--:--
--:--
Listen in podcast apps:

Episode description

In the first episode of "Build To Succeed,” we’re joined by Eric Seidel, Founder of Shorebird, Co-Founder of Flutter and former Director of Engineering at Google. Eric discusses his career journey, shares insights on building impactful products and tackles distinctive approaches to addressing business challenges, particularly focusing on his work with Flutter and Shorebird.


This podcast explores the world of building successful tech products by talking to leaders who have brought ideas to life and nurtured them into long-term successes.  The show highlights the importance of building "the right thing, the right way" — crafting products for longevity while optimizing for business goals. 


Key Takeaways:


(01:49) Eric’s name appears in every WebKit installation, underscoring his vast influence in the tech world.

(05:00) Eric’s journey began almost 20 years ago with a focus on improving web development and eliminating redundant work.

(15:27) Problems of success are good problems to have but should not be solved prematurely.

(17:20) Eric keeps an accountability log to ensure he is working on the most important tasks.

(24:37) A mistake made with Flutter was to focus too long on greenfield applications rather than brownfield ones.

(26:51) The shift from JavaScript to Dart was crucial for Flutter due to performance issues on iOS.

(30:10) Eric’s definition of success has evolved from financial security to making a significant impact.

(35:00) Failure is an essential part of learning and progress, often overlooked by adults.



Resources Mentioned:


Eric Seidel -

https://www.linkedin.com/in/ericseidel/


Shorebird | LinkedIn -

https://www.linkedin.com/company/shorebirddev/


Shorebird | Website -

https://shorebird.dev/


Flutter | LinkedIn -

https://www.linkedin.com/showcase/flutterdevofficial/


Flutter | Website -

https://flutter.dev/


Google -

https://www.linkedin.com/company/google/


WebKit -

https://webkit.org/





Very Good Ventures designs and builds world-class digital experiences for any screen, with the best tools and engineering approaches for consistent, scalable results. Find out how VGV helps you hit the mark at: https://verygood.ventures/ 




#Apps #Flutter #AppDevelopment

Transcript

It needs to be an important problem, 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? Don't probably pick something that is completely outside of your experience, or if you do expect to spend a year learning it. Hi, I'm David, and this is Build To Succeed from Very Good Ventures. Today we're talking with someone whose name is inside every smartphone and maybe even in space. Eric Sidel is currently the founder of Shorebird and creator of the popular multi-platform framework in Flutter during his time at Google.

In this episode, we touch on so much that the only thing I can say is grab your popcorn and get ready to listen to something special. Hi, Eric. How's it going? Really happy to have you here. I'm frankly honored to have you here at UNIV, knowing each other. I was thinking about this before today, like over seven years now, from back there. Pre-before most people knew about Flutter and stuff, way back then, I think our fates have been intertwined over those years. Obviously mine very much so based on your creation with Flutter, and so I just wanted to start by saying, thanks, 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. I really appreciate that. One thing, as we were prepping for this, one thing I learned about you that I didn't know was that you've been like everywhere. Something like 10 different states and lived in Austria at one point, and I just wondered how that travel that background maybe influenced you over the years.

Yeah, my parents moved around a lot, and yeah, I spent a couple years in Austria, and I don't know how it influenced me. I guess I got to see a little bit of America at least. I get to learn how different other parts of the world are from California where I live now. But yeah, it's just been a part of me forever.

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

Yeah, there are quirks about things like the BSD license, 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 is in every install of WebKit everywhere, and WebKit is basically on every digital device, including those that go into space these days.

Yeah, my name and, obviously, hundreds and thousands of others is everywhere. That's pretty awesome. Name in space, and name in every smartphone everywhere. And probably more and more of these days in terms of apps, because I don't know if the obviously you had big influence at Google and with Flutter and a lot of the things you worked on there. And you were at Google for what? Over 14 years? That, right? Something like that.

Yeah, something like that. I had a company a long time ago, and then I, 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 blank, which now runs Chrome. And then we forked blank again to make Flutter, which is what you and I interacted with over the years.

Yeah, I wanted to go back to that company you mentioned before all that, because I think someone who just met you and you worked at Google for 14 years, you might think, oh, here's a big tech guy, but I think you're an entrepreneur at heart, right? Because going way back, what was it? 2006? You were in Y Combinator? Is that right? Something like that?

I think that's right, summer 2006. And I had a pretty early, that's wild. Yeah, we were the second or third class, something like that. Yeah, I had a little no name company in high school, doing consulting these stuff, and then I just, I long thought I wanted to be an entrepreneur, and I stumbled into Y Combinator, would end up being early for Y Combinator's journey.

And then after that failed, after that started failed as most do I took some time off. I think the Appalachian Trail is part of my continuing traveling the world and then in the Google. Nice, did you learn anything from as an early person in the tech community there? Did you learn anything from that YC experience? It's interesting looking back to see how much I feel like both we learn from Y Combinator and how much Y Combinator learned from us.

It's been interesting to watch where Y Combinator refined their pitch over time. And obviously, as I said, my company failed, and I exited divorce from my co-founder, and it wasn't the cleanest in the world. And I think that Y Combinator learned a lot from that experience of several others in our class breaking up in that same way. And yeah, it's hard. It turns out to start things and you you're going to learn a lot.

100% and that's what this is all about. 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. It's hard to start it. It's hard to get something that has value to begin with, and then don't even get me started on scaling and getting something big.

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

So pretty incredible impact there. And you caught us up on that story a little bit before and Webkit and Chrome and then into Flutter. 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. Yeah, okay. So fill in some of the gaps. So I got into this journey. Oh my goodness. Probably at least 15, almost 20 years ago.

I was part of getting on to 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 at 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, including Gmail and search and all just try and finally make these apps really good on the web. And we found that we just couldn't at least couldn't the level of standards that we wanted. We actually had an effort where we took the Android calculator and the Android calculator 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 rounded corners exactly perfect and just that taught us and that is why we ended up creating Flutter. That journey for me has just long been I look out in 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 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 pull us towards single platform development rather than customer development.

Yeah, and it's interesting how you're positioning that to where I think a lot of people think about it as a cost savings right. Oh, we can just write it one time we can have cost savings. But I love that point. It's also about time. It's like, hey, I can spend more time with my family and more time on a feature that matters.

Not writing that same bug twice. It's not just about the economic capitalist side of things of like how do we do more with less. It's also just like how do we do more with what we've got. So love that. And tell us about what you're doing now. Yeah, so I left Google a couple years ago to start a company around Flutter that's called shoreboard and we're solving problems for businesses using Flutter and the product we've developed first is code push for Flutter.

So code push is this idea that all honestly the big apps used today that you should be able to update your app immediately in production. And this is how all the big apps operate. So the YouTube's the TikTok's the Facebook's the center of the world when they have a critical bug they push a critical fix right now and all users get it right now instead of waiting for any update trains or people to click install et cetera.

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 code push 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 yeah,

yeah, I'm mostly just trying to keep up with them. 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 being able to not be beholden to some release train or some approval process or something like that.

And that's why wait for two weeks to get that fixed to your users or that new feature because you're just waiting for an apple or some approver to tell you it's okay to release it just push push your fix and get it out there. It's awesome. I'm really excited to see what you guys do and you got a road map and people are interested.

Maybe we'll drop a link here and see what you guys are up to. I want to really dig into like just the overall experience you've had in your career because like we said, look, why commentator.

I know you started your career at Apple you worked at Google for all this time 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 sending your name into space because of the things you worked on and helping to create flutter and making an impact on the web with Webkit and other things.

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

I think each of these I think of a separate phases and I learned different things I think one of the biggest takeaways that I learned from the why commentator experience was a belief in as they put it and I think they're correct making something people want I think that this is a step that honestly most teams skip over we skipped over in my company when I was doing a white commentator we built a thing that nobody ever wanted because we just never talked to our customers.

And yeah so I learned a lot about building something people want from the why commentator phase and it wasn't even 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 like the place converted in the fall.

But as part of the intern series the executives it 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 in 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 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 well I was at Apple.

I learned it well I was at Apple I learned it well as at Google Google is good at many things I would not list focus on that list and I think that I learned that in contrast in the same way that I learned watching the companies that were successful with why commentators are 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 at 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 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 us we built a thing that people want and so finding customers has never been a problem.

Customers have been beating down our door since we started this venture 15 months ago and our problem is all about how to deliver on the really difficult technical things that we're doing.

I think a lot of early especially early stage companies or if you're just want to start a company or something you feel like you've got this entrepreneurial drive some people just like where's their business opportunity where's there a market to exploit or something or how do I get on this gold rush away I or whatever it is 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 and it's like I think some people think about that is okay we got to go and just keep refining until we find the market.

We're finding until we find the thing that someone wants but what your sense isn't it easier just to start by really identifying what people actually want and maybe start there so I think a lot of people start with the product then try to find the fit as opposed to try to work through the fit and figure out what the product might be.

I think there's so many of these platitudes that smart people that I have come up with but one of them is that it's about falling in love with the problem rather than the solution. And I think that in many of my past phases I've fallen in love with the solution rather than the problem and I feel like with this with Flutter and with co-push 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 again back to your comment about it's more than just saving money we all work on a budget.

And whether that budget is your years on the earth or the time that you're going to put on this project that you're on 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 stretch your budget you can go so much further and that's what I think we're trying to do.

That makes sense that makes sense and I think also like one of the challenges we might face with tools like Flutter and Shorebird things where we can move faster is that I think 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 doesn't have a reason to exist just because you can make it go faster or put something out quicker I think 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 we have to have this not really going that next step what are our customers actually want.

Another thing I've seen that's interesting where Flutter creates this re-platforming opportunity for people and so I've had some people say hey this is actually an interesting time to rethink what is our business today let's not build something based on the premise of the business we started 10 years ago let's go back and let's rethink who is our customer 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 so it's really cool the focus thing is really interesting to me to I think so many companies are really not great that focus is there something that you guys or that you've done or been seen successful to help a team narrow down some of that focus it's really hard right especially 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.

I don't know that I have like scalable strategies other than through cultural immersion but I do have like patterns that I that tricks that I play for myself so one of them is I often question when offered a problem is this a problem of success 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.

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.

You know I think another trick that I use was a habit that I started when I worked with my I have a very close collaborator we started floated together we worked on web get together and when we worked in the past together we're not working on this company together but we work in the past together one of the habits we've had is that we had 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 important and impactful to me because it can change and I think just that general review of are we actually working on the most important thing has been important and maybe it's most important in like doing new things rather than doing a thing you've been doing for 30 years or whatever but I tend to do a lot of new things but I think it's really easy to get distracted by the third most important problem or the 18th most important problem.

And if we are working on the first most important problem what are we doing we're just wasting time. And some of those I think part of the challenge is first most important problems they're hard they're unclear right and so I think especially in today's world where we have all these tools to manage our 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 easier and you can like 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 maybe you've stunted your business by five years by not doing that for three months you know.

So those dopamine hits are important and doing the little clean up stuff is important and those are the things that I often do is warm up like I do a lot of mentorship of engineers but one of the things that I do when I'm coming into a new problem space or a new code base is to do the little clean up stuff to do those double hits right because then you build momentum and stuff but one other trick that I have is that I keep a log sort of accountability log it's like a journal effectively of the stuff that I do it's my to do list slash journal but the advantage of that is that I'm like constantly writing at the top of it okay what are the most important things that I do.

I can see how those change over time I can watch them drop off and it's okay if I go work on the dopamine hits that's good but at least I know once I'm revved up what is the most important thing and again and I'm reviewing it and yeah but to your point right there are 8000 things to do there are five things to do and fear what those five are and going doing them that's the important part.

It's not easy quick question is that a physical notebook you write it down on paper or is it a digital notebook. You could not read my handwriting with a handwriting expert I have an impossible chicken scratch so no I actually use a digital word document or a Google Docs document.

Yeah and I was just curious I'm kind of interested in how people keep track because it's these days you got slack and notion and notes and all these methodologies and stuff like Pomodoro and things and all these and it's funny I personally have gone back to sticky notes.

You could see my desk and I was just literally glittered with sticky notes and that's how I kind of track stuff but just curious it's an interesting thing but those are extremely fascinating insights and thanks for sharing those I really love that thinking and 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 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 warm up and then get you to a point where you can tackles a trickier thing like that.

So then this is a thing that I think I forgot when I was in my 20s doing my first startup is that I think I forgot how human we all are and 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.

Trying to just grind it out that's what we did in my first startup and I just burned out after 15 months of it and working hard is important but you also have to remember you're a human and take care of yourself including letting yourself do the little things. That kind of dovetails into culture of it right because 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.

If we don't get this out somebody's going to beat us to it but I think culture as we think about it within a team is super vital I've heard you talk about this before and I certainly important to me and our team at VGV as well around the culture of how you approach a problem is is also important like spending time and actually being mindful and letting people have some of that space sometimes you get more speed in the long run by letting people be slower in the near term you know there's that phrase I like slow as smooth and smooth as fast if you ever heard that one it's like a special opportunity.

It's like a special ops kind of phrase and I've always liked that where it's like sometimes being like thoughtful and methodical work through stuff but I think that comes to culture and when you think about building products and what makes team successful doing that what kind of influences culture have in your mind and what are some hallmarks of successful cultures.

I think culture is very important I don't know that I could define it super well I guess I think of cultures being shared values 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 I think this is another thing that I learned early on so actually much of my learning is not formal learning like from books or it's from books

but curiously so like my father was learning to be a manager when I was a teenager and so he listened to countless self help manager books in the car where we would be driving around I have not read them but I've listened to some of them when I was a teenager and one of the things that I remember him talking about is incentives and incentives are are important because you're not always in the room and I have come to learn and so you want to understand what's going to happen when you're not in the room right what incentives or whatever you encouraging people to do do

discouraging people to do 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 base level what do we value but anyway so how does that impact on a team I think the biggest impact I have seen is less from the positive side of culture and more from the negative side and that the 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 aren't working out you know help them find their next place to be help make sure that again you talked about the grind question make sure people are killing themselves in a way that is going to just burn people out yeah I don't know I answered your question but that's where my thoughts run

yeah I know it's there and I think one of the things you have mentioned in the past is the concept of like culture debt as well and I think people here the phrase technical debt and in the engineering space at least we have some idea what that means like the choices we've made are going to create issues and slowness and things we're going to have to pay back with interest later

and 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 what does that do in the long run so yeah I think maybe that's a little bit of where you're getting out 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

yeah well I think this is particularly with people right I think one of the things that I have learned through managing relatively large teams is that the cost of having someone who's not working out is not the individual person even if you're getting 1% of what you showed out of that person the much bigger cost is on the team

because it's on the changing of expectations for those around you it's on the cost of people having to help them it's on the cost of people wondering oh Joe isn't doing anything why am I doing something or oh I got to go clean them after Joe again the costs are all

externalized and I think that was a big learning from having to manage a large team 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 that we have this problem around our team now you're trapped as well too

if you don't have processes in place early on to make sure that you want people to achieve if they can get some assistance or coaching or guidance or maybe just coaching out or whatever it is by the time you realize it's a problem it's probably too late and even more expensive to fix and reset that culture

so I wanted to ask you another flutter question if you don't mind because I think obviously I think it's such a successful framework by all accounts I think at least the most popular multi platform framework out there these days and how huge impact on the industry in 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 however many years ago and say hey maybe do this a little bit different was there anything else that comes to mind in terms of how you could have or how to help drive a product team drive to that success a little better.

I think one of the mistakes that we specifically made with flutter was that flutter focused too long on green field and by green field a new applications and I think that if you look at it today 90% of the top applications using flutter are all brown field despite here we are 10 years in and we've known about this problem for at least five years

but our flutter doesn't make it easy at least in terms of docs and examples etc 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 or at least we were too late to do that or we could have been earlier about that.

So I don't know that I have a lot of regrets I think another mistake that I made was doing impeller too late so impeller is flutters rewrite of the graphic stack and flutter started as chrome we took chrome and we initially did not plan to do that. We didn't want to do that. We were trying to build a fast version of the web. They imagined if you could just have a doc type fast at the top and they turned off 90% of the web but the remaining 10% was super fast.

That was what we were trying to do and we did that very successfully I think for a while we made it really fast like 20 times faster on benchmarks. 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 your three years away from being the web and the reality is that it won't be exactly what you added once it gets through standard processor.

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 skier and skier is great. But it's designed for long running processes that 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 our memory to run in and they're only going to render the five circles that are in that app or the 10 buttons in that app.

So impeller was moving in the same way that we moved you may not know this but the original three versions of flutter were all in JavaScript. We eventually rewrote flutter in Dart when we moved to Dart it wasn't called flutter that was called sky but you could hear the collective shrieking of every Dart Flutter engineer there for a second right.

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 JavaScript on iOS. And even if it wasn't it you'd still be compiling the app while you launched it which is silly. And we so we moved to Dart which had an a ot on 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 compile graphics code which is exactly what you want for mobile app. You want to be able to pre compile your 12 circles you're going to draw on your app into super fast graphics code and just including 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 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 a 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 team change and it's the process change and just should have started impeller to years earlier and the world would have been two years further law.

You have the team you have the time and so it's going to cost time and team matter what so it's prioritizing which things you're going to get to this tracks with a lot of the things you've been saying about prioritizing focus choosing the tier one problem that first order problem but there's so many incentives in our lives in our workplaces to make other choices make that cheap choice or make that middle tier choice and leave the big thorny one.

We got a product manager wants to ship a bunch of features and but we got this one thing that's going to consume the entire team for a long time or something and it's really hard to defend off against that but having these stories having this insight helps you as a leader as a manager. To tell that story and say maybe next time around no we got to get on this faster because long run this is going to help our exponential growth curve way faster than these smaller things.

In terms of success in general as you think about your what you've worked on in the past and now where you are today where you're building a new company and having a lot of customers and a great team and how has your definition of success changed over the years and now as your founder again but with this huge body of work and experience behind you how's that shifted for you from early Eric to 2024 Eric.

Early on it was all about money it was all about feeling financially secure I grew up again my father earned significantly more than his parents had because he was a doctor and I looked at you know how we lived growing up in Kansas and I was like how the hell am I going to ever.

For this and so I think for a long time success was money for me and I think I definitely went through a phase where success was time was like freedom to do family and such and I think that was in part my Google phase and I think over time as I've gotten back into building bigger and things was successes to find the right impact how many people am I touching and reaching in my budget on this earth when my time on this earth how much good can I leave.

And how do you evaluate that like the people that you can impact right like how do you because I think a lot of people who are trying to figure out something to do or not for no venture they might be driven by things they read and social or book or 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 is not something they're passionate about how do you zero in on what impact is for you what is the right impact to pursue giving your experiences and your sort of advantages.

Yeah, this was actually another lesson that I recently learned was in leaving Google I thought I was walking away from Flutter because it was a long process honestly to walk away from your baby in that way as I did but I was talking with a bunch of enter 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 being 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 journey has been a lesson of leverage and so you were asking how do you choose what to work on again. It needs to matter to someone needs to be an important problem 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 don't probably pick something that was completely outside of your experience or if you do expect to spend a year learning it.

Yeah, that's very wise advice and I think something that you learn over their over 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 founder market fit is something that's or that's pretty cool that's 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.

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 tying into the some of those things.

This is awesome. I really appreciate this we're wrap up here. I wanted to see like any other words of wisdom or anything you've been part on all the founders and chief product officers and you know engineering managers and stuff out there anything else that drop on them as key learnings. You've got a ton of them here so we don't need anymore I think I've we've got 20 30 awesome things we could have had to do a whole other episode just on any number of the insights that we've talked about here.

There was one thing I wanted to ask you about if you don't mind is you mentioned something in one of our earlier conversations about this idea of a challenge network and I wanted to just unpack that a little bit more. What is that it's not something I'd heard of I hear about executive coaches and getting a peer group and stuff like that but a challenge network seems like an interesting perspective.

So this is from my wife from one of the books that she's reading my wife is a voracious reader and is currently reading through all the business books she can find and I don't know which one it was from but I really I liked the idea because I think otherwise the term peer coaching or mentor 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 which is I just I feel like there's so many people to learn from who have different life experiences than you have.

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 challenge from you are seeking them to learn things from them and I guess I sort of have that and I seek people who will challenge me and that I can learn from. Well and in this ecosystem there's that notion go on fail right go out and like through failures how you learn and I think a lot of our day to day interactions with our peers or co workers or boss or direct reports.

People are I think I believe at least that humans are generally nice 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 challenging 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 works and 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 or you can ask me a question I can fail to answer it because I don't know the answer yet.

That's that's what stuck with me is the relationship there that idea of challenging with someone is like a nice way of saying I'm going to encourage you to fail with your ideas right but in a way that's like friendly not confrontational or something and I think that's interesting as a interpersonal way to get learnings from failure into your day to day life without feeling like a failure all the time.

This is awesome. 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 or learn to do anything they just go out and fail constantly and they fail so many times and I think we adults are trained by whatever societal forces etc to try something once and then avoid the failures that need to happen in order to do something that's not going to happen.

I think that'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 they just run straight into it within two seconds they're dead.

But you know what my three year old my first one did it ran right into the goomba second one pick up the controller jumped and squash the goomba and so it's just if you don't have that failure you're not going to learn you're not going to learn how to squash the goomba so you need that Eric this is awesome 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 and maybe ask you to do this again sometime but I can't thank you enough and again just can't thank you seriously.

From bottom of my heart for my team my family everybody obviously I think about a huge impact on the world and certainly on on VGB and on me personally with your work and your effort and it's just a pleasure to know you and thanks so much for doing this. Thanks for having me. Thank you for joining us I build to succeed a very good ventures podcast we hope you enjoyed exploring the insights and experiences of leaders who have mastered the art of building success and tech products.

Please feel free to leave us a review wherever you listen to the podcast and don't forget to subscribe to us for more episodes.

This transcript was generated by Metacast using AI and may contain inaccuracies. Learn more about transcripts.