A platform to care for the developer's journey

Jason (00:03): A platform engineering approach makes it to where people are able to easily do the right things as long as we make those right things easy to do, as if we reduce that friction and make it just so simple for a team.

Marc (00:21): This season, Andy and Marc are back with a fantastic group of guests.

Andy (00:26): I bet the depths remain classified, and Marc keeps his head in the clouds. With our combined experience in the industry, we can go from the bare metal to the boardroom.

Marc (00:35): In DevOps Sauna Season Three, we'll explore platform engineering, and the people and cultures that make it happen.

Andy (00:42): Enjoy your time in the DevOps Sauna.

Marc (00:52): Okay, we are back in the sauna and continuing our podcasts on platform engineering. I'm super happy to have Jason Walker from American Airlines here. Hi, Jason, how are you today?

Jason (01:06): I'm doing fantastic. How about yourself?

Marc (01:08): It's another beautiful day in sunny Helsinki, actually. It's a little cold. And as usual, I have my cohort, Mr. Andy Allred.

Andy (01:17): Hello, happy to be here. I got a feeling this is going to be a good one.

Marc (01:20): I do too. Jason, I was honored to be able to host your presentation in The DEVOPS Conference in Copenhagen on the platform engineering work that you've been doing with American Airlines. And I'd like to ask first, how did this project get started? How did it ramp up? Because I believe that you had some pretty typical large organization software pathologies. And now I think that you're getting to one of the most state-of-the-art shops that I've seen anyway. How did this start and get going your work there?

Jason (01:55): Yeah. Thank you both for having me on here. And the Copenhagen, the DevOps conference, it was a blast. It was great to be up there and to meet a lot of new people. The journey in American Airlines, when it comes down to, say, a delivery and a technology transformation, it's been kind of an ongoing thing. It certainly started before I came to American Airlines. They're having a very specific focus around platform engineering. And looking at what that starts to mean and as part of that transformation, it was probably about a month before I started, give or take a month, but there were a couple of engineers in our coaching area that were running into an issue because they would have teams come through and as part of a two-to-four-week challenge, sort of the dojo style come in, and let's work on a problem. A lot of time was being spent waiting, waiting on servers, waiting on compute, waiting on IP address, just like waiting on stuff. And we were probably a year and a half into an Azure cloud journey. And there was enough permission in some of the subscriptions for these couple of team members to build up and automate, just quickly spinning up app services or different components within Azure. The team had also identified backstage as an open-source offering from Spotify, and started to look at how that might be something to be able to quickly provision different resources in Azure. I came over about a month after they had started in the garage kind of experiment. And one of the things that I was tasked with or chartered with was to, at least for the near term, to essentially be the product owner, the tech lead for this thing that was called Runway. In the early going there were a lot of conversations, a lot of tough conversations with a lot of the engineers and architects at American Airlines. Based upon the feedback, the perception I was picking up that people were feeling is like, here comes this next new magic bullet. And one of the things that I had to go into and lead with wasn't so much like, hey, check out this Runway, check out this cool tool. It was talking about us changing the way that we approach, how we want to deliver technology, what are the different mechanisms, and what's just the mindset that we want to have about quickly being able to spin up the different resources and components we need that make up an application, that make up a product that's customer facing. And do it in a way that we're able to incorporate all of the little paper cut type of service requests that you might see in whatever your service request tool is. And instead of it being 15 different requests, it's let's enable the right self-service components so that you're not just getting a VM. You're not just getting some disk, you're actually getting almost like Lego bricks, the building blocks for you to deploy a working unit that keeps you going. People started to realize that this wasn't just the say like a shared service coming with another tool that it was more of a mindset. I think that's where we started to pivot towards people going, okay, so show me more. And when we started actually show it. In the presentation, I think I shared a screenshot of a component where we refer to as our Baker's Dozen, there's 13 different elements within cybersecurity and technology risk, and includes things like use the love, like scan your code in through the implementation of runway, our software templates, especially our certified ones that are like, hey, I want to deploy this Python API to Kubernetes includes all the different parts. And it's not like extra requests, it just comes bolted on. And that's where people are starting to realize that there's this opportunity for us to land on a set of standards, we do practice inner source internally. Folks are familiar with that. It's like open source, but it's within the confines of an organization. And a lot of the different software templates and different components that we use are all based on an inner source approach to promote and encourage contributions from others. It isn't a closed box that nobody's able to see what's going on within the platform. In fact, it's the other way around. All of our logs, all of our telemetry is all in the same system that the development community is able to see. Based upon their appetite, if they are wanting to dig in, if they're wanting to understand if they're wanting to see behind the curtain, we just removed the curtain. And I think that's been part of the evolution step of platform engineering coming from the DevOps mindset. It's like let's make sure that people are able to see, let's make sure it's collaborative, let's make sure even when we're trying something for the first time that we're able to do it in very transparent ways to our stakeholders.

Andy (06:49): One thing that I found interesting in there is a lot of the companies I talked to who are thinking about Backstage or looking into Backstage, come away and say, yeah, it's a software template. And we have templates in GitHub, so why would we want templates here, but immediately the first thing you said was you use this as a mechanism to deploy Azure resources, and application stuff, and templates, which include this stuff. You jumped all the way into deploying cloud resources instead of starting with just templates. I'm sure you started somewhere and built internally, but when you have the initial discussions, it sounds like you had everything needed wrapped up into a package. You are much more than just another templating system for a repository.

Jason (07:40): Backstage, their repo for Backstage has adopter’s markdown file, I think we're like number eight, the American Airlines saying yeah, we're going to adopt this thing. It was very informal, that's just like a pull request to a markdown file. It was so early on, very much like alpha level deployments. And we made some pretty big mistakes when it came down to the way that we started to code. Our instance, we have tightly coupled integrations, upgrades were painful. And it even got to a point there were multiple times and we continue every so often, to go like, hey, everyone, especially the team that's maintaining runway, like Backstage is a core component of this. That isn't what makes Runway valuable to American Airlines, Runway is the thing. And so is Backstage. And this is just like the sanity check of is using Backstage, still a corporate founder that we want to include, and the team continues to circle back and somewhat ratify or make it to where it's like, yeah, this is still the approach. And so, with that, we made very specific, intentional decisions to not couple of the things that we need into that same deployment, we make use of plugins and packages to keep it separate, to make those upgrades easier. That is mean, it's where we've been able to be focused more on the overall unit of work that gets deployed and not. I mean, there's still a GitHub repo, there's still the skeleton of an initial application, whether it's, you're doing something with Maven, or you're doing something with FastAPI or fill on wherever in between, and you get the deployment details, it's automatically deployed for you like a Hello World, you can check a box and a Hello World gets deployed. And it includes all the pipeline components. Now we got it to where it includes SAST, and soon it'll include all the SCA open-source scanning. It just continues to be something where we can onboard these different services in one place and make it easier for people to create or update those little components that make up the application as a whole.

Andy (09:43): When you're deploying these cloud resources and whatnot, are you using TerraForm or Crossplane or something else as enabler behind backstage.

Jason (09:52): Yeah, Crossplane is something that the team is looking at. There's a couple of different teams that are to varying degrees, managing or maintaining, you know, Kubernetes environments and going, "Hey, there's something that we certainly could look at." We make use of open source TerraForm for a lot of the different resources and components, everything from, we need something to build up, if we're deploying to Kubernetes, we make use of TerraForm, to actually build up the Kubernetes cluster, we make use of that to also manage any of the network components that are needed within a cloud service provider to deal with the different integrations and we're getting way better at being able to do things like spin up a new cluster, making use of TerraForm. And just a couple of workflows. And next thing you know it's like, here's with different ideas, of course, and different network pieces. But here's a new cluster, and then being able to migrate workloads with almost no downtime. We're getting even to the point of it being making use of the infrastructures code approach to say, we're not even going to patch our Kubernetes environments, or like let's just rehydrate, roll workloads over and then get rid of the old once it's up and running and good just to make it to where it's not like, we need downtime for maintenance. Let's just keep things rolling.

Marc (11:05): Cool. I think there was something really interesting that you said in the pregame talking about self-service, it's like understanding workflow, rather than how a tool works. And if I think about that as well, that you were moving the conversation, I think even beyond mechanisms to deliver technology to the actual payloads themselves, the workloads that are delivering value. Is there something there about how you're reducing the cognitive load for the developers to be able to focus on core value creation?

Jason (11:37): Yeah. As I mentioned, we have the software templates, they're either there to create a new thing, whether it's here's a GitHub repo that has some initial code, like even Hello world, that includes here's some initial tests to make sure like everything is working, whether it's you to test at this Python based, we make sure all the requirements are there for PyTest. We're adding more things like here's maybe a proper Git ignore file for things to not accidentally get checked into code. Also looking at if it's Docker based, like the Docker ignore file, introducing some of the CICD checks for linting various things. We just went through in the last month, and put out there that we're going to I want to ratify. But putting it out there, like everyone that is maintaining Docker images, or container images, hey, CICD has a benchmark, and soon it's going to be the expectation, so let's get our minds wrapped around that security, that Center for Internet Security benchmark that says, here's 13 things that you should be doing so that everyone get on the same page about what that starts to mean, and then have our software templates actually enumerate what those expectations are. We're finding like encoded being way easier for us to introduce changes. And then we make use of semantic versioning for new templates, new underlying dependencies. And so, there's this other software template style that we actually do pull requests to update existing repos. Even if it wasn't something that was created with runway, that's where if it's a matter of, we need to go from version one to version two of some widget that maybe is out there, that it's a pull request to the team that shows exactly what it is we're asking them to do. They don't have to go figure it out. It's not like they have to manually do it at the outside of click the software template, give us the repo name, give us any of the details that are inputs to it. And then it handles the formatting, it submits it as a pull request, the owning team of that app and that repo, have the opportunity to review it to make sure it works. It's not something that's done to them, it's something that's done for them in order for them to be able to kind of like move about. On the cognitive load side, there's a lot of rapid change in the developer experience ecosystem. One thing that the team has done a great job of it is to make sure that we are consistently setting up like office hours, different discovery sessions, like if a question come from the community. And it's like, hey, there's this bug, and we want to fix the bug. Let's have a discussion with the community about like, how do you all think we should fix it? Or here's something that's brand-new feature that we want to add, what's really the important stuff to you all?

That goes beyond demos because at that point, that is just an open forum. I mentioned office hours for people to come and say, I've tried to work on this piece of code that's supposed to iterate with Runway and I'm just running into this problem. I think on the cognitive load side, we've made it hopefully approachable, and that people don't have to feel like they're going to get lambasted or made fun of, if you will, of like coming and going. I'm just trying to figure out how to get started. But besides that, the team doesn't typically ask for something like, hey, can you go open a ticket, if you're running into an issue. Somebody posts on Slack, it's like, somebody's typically jumping in or gets pseudo assigned to it to be able to help that person out and circle back with documentation. If the documentation is out of date. Okay. Oh crap. Let's fix that and make it to where we continue to reduce that friction and sometimes, we miss eventually just dropped the ball. But I think the piece that others find beneficial, and there's more confidence in the idea of like platform engineering and this team that's helping them do good. Helping them get to the point of writing valuable code, we do respond to feature requests, and we respond to I'm having this problem and make it's where we're able to reduce the load, or hopefully reduce the load.

Andy (15:23): I heard somebody talking and saying that their point of view is, anytime somebody comes with a support ticket, it basically means something in our documentation is not up to date, or it is bad. And we need to document that better so they can find and kind of open up a more detailed ticket or whatnot. And it sounds like you've got kind of that approach as well, that anytime somebody asks for help, of course, that means you haven't done something quite right. Or you could do something better. And I'm just curious that how that really affects the mindset of how you approach these support tickets. And that way evolves the service to be better and better, just by nature of how you see the issues coming in.

Jason (16:05): As I mentioned, when I first came to American Airlines, I was the interim product owner, or just the person to help get things started. And Tim, who is now the product owner, I basically recruited him like to come over. And that was after a conversation where we were talking about some features that we're trying to add, and he was just like, these are not the features that are needed. But he needs to do it a different way. And I was like, Tim, I love this passion. And based on you showing this passion, why don't you come over here and be the product owner? What I really wanted out of that, besides the fact that he's a green person is somebody that was now coming from the developer community to step in, and then be able to kind of take the mantle and run with, like this is here to do good for the developer community. It is here for us as American Airlines' mission statement is caring for people on life's journey. This is one of those tools, one of those things that we can bring to the developer experience space and make a better developer community by taking care of folks by reducing cognitive load, by making it easier felt like there was a there was like one of those moments to be able to pass it on. And I bring this up because Tim is all about making sure that things like documentation is up to date. It's like an important aspect of if there's this new release than the documentation needs to be right there with it, if not, like just behind it. And even though there are times where the docs to get a little outdated, or there's some steps, screenshots get out of whack or something, it's one of those top-of-mind items of, hey, let's make sure that this stuff is up to date. And if somebody does open up any ticket like the documentation doesn't seem right, that that's not like, here's a chore we need to do. It's like, hey, that's a bug. Just like with the working code if the working code isn't doing what it's supposed to, and the docs aren't telling you exactly what it is, and there's something wrong with it. That's the same thing as a bug. And so, it gets another layer of attention. And certainly, back to the dev community, I think they pick up on that and see the response by being pretty quick. The next day documentation is up to date, whether it's Tim's prioritized it or one of the developers in this developer experience space is that this is like a five-minute fix. Let me just get it done.

Marc (18:19): You've validated one of the things that I've been pushing lately, which is really that a lot of times when people are putting together a new development platform, and they're having this greenfield versus brownfield kind of thing. It's like, okay, fine, the first way to get out of debt is to stop accumulating new debt. So, it's fine to build something that's good for greenfield or like you said, accelerating, adding new services. But this aspect of being able to, like you described with a pull request, and a template being able to help somebody move to a new version, or even within the platform, understanding that you're not locking yourself in, you're going to be able to continually upgrade a platform as you go along. These kinds of aspects of planning and providing for everything to be moving all of the time and to be able to be updated. But on this greenfield-brownfield approach, are there any other cases that you've been able to uncover where you use backstage and templates in order to equate change to the organization or effect to legacy in some way?

Jason (19:21): Yeah, one of the things that I picked up on was that I specifically was just using the wrong words and talking to some folks that had brownfield type deployments. Because one of the things of the team had created as part of Runway was the ability for software templates to be extended. And that didn't necessarily resonate with some of the folks that are like, I already have something, all of the all the software templates are deploying new things. And I'm sitting there going, well, no, you just extend it and make it to work and we had to do anything. I mean, it's just software and it's a matter of figuring out what those pieces look like and it wasn't until it was a step back. And instead of instead of me defending what was there of just going, show me what your, like the ideal outcome looks like. And once you started to get into those types of conversations, it then became easier for us to say yes because at that point it was, I turned to our hanger coaches, and others to be able to identify and isolate some time where the folks that were working brownfield could sit and pair up with people that were working in the developer experience base off, he was specifically on Runway and create this space where there was like no home field advantage, right? It wasn't like one team going into another team's area. And all of a sudden, the balance of power was out of whack. It was let's go to this open area, I'll buy lunch. And let's get it to where instead of it being, here's everything it can do, let's identify and talk through how we make it do what you want. And that's where folks that had brownfield deployments. And even if it was like, it's in Azure, or it's in some sort of cloud service provider, but it was either manually created, or there isn't necessarily like a pipeline associated with it. It's stuff that works on my computer, get it to where people started to see the art of the possible, and what the outcome could look like by adopting and consuming and creating, reusing the software templates. But that's when we started to get some traction around the well, I've already got this application that's deployed, here's all the configuration, oh, wait a minute, I'm able to actually use a software template to do something like build the next one that looks like the first one. And when I roll my traffic over, now I'm at least using some of the things that are in this Runway platform and this platform engineering, whether that's pulling some TerraForm, pulling some of the other stuff like all of you to automatically hook up to WAF, hook up to source code management, but scanning. Whatever the different component was, and really make it to where there were more opportunities for people to see, and actually experience it and understand how there were already guardrails in place, how there were different things to help govern the steps. Even though it's self-service, it is governed, and there's a strong degree of consistency around the approach. And that's when they were able to start to crack the nut, if you will, on some of the Brownfield type of deployments. There are some things that are like any large company, and the thing in corporate America, there's going to be the probably corporate world around the world, there's some stuff that's out there that it's like, yeah, we're not even going to bother with trying to get, like that one machine that's like off in the corner somewhere. It's like, it's really a Windows 2000 machine. Yeah, let's just let's leave that like nobody acknowledge because we talk about it too much, it'll crash. And next thing kiosks aren't working or something weird.

Marc (23:08): Hi, it's Marc again, if you'd like to hear more about platform engineering, please check out the blog post by Dan Glavind called Get a Unique Snapshot View of Platform Engineering Today, I'll leave a link for you in the show notes. Now back to our show. 

Marc (23:28): All right. We talked a little bit about open source before as well, and looking at dependencies preparing against supply chain attacks and some things there. Could you tell us some of the work that you've done there?

Jason (23:43): Yeah, well, I definitely want to give a shout out to Kelsey Hightower, as the initial keynote at the DevOps conference, he went through salsa and some different pieces about software supply chain. That actually inspired me to not necessarily there while he was talking, but somewhere between there and when I spoke. We have a DevOps maturity repo where we just talk about these of the different levels and the different aspects to see the material of like, we need to start to incorporate some of this stuff, let's just get out of it and identify and understand like, how we can start to consume some of these approaches, so it's a big deal it within the US. The airline industry, there's new regulations and new controls and aspects of controlling governance that are that are coming into play. There have been some rough patches between weather and system outages and different things that you can see in the news going back over a month now. And while American Airlines has been affected by weather, and luckily not affected by some of the things that have come up, we still want to make sure that we are staying with and or ahead of any requirements that come down. And ultimately, the the way that we the way that we work towards securing applications, securing our technology is through due diligence, a lot of transparency internally, and making it to where things like a platform engineering approach, makes it to where people are able to easily do the right things. As long as we make those right things easy to do. Because if we reduce that friction and make it just so simple for a team to get analysis on their custom code, on the dependencies, and if there's vulnerabilities on when you've deployed something, are there vulnerabilities on that endpoint, and then provide easy remediation steps up to an including block the deployment because of vulnerability has been found, or if something is in prod, or something is deployed and not part of a pipeline? What are those steps for them to remediate, do it quickly? Those are the different things that we continue to look at, to level up to make sure end to end, we're keeping our software supply chain clean. This is one of those things that like it keeps me up at night sometimes.

Andy (25:58): You mentioned the hangar crews and the developer experience team. And I'm just curious how many developer or development teams are in American Airlines and how many people working on runway or around Runway to support that?

Jason (26:13): Developer experience being the product. And that Runway being one of the apps in that product. I believe there's two squads, so roughly 10 to 16 people. And then across the board, when it comes down to all the different applications and the squads. There's roughly eight to 12 people on a squad, some lower, some higher, but you know, eight roughly being the average, I think we're right around the high three hundreds, I think sure that they threw if that's somewhere in the 300 range. There's a couple of 1000. We have two major locations for serves like headquarters, and then from there lots of other smaller locations that people work at.

Marc (26:52): I'm going to jump here, you made me like nearly jumped with joy, Jason, when you said developer experience as the product in an IT organization of an airline. It's like that's absolutely fantastic way of looking at things. Kind of a side question, is there a product manager?

Jason (27:08): Yeah, the developer experience product recently moved from our cloud engineering platform product group with that product manager into our product agility space. It's one of the things I mentioned, the hanger coaches, and that is, again, whether it's people looking to get some time around little 'a' agile practices, or if it's getting the Lean DevOps. It's one of the concepts, we call them power ups, but it's one-to-two-day curriculum of going through as a team, as an individual, some as in person, sort of coach driven, some of it is just self-paced online, but those hanger coaches within our product agility space, developer experience, and our DevOps tool enablement, so not our DevOps team. But the team that manages the DevOps tools. I want to make that extremely clear. We don't have a DevOps team; we have a team that enables the tools as a shared platform for everyone to consume. We shifted those two folks over into this product agility space, so that there can be really a closer alignment between the hanger coaches in what they're coaching and practicing on as well as a feedback mechanism. Because if teams are coming through, and things like our documentation doesn't make sense, or if the tool is not easy enough to adopt for a new person, it provides a mechanism for us to identify like, how do we make that a little better, as well as if there's a new practice or something new that's coming out the developer experience, or our DevOps tool enablement, making sure that our hanger coaches are up to date on what that practice or pattern is, and provide them again a feedback mechanism. As a product, and as a product manager that rolls up into our product agility space, it was not a hard sell to get developer experience understood as a product or the need for it to be a product and not something that was off to the side or treated as a project or just not part of our product taxonomy. That was easy.

Andy (29:07): I'm working often with companies who are a little bit smaller than American Airlines, and just getting resources to make custom Backstage plugins or whatever is rather complicated and difficult. We're always looking to take shortcuts where possible. When you were in Copenhagen, we talked a little bit about open-sourcing some of the stuff you've been doing and sharing with the community and whatnot. Any updates on that? 

Jason (29:35): Yeah, I was hoping that you're going to bring this up. American Airlines we've put on our tech blog our love and affection for open source. Internally, we have a policy that that talks about contributions and where we find something that makes a ton of sense for us to contribute to open source. We have a process and a set of steps to be able to identify the project, make sure that we don't want to contribute back to an abandoned open-source project, it's something that should have been orphaned. We have a process for us to do a quick review, we identify people that are on point for the contributions, like the reviews, not that that's the only person that can do contributions. But we want somebody internally that understands what the project is and its direction. With us producing just our own open-source plugin, it is something that we've absolutely talked about. And there's probably just a handful of implementation details that we need to pull out of some of the stuff that we've worked on. The things though, that we have, that we've either created, or that we've plumbed together are derived from other open-source components. Luckily, what that means is that when it comes down to us releasing something under an Apache v2 license, the other either dependencies or components are also under something that is a permissive type of license, making the legal/IP/privacy type of things little easier to navigate through. And there are some cool things that the Runway DevOps team is working on. Once we get things squared away, the plan is to get a tech blog article out there. And then to try to gain interest of like, is this something that if we were to open source it that people would gravitate to? Even just to try it out and give us feedback, let alone like adopt it. I would encourage folks to keep an eye on tech.a.com. And hopefully, within weeks, we'll have an article out there about an approach that we have for short lived environments, and look to see if there's any type of appetite for people wanting to give it a try.

Marc (31:36): We'll leave a link for you in the show notes.

Andy (31:38): Thank you. And I promise there's at least a couple teams I know personally will be taking very keen look at that. 

Marc (31:48): I was about to offer. I know one guy for sure that will. All right. It's been wonderful having you here, Jason. And we could go on and on and on, but I have two questions that we ask everybody that comes on to the podcast. I'd like you to think back when you were a child, what was the first thing you remember that you wanted to be when you grow up?

Jason (32:12): My uncle, he spent 22-27 years in the Air Force, retired Air Force. I was able to multiple times in my life do midshifts with him, he was air traffic control. That's where you go in at like 9p.m. and then leave at 7a.m. And in the couple of bases that we were at, one was Dover, which had the seat fours, which were at the time the biggest cargo plane. The other times were at Luke Air Force Base, which is a fighter training base. Seeing F15s, which have the two engines do touch and goes, I fell in love with F15s, specifically the E model, I wanted to be an Air Force pilot. I even got the paperwork from the Air Force Academy and then right about 15ish, I got tall, I got probably a little too big for a cockpit and realized that I am not destined for air force pilot anything. I would say I was right about eight or nine when I was like I'm going to be an Air Force pilot. And then from there, I fell in love with drafting just like drawing architecture, actually, like the big table and draw drafting out different things. And that led me to do this IT thing.

Marc (33:31): That's cool. I know exactly what those two big engines on the back look like. Second question. Do you remember what the second question is, Andy?

Andy (33:42): You kind of answered it a little bit in your first answer, but was there a time in your life when you realized you're on the wrong path? Or crystallized that you're really on the right path?

Jason (33:55): For sure. I had children very young. Well, my first child was born when I was 16. And then I had a child at 17. And then a third one at 18, 19. And what I had to do, was I needed to make money. I needed to pay rent, I needed to put food on the table. I got to the restaurants, like lots of line cook, busboy, that kind of stuff. I was doing that for a couple years, that sucked. This is not going to sustain anything. And I ended up getting a temp job at Chase Bank working on the phones, working in collections. After 90 days, it was attempted to hire, like 8 days or whenever I was hired. And at the time, they had the old Memorex telex screens, and the phone was actually on the console. If it was like you're yelling at someone because they're like, screw you, I'm not paying the money. It's like no screw you, you're going to an attorney. And then bam, like just be able to slam the phone. They're switching out to 386S. At the time and Windows NT, and when they did that the Telex, the green screen program didn't work. They brought in, it was a Windows based solution, and it was just on the phone and instead of you slamming the phone down, you just click the little hang up button on this soft phone. Well, that wasn't great. Well, the thing is that the way that the buttons were set up, you could tell that the person that created the buttons and laid them out, had never actually worked the phones, because we're in collection, the most prevalent disposition is no answer. I don't need three clicks to click no answer, I need it to be like the big button to move on to the next call. I rewrote, it was just an INI file, but rewrote the buttons and made it to where like, I have like the no answer is a big one. And then all the dispositions, they were color coded and just made it to where it was just easier also, like keyboard enabled it so you didn't have to use the mouse because everyone was used to the Telex keyboard. Other people started to see that I'm walking around with a floppy disk, which is great from an IT security perspective. And the director of technology for collections found out about this, I did a little demo. And it was basically next week, you're not on the phones anymore, you're going to come back into the IT space. And that was when I felt like I was in some sort of right space because it was just like redoing the INI file and like rewriting it and figuring it out. It felt really natural. It felt like yeah, just figuring this out, and then seeing it, ooh that didn't work. Getting feedback, just working on through the, I wouldn't say it was development, if anything, it was just like tuning the configuration of an app. And it just felt natural. And that's what crystallized for me, that led me to be in IT for a while. And it's now 27 years later.

Andy (36:45): That qualifies as a little while.

Marc (36:47): It just feel so familiar, Jason. I have to ask one more little question. What was your first computer then?

Jason (36:54): Well, when I was 13, my grandmother purchased an IBM ATXT. I had 16 color monitors. I have the dual five & a quarters.

Marc (37:06): Yeah. When you go like this, and it opens.

Jason (37:09): Yes. And that was always a tinkerer like taking electronics apart, putting it back together. Not destructively, but just like wanting to see the insides, but the computer and that would have been '85. And apparently, she cashed out a CD or something. It was like went into an IBM store, 'Whichever is the best one!'

Marc (37:34): That cost quite a lot back in those days.

Jason (37:38): Yeah. I don't have an exact number. And I was figuring out different like go to, figure out loops just deal with different things. I guess technically also the Commodore 64 with the tape drive, so that was even earlier. 

Marc (38:00): That's what I was looking for right there. ATXT is quite an interesting start as well. Okay, thank you so much, Jason. Once again, I think you're a huge inspiration. I love how you describe how you guys have done things, the thought leadership. Thank you so much, not only for being who you are, and doing what you do, but sharing it with us and our listeners and going out on the road and doing conferences and things. I think you're just a fantastic contribution to DevOps software and a lot of other things. Thank you again, for being here.

Jason (38:34): Well, I thank you both for allowing me to be here. And I'll tell you that hard work and the energy that the teams bring in American Airlines is what is really making it all possible that you mentioned before of like, you being in the wake as I was walking towards a person in the audience at the DevOps conference. It's a joy to be in their week as they are driving things. But thank you both very much. This has been awesome.

Andy (38:57): Thank you so much.

Marc (38:58): Before we go, let's give our guests an opportunity to introduce themselves and tell you a little bit about who we are.

Jason (39:09): Hey, everyone, this is Jason Walker with American Airlines and I'm a director in cybersecurity and I thoroughly enjoyed hanging out with Marc and Andy in the DevOps Sauna and looking forward to future conversations with them and with everyone out there.

Marc (39:23): My name is Marc Dillon. I'm a lead consultant in the transformation business at Eficode.

Andy (39:28): My name is Andy Allred, and I'm doing platform engineering at Eficode.

Marc (39:32): Thank you for listening. If you enjoyed what you heard, please like and subscribe, it means the world to us. Also check out our other interesting talks and tune in for our next episode. Take care of yourself and remember what really matters is everything we do with machines is to help humans.