Steven Stamps - Leadership Lessons
for Modern Engineering Teams

David DeRemer: 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: 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 to grow, and I'll do what I can to help. I ⁓ do hybrid work 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 to compose music, play a lot of musical instruments. collect cars.

I enjoy cycling trips and aviation is a hobby, both as a private instrumented pilot and as an owner of several airplanes. And ⁓ in another context, one these would be a podcast all by itself. David DeRemer: 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 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 your to management, engineering, technology, design, etc. ⁓ Steven Stamps: 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 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 we're not talking about overloading processes with high ceremony documentation. ⁓ this maps to how I to lead teams. every ticket has checklists, every release has checklists, and just helps to make that 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 not only plan the flight of the destination airport where we'd like to go, but alternate if that airport snowed in or has bad weather. And even in that airport, alternate approaches and procedures. I also, every ⁓ journey and a lot of them included my family, I had an FAA certified 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 last, well, actually not last. The third part of that is key transitions. In aviation, the transitions are takeoff and landing.

Takeoff is things can go and it's really difficult to recover. And so you need to do a lot of preparation before takeoff to make sure that equipment and the runway and the are 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 on the bus, if you will, the right scope, right KPIs and metrics for measuring success. ⁓ If you don't get right very early on in the project, the rest of the project is going to suffer and may even And then ⁓ the landing metaphor, you know, a project be going really well, it's a long-term project, and then the leaders their eyes off the ball and project wanders and loses focus isn't successful. So, and then the last piece from aviation I would share that's critical 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, address the situation. But what happens too is that pilots do not confess that there's a problem. They try to solve things themselves, problems pile up on each other. ⁓ And by the time they do confess, it's too late to save the airplane and save the occupants.

Exact same with projects is when that project starts going sideways, ⁓ there's risk, you need to confess immediately. You need to talk to your team. You need to talk to your organization. if you, Talk to people early and, leverage the wisdom of there are very few situations you can't overcome and get back on track.

yeah, aviation has been a part of my life. Wow. David DeRemer: 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 dive into those and how to actually do that.

Sounds like aspiring product leaders and engineers ⁓ want to consider getting some, some flight training. It seems like it would be a good, ⁓ skill to add to the, to what they're able to do. Steven Stamps: 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: 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 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: I can, and I might surprise you a little bit with the prologue to the story. So my mother passed away year at the age of 100. Not a sad thing. She had an incredibly rich life.

And when I look her life, she was a teacher. She 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 use a computer and a phone better than a lot of people. And I look at myself and when I started in this profession, I was using Fortran which had no subroutines. and it was on an IBM 360 using punch cards with JCL. So that was my beginning then And I also, the very beginning, we lived in a very different world.

There wasn't there wasn't open source. And so every computer had their own unique bespoke hardware, their own unique bespoke operating system, their own languages. And I was counting up the night, David, and I counted 12 different systems. that I had to use and learned in my first four years.

360, DEC PDP, Wang, Univac, Burroughs, NCR controlled data, Honeywell, Data General, Prime, GE, and MacroData reality with the pick operating system. Every of those had three lineal feet of technical because there was no online docs like we're used to today. And ⁓ so time needed to interface with the system, you had to break out. 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 special to identify where ⁓ the industry and needed to what technologies would most likely take us there, and then would become an early adopter and advocate.

for those technologies. And 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 hardware, computer, and a nine track tape from AT &T Bell Labs with Unix System 3 on it.

basically, I ⁓ a crate full of hardware from DEC with operating system and a tape. had to write a C program bootloader to bootload Unix from the nine track tape ⁓ the hardware. And this 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 thinking about this podcast, I put together a list ⁓ of the major innovations that I adopted. next was relational databases. Believe it or not, that was a new wonderful thing. Object-oriented programming.

A side note there, before object-oriented in C, I was actually creating structures ⁓ that included data and 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.

⁓ actually bought Sun Workstations from Scott McNeely and Bill Joy from the back of a station wagon on Wall Street in the early days. Then there was They were invented after started. Then the and the internet. Java was a huge forward.

REST and then Linux the LAMP stack, cloud computing and virtualization, NoSQL, mobile and Android. was very early with Android, very with Kotlin. What a lovely language. Then Flutter and Dart.

I have to confess I was initially ⁓ disappointed that it wasn't Flutter 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 folks in Silicon Valley because I'd like to get involved in home-based robots and using Flutter to build the mobile apps that would use to monitor and manage and...

provide some extra safety features for home humanoid robots. So that's ⁓ good arc of my career that ⁓ of matches my mom's going to work on a horse ⁓ then flying out to NASA to learn all about science. David DeRemer: 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 ⁓ 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, Are there things that have held true throughout your career?

Steven Stamps: There Let's. I think we all know that the people that have not changed. 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.

People and organizations have not changed. One of the issues 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... something that has always been there and has changed.

Another way it's expressed 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 amazing product for the organization ⁓ and for users, but something is place that's good enough. It may even be object-oriented cobalt, just have some fun there.

But the engineers know and the product managers know that 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 who are resisting are often the people who built their career on the existing way of doing things.

We, meaning you and I our Flutter community, deal with that every time we try to get an organization to pivot to Flutter. You've got, the case of Disney, I had 60 Android engineers building the ESPN app and ESPN Plus ⁓ and a of other Disney apps. There were equally iOS engineers. They each had their own organization of leaders and hierarchy and politics.

And to this day, I have been able to get them to address ⁓ the fact that they could be saving tens of millions of dollars every year addressing 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 and organizations that technology changes very quickly relative to human tribalism. which hasn't changed for 10,000 years.

you know, people, in the case of our Flutter world, you've got the iOS tribe, you've got the Android tribe, and that's ingrained of human nature and is always a to and those teams together. Although to be very positive, I have done 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: Yeah, love to dig 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 make those transitions effectively? Because I think you're right.

The human tribalism, the You know, maybe there's even genetic, right? And deep human behavior that makes us 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: there's different scenarios to talk about here. One is the Greenfield scenario, like were discussing ESPN as an example, where they're not using Flutter, they're not thinking about ⁓ Flutter. In that situation, 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 to speak in terms ⁓ of leadership value systems, aligning the technical issues with the balance sheet How is this going help us ⁓ save money? Not only 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 ⁓ in is from the top down. It's just not going to work otherwise. But second scenario, which I a lot, is you have an you have a tech stack that at one point in the too distant future, was pretty modern. And then approach is to create a culture of perpetual And I call it fearless refactoring.

This happens a couple different ways. One ⁓ is just about every an goes in enhance a ⁓ 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 immediately a ticket for all of those. We immediately identify what point in the future we want to work on ticket.

and 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 separate podcast also, one of the metaphors I use with my teams is that we've all 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. if my team is capturing every 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 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 business. that's one of the ways. Item number two, as a leader and especially as a senior leader, I choose to beg forgiveness.

So, 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 minimum viable product that I could deploy. And this is 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 just anticipate that's going to happen and sure at least that the metaphors and the abstractions going to support a longer term production ready But that doesn't happen, what I may ⁓ David DeRemer: Mm-hmm. Steven Stamps: is go ahead and slip that into production anyway.

and everything team does in 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, was exhibiting a executive leadership initiative. And the way, here's the 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. do you want me to pull it out of production and that opportunity? So those are some of my techniques. They're not favorite of some of my very senior leaders.

But at the end of the day, that in some cases seems be the only way I can keep my organization moving ahead and moving modern. I did that the way with AI. We'll talk about that a little bit. later on, but that's exactly the approach I took with AI previous employers.

David DeRemer: 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. you ask for permission you're never gonna get it you know in those types of environments and cultures sometimes the only way to 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 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 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 taking innovation. And I think that that's Steven Stamps: to interrupt David, but I'm familiar that scenario, but I contend that ⁓ those two are not mutually exclusive. I think they can be fully supportive of each other with the right culture, with right processes.

know, earlier 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 muscle that's been exercised hundreds of times throughout the year with checklists, with historical KPIs to 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 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 side ⁓ point is that teams ⁓ product teams, engineering teams, they go on Whether triaging deciding how to optimize the performance of a stack or whether you're ideating on how to optimize a user experience 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 your time and resources on the things. David DeRemer: 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 is pretty low, ⁓ that's to work out pretty good for you, I think. Steven Stamps: It usually does. I'll use AI as an example and I won't go into any great details.

But the problem with innovation is the politics. I did a of work at my previous employer the AI team in another part of the organization you know, after two years still hadn't delivered. 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 in a perfect world and there are going to be times where the organization is not going to make sense. David DeRemer: 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 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 fortunate enough to get to know you and meet you as a result of your involvement in the Flir community. Can you dig into a little bit for us around?

How did you find Flutter how did you manage getting that in and kind of like leading a transformation to build apps in your previous roles? Steven Stamps: You bet. So as I had mentioned earlier, I led a team of about 60 engineers and product managers at Disney for ESPN app ⁓ and of the other apps that I was responsible And I was extremely frustrated with the involved and the ⁓ inefficiency there. And so I was recruited away from Disney by AWS, and in that case not the advice I've so many young engineers, and that is not make decisions based on compensation.

know, AWS was me more money than God, but the culture and... 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 ⁓ that 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 more powerful than the servers that I was using the two thousands to manage massive transaction volumes ⁓ for ⁓ and So very exciting.

But I hated the and the technical stove of iOS versus Android. You know, there's been a couple of other before Flutter to do cross-platform mobile, and of them were satisfying. I thought I would take a swing at Flutter, and I used at startup, fintech startup, 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 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 with ⁓ Enzo, with this startup.

They were underfunded and led as 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... 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 without full engagement and, leadership, their client. So otherwise you're caught, you know, guessing what's going to work or what's going to be successful. And, it's unfair to you and it provide the results. So that was it.

going on there. So I, I, built out a world-class team of Flutter shout out to every one of them, amazing team, and, established this culture fearless refactoring, established a culture ⁓ no one swims alone. you know, every feature owned by the entire team. Every problem is owned by the entire team.

established a core architecture team, which were essentially the and most innovative engineers who met every for an hour at 730, bless their heart. But that was 730 Pacific The reason for time was that 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? those kinds of 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. was called MCOR for Mobile Corps. And the was on average, you'd only have to wait 12 hours to ⁓ get answers get And so just wait until tomorrow morning then you've got the entire there and attendance was required. So everyone had 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 a really exciting meeting and exciting time.

David DeRemer: you managed to convince the leadership there to ⁓ with Flutter. And so what was that process? Steven Stamps: They are, in fairness, had started, but there was, but at the time I was ⁓ recruited, was question, you know, was the flutter decision the right decision, you know, they weren't getting they, what they wanted to, get out of their 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: Okay, cool. Nice. Yeah, we've seen that you can imagine many, many times where you read 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 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, practices of the teams and the things that go into it.

⁓ 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: I 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 take this and you to take this app.

And the vision that I introduced into this team an event-driven architecture. We'll talk about a little bit more later, but it's really critical that both the product people and the engineers also have a clear architecturally. 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 vision and why it was important and why they needed to thoroughly understand it and 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. worked with the team create a very thoroughly defined release candidate and release process with KPIs that be followed religiously for every And initially we went to every weeks, then we tightened down to every three ⁓ and then in less than Five months, we were down to every two weeks, a release, and the of bugs was single digit, and none of them were P1s or P2s. That did a couple of things.

allowed us to publish release calendar a year in advance. Why was that important? Because ⁓ when stakeholders technology partners come to us talk about when they wanted to deliver something, my questions would always direct them back to the release calendar ⁓ when do you think you want to release Now, we'll get in a little bit to my perspective as a senior leader. I spent a lot 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. So of the benefits in meetings, I would pull up the mobile release calendar and I would say, so you Q4, do you mean this release at the end of December? And by 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 for November 11th or the date happens to be.

Is that the you're talking about? They would say yes. say, well, ⁓ so if that's you plan on releasing that feature, which is being driven by this back-end service, then we'll need a 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 is I sit there, let this happen. Commitments are now made to the board of directors to business partners external to the company that we're going to deliver something on or whatever. We've all been there before. What happens?

Nights, weekends, ⁓ don't 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 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 through the realistic opportunity is build and deploy this. David DeRemer: I want to also dig in with what 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 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 in the future are a valuable part of your technology approach. Steven Stamps: The reason I wrote that article is I think this is a pivotal moment in time for the Flutter community and leaders such as yourself in that community to 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 ⁓ is in lot of industries like hospitality, where I was previously, The profitability has, 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 a certain level of profitability. 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. that's consistent with the current culture of pruning back the organization cut expenses, but is ⁓ unlike lot those other decisions, would be a very strategic move to position themselves to perpetually save $10 million a year on staff or on contractors.

⁓ The cost savings 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 issue parity and feature parity and parity debt. Either the Android or the iOS team rush with the feature, it done before the other platform and deploy it, or would ahead and it done and then have to sit on it for two months waiting for the other to finish and test ⁓ their feature. That is 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 just-in-time of ⁓ raw materials. ⁓ idea was, an auto manufacturer doesn't need 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 sitting back in the warehouse and the company is not benefiting from those benefits. ⁓ And so you need to focus on what business is referred to as inventory turns. As soon as an engineer and product manager works on a problem or new feature, that 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, ⁓ a huge, huge issue in my book that nobody talks about. Also the asset. time you write a line of code, you're creating an asset for the company.

If that asset in flutter, ⁓ David DeRemer: metaphor. Steven Stamps: then not only can you deploy it to iOS and Android, but we did this MGM. We deploy the same Flutter code to Windows, to Linux, and the web. now to be able, basically ⁓ like a tangible goods company able to sell the exact same ⁓ product.

to three different customers make that revenue three times over. So that's something else that people don't talk much about that in my view is ⁓ valuable. The other topic is the other driver is velocity ⁓ and market is when ⁓ now instead having spread across different platforms, Android, iOS, Windows, all your best people are down into one team that can 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 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, are the average of the five people that you most commonly work with every day. And so, as 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. to new levels that were unimaginable. And that results ⁓ velocity and market agility.

The last point I would make that's a for this is risk and brand consistency. This is the way to make sure that Your digital storefront identical the same high quality regardless of the platform, web, iOS, Android, Windows. And now you have talent density, not only on engineering and product, but on QA, you can also have even higher quality. deliveries 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, a single team with tremendous talent density, and themselves strategically for the future. David DeRemer: 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, question I've really enjoyed 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: That cared deeply his and each team that he cared deeply the consumers of technology and ⁓ that he was ⁓ a refactor. Yes. David DeRemer: maybe fearless refactoring. Steven Stamps: pursuing new technology, new innovation.

So those are probably the areas. But ⁓ we've a lot today, David, about technology. But the bottom line for me, I love 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 started with me out of college or that worked on one of my teams. And 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 career, but I worked very hard to sure that I position my teams to win. So 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 evenings are theirs to enjoy with family and and hobbies. Those are the things I'm most proud of. passion for the technology, huge for the next chapter. I'm really to have an opportunity to get involved in the home robotics industry.

I'm looking at some there, but I would be delighted to be in any where I can provide leadership to a company that wants to pivot to Flutter or wants 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. Those are all things that excite me, at the end of the day, it's the people. David DeRemer: 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 tend to agree with you. Without the people, what fun is it even? know?

Well, thanks, Steven. This amazing. We're definitely to do it again sometime, because there's other things we could definitely talk about for quite some time. If people want connect with you, find you, what's the best way get in touch?

Steven Stamps: Exactly, exactly. The best way would be a reach out to me on LinkedIn with a connection request. specifically, ⁓ would be interested if want to connect relative to transitioning your organization to Flutter, if want to ⁓ on implementing a multi-tier machine architecture. I've done a of work there.

If you want to reach out. because you're part of a humanoid company and are interested in my ideas there for a mobile app for your customers to use. Those are topics that I would be very excited to hear from this audience. And as send all my love to the community.

It's very important that you're successful. And ⁓ nothing I wouldn't do to ⁓ that success. David DeRemer: 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: That sounds great.

Take care.