Agile Development Gives You Wings: How Red Bull Paired With Artium

Agile Development Gives You Wings: How Red Bull Paired With Artium

By

Admin

on •

May 2, 2023

Agile Development Gives You Wings: How Red Bull Paired With Artium

“Your business applications should be just as intuitive as every other app or website or anything else that you're engaging with in your day-to-day lives”. That’s the product-led approach that Jon Walton took as an engineering leader at Red Bull, where he spent nearly a decade working on the apps that help the energy drink maker run the extreme sports competitions and spectacles it's known for.

Here’s Jon Walton on Crafted, Artium’s new podcast.

Listen and subscribe to Crafted: Apple Podcasts | Spotify | All Podcast Apps

Jon Walton: ... your business applications, whether they're a finance tool or a sales tool or a marketing tool or whatever else in the portfolio, should be just as intuitive as every other app or website or anything else that you're engaging with in your day-to-day lives. And that is really the argument in the case study for why product-led organizations is really the right way to approach technology portfolio spend and strategy in any organization going forward. It's something that we really focused on at Red Bull.

Dan Blumberg: That's Jon Walton. He's a product and engineering leader who spent nearly a decade at Red Bull working on the apps that helped the energy drink maker run the extreme sports competitions and spectacles it's known for.

Red Bull Clip: I'm going to try to land this plane on this tiny helipad.

I wanted to be the first human outside of an aircraft breaking the sound barrier.

Okay. Here we go, Felix.

I'm going over.

Dan Blumberg: Things like a sky diver's free fall from space or flying a plane through a tunnel or having F1 drivers race cars in reverse or... You get the idea. In this episode, Jon tells us why these special events needed special custom-built software and how Red Bull improved the way it built software in the first place by embracing principles like lean, agile and pair programming that we're so fond of here at Artium.

Jon Walton: It actually transformed the teams' relationships between each other, but the ways that they operated together in ways that we just didn't even anticipate.

Red Bull Clip: We're going to see how far they can go. They're off. Jump into the mighty Mississippi.

Going big is what he does.

Dan Blumberg: Welcome to Crafted, a show about great products and the people who make them. I'm your host, Dan Blumberg. I'm a product and engagement leader at Artium, where my colleagues and I help companies build incredible products, recruit high performing teams, and help you achieve the culture of craft you need to build great software long after we're gone. Like a lot of our guests, Jon's starting point for software development seems unconventional. He trained in biomedical engineering with the intent of going into medicine, but he specialized in computing and imaging and that brought him to the FAA, where he built air traffic control systems. The scientific nature of product development at the FAA really appealed to Jon, especially as it applied to human computer interaction.

Jon Walton: You can imagine very rudimentary things like colors of text and location of buttons and the speed and frequency at which things flashed in front of your face. So, to the average 2023 consumer with an iPhone the environment may look very simple and old, but in fact there's so much science that goes into the process of building an interface that is very purpose-driven, is very oriented around human behavior and psychology and getting attention at the exact right time and being able to process high volumes of information super efficiently without distraction. So, basic things we would agonize over like colors, frequency at which things would flash and where they would show up on the displays. It's a monochrome screen for all intents and purposes with very little color in place. What was super cool about that opportunity was that, especially when I was very early in my career, is that really showed me the value of the human computer interface and really highly organized software development practices, and I really used a lot of that experience working with the FAA to then roll that into both my current role and previous roles.

Dan Blumberg: Is that why you went to Red Bull? You needed more color?

Jon Walton: Yes. That's one big reason.

Dan Blumberg: Why is Red Bull putting people in space and sponsoring extreme diving competitions? That is a non-linear strategy to selling energy drinks.

Jon Walton: Isn't it? I agree with you, but once you really understand the vision, in the end, the mission of the company is to give wings to people and ideas. And through, of course, the sale of the energy drink. The energy drink itself does that, but of course the brand supporting these crazy ideas, that shows that humans can do maybe unthinkable things.

Dan Blumberg: If there's a competition over a weekend, you're going to have all the athletes there, all the brand folks there, and you were building a lot of software to support those kinds of competitions. Can you walk us through an example of some of the software that you build and how it relates to the big events and the media arm and the physical goods?

Jon Walton: Yeah, absolutely. So, there aren't many other brands doing this type of thing, and that means that Red Bull does have a lot of unique business cases, particularly on the marketing side and especially producing such a high volume of marketing activations and large format events, and especially then having to parlay that into a much larger enterprise strategy on the backend is a unique challenge. So, everybody's seen the white labeled event apps that are out there that most professional conferences use, as well as you go to a music festival or something along those lines and you get the event app that shows you the map of all the different key locations, the calendar of events. There's usually some kind of chat wall and document sharing and things along those lines, as well as notifications. We have a very similar use case for that, of course, by producing so many events globally.

So, there was the opportunity there to develop an event supporting application. We started with looking at the market landscape at the time, but realized pretty quickly that most of the white labeled solutions, A, really just weren't up to the UI/UX expectations of our organization as well as just some of the unique features that we were looking for. So, in the end, we actually worked pretty closely with Artium and you guys were instrumental in supporting that strategy there. It was actually coincidentally a great time for us to mature some of our engineering practices, and I would say that that really led to the eventual success of the application and the quality of the delivery there.

Dan Blumberg: I want to get back to what you said. The decision to build this custom software came at an opportune time when you also were looking for ways to level up the engineering org at Red Bull, and I wonder if you could just speak to some of the issues that you were looking to address and then some of the ways you addressed them.

Jon Walton: We really took a quick view of how we can mature our software development processes and our management of those software development processes. So, a combination of really looking at XP principles, which to a lot of organizations sounds like far-flung maturity practices that you only see in the most advanced software engineering organizations, but in fact, we really plucked a lot of traditional XP processes from the industry and from the playbook and implemented them within the teams. A great example of them are, of course, paired programming, and we saw so much value from this in our engineering teams. In fact, not only the engineers, of course, would be doing pairing, but actually some of our project and product leaders would end up joining the pairing sessions to really understand how the teams were operating and get closer to them and building those relationships.

I could go on and on and talk about pairing, and a lot of the people in the Artium world are big fans of this too, and we were skeptics, of course, at the beginning, but it added so much productivity. It added a ton of technical knowledge sharing, which enabled us to advance beyond the old school individual layers of the tech stack developers. You have your front-end developers. You have your back-end developers. You have your API or middleware layer developers. You have your database engineers, et cetera. We evolved slowly through this practice to mature all of our engineering staff to a more or less full stack development team.

Dan Blumberg: Let me play the skeptic for a second.

Jon Walton: Sure.

Dan Blumberg: I don't understand how pair programming, two engineers doing the work that previously one person would do, how can that possibly be more productive?

Jon Walton: Yeah. Imagine doing that exact same job with someone standing over your shoulder. You're not going to be pulling up your Instagram DMs. You're not going to be sitting there playing with the dog. You're going to be focused on your work. So, it becomes a very high-focused, intense productivity environment. And I think on top of that too, it's huge for knowledge sharing because you're actually learning from someone's completely different perspective on how to solve a problem or how to approach something. And so we ended up seeing this huge flourishing of knowledge within the team and it actually transformed even the ways that the teams, the relationships between each other, but the ways that they operated together in ways that we just didn't even anticipate. When pairing gets introduced, of course, you're now really having to spend intimate time with another person, watching their work, sharing ideas, challenging them, asking questions, and doing it on a regular basis in a way that wouldn't be happening otherwise. And that ends up creating just a camaraderie among the team that drives just all kinds of tangential benefits that you can imagine.

Dan Blumberg: I want to dig into one more XP principle, which is a test-driven development. I wonder if that was something that you felt you needed to improve and use this app as a way to improve it. If it is, I'd love to hear that story and what effects you've seen from that

Jon Walton: Test and QA in general was a huge opportunity. The test-driven development approach really, I would say, set the foundation for a whole overhaul of our testing and QA strategy. By integrating code level unit testing into the development environment as part of the work, it's like pick your poison. Do you want to do a ton of manual testing with a ton of rework or do you want to address most of the issues up front and do far less manual testing? And I think that the latter was definitely the experience we had. So, much higher degree of overall code quality, but also it then set the pace for lots of other more advanced QA processes. So, what we ended up with over the long journey was super high quality products, testing deeply integrated into the development lifecycle that bred just super high quality software.

Dan Blumberg: So, just playing the skeptic one more time. Now you're telling me that not only are there going to be two engineers sitting next to each other or virtually sitting next to each other, but they're not even going to start by writing code. They're going to write a test first.

Jon Walton: Yeah, absolutely.

Dan Blumberg: And that's still more productive, right?

Jon Walton: Yeah, absolutely. The amount of time, if you added it all up and had a very traditional manual QA person or staff of people testing, identifying, if they even identify an issue, submitting that back into the development backlog, getting that slated in to prioritize, retesting it manually versus in most cases catching these things up front far outweighs the amount of effort in the grand scheme of things. But it does absolutely take a culture shift to do that. It's not something that happens overnight. I think the real benefits that we saw working with Artium actually through this process was bringing in senior engineers to really showcase these best practices with our engineering team. Because of course, it's great to hear somebody tell you best practices, but it's a totally different thing when they're actually doing it with you through an entire project. Seeing them do it, asking them questions in real time and embedding that expertise, it's like you teach someone to fish. You don't really need to go back to the expert anymore when you know how to fish.

Dan Blumberg: That's awesome. And just I've realized I'm playing this skeptic a little bit here, but I actually would love to hear what some of the people on your teams, if they were skeptical about this, how would you advise other engineering leaders who are thinking about implementing any of these principles who may face pushback? What would your response be?

Jon Walton: We absolutely had pushback. Any change from existing process is always met with some resistance. I think that by doing it and then realizing and taking time to recognize the benefits, I think then you see an iterative ongoing improvement cycle. This wasn't things that we changed and transitioned to overnight, but it absolutely, with the benefit of hindsight, look back six months, a year, three years, five years, it's a completely different organization with completely different capabilities. I would say that to people who question this approach, "Try it." That's always the first thing. And I think that even during some of these things, these new changes that we implemented, it wasn't just on the technical side. It was, of course, best practice across the board.

I'm a really good student of industry best practice and the science of how to do things the right way. There's no need in the end to really reinvent the wheel. A lot of these things are well-established principles and there's a reason that they're well-established. The key stakeholders who are, basically, who are accepting whatever features we deliver, they're like, "Yeah, this is actually... I'm seeing really high quality. I'm excited about the solution. I'm excited about the next thing. We have some new ideas.| So, that then starts creating this culture of continuous improvement, lots of open and honest feedback and growth as a result, and it builds on each other.

Dan Blumberg: These are practices that Jon's enthusiastically carrying with him to his new role as a VP of product management at the athletic clothing retailer, Vuori.

Jon Walton: I'm really excited because at Vuori, from a technology standpoint, we are really looking to drive a product-led mindset and product-oriented mindset towards the entire technology portfolio. So, not just the enterprise technology that's required to run a large clothing brand, but also, of course, our digital products and things like that too that are our core parts of our business. If you're implementing a new ERP system for a high growth organization, it's not just about taking the vanilla, off-the-shelf ERP solution, it's about, how do we think about the future of the organization? How do we think about ways that we can customize this?

How do we think about the opportunity that implementing a modern ERP might provide for other areas of our organization? And putting together this much broader roadmap, which in the end you go then from an IT service-management-led and organized organization to a product-led organization where this product strategy, regardless of what the product is, becomes basically the cornerstone, the intersection of the way that we do business and all of the strategy that comes from that. So, it's really exciting stuff to see organizations like Vuori really embrace that mindset.

Dan Blumberg: And that product-led approach is tied to consumer led-expectations.

Jon Walton: Like the iPhone generation, digital natives. If I am used to very slick, modern, high engagement applications that are in my phone at my fingertips and I'm engaging with them however many hours a day, and then I have to go use a tool at work that feels archaic and clunky and I can't figure out where things are on the menu and I need to take a training to know how to use it, that doesn't make any sense. Your business applications, whether they're a finance tool or a sales tool or a marketing tool or whatever else in the portfolio, should be just as intuitive as every other app or website or anything else that you're engaging with in your day-to-day lives. And that is really, I would say, the argument and the case study for why product-led organizations is really the right way to approach technology portfolio spend and strategy in any organization going forward.

It's something that we really focused on at Red Bull, but also in the case of in Vuori and taking this very product-led, product-oriented mindset to managing the technology portfolio, it ensures that you're putting the end user first. And in the end, it's not about how many clicks I'm getting or impressions I'm getting or how much time I spend on the app. It's actually more about how productive I am using this solution. And even then, if you decide to build solutions and you don't go with a vendor, you want to make sure that you're following these best practices and you're not just following the strict set of requirements that a key business stakeholder is providing you. By being a technology leader, a product leader, you can really understand that, "Hey, there's so much other things we can do with a solution besides just this core fundamental set of business requirements." And that really sets you up for super long-term success and you end up driving the business roadmap versus being reactive to it. And that's really the value of being a product-led organization at a minimum.

Dan Blumberg: Jon, thank you. I really truly could go on and on on this stuff, but there's a lot of really interesting stories here and so thank you.

Jon Walton: My pleasure. My pleasure.

Dan Blumberg: That's Jon Walton. At Artium, we build incredible products, recruit high performing teams, and help you achieve the culture of craft you need to build great software long after we're gone. We artisans love partnering with creative people to build their visions of the future. If you want to explore pairing with us to build something great or level up your organization, let's talk. Along with our friends at Red Bull, we've helped lots of startups and big enterprises reach new heights. You can learn more about us at thisisartium.com and start a conversation by emailing hello@thisisartium.com. If you liked today's episode, please subscribe and spread the word about our Webby honored podcast.

“Your business applications should be just as intuitive as every other app or website or anything else that you're engaging with in your day-to-day lives”. That’s the product-led approach that Jon Walton took as an engineering leader at Red Bull, where he spent nearly a decade working on the apps that help the energy drink maker run the extreme sports competitions and spectacles it's known for.

Here’s Jon Walton on Crafted, Artium’s new podcast.

Listen and subscribe to Crafted: Apple Podcasts | Spotify | All Podcast Apps

Jon Walton: ... your business applications, whether they're a finance tool or a sales tool or a marketing tool or whatever else in the portfolio, should be just as intuitive as every other app or website or anything else that you're engaging with in your day-to-day lives. And that is really the argument in the case study for why product-led organizations is really the right way to approach technology portfolio spend and strategy in any organization going forward. It's something that we really focused on at Red Bull.

Dan Blumberg: That's Jon Walton. He's a product and engineering leader who spent nearly a decade at Red Bull working on the apps that helped the energy drink maker run the extreme sports competitions and spectacles it's known for.

Red Bull Clip: I'm going to try to land this plane on this tiny helipad.

I wanted to be the first human outside of an aircraft breaking the sound barrier.

Okay. Here we go, Felix.

I'm going over.

Dan Blumberg: Things like a sky diver's free fall from space or flying a plane through a tunnel or having F1 drivers race cars in reverse or... You get the idea. In this episode, Jon tells us why these special events needed special custom-built software and how Red Bull improved the way it built software in the first place by embracing principles like lean, agile and pair programming that we're so fond of here at Artium.

Jon Walton: It actually transformed the teams' relationships between each other, but the ways that they operated together in ways that we just didn't even anticipate.

Red Bull Clip: We're going to see how far they can go. They're off. Jump into the mighty Mississippi.

Going big is what he does.

Dan Blumberg: Welcome to Crafted, a show about great products and the people who make them. I'm your host, Dan Blumberg. I'm a product and engagement leader at Artium, where my colleagues and I help companies build incredible products, recruit high performing teams, and help you achieve the culture of craft you need to build great software long after we're gone. Like a lot of our guests, Jon's starting point for software development seems unconventional. He trained in biomedical engineering with the intent of going into medicine, but he specialized in computing and imaging and that brought him to the FAA, where he built air traffic control systems. The scientific nature of product development at the FAA really appealed to Jon, especially as it applied to human computer interaction.

Jon Walton: You can imagine very rudimentary things like colors of text and location of buttons and the speed and frequency at which things flashed in front of your face. So, to the average 2023 consumer with an iPhone the environment may look very simple and old, but in fact there's so much science that goes into the process of building an interface that is very purpose-driven, is very oriented around human behavior and psychology and getting attention at the exact right time and being able to process high volumes of information super efficiently without distraction. So, basic things we would agonize over like colors, frequency at which things would flash and where they would show up on the displays. It's a monochrome screen for all intents and purposes with very little color in place. What was super cool about that opportunity was that, especially when I was very early in my career, is that really showed me the value of the human computer interface and really highly organized software development practices, and I really used a lot of that experience working with the FAA to then roll that into both my current role and previous roles.

Dan Blumberg: Is that why you went to Red Bull? You needed more color?

Jon Walton: Yes. That's one big reason.

Dan Blumberg: Why is Red Bull putting people in space and sponsoring extreme diving competitions? That is a non-linear strategy to selling energy drinks.

Jon Walton: Isn't it? I agree with you, but once you really understand the vision, in the end, the mission of the company is to give wings to people and ideas. And through, of course, the sale of the energy drink. The energy drink itself does that, but of course the brand supporting these crazy ideas, that shows that humans can do maybe unthinkable things.

Dan Blumberg: If there's a competition over a weekend, you're going to have all the athletes there, all the brand folks there, and you were building a lot of software to support those kinds of competitions. Can you walk us through an example of some of the software that you build and how it relates to the big events and the media arm and the physical goods?

Jon Walton: Yeah, absolutely. So, there aren't many other brands doing this type of thing, and that means that Red Bull does have a lot of unique business cases, particularly on the marketing side and especially producing such a high volume of marketing activations and large format events, and especially then having to parlay that into a much larger enterprise strategy on the backend is a unique challenge. So, everybody's seen the white labeled event apps that are out there that most professional conferences use, as well as you go to a music festival or something along those lines and you get the event app that shows you the map of all the different key locations, the calendar of events. There's usually some kind of chat wall and document sharing and things along those lines, as well as notifications. We have a very similar use case for that, of course, by producing so many events globally.

So, there was the opportunity there to develop an event supporting application. We started with looking at the market landscape at the time, but realized pretty quickly that most of the white labeled solutions, A, really just weren't up to the UI/UX expectations of our organization as well as just some of the unique features that we were looking for. So, in the end, we actually worked pretty closely with Artium and you guys were instrumental in supporting that strategy there. It was actually coincidentally a great time for us to mature some of our engineering practices, and I would say that that really led to the eventual success of the application and the quality of the delivery there.

Dan Blumberg: I want to get back to what you said. The decision to build this custom software came at an opportune time when you also were looking for ways to level up the engineering org at Red Bull, and I wonder if you could just speak to some of the issues that you were looking to address and then some of the ways you addressed them.

Jon Walton: We really took a quick view of how we can mature our software development processes and our management of those software development processes. So, a combination of really looking at XP principles, which to a lot of organizations sounds like far-flung maturity practices that you only see in the most advanced software engineering organizations, but in fact, we really plucked a lot of traditional XP processes from the industry and from the playbook and implemented them within the teams. A great example of them are, of course, paired programming, and we saw so much value from this in our engineering teams. In fact, not only the engineers, of course, would be doing pairing, but actually some of our project and product leaders would end up joining the pairing sessions to really understand how the teams were operating and get closer to them and building those relationships.

I could go on and on and talk about pairing, and a lot of the people in the Artium world are big fans of this too, and we were skeptics, of course, at the beginning, but it added so much productivity. It added a ton of technical knowledge sharing, which enabled us to advance beyond the old school individual layers of the tech stack developers. You have your front-end developers. You have your back-end developers. You have your API or middleware layer developers. You have your database engineers, et cetera. We evolved slowly through this practice to mature all of our engineering staff to a more or less full stack development team.

Dan Blumberg: Let me play the skeptic for a second.

Jon Walton: Sure.

Dan Blumberg: I don't understand how pair programming, two engineers doing the work that previously one person would do, how can that possibly be more productive?

Jon Walton: Yeah. Imagine doing that exact same job with someone standing over your shoulder. You're not going to be pulling up your Instagram DMs. You're not going to be sitting there playing with the dog. You're going to be focused on your work. So, it becomes a very high-focused, intense productivity environment. And I think on top of that too, it's huge for knowledge sharing because you're actually learning from someone's completely different perspective on how to solve a problem or how to approach something. And so we ended up seeing this huge flourishing of knowledge within the team and it actually transformed even the ways that the teams, the relationships between each other, but the ways that they operated together in ways that we just didn't even anticipate. When pairing gets introduced, of course, you're now really having to spend intimate time with another person, watching their work, sharing ideas, challenging them, asking questions, and doing it on a regular basis in a way that wouldn't be happening otherwise. And that ends up creating just a camaraderie among the team that drives just all kinds of tangential benefits that you can imagine.

Dan Blumberg: I want to dig into one more XP principle, which is a test-driven development. I wonder if that was something that you felt you needed to improve and use this app as a way to improve it. If it is, I'd love to hear that story and what effects you've seen from that

Jon Walton: Test and QA in general was a huge opportunity. The test-driven development approach really, I would say, set the foundation for a whole overhaul of our testing and QA strategy. By integrating code level unit testing into the development environment as part of the work, it's like pick your poison. Do you want to do a ton of manual testing with a ton of rework or do you want to address most of the issues up front and do far less manual testing? And I think that the latter was definitely the experience we had. So, much higher degree of overall code quality, but also it then set the pace for lots of other more advanced QA processes. So, what we ended up with over the long journey was super high quality products, testing deeply integrated into the development lifecycle that bred just super high quality software.

Dan Blumberg: So, just playing the skeptic one more time. Now you're telling me that not only are there going to be two engineers sitting next to each other or virtually sitting next to each other, but they're not even going to start by writing code. They're going to write a test first.

Jon Walton: Yeah, absolutely.

Dan Blumberg: And that's still more productive, right?

Jon Walton: Yeah, absolutely. The amount of time, if you added it all up and had a very traditional manual QA person or staff of people testing, identifying, if they even identify an issue, submitting that back into the development backlog, getting that slated in to prioritize, retesting it manually versus in most cases catching these things up front far outweighs the amount of effort in the grand scheme of things. But it does absolutely take a culture shift to do that. It's not something that happens overnight. I think the real benefits that we saw working with Artium actually through this process was bringing in senior engineers to really showcase these best practices with our engineering team. Because of course, it's great to hear somebody tell you best practices, but it's a totally different thing when they're actually doing it with you through an entire project. Seeing them do it, asking them questions in real time and embedding that expertise, it's like you teach someone to fish. You don't really need to go back to the expert anymore when you know how to fish.

Dan Blumberg: That's awesome. And just I've realized I'm playing this skeptic a little bit here, but I actually would love to hear what some of the people on your teams, if they were skeptical about this, how would you advise other engineering leaders who are thinking about implementing any of these principles who may face pushback? What would your response be?

Jon Walton: We absolutely had pushback. Any change from existing process is always met with some resistance. I think that by doing it and then realizing and taking time to recognize the benefits, I think then you see an iterative ongoing improvement cycle. This wasn't things that we changed and transitioned to overnight, but it absolutely, with the benefit of hindsight, look back six months, a year, three years, five years, it's a completely different organization with completely different capabilities. I would say that to people who question this approach, "Try it." That's always the first thing. And I think that even during some of these things, these new changes that we implemented, it wasn't just on the technical side. It was, of course, best practice across the board.

I'm a really good student of industry best practice and the science of how to do things the right way. There's no need in the end to really reinvent the wheel. A lot of these things are well-established principles and there's a reason that they're well-established. The key stakeholders who are, basically, who are accepting whatever features we deliver, they're like, "Yeah, this is actually... I'm seeing really high quality. I'm excited about the solution. I'm excited about the next thing. We have some new ideas.| So, that then starts creating this culture of continuous improvement, lots of open and honest feedback and growth as a result, and it builds on each other.

Dan Blumberg: These are practices that Jon's enthusiastically carrying with him to his new role as a VP of product management at the athletic clothing retailer, Vuori.

Jon Walton: I'm really excited because at Vuori, from a technology standpoint, we are really looking to drive a product-led mindset and product-oriented mindset towards the entire technology portfolio. So, not just the enterprise technology that's required to run a large clothing brand, but also, of course, our digital products and things like that too that are our core parts of our business. If you're implementing a new ERP system for a high growth organization, it's not just about taking the vanilla, off-the-shelf ERP solution, it's about, how do we think about the future of the organization? How do we think about ways that we can customize this?

How do we think about the opportunity that implementing a modern ERP might provide for other areas of our organization? And putting together this much broader roadmap, which in the end you go then from an IT service-management-led and organized organization to a product-led organization where this product strategy, regardless of what the product is, becomes basically the cornerstone, the intersection of the way that we do business and all of the strategy that comes from that. So, it's really exciting stuff to see organizations like Vuori really embrace that mindset.

Dan Blumberg: And that product-led approach is tied to consumer led-expectations.

Jon Walton: Like the iPhone generation, digital natives. If I am used to very slick, modern, high engagement applications that are in my phone at my fingertips and I'm engaging with them however many hours a day, and then I have to go use a tool at work that feels archaic and clunky and I can't figure out where things are on the menu and I need to take a training to know how to use it, that doesn't make any sense. Your business applications, whether they're a finance tool or a sales tool or a marketing tool or whatever else in the portfolio, should be just as intuitive as every other app or website or anything else that you're engaging with in your day-to-day lives. And that is really, I would say, the argument and the case study for why product-led organizations is really the right way to approach technology portfolio spend and strategy in any organization going forward.

It's something that we really focused on at Red Bull, but also in the case of in Vuori and taking this very product-led, product-oriented mindset to managing the technology portfolio, it ensures that you're putting the end user first. And in the end, it's not about how many clicks I'm getting or impressions I'm getting or how much time I spend on the app. It's actually more about how productive I am using this solution. And even then, if you decide to build solutions and you don't go with a vendor, you want to make sure that you're following these best practices and you're not just following the strict set of requirements that a key business stakeholder is providing you. By being a technology leader, a product leader, you can really understand that, "Hey, there's so much other things we can do with a solution besides just this core fundamental set of business requirements." And that really sets you up for super long-term success and you end up driving the business roadmap versus being reactive to it. And that's really the value of being a product-led organization at a minimum.

Dan Blumberg: Jon, thank you. I really truly could go on and on on this stuff, but there's a lot of really interesting stories here and so thank you.

Jon Walton: My pleasure. My pleasure.

Dan Blumberg: That's Jon Walton. At Artium, we build incredible products, recruit high performing teams, and help you achieve the culture of craft you need to build great software long after we're gone. We artisans love partnering with creative people to build their visions of the future. If you want to explore pairing with us to build something great or level up your organization, let's talk. Along with our friends at Red Bull, we've helped lots of startups and big enterprises reach new heights. You can learn more about us at thisisartium.com and start a conversation by emailing hello@thisisartium.com. If you liked today's episode, please subscribe and spread the word about our Webby honored podcast.

“Your business applications should be just as intuitive as every other app or website or anything else that you're engaging with in your day-to-day lives”. That’s the product-led approach that Jon Walton took as an engineering leader at Red Bull, where he spent nearly a decade working on the apps that help the energy drink maker run the extreme sports competitions and spectacles it's known for.

Here’s Jon Walton on Crafted, Artium’s new podcast.

Listen and subscribe to Crafted: Apple Podcasts | Spotify | All Podcast Apps

Jon Walton: ... your business applications, whether they're a finance tool or a sales tool or a marketing tool or whatever else in the portfolio, should be just as intuitive as every other app or website or anything else that you're engaging with in your day-to-day lives. And that is really the argument in the case study for why product-led organizations is really the right way to approach technology portfolio spend and strategy in any organization going forward. It's something that we really focused on at Red Bull.

Dan Blumberg: That's Jon Walton. He's a product and engineering leader who spent nearly a decade at Red Bull working on the apps that helped the energy drink maker run the extreme sports competitions and spectacles it's known for.

Red Bull Clip: I'm going to try to land this plane on this tiny helipad.

I wanted to be the first human outside of an aircraft breaking the sound barrier.

Okay. Here we go, Felix.

I'm going over.

Dan Blumberg: Things like a sky diver's free fall from space or flying a plane through a tunnel or having F1 drivers race cars in reverse or... You get the idea. In this episode, Jon tells us why these special events needed special custom-built software and how Red Bull improved the way it built software in the first place by embracing principles like lean, agile and pair programming that we're so fond of here at Artium.

Jon Walton: It actually transformed the teams' relationships between each other, but the ways that they operated together in ways that we just didn't even anticipate.

Red Bull Clip: We're going to see how far they can go. They're off. Jump into the mighty Mississippi.

Going big is what he does.

Dan Blumberg: Welcome to Crafted, a show about great products and the people who make them. I'm your host, Dan Blumberg. I'm a product and engagement leader at Artium, where my colleagues and I help companies build incredible products, recruit high performing teams, and help you achieve the culture of craft you need to build great software long after we're gone. Like a lot of our guests, Jon's starting point for software development seems unconventional. He trained in biomedical engineering with the intent of going into medicine, but he specialized in computing and imaging and that brought him to the FAA, where he built air traffic control systems. The scientific nature of product development at the FAA really appealed to Jon, especially as it applied to human computer interaction.

Jon Walton: You can imagine very rudimentary things like colors of text and location of buttons and the speed and frequency at which things flashed in front of your face. So, to the average 2023 consumer with an iPhone the environment may look very simple and old, but in fact there's so much science that goes into the process of building an interface that is very purpose-driven, is very oriented around human behavior and psychology and getting attention at the exact right time and being able to process high volumes of information super efficiently without distraction. So, basic things we would agonize over like colors, frequency at which things would flash and where they would show up on the displays. It's a monochrome screen for all intents and purposes with very little color in place. What was super cool about that opportunity was that, especially when I was very early in my career, is that really showed me the value of the human computer interface and really highly organized software development practices, and I really used a lot of that experience working with the FAA to then roll that into both my current role and previous roles.

Dan Blumberg: Is that why you went to Red Bull? You needed more color?

Jon Walton: Yes. That's one big reason.

Dan Blumberg: Why is Red Bull putting people in space and sponsoring extreme diving competitions? That is a non-linear strategy to selling energy drinks.

Jon Walton: Isn't it? I agree with you, but once you really understand the vision, in the end, the mission of the company is to give wings to people and ideas. And through, of course, the sale of the energy drink. The energy drink itself does that, but of course the brand supporting these crazy ideas, that shows that humans can do maybe unthinkable things.

Dan Blumberg: If there's a competition over a weekend, you're going to have all the athletes there, all the brand folks there, and you were building a lot of software to support those kinds of competitions. Can you walk us through an example of some of the software that you build and how it relates to the big events and the media arm and the physical goods?

Jon Walton: Yeah, absolutely. So, there aren't many other brands doing this type of thing, and that means that Red Bull does have a lot of unique business cases, particularly on the marketing side and especially producing such a high volume of marketing activations and large format events, and especially then having to parlay that into a much larger enterprise strategy on the backend is a unique challenge. So, everybody's seen the white labeled event apps that are out there that most professional conferences use, as well as you go to a music festival or something along those lines and you get the event app that shows you the map of all the different key locations, the calendar of events. There's usually some kind of chat wall and document sharing and things along those lines, as well as notifications. We have a very similar use case for that, of course, by producing so many events globally.

So, there was the opportunity there to develop an event supporting application. We started with looking at the market landscape at the time, but realized pretty quickly that most of the white labeled solutions, A, really just weren't up to the UI/UX expectations of our organization as well as just some of the unique features that we were looking for. So, in the end, we actually worked pretty closely with Artium and you guys were instrumental in supporting that strategy there. It was actually coincidentally a great time for us to mature some of our engineering practices, and I would say that that really led to the eventual success of the application and the quality of the delivery there.

Dan Blumberg: I want to get back to what you said. The decision to build this custom software came at an opportune time when you also were looking for ways to level up the engineering org at Red Bull, and I wonder if you could just speak to some of the issues that you were looking to address and then some of the ways you addressed them.

Jon Walton: We really took a quick view of how we can mature our software development processes and our management of those software development processes. So, a combination of really looking at XP principles, which to a lot of organizations sounds like far-flung maturity practices that you only see in the most advanced software engineering organizations, but in fact, we really plucked a lot of traditional XP processes from the industry and from the playbook and implemented them within the teams. A great example of them are, of course, paired programming, and we saw so much value from this in our engineering teams. In fact, not only the engineers, of course, would be doing pairing, but actually some of our project and product leaders would end up joining the pairing sessions to really understand how the teams were operating and get closer to them and building those relationships.

I could go on and on and talk about pairing, and a lot of the people in the Artium world are big fans of this too, and we were skeptics, of course, at the beginning, but it added so much productivity. It added a ton of technical knowledge sharing, which enabled us to advance beyond the old school individual layers of the tech stack developers. You have your front-end developers. You have your back-end developers. You have your API or middleware layer developers. You have your database engineers, et cetera. We evolved slowly through this practice to mature all of our engineering staff to a more or less full stack development team.

Dan Blumberg: Let me play the skeptic for a second.

Jon Walton: Sure.

Dan Blumberg: I don't understand how pair programming, two engineers doing the work that previously one person would do, how can that possibly be more productive?

Jon Walton: Yeah. Imagine doing that exact same job with someone standing over your shoulder. You're not going to be pulling up your Instagram DMs. You're not going to be sitting there playing with the dog. You're going to be focused on your work. So, it becomes a very high-focused, intense productivity environment. And I think on top of that too, it's huge for knowledge sharing because you're actually learning from someone's completely different perspective on how to solve a problem or how to approach something. And so we ended up seeing this huge flourishing of knowledge within the team and it actually transformed even the ways that the teams, the relationships between each other, but the ways that they operated together in ways that we just didn't even anticipate. When pairing gets introduced, of course, you're now really having to spend intimate time with another person, watching their work, sharing ideas, challenging them, asking questions, and doing it on a regular basis in a way that wouldn't be happening otherwise. And that ends up creating just a camaraderie among the team that drives just all kinds of tangential benefits that you can imagine.

Dan Blumberg: I want to dig into one more XP principle, which is a test-driven development. I wonder if that was something that you felt you needed to improve and use this app as a way to improve it. If it is, I'd love to hear that story and what effects you've seen from that

Jon Walton: Test and QA in general was a huge opportunity. The test-driven development approach really, I would say, set the foundation for a whole overhaul of our testing and QA strategy. By integrating code level unit testing into the development environment as part of the work, it's like pick your poison. Do you want to do a ton of manual testing with a ton of rework or do you want to address most of the issues up front and do far less manual testing? And I think that the latter was definitely the experience we had. So, much higher degree of overall code quality, but also it then set the pace for lots of other more advanced QA processes. So, what we ended up with over the long journey was super high quality products, testing deeply integrated into the development lifecycle that bred just super high quality software.

Dan Blumberg: So, just playing the skeptic one more time. Now you're telling me that not only are there going to be two engineers sitting next to each other or virtually sitting next to each other, but they're not even going to start by writing code. They're going to write a test first.

Jon Walton: Yeah, absolutely.

Dan Blumberg: And that's still more productive, right?

Jon Walton: Yeah, absolutely. The amount of time, if you added it all up and had a very traditional manual QA person or staff of people testing, identifying, if they even identify an issue, submitting that back into the development backlog, getting that slated in to prioritize, retesting it manually versus in most cases catching these things up front far outweighs the amount of effort in the grand scheme of things. But it does absolutely take a culture shift to do that. It's not something that happens overnight. I think the real benefits that we saw working with Artium actually through this process was bringing in senior engineers to really showcase these best practices with our engineering team. Because of course, it's great to hear somebody tell you best practices, but it's a totally different thing when they're actually doing it with you through an entire project. Seeing them do it, asking them questions in real time and embedding that expertise, it's like you teach someone to fish. You don't really need to go back to the expert anymore when you know how to fish.

Dan Blumberg: That's awesome. And just I've realized I'm playing this skeptic a little bit here, but I actually would love to hear what some of the people on your teams, if they were skeptical about this, how would you advise other engineering leaders who are thinking about implementing any of these principles who may face pushback? What would your response be?

Jon Walton: We absolutely had pushback. Any change from existing process is always met with some resistance. I think that by doing it and then realizing and taking time to recognize the benefits, I think then you see an iterative ongoing improvement cycle. This wasn't things that we changed and transitioned to overnight, but it absolutely, with the benefit of hindsight, look back six months, a year, three years, five years, it's a completely different organization with completely different capabilities. I would say that to people who question this approach, "Try it." That's always the first thing. And I think that even during some of these things, these new changes that we implemented, it wasn't just on the technical side. It was, of course, best practice across the board.

I'm a really good student of industry best practice and the science of how to do things the right way. There's no need in the end to really reinvent the wheel. A lot of these things are well-established principles and there's a reason that they're well-established. The key stakeholders who are, basically, who are accepting whatever features we deliver, they're like, "Yeah, this is actually... I'm seeing really high quality. I'm excited about the solution. I'm excited about the next thing. We have some new ideas.| So, that then starts creating this culture of continuous improvement, lots of open and honest feedback and growth as a result, and it builds on each other.

Dan Blumberg: These are practices that Jon's enthusiastically carrying with him to his new role as a VP of product management at the athletic clothing retailer, Vuori.

Jon Walton: I'm really excited because at Vuori, from a technology standpoint, we are really looking to drive a product-led mindset and product-oriented mindset towards the entire technology portfolio. So, not just the enterprise technology that's required to run a large clothing brand, but also, of course, our digital products and things like that too that are our core parts of our business. If you're implementing a new ERP system for a high growth organization, it's not just about taking the vanilla, off-the-shelf ERP solution, it's about, how do we think about the future of the organization? How do we think about ways that we can customize this?

How do we think about the opportunity that implementing a modern ERP might provide for other areas of our organization? And putting together this much broader roadmap, which in the end you go then from an IT service-management-led and organized organization to a product-led organization where this product strategy, regardless of what the product is, becomes basically the cornerstone, the intersection of the way that we do business and all of the strategy that comes from that. So, it's really exciting stuff to see organizations like Vuori really embrace that mindset.

Dan Blumberg: And that product-led approach is tied to consumer led-expectations.

Jon Walton: Like the iPhone generation, digital natives. If I am used to very slick, modern, high engagement applications that are in my phone at my fingertips and I'm engaging with them however many hours a day, and then I have to go use a tool at work that feels archaic and clunky and I can't figure out where things are on the menu and I need to take a training to know how to use it, that doesn't make any sense. Your business applications, whether they're a finance tool or a sales tool or a marketing tool or whatever else in the portfolio, should be just as intuitive as every other app or website or anything else that you're engaging with in your day-to-day lives. And that is really, I would say, the argument and the case study for why product-led organizations is really the right way to approach technology portfolio spend and strategy in any organization going forward.

It's something that we really focused on at Red Bull, but also in the case of in Vuori and taking this very product-led, product-oriented mindset to managing the technology portfolio, it ensures that you're putting the end user first. And in the end, it's not about how many clicks I'm getting or impressions I'm getting or how much time I spend on the app. It's actually more about how productive I am using this solution. And even then, if you decide to build solutions and you don't go with a vendor, you want to make sure that you're following these best practices and you're not just following the strict set of requirements that a key business stakeholder is providing you. By being a technology leader, a product leader, you can really understand that, "Hey, there's so much other things we can do with a solution besides just this core fundamental set of business requirements." And that really sets you up for super long-term success and you end up driving the business roadmap versus being reactive to it. And that's really the value of being a product-led organization at a minimum.

Dan Blumberg: Jon, thank you. I really truly could go on and on on this stuff, but there's a lot of really interesting stories here and so thank you.

Jon Walton: My pleasure. My pleasure.

Dan Blumberg: That's Jon Walton. At Artium, we build incredible products, recruit high performing teams, and help you achieve the culture of craft you need to build great software long after we're gone. We artisans love partnering with creative people to build their visions of the future. If you want to explore pairing with us to build something great or level up your organization, let's talk. Along with our friends at Red Bull, we've helped lots of startups and big enterprises reach new heights. You can learn more about us at thisisartium.com and start a conversation by emailing hello@thisisartium.com. If you liked today's episode, please subscribe and spread the word about our Webby honored podcast.