Disney Streaming’s Brandon Lonac on Building Engineering Teams With Respect and Clear Communication

Brandon Lonac joined Disney Streaming with decades of experience building software and scaling teams. But he also brought a simple and powerful trait: good manners.

Throughout his career, from pioneering video delivery on flip phones to scaling services for tens of millions of users, Brandon has always tied technical performance to team culture. His guiding principle is clear: Respect, humility, and good communication build better software and stronger teams. As vice president of software engineering, Brandon applies those principles to expand Hulu, integrate Disney+, and drive innovation throughout the company. 

In this episode of Keep Moving Forward, Brandon shares leadership lessons for scaling technology without sacrificing humanity.

  • 36 min

Disney Streaming’s Brandon Lonac on Building Engineering Teams With Respect and Clear Communication

Keep Moving Forward

Play

Respect Is Foundational, Not Optional

Brandon learned the importance of respect as a child. “I attribute my manners to my mom,” who taught him the power of saying “please” and “thank you.”

Common courtesy isn’t a trivial matter, even in the fast-moving world of tech. Brandon has seen how respect shapes engineering team cultures and outcomes.

“When you have a culture of respect and inclusion, and value people's opinions, and give people the space to share and communicate, then not only do they feel more empowered to do their best work, but also then you see the results at the company,” he explains.

Brandon offers a similar piece of advice for engineering leaders: You don't always have to be right. 

“It’s better to be humble, and if you really try to understand other people's perspectives and collaborate, it's all about communication and collaboration,” Brandon says. “If you think you're really right, take a step back and really ask yourself, ‘Are you sure?’ It's not worth really pushing.”

Clear Communication Creates Effective Teams

When hiring engineers, Brandon prioritizes clear communication, assessing candidates by how they explain their choices and whether they can engage in constructive discussions.

“I generally believe that communication is such a large portion of jobs as technologists, as engineers,” Brandon says. “It’s all about communicating with your team members and other people.”

That emphasis doesn’t end after hiring. Brandon encourages being open to new ideas, challenges, and respectful disagreement. “Over the course of a workday, week, month, years, there's naturally going to be some conflict,” he says. “How do you resolve that conflict?”

His solution is to build teams that embrace curiosity and communicate transparently. When engineers feel safe to speak up, teams can work through disagreement and deliver better solutions.

Leave the Code Cleaner Than You Found It

Engineering teams often blame technical debt for slowing them down, but Brandon believes the problem is more about how teams manage debt. Another lesson from his mother inspires Brandon’s approach: “Always leave it cleaner than you found it.” That means leaving your code cleaner, clearer, and in a better state for the next engineer.

“If you're in the code and you're fixing something, then fix something else at the same time,” he explains. “Don't just do the one fix you're asked to do.”

This approach keeps systems running and fosters a culture of ownership and continuous improvement. Whether you wrote the original code isn’t important, because every engineer is accountable for maintaining quality.

For Brandon, the long-term payoff isn’t just better technology. It’s about building teams where every worker is proud of their work and takes responsibility for the team’s success.

Transcript

Brandon Lonac:

When you have a culture of respect and inclusion, and value people's opinion, and give people the space to share and communicate, then not only do they feel more empowered to do their best work, but also then, you see the results at the company, as well. I have been fortunate enough, as well, to be in a couple places where I've seen the benefits of it.

Caleb Brown:

Hey everyone, and welcome to Keep Moving Forward, the podcast from X-Team for tech professionals who are passionate about growth, leadership, and innovation. I'm your host, Caleb Brown, and in each episode, we'll dive into candid conversations with the tech industry's brightest minds, seasoned leaders, forward-thinking engineers, and visionary experts. 

Today, I'm joined by Brandon Lonac, vice president of software engineering at Disney Streaming. Brandon's career spans more than two decades of shaping the way we consume media. He helped pioneer video on mobile phones in the early 2000s, and now he's leading Hulu's expansion, driving integration and innovation at Disney+.

In this episode, Brandon opens up about the lessons he's learned scaling engineering teams, balancing autonomy with standardization, and building systems that hold up under millions of concurrent users. We talk about how respect and simple human decency — things like saying “please” and “thank you” — form the foundation for strong technical cultures. Brandon also shares why communication and curiosity are at the top of his priorities when hiring and mentoring engineers. If you've ever wondered what it takes to lead at the intersection of media scale and technology or how to keep teams grounded while moving fast, this conversation delivers. Let's get into it.

Thank you so much for agreeing to join the podcast and be a guest today. Super-excited. Obviously had an opportunity to dive into your background and everything, and really interesting stuff. You've tackled a lot of just fascinating problems, big problems, and I'm excited to dive into that today, so thank you so much.

Brandon Lonac:

Yeah, you bet. Yeah, I'm excited, Caleb, to be here.

Caleb Brown:

Awesome. Cool. And then maybe we could just kick things off with you walking through your career journey. What sparked that interest in the world of media and streaming technology?

Brandon Lonac:

I've always been interested in working in software that would help impact people's lives. And I started off writing in college, and just after college, building database-driven websites for various companies and real estate websites and travel companies and school districts. And it was exciting, but I was just lured by working in a space that could really impact people's lives and media. I had the opportunity early in the 2000s to find my way into a company that was delivering video over cellphones, and I was just hooked. That was after Napster and like, wonder what's going to happen with media at that time and video? Will similar things happen? And so I'm a huge movie fan, and it was just so exciting to me to have an opportunity to work in an environment where we could potentially be part of the transition from traditional media to whatever it looked like at that time. Now we know, 25 years later or so.

Caleb Brown:

Absolutely. Well, I'm glad you mentioned that, and I was going to bring it up. The platform, you were part of, like you said, pioneering those efforts to put video on mobile phones. And so I thought maybe we could dive into that a little bit more, what it was like developing that technology that was so ahead of its time. And I'm sure you'll set the stage a little bit, but let me do that, is that I was looking into the platform, and I truly believe I had heard of it. I've followed startups most of my entire life, but, I mean, that company started, I believe in 2000. You joined a few years later, and so you're thinking about delivering media on cellphones at that time. It was years later that we even got streaming on something like Netflix, it was so almost a decade later, so it's just such an interesting time. So maybe you can dive in just a little bit more about that time at the platform.

Brandon Lonac:

Yeah, it was very exciting. I feel very fortunate to have worked with a couple people and had connected with prior companies, and just connected with them at that point in time, it was 2004, I think, 2003, I think, when I joined. And I was brought on to help bring small, one-inch-by-one inch videos to flip phones. At the time, that was all the rage to have a flip phone and a Razr and all those kinds of those phones. 

Large part of that, the biggest challenge was two things. One was actually getting the phones to play the video. I recall there were some challenges with the OS and just even the capability of the phones at that time, as well as just so many integrations that we had to do in order to make the content available and get it to connect into the cell providers.

There was a number of integration challenges that I had not been exposed to yet in my professional experience in the other startups I'd worked at. But I started to learn about how you would connect various systems to each other, what it would look like to have contracts that were easier for systems to connect with and stable. If I recall, there was a lot of iteration, and so there then was a lot of churn at that time, as well, about how to get the information into the cell carrier system, and then we could make everything connect it all. So that was my first real exposure, as well, not only to a direct consumer-facing experience that definitely was different and revolutionary, but also starting how you piece large software systems together. How do you think about systems that can scale, especially when they are servicing empowering consumer experiences?

So it was a few years later where that work at the platform had started to support a number of large consumer brands, bringing video to websites and things. And the challenges that you have to solve and face when you really are supporting brands that are directly supporting consumers. And so you start to learn during that same time of having to learn that you can't always plan for what users are going to do. And if, all of a sudden, there's some breaking news or something, everyone wants to see it, right? And so then, you start to deal with, how do you build systems that are scalable and can handle stampeding herds, so to speak, and traffic while keeping the experience up? So those are some of the big things from that period that I had to work through, and feel very fortunate to have had the opportunity to help others to solve those problems.

Caleb Brown:

100%. No, that's super-cool to be involved with that kind of streaming media at that time and to see the evolution of that over the years, of course. Switching gears just a little bit, I think on our prep call initially, you had mentioned the importance of treating everyone with respect, always saying “please” and “thank you.” And, of course, a simple approach, right? What we tell kids early on. But I was still struck by it, and thought it was very interesting, and want to dig into that a little bit more and talk about how that approach impacted your leadership style?

Brandon Lonac:

That's a good question. I attribute my manners to my mom. There was always, "Brandon always say, please. Always say please." And really from her just really learning the value of respecting everybody. Doesn't matter who you are or who they are, what they do, everyone deserves respect. And that really has impacted me over the years as I've moved into more leadership roles, and I think it translates. But one thing I've found is, especially with hierarchy of roles in companies and whatnot, is that it's easy to have a perception that you don't necessarily need to say “please” to other people unless maybe you're a higher role than they are or lower at, and I've seen it myself and witnessed it. There's a breakdown in some ways in almost social manners or norms sometimes. And I've also experienced that since then that leads to a less-than-ideal culture where people don't feel safe or they don't feel comfortable sharing ideas or communicating, and I've seen the result of that.

It may seem silly, I think, to put effort into that kind of communication because you’re in software and technology and things like that. But I've seen negative impact to some of the companies I worked at over the years as a result of that. But I've also seen the flip side, where when you have a culture of respect and inclusion, and value people's opinion, and give people the space to share and communicate, then not only do they feel more empowered to do their best work, but also then you see the results at the company, as well. I've been fortunate enough, as well, to be in a couple places where I've seen the benefits of it firsthand. 

So go back to a lot of validation, I think, a tribute to my mom, instilling those basic manners with me as I grow up. But then now, also, be able to see just the impact and personally in times in my life when you generally try to always be polite and respectful of people, ask them questions, respect their time or whatever.But then also also reflect on times when I've not done that myself in certain situations, and then later on you feel — I mean, I don't feel so great about that interaction, and I reflect on it and I'm like, "I don't think I was treating them with respect." And that outcome was harder, and it wasn't a great outcome, I think, maybe for anyone. So drawing some experience to validate that, in general, better to treat people with respect and always say “please” and “thank you.” There's positives on the outside of that for doing that.

Caleb Brown:

100%. And obviously very important when talking to humans, but that reminded me of something I just saw, and I don't know if this is true. But I just saw something online that said that being mean to LLMs, like coding assistants, improved their coding ability, and that bummed me out so much. I hope that's not true. I hope if that is true, we can fix that.

Brandon Lonac:

Yeah, I've not seen that, but I agree. That kind of bums me out.

Caleb Brown:

Yeah, me too.

Brandon Lonac:

I hope that's not true, or they can remove that.

Caleb Brown:

Yes, I hope that is the next AI technology is making them work when you're nice to them.

Brandon Lonac:

Right? Yeah, exactly. Exactly. Let's take the good things that we do, not the bad things.

Caleb Brown:

That's exactly right. When hiring for your team, I wanted to just ask you what you're looking for in their responses?

Brandon Lonac:

It's a good question. I am, at this point, over the years of interviewing lots of people and things, I really look for people's ability to communicate their ideas, communicate their decisions. And when I'm interviewing — generally for the position, it usually varies a little bit on the position, but in that case, you ask that question, "What's been hard, and how'd you solve it?" to gauge their input as well. So, how well can they describe the solution, how well can they describe their opinions about it, communicate about it? Usually, through those kinds of questions and information, you can tell how involved they were, whether they're overstating or not, because I find, as well, that just asking people to explain, "Well, why did you choose technology X versus Y?" You can usually find out about how passionate maybe they were about that decision.

And I actually will, as well, I play devil's advocate. So even if I agree, or maybe it's something like, "Oh yeah, X is clearly the right choice there, in that case," but I'll say, "Well, why did you choose Y? I've heard Y does, maybe it's 20% faster." Play devil's advocate a little bit, and do that as well just to help gauge how people respond, or if they're able to communicate again particularly about the ideas, or maybe they get flustered. I've talked to people in the past where asking them basically the counter-question, "Well, why did you do that?" and pushed on that a little bit, they get frustrated, and they don't necessarily respond super well.

I do this because I generally believe that communication is such a large portion of jobs as technologists, as engineers. That it's all about communicating with your team members and other people is a majority of it. And then written communications. Over the course of a workday, week, month, years, is naturally going to be some conflict. It's naturally going to be a disagreement with your peers, and how do you resolve that conflict? 

And so to me, I've found, with trying to ascertain someone's ability to communicate and how they respond to maybe asking, "Well, what do you mean? I disagree with you." That's really my goal, and I've found that to be pretty effective, I think, in helping to build teams, helping to pull people together that are already good at communicating and sharing ideas and resolving conflicts.

Caleb Brown:

Absolutely. That's helpful. That makes sense. We've talked a little bit about communication now and teams and things like that. And I imagine some of the earlier companies you started with were smaller, but at this point in your career, you're working on much, much larger teams, much larger organizations. How do you maintain cohesive communication across such large engineering organizations? And especially we're considering things like Dunbar's number of limitations, 150 connections. How is that at this kind of scale, and how do you manage that?

Brandon Lonac:

I think it's really important to set expectations and make sure that people know what is being asked of them and what their guidance is. So going back to communication for a second, this is partially why I think relationships and communication are like the foundation of technology. Because if people feel safe to communicate, they'll feel safe to share their ideas, and if they share their ideas, then people will give their best work, right? They'll truly be able to communicate with people and hash out ideas and drive and deliver features and value and whatnot. 

And so I think that goes back to how you organize lots of people. Is that helping to create that safe space for them and setting their objectives, "What are the expectations?" And give them the context and say, "OK, go build this." You have the trust, you have trust in your teammates. You feel safe to create, to share your ideas, to experiment, to even fail, but to iterate. As long as people have as much to possible, "Here's the expectation, here's the outcomes we're looking for," that creates the space for them to build in that and fill in the gap. I think going down and having to be very specific about giving detailed instructions to lots and lots of people, that's just time-consuming, and it's a recipe for disaster that gets towards full waterfall and things, processes. 

So I think the key is setting expectation. Objectives, I think this is where OKRs are great, making sure teams know this is the top-line goal, here is the key metric that we measure against. And then if teams feel safe, "Go implement, go meet this goal, work to meet that goal, and iterate in your smaller group.” And checking in on progress of those OKRs, I think, is critical. Which then also is to make sure that everybody knows what they are. You got to make sure that everybody knows, "This is what we need to do." 

But it's also important to say why. I think I love Simon Sinek and his perspectives about that you always start or begin with why. It is so important. It's so true. Having that bit of information of why this is important to the business, why it's important to our users, why is it important to maybe the team itself, we have to improve our support systems or whatever, that why is super-critical. And so focusing on why it's important, setting the objectives, the high-level goals and make sure people understand that, and then give them the freedom and the space to deliver within, launch features within that framework, I think, is the keys to large organizations.

Caleb Brown:

So no, that definitely makes sense. So I did want to just dive into that a little bit more because I'm wondering how you kind of balance standardization across an organization while you're still giving teams and individual contributors, to some degree, the autonomy to solve those problems in their own way?

Brandon Lonac:

So my experience over the years in technology, I think there's really only a couple things that you really have to standardize on. And I think there's probably lots of things you could standardize, and I know there would be levels of benefit to more standardization or not, but then it reduces freedom. But in terms of what they really need to standardize on is, how does engineering, how do developers release their software, how do they deploy their code? Just the process about releasing and sending out features, I think it's super-critical to have as much standardization as possible in that build pipeline, in the release process, CI/CD. Like all those practices, as much as possible, standardized because those are things that meaningfully impact not only the business but also the users and experiences. Users come to expect to use your product, and any downtime to those products, that really impacts them. So I think standardization around deployment, build processes. 

Obviously, I think, support, pager-duty type. How do you interact with incidents, how do you engage teams? You can't send a text to one team and send a Slack or email to another. You need to have all the same communication standards there. And then, as well, I think there's a size in your company, as well, where teams can be autonomous in what they choose to build. what technologies, what languages they use, what data stores they use. But I think when you cross a certain threshold and engineering size, that's also, too, where you need to standardize a little bit on what languages are used and what data stores that are the backbones for the technology stack and things.

Caleb Brown:

That's helpful. I'm glad we went into that because that's interesting and very helpful. And I actually have yet to work on a team that large. Probably the largest engineering team I've ever worked on is maybe 10 folks. So it's interesting to hear the perspective of such scale. And speaking of scale, you were part of Hulu's growth at around 5-6 million subscribers, all the way then up to tens of millions. And so I wanted to talk a little bit about what was the biggest technical challenge there of scaling that you faced from that kind of growth perspective, which is a lot of people?

Brandon Lonac:

Yeah, it was. The largest challenge, I think, has been over the years supporting a live linear system. Linear is so much different from just regular VOD, video on demand, or YouTube, and you're just watching clips at a time or maybe individual shows or something. But linear is connected back into the traditional broadcast media infrastructure. And so because of that, you're still limited by how the broadcast companies operate, as well as you have a connection into consumers’ expectations for how linear should work and how it should look, what they should see and interact. So those are two hindrances that shape a little bit of how technology, how you have to build it and then deal with scaling it and new features to bring it to a product like Hulu.

Caleb Brown:

So kind of staying on that topic a little bit, when leading the integration, Hulu into Disney+, what are some of the kind of complex technical or even organizational challenges that you encountered in that kind of situation?

Brandon Lonac:

A lot of the challenges in that case, this goes back to my feelings over the years like, what do you standardize on, and how you communicate, and what processes do you use? In that case of bringing Hulu to Disney+, there was a lot of opinions, and so we had to work through and create, identify, which opinions needed to be sorted out because not everything was important to have to resolve and hash out. But then help folks to figure out which ones are the most important ones to solve. And then it becomes a case of helping the engineering organization organize into a way that could complete and work the project.

So forming areas of focus. So let's say, "Oh, this is the log inside, this is the playback stream, this is the browse stream." So basically, for lack of a better word, barring from SAFe, like release trains, create various release trains for the different types of work that needed to be completed. And most of the challenges were making sure that those, like say, release trains of functionality were all aligning in the same direction. And when they had to stop and meet at the same integration points, that they would.

So that's the largest part around getting a lot of engineers working on the same functionality, bringing such a huge catalog and feature set like Hulu and making it available on Disney+. Really all about integrating and making sure the engineers can communicate at the right time.

Caleb Brown:

Like I said, I've only worked on pretty small teams, so this kind of scale is really fascinating to me. What's your approach for technical debt when operating at, again, a massive scale, millions of users that are depending on your services? I know that people get pretty mad when their videos do not play, so they are depending on your services. So I was interested on technical debt on that kind of level.

Brandon Lonac:

I feel that and think that technical debt, it's used as a derogatory term, I think, in software. And I think it's used to describe, usually, decisions that were made by previous people who are no longer there or maybe moved on to another team. More often than saying that it's, what I think is the more correct definition of it being, is a level of friction in the services that's a slowing down velocity of development. So taking that lens on it, I also feel that it's a crutch. It's used as a crutch or an excuse sometimes by engineers not to do something: "I don't want to do that because tech debt, or it's not interesting because it's not a new feature capability." 

And my perspective on that way is, because usually I've seen over time, as you get large initiatives that like, "Oh, fix the broken windows, put time towards fixing tech debt," where, I really actually think my perspective is that it's an engineer's responsibility, and it's the team's responsibility to always be fixing. Always be fixing. And I'll go back, this is another thing from my mom, which was she was like, "Always leave it cleaner than you found it. Always leave it cleaner than you found it. Pick it up, leave it cleaner than you found it." And so my perspective is apply that to software. And I've told this to the teams over the years, "If you're in the code, and you're fixing something, then fix something else at the same time. Don't just do the one fix you're asked to do. Leave it cleaner than you found it."

And they say, "Oh, it will only take me an hour or two." "Well, just double that. There's not that much difference in the grand scheme of thing in times, whether it took you an hour or two to do something versus two or three or four. Just leave it cleaner than you found it." And I think over time, it helps systems, and I've seen this as well, it can help your system stay more maintainable longer because it is operating at efficiency. You might have better observability, the teams feel confident about making changes because you probably also have some automated testing and quality, so to speak. 

So I think there is a threshold if you have too much tech debt, and people feel that they're like, "Oh, that's due to the old team or it's inherited or whatever." But even in that case, I still push on folks to do your best with cleaning it up, and then if there really is a point at which that's not going to happen, there's too much work to do, maybe a large-scale migration of versions on something like a data store or a large third-party system or something you have to do a big migration, OK, those might have to be projects. But I think generally being positive about not using the word “tech debt,” but then leaving things clearer than you found it in improvements.

Caleb Brown:

Right out of college, I joined a startup, and I feel like I never learned, "That's not my job." I feel like what has benefited me a lot is just naturally wearing a lot of hats in an organization. I think that's very cool to hear that if you're working on a feature or a bug and you see something else, improving that along the way and not just waiting for someone else to make a ticket on that. I like that. 

And I wanted to ask you the last question on the scaling stuff. Just any advice you'd give to an engineering leader who was transitioning from a startup environment to a much larger organization. Any kind of advice you've had for someone in that position.

Brandon Lonac:

I would encourage them to be open to learning. And I think from a startup, like you just mentioned, you had worn many hats. I did startups early on in my career, too, and I did the same thing. You wear a lot of hats, and you really learn. You can go all over the system, you can go from front end to back end, and I think it's really helpful for engineers to get that perspective. And I think that's then useful for transitioning from a small company to a large company because, coming from a small company, you have to lean in, you have to say, "Oh, I'll pick up the trash, too. It's not my job, but I'll pick up the trash." And I think that mentality of leaning in — and the goal here is to help the overall business and all of our customers. The goal isn't necessarily to help your specific team and say, "No, that's not my job. I'm on this big team." It's all about the overall goals for the company and even engineering organization. 

So I would encourage folks to be open to learning, lean in and see how they can help the broader teams. And be open to maybe challenging some of their assumptions that they may have like, "Oh, this is how you build software, or this is how a system scales." I think just be open to like, "Oh, well, maybe that doesn't always work." So probably those would be the three top-of-mind things that I would tell somebody.

Caleb Brown:

Love that. Yeah, that's awesome. Just a question or two, I wanted to wrap up on kind of a future outlook kind of thing, future perspective thing. I just want to know, you've been in this world for a while, and specifically in media and streaming media, how do you see streaming technology and even architecture evolving over the next five to maybe even 10 years? I know that's quite the outlook.

Brandon Lonac:

It's a good question. I think over time, we've seen, even a few years ago, standardization in how video gets delivered, more commoditized. So now we have actual video delivery is pretty commodity. I think the same can be said for experiences like discovery, how do you go to a website to see what you have. Lots of brands have their own video service, and that's just a reflection of commoditizing it, of how you can show content to users. I think that trend will continue, that it's very easy for brands just have anything they want, but I also think that those people won't really probably engage with those as much. 

I think there is kind of a consolidation of brand and eyeballs, I think, of how not only users, consumers, what they'll choose and where they'll go to find their content, but then those places that they go to find their content will increase their diversity of content, have more and more things, might have more and more overlap. I think we've seen this already with other streamers getting into live like Netflix, and Apple, too. So you're starting to see all the big players do similar things. I think that'll continue. 

And from a technology perspective, there's definitely going to be a shift away as well from how we deal with broadcast, I think. That's also going to start to change. And then I think in terms of scaling, every year, we see now with LLMs  is that it'll be easier and easier to have really high-scale systems that can handle millions and millions of users. As parts of those systems become more commodity in themselves, which then will free engineers up and teams and things to really build the features and personalization that really is focused on their particular brand or experience or type of content.

I think we're definitely seeing trends where that becomes easier. And what was a few years ago, super-difficult — you needed completely your own personalization system and pipelines and your own models and teams and online inferencing and all those kind of systems — you can get that stuff now through cloud providers, right? It's just stitching those things together. So I think the benefit there is more time, again, more time to build engaging experiences, focusing on a business's particular challenge or focus that they want to solve for.

Actually, the last thing, turning to our engineers. Every engineer who would benefit from personalization experience and understanding machine learning and models. And that is just going to be more the focus, and having that experience in any way, even if it's able to actually able to produce and write a full custom model and system versus just knowing how to put the pieces together from cloud providers, will be critical, especially in the next five to 10 years.

Caleb Brown:

Awesome. I wanted to just kind of wrap it up then on, like I said, you've had a phenomenal career, incredibly interesting. I wanted to know the single most important kind of leadership lesson that your career has taught you, and what you'd like other engineers to know, how you'd like to kind of share that knowledge that you've learned over the years?

Brandon Lonac:

You don't have to be right. And when you think you're right, and you're really pushing that you're right, you may be right. However, it doesn't always end as you may think it does. So it's better to be humble, and if you really try to understand other people's perspectives and collaborate, it's all about communication and collaboration. But the one thing is, if you think you're really right, take a step back and really ask yourself, "Are you sure?’ It's not worth really pushing.

Caleb Brown:

Absolutely love that. I think that's a very good one, too. And Brandon, thank you so much for your time. I really do appreciate it. This was great. This was great. I really enjoyed this conversation.

Brandon Lonac:

Great. Thank you, Caleb. Yeah, you too.

Caleb Brown:

Absolutely. That was a masterclass in leadership and technical perspective from Brandon. What resonated most with me is how deeply Brandon ties high-performance engineering to culture, specifically to communication, humility, and respect. He reminded us that the most scalable systems are built by teams that feel safe enough to speak up, challenge assumptions, and iterate without fear. From advocating for everyday manners to champion team autonomy within clear goals, Brandon has a way of grounding big technical conversations in very human truth.

And his point about always leaving the code cleaner than you found it, that's the kind of ethos that doesn't just scale products, it scales teams. Brandon's insight offers a clear roadmap for anyone navigating leadership at scale, from building resilient teams to cultivating the kind of culture where people and ideas can thrive. 

Join us next time for more insightful conversations with tech leaders who inspire us to grow, lead, and innovate. Find us on Apple Podcasts, Spotify, or YouTube Music. And don't forget to share this episode if it resonated with you. Until next time.