Most conversations about modern software focus on tools — new frameworks, new languages, new trends. But the biggest challenges in software engineering have not changed in decades. In this episode of Build to Succeed, VGV CEO David DeRemer sits down with Steven Stamps — a veteran technologist whose career spans Fortran and mainframes through Flutter and AI — to unpack a deeper truth: the real challenge is not technology. It is people, process, and leadership.
A Career That Spans the Entire Stack of Modern Tech
Steven’s journey through software engineering is unusually expansive. He started in the era of punch cards and IBM mainframes, proprietary systems with no shared standards, and dozens of incompatible platforms. Over time, he became an early adopter of nearly every major shift: Unix, relational databases, object-oriented programming, the internet, mobile, and now Flutter and AI. His approach is consistent — find where the industry is going, and move early.
The Lessons Aviation Teaches About Software
One of the most practical parts of the conversation comes from Steven’s experience as a pilot. He draws a direct parallel between aviation and engineering.
1. Checklists Create Consistency
High-performing teams do not rely on memory — they rely on systems. Every release, every ticket, every process should be repeatable and predictable.
2. Plan for Failure, Not Just Success
Pilots do not just plan their destination — they plan alternates. Great engineering teams do the same: backup strategies, fallback paths, and edge-case thinking.
3. The Most Dangerous Moments Are the Transitions
In aviation, takeoff and landing are where most failures happen. In software, it is the same. A poor project kickoff sets up long-term failure. A lack of focus at the end produces broken delivery.
4. Confess Problems Early
Confessing problems early can save the project.
Teams fail not because problems happen, but because they are hidden too long.
What Hasn’t Changed in Software Engineering
Despite massive technological progress, some things remain constant: resistance to change, organizational politics, “if it ain’t broke, don’t fix it” thinking, and team tribalism (iOS vs. Android, and so on). Steven calls out a key truth:
Technology evolves quickly. Human behavior does not.
That gap is where most transformations fail.
Fearless Refactoring: A Different Way to Build Teams
One of the most powerful ideas in the episode is fearless refactoring. Instead of treating improvements as optional, high-performing teams capture every opportunity for improvement, add it to a structured backlog, and schedule it intentionally in future sprints.
A backlog of refactorings is a strategic asset.
This creates a culture where innovation is continuous, technical debt is managed proactively, and teams always move forward.
Innovation vs. Operations Isn’t a Tradeoff
A common belief in tech is that you must choose between stability (operations) and innovation (experimentation). Steven challenges that idea. With the right systems in place — feature flags, A/B testing, data-driven decision-making — teams can have both. Organizations can experiment safely, validate ideas quickly, and protect production systems.
Why Flutter Is a Business Decision
One of the biggest takeaways from the episode is that Flutter is not just a technical upgrade. It is a strategic business move.
Cost Efficiency
Maintaining separate iOS and Android teams is expensive. Flutter consolidates effort into one team.
Speed to Market
A single codebase means faster releases and quicker iteration.
Eliminating Parity Debt
No more waiting for features to catch up across platforms.
Better ROI on Engineering Work
Steven introduces a powerful metaphor: code as inventory. If features sit unused while waiting for another platform, that is wasted investment. Faster releases mean faster returns.
Talent Density
Instead of splitting teams across platforms, Flutter enables smaller teams, more senior engineers, and higher overall performance.
The Hard Truth About Organizational Change
Even when the benefits are clear, adoption is difficult. Why? Because people protect what they have built, leadership hesitates to disrupt, and politics slow progress.
Politics often hinder technological progress.
That is why real change often requires top-down leadership alignment, clear business justification, and sometimes a willingness to act before consensus.
The Real Focus: People Over Technology
For all the talk about frameworks and systems, Steven ends with a simple perspective. The most important part of engineering is not code. It is people — building strong teams, supporting careers, and creating sustainable environments. That is what drives long-term success.
Final Takeaway
If there is one idea that defines this episode, it is this: the best teams do not just adopt new technology. They build systems — and cultures — that make continuous improvement inevitable. Flutter is part of that story. But leadership is what makes it work.
Resources & Links
- Connect with Steven on LinkedIn: linkedin.com/in/stevendstamps
- Learn more about Flutter: flutter.dev
Transcript
David DeRemer (00:01.912)
All right, welcome Stephen. Thrilled to have you on Build to Succeed. To kick us off, can you introduce yourself and the kind of work you do?
Steven Stamps (00:09.12)
I sure can. By the way, I’m really happy to be here with you, David, and love reaching out to the Flutter community. I think it’s a super important community that needs to grow, and I’ll do what I can to help. I do hybrid work from upstate New York, where I recently built our bespoke forever home on 26 acres of virgin forest. That’s been a project.
I live with my wife who’s a retired medical doctor and we have a three-year-old little boy named Wyatt. I have a lot of interests outside of work. I like to compose music, play a lot of musical instruments. collect cars. I enjoy long cycling trips and aviation is a hobby, both as a private instrumented pilot and as an owner of several airplanes. And in another context, any one of these would be a
podcast all by itself.
David DeRemer (01:07.726)
That’s great. Well, you already teed me up because one of the ways I like to start is by asking for things you do in your personal life that bring you back into technology where you kind of get better at work as a result of the things you do outside of work. And I know you and I caught up a little bit about aviation and I’m curious if there were things from aviation that you found have really worked to improve your approach to management, engineering, technology, design, etc.
Steven Stamps (01:33.742)
Excellent question. Aviation has been a very important part of my life, not professionally, but both as a hobby and I own my own consulting company for 18 years and had my own airplane to travel around to clients. It’s been important and informative for me.
for a couple of reasons. There’s a checklist for every aspect of aviation. If you’re a good pilot, you don’t do anything without following a checklist and confirming it. just like Santa, checking it twice, making sure that you haven’t missed anything. The checklist is a highly efficient and low ceremony habit. So, you know, we’re not talking about
overloading your processes with high ceremony documentation. And this maps to how I like to lead teams. So every ticket has checklists, every release has checklists, and it just helps to make sure that everyone’s on the same page and that we have consistent quality and that we’re all safe and our users are safe when you deploy.
new apps. know, with aviation, have flight planning and that flight planning has options. So you not only plan the flight of the destination airport where we’d like to go, but alternate airports if that airport gets snowed in or has bad weather. And even in that airport, alternate approaches and procedures. Personally, I also, before every
journey and a lot of them included my family, I had an FAA certified flight simulator in the basement and I would fly all those approaches and all those alternates before every trip so that I would be prepared. And those are also the kinds of habits that I instill in my teams. And then the last, well, actually not last.
Steven Stamps (03:54.286)
The third part of that is key transitions. In aviation, the key transitions are takeoff and landing. Takeoff is where things can go badly and it’s really difficult to recover. And so you need to do a lot of preparation before takeoff to make sure that your equipment and the runway and the weather are going to support that takeoff successfully.
And then the other transition that’s critical is landing. a lot of accidents happen there unnecessarily because the pilot gets the runway in sight. They’ve just come through a tough trip. They’ve had ice, they’ve had weather, and so they relax. And then they end up not having a good landing, tipping the plane over. And these are lessons that I take directly into leading projects.
Getting a project started properly, the right people on the bus, if you will, the right scope, the right KPIs and metrics for measuring success. If you don’t get those right very early on in the project, the rest of the project is going to suffer and may not even succeed. And then the landing metaphor, you know, a project might be going really well, it’s a long-term project, and then
the leaders take their eyes off the ball and the project wanders and loses focus and isn’t successful. So, and then the last piece from aviation I would share that’s critical is confess. When you’re a pilot and when you’re up in the air and when things are going poorly, equipment, bad decisions on your part,
most important thing to do is to confess to air traffic control so that you can get advice, get help, and address the situation. But what happens too frequently is that pilots do not confess that there’s a problem. They try to solve things themselves, problems pile up on each other. And then by the time they do confess, it’s too late to save the airplane and save the occupants. Exact same metaphor with projects is when that project starts going sideways,
Steven Stamps (06:17.432)
there’s risk, you need to confess immediately. You need to talk to your team. You need to talk to your organization. And if you, Talk to people early and, leverage the wisdom of teams. there are very few situations you can’t overcome and get back on track. yeah, aviation has been a big part of my life. Wow.
David DeRemer (06:40.802)
Well, and so many good parallels there. mean, just every one of those, we could probably do an episode on every single one of those points you just made and deep dive into those and how to actually do that. Sounds like aspiring product leaders and engineers might want to consider getting some, some flight training. It seems like it would be a good, good skill to add to the, to what they’re able to do.
Steven Stamps (07:00.686)
Well, I mentioned I have a three-year-old little boy. I can assure you he will be getting his Pilots license when he turns 16. I think it’s great training.
David DeRemer (07:08.364)
Amazing. Yeah, it’s wonderful. You I also know that you’ve had an incredible career and you know, is in our world of software engineering. A lot of people these days are focused on these thin layers of the stack, right? You’re building front end apps or you’re building websites or things on those lines. And I know if I’m correct, you got your start in the late 70s working with Fortran even.
Can you tell us a little bit about that journey all the way from those days all the way to where we are now with AI and all the things happening?
Steven Stamps (07:39.318)
I can, and I might surprise you a little bit with the prologue to the story. So my mother passed away this year at the age of 100. Not a sad thing. She had an incredibly rich life. And when I look at her life, she was a teacher. She started her career in a one-room schoolhouse, riding a horse to work, building a fire to keep the kids warm in the wintertime. And then…
Through the 60s, she was part of a NASA program to learn all about science and space and bring that back to her science classrooms. And then right up until she passed away, she could use a computer and a phone better than a lot of people. And I look at myself and when I first started in this profession, I was using Fortran 4, which had no subroutines.
and it was on an IBM 360 using punch cards with JCL. So that was my beginning and then I…
And I also, at the very beginning, we lived in a very different world. There wasn’t UNIX, there wasn’t open source. And so every computer company had their own unique bespoke hardware, their own unique bespoke operating system, their own languages. And I was counting up the other night, David, and I counted 12 different systems.
that I had to use and learned in my first four years. IBM 360, DEC PDP, Wang, Univac, Burroughs, NCR controlled data, Honeywell, Data General, Prime, GE, and MacroData reality with the pick operating system. Every one of those had three lineal feet of technical documentation because there was no online docs like we’re used to today. And so every time you needed to interface with the system, you had to break out.
Steven Stamps (09:47.214)
the docs and figure out how to use these unique metaphors and this unique approach. I got pretty tired of that pretty quickly. And so I…
introduced the remaining phase of my career where I was an early adopter and advocate for new innovations. I quickly developed a special skill to identify where the industry and profession needed to go, what technologies would most likely take us there, and then would become an early adopter and advocate.
for those technologies. And that started with the original AT &T Unix System 3. That’s how I escaped all these proprietary operating systems. I built one of the first Unix data centers on Wall Street in World Trade Center 1 on the 76th floor using a PDP, a deck PDP piece of hardware, mini computer, and a nine track
tape from AT &T Bell Labs with Unix System 3 on it. basically, I received a crate full of hardware from DEC with no operating system and a nine-track tape.
had to write a C program bootloader to bootload Unix from the nine track tape onto the hardware. And all this arrived on a Friday afternoon and I had to have it up and running by Monday morning because I had new employees starting that were going to start writing C code. So that was the beginning. And then the other evening as I was thinking about this podcast, I put together a list of the major
Steven Stamps (11:47.138)
innovations that I adopted. The next was relational databases. Believe it or not, that was a new wonderful thing. Object-oriented programming. A side note there, before object-oriented programming in C, I was actually creating C structures that included data and function pointers. So I was essentially doing object-oriented then. That’s how I organize these very large
applications that I was building for Chase and the financial industry. Then it was Sun Workstations. I actually bought Sun Workstations from Scott McNeely and Bill Joy from the back of a station wagon on Wall Street in the very early days. Then there was PCs. They were invented after I started. Then the browser and the internet. Java was a huge step forward. REST and JSON.
then Linux and the LAMP stack, cloud computing and virtualization, NoSQL, mobile and Android. I was very early with Android, very early with Kotlin. What a lovely language. Then Flutter and Dart. I have to confess I was initially disappointed that it wasn’t Flutter and Kotlin, because I had already fallen in love with the language.
But it’s worked out well and I get along just fine. Recently, it’s AI and machine learning. And currently, I’m reaching out to some folks in Silicon Valley because I’d like to get involved in home-based humanoid robots and using Flutter to build the mobile apps that consumers would use to monitor and manage and…
provide some extra safety features for home humanoid robots. So that’s a pretty good arc of my career that kind of matches my mom’s going to work on a horse and then flying out to NASA to learn all about science.
David DeRemer (13:57.642)
It’s it’s super amazing and I’m humbled to be here chatting with you with your experience that you’ve spanned such an incredible arc of technology. forget you might know there’s a famous computer science book that name is escaping me and like in the beginning it talks about how we’re just kind of rolling around on the top of a stack of mattresses. The modern developer and I think they wrote that like 20 years ago and I think it’s more so now where it’s just these all these layers stacked up where the abstraction is so great that here we are writing.
Dart and Flutter code and building all these applications. And you just took us through the history of like modern software engineering, you know, and you got a chance to see all of that with such incredible perspective. What are are there like some constants that you see have been consistent themes throughout that journey that even though we’re dealing with AI and can deploy massive, you know, infrastructure with a command line sentence, right? Are there things that have held true throughout your career?
Steven Stamps (14:55.049)
There are…
Steven Stamps (15:02.56)
Let’s.
I think we all know that it’s the people that have not changed. And I actually made a few notes here. Let me find because…
Steven Stamps (15:20.737)
since we have a moment.
Steven Stamps (15:36.13)
There we go. Save Dustin some time. So.
Steven Stamps (15:46.51)
The main thing to focus on as a leader and as an individual contributor is what has not changed. So I’m glad you brought that question to the discussion, David.
Steven Stamps (16:04.152)
People and organizations have not changed. One of the issues that’s been universal, it’s kind of regional, and I’ll talk about that in a minute, but the culture of if it ain’t broke, don’t fix it. I’ve worked in and lived for extensive time in Chicago, New York City, and San Francisco.
loved all those cities, loved the cultures, but they’re very different. When I was in Chicago, it was very frustrating because the dominant culture in the Midwest is if it ain’t broke, really bad, don’t fix it. And for someone like me, who is a perpetual, virtual, fearless, refactoring leader, that was very frustrating. But that’s…
That’s something that has always been there and has never changed. Another way it’s expressed is good is the enemy of great. That’s a common problem. What will happen is you’ll build a world-class team of engineers and product managers and they want to build an amazing product for the organization and
for the users, but something is in place that’s good enough. It may even be object-oriented cobalt, just to have some fun there. But the engineers know and the product managers know that we need to evolve and move ahead.
organization and many of the leaders there follow the path of least resistance. So that’s number one. Number two, the people who are resisting change are often the people who built their career on the existing way of doing things. We, meaning you and I and our Flutter community, deal with that every time we try to get an organization to pivot to Flutter.
Steven Stamps (18:25.174)
You’ve got, in the case of Disney, I had 60 Android engineers building the ESPN app and ESPN Plus and a number of other Disney apps. There were equally 60 iOS engineers. They each had their own organization of leaders and hierarchy and politics. And to this day, I have not been able to get them to address
the fact that they could be saving tens of millions of dollars every year and addressing a lot of those other issues you and I have discussed, if it weren’t for the fact that the people that currently populate and lead those groups are resistant to that change. The third item I would point out relative to people and organizations is that technology changes very quickly relative to human tribalism.
which hasn’t changed for 10,000 years. you know, people, and in the case of our Flutter world, you’ve got the iOS tribe, you’ve got the Android tribe, and that’s an ingrained part of human nature and is always a challenge to overcome and pull those teams together. Although to be very positive, I have done that multiple times.
So I can assure you that it’s very possible, but it takes a lot of work and strong political will from the leadership.
David DeRemer (20:03.49)
Yeah, I’d love to dig into that actually, if you don’t mind, which is as someone who’s been an innovator, you’ve ridden the wave of technology and have been able to adapt to the next one as a as opposed to just riding the one you’re on in. And then you got to swim back out again and figure that out. You just stay out there, keep riding the next one. How what are some strategies or approaches you’ve found to help organizations and teams adapt and kind of make those transitions effectively? Because I think you’re right. The human tribalism, the
You know, maybe there’s even genetic, right? And ingrained deep human behavior that makes us resistant to change. How do you get teams to switch over? How do you get teams to be more innovative and adopt new technologies as it comes along?
Steven Stamps (20:47.854)
So there’s two different scenarios to talk about here. One is the Greenfield scenario, like we were discussing at ESPN as an example, where they’re not using Flutter, they’re not thinking about Flutter. In that situation, you can’t do it from the bottom up. It’s got to be from the top down.
You’ve got to establish a trusting relationship with the senior leaders. You need to speak in terms of senior leadership value systems, aligning the technical issues with the balance sheet issues. How is this going to help us save money? Not only is it going to help us save money, how is it going to help us generate more revenue?
or accelerate our delivery value to the market. So in that scenario, the only way in is from the top down. It’s just not going to work otherwise. But the second scenario, which I enjoy a lot, is you have an application, you have a tech stack that at one point in the not too distant future,
was pretty modern. And then my approach is to create a culture of perpetual refactoring. And I call it fearless refactoring. This happens a couple different ways. One is just about every time an engineer goes in to enhance a feature,
or to add a feature, they see things that aren’t quite right or that could be better. The way I run my teams is we immediately create a ticket for all of those. We immediately identify at what point in the future we want to work on that ticket.
Steven Stamps (23:10.551)
and we proactively schedule it for five sprints out, six sprints out, eight sprints out.
And this guarantees number one, that you capture the idea. One of the metaphors, and this could be a separate podcast also, one of the metaphors I use with my teams is that we’ve all heard you live in a knowledge economy, but most people have no idea what that means. In my view, what that means is
A knowledge economy is about having great ideas, resourcing those ideas to implement them and then deliver it to the marketplace for value. So the raw material in the knowledge economy is new ideas. So if my team is capturing every ideas and we’ve got a hundred great refactories in the backlog, your team doesn’t do that. And then you get
in the fourth quarter of the year, let’s say, and people say, well, gee, what should we do in 2026? And then you start scrambling around for really good ideas. Whereas my team, we already have a backlog of hundred refactorings with identifying what the value is to the market, what the value is to the business. And we’ve also captured a lot of detail in that ticket so that
we’re much more successful in the knowledge economy because we have more raw resources and they’re higher quality raw resources to build out the features and the opportunities for the business. that’s one of the ways. Item number two, as a leader and especially as a senior leader, I choose to beg for forgiveness. So,
Steven Stamps (25:18.25)
I’ll do this in one of two ways. One of the more transparent ways is I will schedule a POC. But in the back of my mind, I’m designing a POC that is a minimum viable product that I could deploy. And this is for two reasons. Number one,
A lot of times, if you have a successful POC, what happens? The executive team says, hey, can you put that into production next week? And so I just anticipate that’s going to happen and make sure at least that the metaphors and the abstractions are going to support a longer term production ready solution. But if that doesn’t happen, what I may do
David DeRemer (25:53.57)
Mm-hmm.
Steven Stamps (26:15.074)
is go ahead and slip that into production anyway. and everything my team does in production is behind feature flags and everything is behind A-B tests. so slip it into production. Of course, it’s behind a feature flag. It’s also behind an A-B test with a staged rollout, but
very, very quickly, I captured data. So then what happens in this scenario is I get found out, know, Steven, why did you deploy blah, blah, blah, whatever. And I’m like, well, I was exhibiting a executive leadership initiative. And by the way, here’s the data. It’s built, it’s deployed. And here’s the data that says we’re getting X percent more revenue or X percent.
fewer crashes. So do you want me to pull it out of production and lose that opportunity? So those are some of my techniques. They’re not favorite techniques of some of my very senior leaders. But at the end of the day, that in some cases seems to be the only way I can keep my organization moving ahead and moving modern. I did that by the way with AI. We’ll talk about that a little bit.
later on, but that’s exactly the approach I took with AI and previous employers.
David DeRemer (27:48.428)
I love the idea just going in saying like I’m gonna I’m gonna beg for forgiveness if you’re the innovator if you’re the person is gonna push and make change and like you’re saying about just sort of the tribalism all the resistance to change all the all the things that are stacked against taking bold risky steps. If you ask for permission you’re never gonna get it you know in those types of environments and cultures sometimes the only way to do it is to force it through I remember I think might have been another podcast but I listened to something once where they were talking about the.
like entrepreneurial ventures. Usually there’s like a person or team that starts it, you know, and they’re just moving really fast, trying a bunch of things, taking a lot of risks. And then eventually that company gets serious enough where there’s something to protect, you know, they’ve they’re getting enough revenue, they got big customers, there’s risk there. And then they hire like a CEO or something, you know, and they were describing that at this moment, you’re introducing this tension in the business where innovation
and operations are like exactly opposed to each other because innovation you want to try 10 things through nine of them away and keep the one that works. Operations it’s like no, no, no, I want to reduce everything that is that I know is not going to work and I want to focus just on the stability safe stuff. like instantaneously you have this kind of competitive dynamic between safety and risk taking innovation. And I think that that’s
Steven Stamps (29:08.142)
Sorry to interrupt David, but I’m intimately familiar with that scenario, but I contend that those two priorities are not mutually exclusive. I think they can be fully supportive of each other with the right culture, with the right processes. know, earlier we talked about checklists.
and process discipline. You know, there’s nothing that happens on my teams that isn’t a thoroughly defined process. That’s a process muscle that’s been exercised hundreds of times throughout the year with checklists, with historical KPIs to track how we do that. So you take that along with a culture of
Feature flagging and A-B testing, absolutely everything that goes into production. And now you can protect your company, protect your revenue, protect your assets while still being a fearless refactor, a fearless innovator, because those are behind feature flags, those are behind A-B tests, so that you’ve got data. Which the other side point there is that most teams
product teams, engineering teams, they go on intuition. Whether you’re triaging or deciding how to optimize the performance of a stack or whether you’re ideating on how to optimize a user experience and user engagement, most teams are not aggressive about everything being driven by data.
If you don’t do that, if everything isn’t behind a feature flag, if everything isn’t behind an A-B test or an A-B-C test, then you’re likely not spending your time and resources on the right things.
David DeRemer (31:20.078)
Yeah, well, if you’re all prepared and your model is to beg for forgiveness, but you’ve done all your checklist to make sure that the likelihood you’re going to have to ask for forgiveness is pretty low, that’s going to work out pretty good for you, I think.
Steven Stamps (31:32.686)
It usually does. I’ll use AI as an example and I won’t go into any great details. But the other problem with innovation is the organizational politics. And I did a lot of AI work at my previous employer because the AI team in another part of the organization
you know, after two years still hadn’t delivered.
Steven Stamps (32:08.654)
a high quality product. And I personally had the expertise and I had the expertise of my team to be able to build out a lot of this. And it was extremely successful. But that was one of the rare cases where politically it was not successful because
politics were just too big, too high, and it was about the politics, it was about power, it wasn’t about delivering the best solution, most cost effectively and as quickly as possible. So, you know, we don’t live in a perfect world and there are going to be times where the organization is just not going to make sense.
David DeRemer (32:58.002)
Yeah, this is something I think we talked to junior engineers a lot or you know, those of us that have been doing this for a long time. You learn that you know the engineering, knowing the SDK is knowing how to architect a code system, how to work with other engineers through the tools and everything. As you progress in your career, so much of it is about managing the people, not just the code communication, how to sell ideas, how to manage different personalities and knowing when to ask for permission or.
beg forgiveness and all of these different things. And it becomes such a crucial skill that you have to develop in teams. Because you’re right, no matter what we do, we can’t get around that. But you’ve had a lot of successes in your career doing exactly this, like getting technology off the ground. And I know we’ve connected, and I’m fortunate enough to get to know you and meet you as a result of your involvement in the Flir community. Can you dig into that a little bit for us around?
How did you find Flutter and how did you manage getting that in and kind of like leading a transformation to build Flutter apps in your previous roles?
Steven Stamps (33:59.084)
You bet. So as I had mentioned earlier, I led a team of about 60 engineers and product managers at Disney for the ESPN app and some of the other apps that I was responsible for. And I was extremely frustrated with the politics involved and the
inefficiency evolved there. And so I was recruited away from Disney by Amazon, AWS, and in that case did not follow the advice I’ve given so many young engineers, and that is do not make career decisions based on compensation.
So, know, AWS was paying me more money than God, but the culture and…
The technology in the area that I was in was broken beyond my ability to be able to fix it. So, and it wasn’t mobile. So, and at that time I realized two things. Number one, that I have a huge passion for mobile. The reason for that is because of the intimate relationship with the user. It’s an entire data center in the pocket.
of each of your hundreds of thousands of users and more powerful than the servers that I was using in the two thousands to manage massive transaction volumes for banks and brokerages. So very exciting. But I hated the politics and the technical stove piping of iOS versus Android.
Steven Stamps (36:11.32)
You know, there’s been a couple of other efforts before Flutter to do cross-platform mobile, and none of them were satisfying. I thought I would take a swing at Flutter, and I used Flutter at a startup, a fintech startup, a new bank called Enzo, to build a banking app.
Greenfield for a startup with Flutter. there I had done some research before that, but that was where I proved to myself that there wasn’t anything that I wanted to do on a mobile device that I couldn’t do very well with Flutter. so that was where I started.
That startup, it’s funny, when I was out on, when I lived in San Francisco, I can’t tell you how many engineers I hired and worked with who had worked for 10 startups already in their career. And I experienced that with Enzo, with this FinTech startup. They were underfunded and weekly led as far as the product vision.
And so I had, unlike today, I’d put an open for work flag in my LinkedIn. And that afternoon I had an offer from NGM, a senior VP that I had worked with at Disney on the ESPN app, reached out to me and said, Hey, things are a mess over here with our mobile. And.
I need you to come in and…
Steven Stamps (38:13.614)
clean things up. When I went on board, they had one full-time employee on that team. The app had been built by a range of contractors and with no leadership from MGM engineering leaders. And one of the things I will say,
a contractor cannot be terribly successful without full engagement and, leadership, from their client. So otherwise you’re just caught, you know, guessing what’s going to work or what’s going to be successful. And, it’s unfair to you and it doesn’t provide the results. So that was what it.
going on there. So I, I, built out a world-class team of Flutter engineers, shout out to every one of them, amazing team, and, established this culture of, fearless refactoring, established a culture of no one swims alone. you know, every feature is owned by the entire team. Every problem is owned by the entire team.
established a core architecture team, which were essentially the strongest and most innovative engineers who met every morning for an hour at 730, bless their heart. But that was 730 Pacific time. The reason for that time was that was the one time that my boss and other C-level executives
wouldn’t schedule a meeting over the top of our meetings. So that guaranteed every day we had an hour to talk about what it was not a stand up. It was let’s talk about, you know, what did we learn? You know, you know, what are our challenges? What are the opportunities?
Steven Stamps (40:31.138)
those kinds of high, high quality engineering discussions happening every day with a loose agenda. Basically, in any 24 hour period, this also helped us, by the way, dramatically cut back on meetings. Because instead of either me or other team members calling a meeting for every important topic, you just add that topic to
the agenda for tomorrow’s standup. It was called MCOR for Mobile Corps. And the philosophy was on average, you’d only have to wait 12 hours to get answers and get help. And so just wait until tomorrow morning and then you’ve got the entire team there and attendance was required. So everyone had to be there.
and had to be engaged. And it was a phenomenal way to lift up the entire team. Everyone learned from everyone and.
It was a really exciting meeting and exciting time.
David DeRemer (41:45.454)
And you managed to convince the leadership there to rebuild with Flutter. And so what was that process?
Steven Stamps (41:54.466)
They are, and in fairness, had started, but there was, but at the time I was recruited, there was question, you know, was the flutter decision the right decision, you know, because they weren’t getting what they, what they wanted to, get out of their mobile app and out of their mobile team. And it wasn’t a flutter issue. It was a, it was a process issue or culture issue.
David DeRemer (41:57.39)
Okay, cool. Nice.
David DeRemer (42:24.95)
Yeah, we’ve seen that as you can imagine many, many times where you read the label of Flutter and all those great benefits, know, 50 % or more reduction in cost and doubling speed and quality improvements and all this stuff. And then you don’t see it and you’re like, what’s going on? And it’s very easy to blame the tool, especially if people have built their careers on expertise and things they don’t want to say, no, it’s because we implemented it incorrectly or something like that. But you know, it is just a tool.
And a lot of it is the architecture, the processes, the practices of the teams and the things that go into it. And it’s actually interesting, right? And I’m sure like you observed this with your team. You can come in and you can, once you fix those things, it’s amazing how much progress teams can make. when you just start aligning on doing things consistently, repetitively, like the meetings being mandatory and those sorts of things, just everyone’s going to write tests, you know, we’re going to AB things, we’re going to do feature flags. We’re going to
set up these best practices that we’re all gonna follow swimming together. Were there specific things like that that you came in that like, what were the highest impact kind of changes you made pretty quickly?
Steven Stamps (43:32.758)
So before I jump into that, bring me back around. But I want to point out that those are all critical and important, but that’s not enough. What you also have to establish is an end-to-end clear architectural vision of where you want to take this technology and where you want to take this app. And the vision that I
introduced into this team was an end-to-end event-driven architecture. We’ll talk about that a little bit more later, but it’s really critical that both the product people and the engineers also have a clear vision architecturally.
what the theme and what the objectives and what the benefits are of this strategic architecture that you’re pursuing. And also, spent a lot of time educating product managers on the architectural vision and why it was important and why they needed to thoroughly understand it and incorporate it into every ticket and every ideation of new and improved features.
Yes. So let’s roll back to your original question. When I came on board, there was a new mobile release roughly about every seven weeks. Unpredictable. The release would go out with more than 100 bugs, and it was a mess. One of the first things
I did was create a.
Steven Stamps (45:34.456)
worked with the team to create a very thoroughly defined release candidate and release process with KPIs that would be followed religiously for every release. And initially we went to releases every four weeks, then we tightened it down to every three weeks.
and then in less than
Five months, we were down to every two weeks, a new release, and the number of bugs was single digit, and none of them were P1s or P2s.
Steven Stamps (46:24.664)
That did a couple of things. It allowed us to publish a release calendar a year in advance. Why was that important? Because when stakeholders or technology partners would come to us and…
talk about when they wanted to deliver something, my questions would always direct them back to the release calendar of when do you think you want to release this. Now, we’ll get in a little bit to my perspective as a senior leader. I spent a lot of time in senior leadership meetings
looking at PowerPoint presentations that were purely aspirational. There would be a slide with a Gantt chart showing we’re going to deliver this in Q2, deliver this in Q3, deliver this in Q4.
Steven Stamps (47:41.824)
So one of the benefits in those meetings, I would pull up the mobile release calendar and I would say, so you said Q4, do you mean this release at the end of December? And by the way, we have no releases at the end of December because I don’t do releases after Thanksgiving.
The last release, if it’s a Q4, the last release is scheduled for November 11th or whatever the date happens to be. Is that the one you’re talking about? They would say yes. say, well, so if that’s when you plan on releasing that feature, which is being driven by this back-end service, then we’ll need a sprint to incorporate to
to test and validate that significant new service. We’ll need a sprint before that to integrate that API and that UX into the app. We’ll need a sprint before that to get a UX design from the design team, et cetera, et cetera. So that means that you are gonna have to be done with building your service by September.
whatever. And then they’ll be like, whoa, no, no, no, no, we’ll, we’ll, we’ll finish our code in December. And then you start having a realistic conversation about, okay, so we’re talking about, this is going to be in release 26.3 in February of 2026. And then now we talked before from an aviation perspective about,
Takeoffs are high risk and if you don’t prepare properly for a takeoff with the right equipment and the right preparation, bad things can happen that doom the rest of the flight. This is a parallel with that metaphor is with this technique, I make sure in that aspirational sea level meeting that we get a realistic target date for delivering that feature. If I don’t do that, then what happens
Steven Stamps (50:02.046)
is I sit there, let this happen. Commitments are now made to the board of directors and to business partners external to the company that we’re going to deliver something on December or whatever. We’ve all been there before. What happens? Nights, weekends, we don’t care about quality. We’re just throwing doodoo against the wall, see what sticks and we ship it. So.
This is an example, one of many of techniques that I use to get ahead of things. But not be sitting there in that meeting as a negative Nancy, not be sitting there saying, we can’t do it, we can’t do it, but sitting there and walking the team through what the realistic opportunity is to build and deploy this.
David DeRemer (50:58.382)
I want to also dig in with what time we have left around recently you put something on LinkedIn that you called Flutter as a business imperative. And so now that you’ve kind of worked with it for quite some time and I’ve seen the actual impacts of this change once you get teams on board and you get everybody working to get the impact, you kind of have been advocating for Flutter, not just as a tech choice, but really as a business strategy. And I’m curious if you could explain some of your ideas that went into that.
that document you prepared and why you think Flutter and tools like it, right? There may be others and things in the future are a valuable part of your modern technology approach.
Steven Stamps (51:40.194)
Well, the reason I wrote that article is, and I’m actually gonna look it up to make sure we.
Steven Stamps (51:53.944)
There we go. We hit all the points. The reason I wrote that article is I think this is a pivotal moment in time for the Flutter community and for leaders such as yourself in that community to lean in to the opportunity that we have.
due to the changes in the economy. We’ve all witnessed companies are laying off tens of thousands of engineers and other employees. The reason they’re doing that is in a lot of industries like hospitality, where I was previously,
The profitability has, the revenue has dropped. The profitability of that revenue has dropped. Expenses have increased. And so very senior leadership are cutting employees and cutting contractors so that they can maintain a certain level of profitability.
Steven Stamps (53:20.302)
This is our moment because if you wanted to save a big chunk of money at Disney ESPN or at any other company that is currently maintaining a separate iOS and Android code base, there is an easy 30 to 50 % or even more cost savings available right out of the box.
Steven Stamps (53:51.778)
that’s consistent with the current culture of pruning back the organization to cut expenses, but also is a, unlike a lot of those other decisions, would be a very smart strategic move to position themselves to perpetually save $10 million a year on staff or on contractors. But
The cost savings from a strategic standpoint is only, in my view, a very small part of this. One of the big issues that I encountered at Disney was the issue of parity and feature parity and parity debt. Either the Android or the iOS team would rush ahead
with the feature, get it done before the other platform and deploy it, or they would rush ahead and get it done and then have to sit on it for two months waiting for the other platform to finish and test their feature. That is hugely expensive from a business standpoint if you think of it in terms of inventory and inventory turns.
Back in the 90s, there was a big push on just-in-time delivery of raw materials. The idea there was, know, an auto manufacturer doesn’t need a million bunkers piled up at the beginning of the production line and paying for all that inventory and the space to store it when they’re only going to create 10,000 cars a day. Well, very few people think of it
this way, but all of that code and all those PRs that you’ve reviewed and merged and are ready to go into a release candidate and are sitting after, that’s inventory. You’ve paid for those developers, you’ve paid for that processing time. Those are finished goods, but they’re sitting back in the warehouse and the company is not benefiting from those benefits.
Steven Stamps (56:18.378)
And so you need to focus on what a business is referred to as inventory turns. As soon as an engineer and a product manager works on a problem or a new feature, that needs to quickly be turned into a release candidate and deployed into production.
And the quicker you do that, the quicker you get a return on investment. So, debt is a huge, huge issue in my book that nobody talks about. Also future-proofing the asset. Every time you write a line of code, you’re creating an asset for the company. If that asset is in flutter,
David DeRemer (56:48.942)
Fantastic metaphor.
Steven Stamps (57:11.222)
then not only can you deploy it to iOS and Android, but we did this at MGM. We deploy the same Flutter code to Windows, to Linux, and to the web. So now to be able, basically it’s like a tangible goods company being able to sell the exact same product.
to three different customers and make that revenue three times over. So that’s something else that people don’t talk much about that in my view is hugely valuable. The other topic is the other driver is velocity and market agility is when now instead of having resources spread across different
platforms, Android, iOS, Windows, web, all your best people are distilled down into one team that can move much more quickly with much higher quality to address new opportunities. And one of the things that I’ve achieved there and that companies can achieve there that also isn’t discussed is something called talent density.
So rather than having these three or four teams across, know, Web iOS and Android with one or two star players holding up each of those teams, if you will, now you can have a single team with dominated by senior engineers, principal engineers, and the talent density is tremendous. The reason that’s important is
I contend that you are essentially equivalent, you are the average of the five people that you most commonly work with every day. And so, as an athlete, if you just played with world-class tennis players, you’d be a much better tennis player than just playing with your buddies down the street. It’s the same thing with talent density. When I create those teams and I did this at MGM, everybody lifts everybody up.
Steven Stamps (59:37.582)
to new levels that were unimaginable. And that results in velocity and market agility. The last point I would make that’s a driver for this is risk and brand consistency. This is the way to make sure that
Steven Stamps (01:00:03.948)
Your digital storefront is identical and the same high quality regardless of the platform, web, iOS, Android, Windows. And now because you have talent density, not only on engineering and product, but on QA, you can also have even higher quality.
deliveries on your release candidates and on your deployments. So there are so many reasons more that we haven’t really talked about here, but so many reasons why now is the time for companies that are maintaining a separate iOS and Android team to pivot to Flutter, create a single team with tremendous talent density, and position themselves strategically for the future.
David DeRemer (01:00:55.854)
That’s those are all incredible points. And I love the labels that you have for those talent density and all those. Those are amazing. We’ll definitely need to help you tell the story and get it out there. All the things you’re pointing at. We also believe and agree with and you’ve done a really fantastic job of summarizing those. So I mean, we could we could be we could keep talking all day long, Steven. I think in fact, we might have to do more because I think we’re just scratching the surface on probably 20 different things we could each spend an hour on. But
I think to close out this one, one question I’ve really enjoyed asking and you have so many unique experiences. I’m curious what yours would be. If someone wrote a biography of you or you wrote a memoir one day, what do think the title would be and what would it be about?
Steven Stamps (01:01:42.27)
That Stephen cared deeply about his team and each team member, that he cared deeply about the consumers of his technology and that he was a fearless refactor. Yes.
David DeRemer (01:02:07.244)
maybe fearless refactoring.
Steven Stamps (01:02:09.646)
Fairly pursuing new technology, new innovation. So those are probably the three areas. But we’ve talked a lot today, David, about technology. But the bottom line for me, I love the technology, but it’s the people I really have a passion for. if you were to ask me what I’m most proud of, I can…
point out people across a range of industries in extremely senior positions that started with me out of college or that worked on one of my teams. And the impact I was able to have on their lives and on their careers is something I’m really proud of. And not only over the arc of their career, but I worked very hard to make sure that
I position my teams to win. So from our earlier discussion, I make sure they don’t get committed to unrealistic deadlines, unrealistic deliverables. I make sure that they’re not living in a death march, that their weekends and their evenings are theirs to enjoy with family and friends and hobbies. Those are the things I’m
most proud of. Huge passion for the technology, huge passion for the next chapter. I’m really hoping to have an opportunity to get involved in the home robotics industry. I’m looking at some opportunities there, but I would be delighted
to be in any scenario where I can provide leadership to a company that wants to pivot to Flutter or wants to incorporate embedded AI, which we haven’t talked about and is a whole podcast. embedding tiny language models in Flutter apps, building narrow language models to deploy as part of services in the cloud.
Steven Stamps (01:04:32.194)
Those are all things that excite me, but at the end of the day, it’s the people.
David DeRemer (01:04:39.084)
Hmm. Wonderful, especially in today’s world where there’s so much talk about replacing people with technology. It’s wonderful to hear that sentiment and I tend to agree with you. Without the people, what fun is it even? know? Well, thanks, Steven. This is amazing. We’re definitely have to do it again sometime, because there’s other things we could definitely talk about for quite some time. If people want to connect with you, find you, what’s the best way to get in touch?
Steven Stamps (01:04:52.075)
Exactly, exactly.
Steven Stamps (01:05:06.018)
The best way would be a reach out to me on LinkedIn with a connection request. And specifically, I would be interested if you want to connect relative to transitioning your organization to Flutter, if you want to connect on implementing a multi-tier AI machine learning architecture. I’ve done a lot of work there. If you want to reach out.
because you’re part of a humanoid robotics company and are interested in my ideas there for a mobile app for your customers to use. Those are the topics that I would be very excited to hear from this audience. And as always, send all my love to the Flutter community.
It’s very important that you’re successful. And there’s nothing I wouldn’t do to support that success.
David DeRemer (01:06:09.642)
Yeah, I tend to agree with you. Well, thanks so much. Appreciate your time today and for being a guest on our show. And there will be some links in the bios for finding you and all the things you’ve been talking about. So thanks so much.
Steven Stamps (01:06:22.2)
That sounds great. Take care.