Ep. 35: Be A Force Multiplier - Amplifying Engineering Impact with Jeff Bailey

Speaker A: Hello and welcome. You're listening to Building with People for People, the unfiltered Build podcast, episode 35 where we talk to people behind the tech, explore their journeys and make sense of what and how we build through a human lens. I'm your host Nigel Finley. This episode is brought to you by Clarity, previously getspace Imagine a team that thrives on clear communication, efficient workflows and data driven decisions. Clarity provides the lens to make this a reality. Clarity was founded on four core structured communication, Feedback, Context and Visibility. Our flagship product, Real Time Feedback, a microsurvey platform integrated into the development workflow, allows you to quickly identify issues in order to correct and validate successful outcomes. Join us and experience the power of real time insights to propel your organization to new heights. Learn more at clarity.dev. that's C L A I R I T Y.de back to the show. The software world is vast and ever changing. Cutting through the noise of language fads and building a system that meets m your organizational goals is maintainable, scalable, performant and clean is no easy feat. It is the principal engineers that stand at the helm and steer the ship in the right direction. Today we dive into the world of one principal engineer steering the ship for an iconic brand and how he views his role, what it means to be a principal engineer, his thoughts on AI and software, the importance and meaning of inner source software development and much more. Our guest is one of those superheroes guiding a famous brand to success. He started his software journey as a teenager and his first computer was a Whitebox 286. He traded his Sega Master system and some games to acquire. He now has over 25 years of professional software development experience. He's worked for companies like Internet in a Mall, earthlink, Evoke and Axiom doing consulting work and has a wide range of experience in languages like Perl to ColdFusion to Python to Java to JavaScript and many more. He's currently a principal software engineer at Nike and the co leader of the tech modernization team. He believes you must be a force multiplier to enable maximum efficiency for your team and prioritizing the right tool for the job. When our guest is not designing architecture or driving excellence at Nike, he's gaming on his Nintendo Switch, Steam and Xbox or creating a moody vibe playing his guitar. Jeff Bailey, welcome to the show.

Speaker B: Thank you Nigel. Appreciate that uh, introduction. How are you doing this morning?

Speaker A: Oh, uh, doing wonderful. It's nice and nice and early your time. So thanks again for signing on to have some wonderful conversation.

Speaker B: Here you're very welcome.

Speaker A: All right, so I'd like to start the conversation with a lightning round that I call Building Bits and Bytes. It's four questions, ask everybody and you're in the hot seat. Are you ready?

Speaker B: Yes. Let's go.

Speaker A: Why do you build software?

Speaker B: So uh, I'll give you a short story on this. Uh, when I was working at Internet in a mall and we were selling dial up accounts, I was a tech support manager and I had a few people that were reporting to me at the time and they were spending a uh, grip of time trying to manage our websites. So we had of course like geocities and all these other free websites back in the day and uh, we of course provided that service and they were spending eight hours a day just manually configuring systems and rebooting, etc and I handed this like I wrote down the whole list of things that they were doing. Your classic first write down what you want on Automate and then handed that list over to a software engineer at the company and I said, hey, can you automate this? And he said sure, give me a couple weeks. And so I came back in a couple weeks and I had a script and we used the script to save eight hours a day or two people. And I was like, okay, that's my bag right there. I'm gonna jump right into that.

Speaker A: Who is your cheerleader or your support system?

Speaker B: That would be my wife. Uh, she is always there for me and of course I have my stable uh, of awesome friends that I reach out to whenever I need some help or uh, just a shoulder to cry on.

Speaker A: What about the best advice you've ever received?

Speaker B: So the best advice I ever received was actually at Internet M and in a mall. So the chief technology officer over there, his name is Michael Friedman. I haven't talked to him for years but what he said is software languages are simply tools and those tools, you use them um, in the right context and don't get too caught up in it.

Speaker A: Amen to that. Last question. Any tech or any tools you are using to help solve everyday problems?

Speaker B: Yeah, I use a lot of different tools on my website. If you search for tools you'll find uh, my full list. But uh, one of the tools that I recently ran into is a tool called Nushell. Uh, what it does is it allows you to uh, run commands against JSON, CSVs and all those other files and use the same query language against those files, uh, which I find uh, nice and approachable. I use JQ a lot for JSON, but Learning one, uh, syntax for all your files is a pretty valuable approach. And then I have to give a plug to Alfred on my Mac os. It's awesome for automation. It basically gives you a command line for your uh, operating system that you can execute tasks on and set up workflows and automate everything you do.

Speaker A: Amazing. I'll make sure to put those in the, in the show notes for people to people to reference.

Speaker B: Great,

Speaker A: excellent. So I like to kind of start off our in depth conversation learning a little bit about our guests and understanding kind of where, where they came from. Because a big part of this show is about building software with people. And I think the experiences that we bring to the table really shape the kinds of software that we, that we can build together. So you started your journey into software as a teenager, but I'm curious, did you have a eureka moment when you knew software engineering career was what you wanted to get into?

Speaker B: I did. And it was well before I was a teenager. Uh, I was in sixth grade and I was doing this career, uh, report, right? So everyone in the class was looking at different possible jobs and they were wondering, hey, what do I want to do with my life? And so I went and explored software engineering. And as I was reading through the material I learned that there was going to be way more demand for software developers than supply. And I was just, I don't know if I have an economics inclination, but I was like that sounds like a good deal to me. Uh, and I decided to dig into uh, software and computers as much as possible early in my, in my life.

Speaker A: So after many years, now you're a principal, can you kind of walk us through your journey sort of how, how you got to where you are?

Speaker B: Yeah, Uh, I think like every person uh, who gets into software, they start with a book and they wonder what is, what is this thing? Right? I actually started with a magazine. I uh, started with PC magazine way back in the day. And I remember reading it and just my eyes glazing over because there's so many acronyms. And for someone who's new, it's incredibly overwhelming. You really don't know where to start. And so over time I of course big pick the biggest fish and I tried to learn Borland C. And I was very discouraged. And so I set it aside for a while. Uh, and then uh, over time I crept, you know, crept back into uh, software development through uh, learning at uh, Earthlink about opportunities to go further. And that's where I actually picked up Cold Fusion. I don't use it Today. But I loved it because it was a great, you know, uh, I like to have consistency in my development environment and being able to go from HTML to uh, tags and Cold Fusion was incredibly nice. Uh, after going from Perl, right? Perl was my first language and Pearl is a pretty, uh, it's a bit obtuse, it's very powerful, but it's, you know, not terribly approachable. So going from that I just kept on learning more and more and more and took on role after role and I kind of just let the wind blow me where I wanted, where it let me go, right. I just let it go and I, I got into all kinds of diverse, uh, jobs. Um, of course Axiom was incredibly diverse because it's a consulting company. But I worked at a company called Sudden Values and what they did is they uh, did things like Groupon, right? And so we were doing these like sudden blitz things where you would put out a deal for limited time, try to get people to click and buy and. And then, uh. Yeah, fun story with that. I won't even talk about it. But he kind of took a nosedive with his business. That was a little weird. Um, so I've had a very uh, odd, uh, career as a whole. When I got to Nike, I had just been in the fire of all kinds of different things, just learning and growing and earning, you know, and then when I wasn't earning, of course I would switch roles. In fact, I have a blog post about that. It's called Learning, Earning and Growing and I highly recommend it for someone who is trying to continuously learn in their career and uh, become the principal engineer or the principal architect or any of these other higher uh, level roles where you have more responsibility.

Speaker A: So you mentioned as a new developer you felt there were so many things to learn and it was just such a wide world. Given the technology shift. Since you first started with, with new engineers coming in, do you have any sort of tidbits of advice to sort of. I mean the landscape is still huge in just a different way, right? Maybe even bigger. I don't know.

Speaker B: It's, it's bigger. Yeah.

Speaker A: Do you have any sort of recommendations on for new folks getting in to sort of help them ease their nerves about the wide world?

Speaker B: Uh, yeah. Uh, start with a problem. Don't go in. Just think, I'm going to learn something. I'm just going to read all the books and just muck m my way through it. Find a problem you want to solve. If you are pressing a bunch of buttons on your computer every Single day. Find a way to automate that process with any language. Doesn't matter what language it is. And then secondly, you need to find what you love. If you don't love it, don't do it. And I love games, but you also have to balance that. Right. I wanted to get in the game development and then I saw that the game industry has quite a bit of pressure against it because they, they're a lot like the movie industry. They have a lot of pressure to ship, ship, ship and if, and there's a lot of money on the line. So there's a lot of pressure. And I'm like, I want to, I want to work life balance. I want to be able to live my life. Um, but if you love that, go after it. It's okay to go in the fire if you want to really grow and build resilience.

Speaker A: Great recommendations. Thank you. So really quickly, I'm really curious, uh, when we first got Internet, our Internet provider was earthlink. Uh, and I'm really curious how has the evolution of the Internet and technology sort of changed how you think about your work?

Speaker B: Yeah, I'll touch on earthlink a little bit. Uh, one of the things I, it's funny, funny story. Internet and Amal got bought by earthlink. So Internet and Amal went out of business, uh, because they were not tracking their financials appropriately. So they picked up a financial system too late. And uh, as they expanded across the entire United States and had presence in many different prominent malls, uh, they ended up in a horrible position of having to close down the whole shop. And there were like fire sale situations. People are like, oh, I'm not going to get my last paycheck. I'm going to go take this, this computer and I'm going to go home. Bye.

Speaker A: Oh, wow.

Speaker B: So earthlink, uh, bought them and I ended up talking to someone through a, a chat. So a chat window in Linux, right? So we're in Linux. This person chatted me up with the chat command and we started talking and uh, it was such a funny uh, experience. They said, come over and interview with us. And then I sat down, had lunch and I had a job afterwards. This was this, this was the age back then there was, it was easier to get into things if you had the skill set. And over time, um, it has become more and more difficult for the tech industry people, the people that want to get into tech industry to get in. And I find that uh, a little bit alarming. Right. I feel like, I feel like we need to give people that are New a chance to come in. And luckily Nike has an intern program. I was able to interact with several great, uh, up and coming interns. They all had to compete to get into the, into the intern program. And they were all really sharp. They dug in deep, they tried to learn what was going on. Some of even built some software and then presented it afterwards. So, ah, this, you know, in summary, this industry, don't give up on it. Try to, try to jump in through the loopholes. There's a lot of them. Um, and tech itself, uh, don't get too caught up in it. And this is People for People podcast. Uh, it should be for people. Technology ultimately is for people to help them do something better or simplify their life or just make them allow them to go do something they would rather do than messing around with some technology.

Speaker A: Well said. So I want to shift to kind of a little bit about your role as a principal engineer and sort of what it means to be a principal. And let's, let's actually just start there. In your words, what is a principal engineer?

Speaker B: Yeah, and you started out the podcast by saying, uh, force multiplier. And that's the key phrase for me. Uh, what you as a principal engineer, I believe are responsible for more than anything is to amplify the ability for all of the people around you to get through the difficult problems that they're trying to solve in a more effective way and be able to come closer to the problems that people have. Your customers being able to get as close as you can to where the rubber meets the road. When your software is delivered to production and it's being clicked on or complained, uh, about by someone, those complaints, please embrace them as well. Right. Uh, you should really be curious, deeply curious, and try to dig into the why of things. And one thing I see, uh, principal engineers, some of them, they go really deep and other ones go wide. I think there should be a balance between the two. You should be able to go really deep on certain things, um, that are, that you, that you love. Right. Going back to the things you love and then go wide so that you can understand where you might find new love and you might find new opportunities to use those tools to simplify the work around the people that you are are trying to help.

Speaker A: And we chatted, we chatted before, before the podcast and you had mentioned a few things that your mentor had said. He had talked about the different levels and how you kind of think about them. Uh, would you mind repeating that for, for the listeners?

Speaker B: Yeah, certainly. So, uh, one of My buddies. He uh, is a senior director now. He's overseeing several different uh, mobile and web developers that are building Nike.com and the Nike app. And uh, he, he said the, the way you can look at this with a principal engineer is that the software engineer is looking down and at their code. They're looking down and they're building their, their software and they're shipping it. The lead engineer is looking up more, at least laterally to the teams that depend on them to ship or have integrations with, et cetera. And then the principal engineer looks another click up and looks out into the industry and goes and connects with people at Amazon and Gartner and all those other, and Forrester and McKinsey. Ah, and starts reading and understanding what are the industry trends. Don't get too caught up in them but like understand where there are opportunities to make things easier for all of those people that are looking down and laterally across the enterprise. And architects I would say are looking up a little bit more. Right. Uh, they're getting closer to the uh, architectural problems across the business. And I work a lot with those are uh, those principal architects. And for those people that are in that role you need to really understand what is the three year roadmap for all the systems that you have uh, control, you have either control over or at least influence over so that you can really understand. They have to be really curious. Principal uh, architect needs to look way up and be really curious, understand all the business functions, how they connect, where there's duplication. And in my tech modernization team, that's one of our main remits is finding duplication across the enterprise and helping Nike streamline its business.

Speaker A: We'll get to the tech modernization team because I think that's really interesting and we'll follow up on that uh, deduplication idea. But first I know that you run a community of practice for principals and sort of this idea, you know, we talk about how the industry is very vast and ever changing and you've given us some really, really interesting insights on sort of where a principal is looking. Right. How do those things translate into how you structure your community of practice for, for principals? What does it look like and, and what could you expect if, if someone were to join that forum?

Speaker B: Yeah, let's uh, let's go back to the statement I made earlier, uh, earlier about Gartner and specifically. Right. So to give you a little background, Chris Kasten, who uh, is no longer at Nike but was there before, was, was driving a platform strategy over there and we were going to engage, we actually already engaged with Gartner to start building a story around platform engineering and why it's important for Nike. And uh, Chris Kasten uh, built like this internal paper for platform engineering. So if you have Gartner access you can look for platform engineering Nike and you can find uh, that documentation. And uh, that was going to be an input. I'm going to still do this I hope, uh, an input into a presentation to principal engineers to give them a North Star of platform engineering and then following up fast following with a what does it mean to be a principal engineer? Uh presentation. And I was. And I'm going to pull in uh Amazon Leaders over there and I'm going to pull in Gartner, I'm going to pull in all these different uh, angles to help them understand how important it is to level up what we do and become more impactful and uh, more effective for the enterprise for the purpose of serving our customers. And that was my goal. And then to add on to it, the most important icing on the cake to me is uh, inner source. So platform engineering does not work without an open source mindset. And inner source, I'll explain that for people that don't know is just simply using open source inside your company. So transferring that open source mindset uh, behind your company's firewall and getting people to understand they don't have to wait for a roadmap item to be complete. You don't need to wait, you just go in and you engage the team in their community. Each platform should have its own community. This to me is a natural progression of platforms. A little sidebar. Apple started uh, several products back in the day and they didn't have any communities that were directed at all. The community started building around their platform, their systems and they started sharing information in forums and having chats and all kinds of other stuff and they would share tips and understanding. And so each platform you have inside of your enterprise, if you're in a large enterprise, should have a strong base community of practice. So if you have a service platform like we have, that has uh, kubernetes and ECS etc, you should be helping that community be successful with your platform and you should continue to nurture uh, that environment like a garden. So to close up this principal engineer they have to understand inner source, they have to understand open source and they need to promote it and they need to accept those contributions to their platform and be receptive and understanding that people have needs. And if you're blocking them from using Your platform, it's not good for them, it's not good for the customer, it's not good for the people that are buying your products.

Speaker A: Well, let's dive in a little bit more to intersource, um, because I'm curious, sort of what in operational sense what does that look like at Nike? Like what are the minimum requirements, for example, that you would need a project to be considered as intersource?

Speaker B: Yeah. Um, you can be really strict and you could lint your products, your projects, your git projects and you could see if you have a contributing md, if you have a developer md, if you have all the things that you need to make your project receptive and ready for people to contribute. And I think starting simple and just adding and contributing to MD is completely acceptable. Just make it clear and be empathetic. You have to put yourself in the shoe of someone who just cloned that repository and try to understand their experience. And even better, just hand hold with a few people and understand what their experience is because ultimately it benefits you if they provide a new contribution that is going to make your project more valuable for people. Uh, because then of course, you know, you get the notoriety and the influence and eventually you create what I call an inner force project where people are forced to use it. We have several tools like that at Nike where sometimes you're not so happy you're forced to use it, but it's there because developers just created it out of a need. And uh, that right there is the value. Right. So now they're all not wasting time doing things that they would otherwise be doing manually. This packaged up in a nice uh, Python, uh, package or whatever tool and then you install it with Homebrew and you're off to the races. So ah, that's, that's important.

Speaker A: Do you find that it's kind of a, it's a way, it's sort of a codified, documented way for how teams can structure their projects to enable other teams to know how to use it and how to contribute it. Sort of as like a, a contract of sorts to make it easier for the communication between teams without actually having to necessarily communicate with the teams. But they're able to do it through the documentation and through the software.

Speaker B: Yeah, I think of it as more as a mindset like DevOps. Right. So, ah, open source is a mindset. DevOps is a mindset. Inner Source is another mindset. If you already know Open source, you can overlay that on top of inner source. It just has different concerns and has different Opportunities to uh, be more uh, you can connect some of the internal uh, information like employee information, understanding who's using these projects, what's the adoption rate, how do these Inner Source projects connect to all these tech solutions, how do they support them? And you can start measuring that, that data to understand better how Inner Source is improving your, your experience and accelerating your time to market. And that to me is one of the main things is there's two main things. Reuse, right, so you're not reinventing wheels and then the second is accelerating time to market. So if you're not blocked by a roadmap then you can get your product out to market more quickly and serve your customers needs. That's where InnerSource can be incredibly valuable. And then of course not, not to discount it, but the community and trust aspect is incredibly important. That's one thing. So Open Source builds trust and community amongst small groups of people. Inner Source does the same thing. People start learning from each other, they start realizing, oh, there's this other vast world I didn't even think about and you might just collapse the Inner Source project completely because you found another one that is doing the same thing, which I have seen happen on multiple occasions and you just move and group those people together into that new project. Now to tack onto that, I recommend anyone who's doing Inner Source to join the Inner Source Commons. So innersource commons.org and taking a look at our patterns and our Managing Inner Source book, which is going to be taking a little bit of an upheaval, we're going to change it to how to create an Inner Source Program or Program Office. We're still trying to figure that out, but uh, that Program Office will help you simplify and get everyone on the same page and start connecting your Inner Source practices with your DevOps practices and your platform engineering practices and then hopefully taking metrics where I'm focused, uh, and then measuring your project's efficacy and the efficacy of the community around your projects and then you can start helping and investing in those communities. So Open Source works best when there's an upfront investment from some dedicated company that builds the foundation for an open source project that will last and stand the test of time. And so a plug to uh, the Chaos Community, it's a caoss, I believe, that is a Linux foundation project and that project was built by several wonderful PhDs that are academic in nature and they have built a wonderful set of metrics to trying to codify into an ISO standard so we can use those Metrics to measure our progression as software developers and practitioners of the projects, which I think is amazing. Uh, being able to measure the cycle time, PR cycle time in a systematic, simplified, uh, way that is common across the industry becomes an interesting benchmarking tool. Now of course, just like uh, you know, Agile, where you say it's three starter points, which I don't highly recommend going too deep into those weeds because uh, that, that could create a flame war as we all know. But yeah, but you got to be careful when you measure. Not everything's apples to apples. Think about your context and uh, this is no different.

Speaker A: So because you're kind of creating that community with Inner Source, would you say that it is, there's a little bit of this, it's providing visibility to, within your organization of the different projects. Because if I'm over here on um, team A and you're on team B, and maybe we don't really ever talk to each other, but I might be able to discover what you're working on easier because of these standards and how you're supposed to fit these projects together. I think you mentioned you have something where you can look up what projects are on Inner Source, right, within your systems.

Speaker B: Yeah, that's a really good question. Um, in fact that's where we started, uh, with InnerSource, you know, as you, you know, you don't remember some of the things you did at the beginning of something, right. But uh, but you, you can benefit greatly from just simply having and classifying your projects as Inner Source. And so what we did is we made it, we just used a really simple convention. We said if you add a topic with nike-innersource to your GitHub project, then that is now an Inner Source project. I plan on going back and checking for a, uh, contributing debt MD across the enterprise and looking at all of the projects and then sending a message to those people. And lucky me, I've got keys to the kingdom on this. I might just inject an issue into their GitHub backlog. We'll see. Uh, and get them to go to our Inner Source recipe which uh, was inner sourced. I run an Inner Source community of practice and we built a recipe together. We did some mobbing and we wrote down the mob programming convention. Um, simply you've got a driver and, and an observer and you've got several other people that we get a person who's writing and everyone can do this in their own way. There's many different ways to do mob programming, but it's highly Effective to crowdsource. Uh, the collective view of great professionals that understand and want to uh, add to the value of inner source at uh, Nike or any other product for that matter. And because these people self select and they join the inner source community they already, you don't have to try to, to convince them that it's interesting. Right. So what we do is we advertise the events in our Slack channels and then uh, people could just click the button and join. Well we have an automated system that sends out messages right before the meeting. Hey this meeting's starting to start. Is get about ready to start. Click the join button. There's a button in Slack. It's. We got uh, a whole app for that Slack app and everything else. And that Inner source project was highly successful. We built that recipe. We give uh, the information on how to query the inner source projects uh, in our GitHub projects and then we have a. Funny enough on the side someone built a portal for it. I didn't even tell them, I didn't even ask them to do it. They went and built that and now we have a directory of inner source projects for Nike and anyone at any developer can access that directory and we're going to contin, we're continuing to, to level it up, add some attributes to it and then we'll add the measurements to that and say hey, this is the Internet Internet maturity, the inner source maturity score. Right. M so we have this maturity framework in the platform engineering world uh, and we're going to use that.

Speaker A: Amazing. And is there a certain size in which companies are that you would recommend them starting intersource or does it matter? I mean any size is the right time to start intersource.

Speaker B: I would recommend small companies to start early and often I would recommend them to even think open source if they have any software at all, uh, from the very beginning. And if you can't open source it, then inner source it. Uh, there's definitely projects that are being worked on internally. They don't want, you know, companies don't want competitors to, to even know that they're working on something because they want to make a big slap splash or whatever. Uh, that's understandable. That's where you would pull inner source off the, the shelf. But open source start with it early and often there's big benefits with that. You get uh, public uh, recognition and you get brand value. You get all kinds of wonderful benefits just by being open source. You join a community by default. People that think open source and those people are Very receptive and friendly.

Speaker A: And you mentioned the community of practice of intersource. Is that just within Nike or do you run, do you run it outside of Nike as well?

Speaker B: So, uh, I run the internal one at Nike and then I'm part of the Inner Source Commons. So I'm a foundation member in that community of practice. It is a nonprofit that is global. Uh, we have people from Microsoft and IBM and, and well, uh, Sky. My buddy Russ, uh, Rutledge over there, give him a nice shout out. He, he used uh, to work at Nike. He now works at Wells guy. He's still championing Inner Source. Wonderful guy. Pop into the Inner Source Common Slack and, and say hi, we run it in Inner Source Program Office working group where we're building knowledge for those people that want to practice Inner Source.

Speaker A: Excellent. And I'll put some, put some of those links in the show notes as well where people can find that Inner Source Commons.

Speaker B: Awesome.

Speaker A: Kind of following this trend of technology advancement, I'm curious your thoughts on how the proliferation of AI affects our jobs, affects what you do, affects the industry. Um, tell us your thoughts on AI.

Speaker B: Yeah, I would like to deflate the balloon right off the bat. So you're going to find that most of the AI use cases are centered around process automation. And I think that as the hype starts to fade, which it's already starting to fade, I heard a friend of mine read an article and told me that people are starting to have an aversion to people that are selling products that say Gen AI in it. There's already like a low lowered receptiveness to people trying to jam that down our throats, so to speak. And uh, that right there is, this is just the hype cycle of tech, right? So then with that said, there's still a big bang experience here, right? So we, we gradually got computers over time. They got better and better. A little slower, like they, they, they were slower, they got faster and it was a slow burn. Right. It wasn't immediate. The Internet was the same way. It started out really small. In fact, the BBSs were the predecessor. You know, we had connections that way and it slowly grew over time. But this was like a, uh, hey, boom. You can completely change your workflow scenario with AI, which uh, obviously is causing a big stir. People are still talking about it all the time. I think the biggest thing to remember is that it's just a tool to automate and simplify your work. And sometimes just like any other tool, if you don't use it right, it's going to get in your way. So I use Copilot and I had this fun little battle with it, trying to get it to tell me why something wasn't working with uh, Unicode encoding in Python. And it kept lying to me over and over and over. And I asked, I asked, uh, another AI llama, uh, and I tried that and it lied to me in a similar way, almost the same way, right? And then I finally pushed it into a corner and forced it to tell me the truth. And then it did finally tell me the truth and then I was off to the races. But it was such a, such a pain. Uh, you know, as we know in software development, one of my big gripes is that documentation tends to be, ah, anemic. It's not, it's not getting to the edge cases, it's just saying, here's the API, good luck, have fun. That's one of the downsides of open source. Sometimes you have to jump into the end of the code to understand it. AI is super helpful for, um, giving you prompts. You can give it a prompt, it gives you many more. Um, someone said, hey, you're going to be a prompt engineer. I'm like, hey, the AI could just be a prompt engineer. Just ask it for some prompts. But I, you know, all that is really cool. Like I use it for image generation, uh, often for my blog posts I'll just type in like, I would be really lazy and just say, give me an image with a dark background that fits the vibe of this blog post and just paste the blog post in and it generates an image for me. That's great. You know, I don't have to be tedious and do the, you know, the canva business that I'm doing, uh, right now in a, in a, in a manual way. I can just have it do everything I want to. I mean I don't have to go sort and select and look through like 500 pictures to decide the one I want to do. And nobody wants to use when, uh, nobody wants to rebuild images over and over. I mean even like a person who's generating images doesn't want to do that all the time. They're going to reuse like a comic artist will reuse a lot of their base foundational, uh, artifacts to, to build new comics every day. They don't want to redo that, right? If they could just use their base artifacts in a model and build their comic quickly and get their point across, they might even do that, right? So I, I think that is highly valuable. People are worried it's going to take, take uh, a lot of the humanity out. I think that humanity is going to start uh, elevating and becoming, becoming more uh, more interested in the human aspects rather than the nuts and bolts of trying to get things done in their life. I feel like I'm hopeful that's where AI will go. Uh, but with like any technology, uh, you never know. You never know what's going to happen.

Speaker A: I love that. Yeah, thank you for that take. Appreciate it. Let's talk about your tech modernization team. Tell us about what it is. Tell us about the mission you mentioned sort of deduping and streamlining. What is this team?

Speaker B: Yeah, um, I'll give you a quick uh, recap though. I've been at the team for now two years. It started out as the Global Platform center of Excellence and we were focused on driving the platform strategy across Nike and getting people to adopt platform engineering and shifting uh, to reusable solutions that the entire enterprise can depend on and use rather than building their own solution in silos and duplicating uh, the efforts across the enterprise. Uh, that's one of the main goals of platform engineering is to centralize your uh, SME knowledge on particular uh, disciplines and areas and to reuse those products rather than rebuilding them everywhere. So when you have 50 to 100 teams, uh, building kubernetes clusters across the enterprise, that's a really expensive proposition. Uh, it's got a lot of pointy edges and you know, hats off to the people that built it. It's an amazing product but it's incredibly flexible and the more complexity you have, the more rope you have to hang yourself with. It's just so to speak. Um, so that journey was interesting and fascinating. We had to do a lot of selling to vice presidents and, and getting in front of their teams and saying, hey, there's this platform catalog. We want you to work together to build this catalog so we can understand the software that we have here at Nike. Uh, well that was trying to solve the problem one way and I think it is a good way to fix the problem long term. But it's a massive cultural change that requires consistent, consistent messaging and sometimes some heavy handedness, uh, to get to a point where people are using it. It's a, it's a massive shift. You know, it's really hard to get people to change and uh, I don't, I don't blame them sometimes if you're happy and you enjoy the way you're doing things you don't want to Change, Uh, but on the other hand, if the change is better for the group, for the company, then we should get after. And so tech modernization is a more direct approach, uh, to the license costs, the hosting costs, the hardware costs, the labor costs. Like all those, all those things are considered as we look at the software that is being purchased or renewed across Nike. So if you were going to go, uh, buy G Suite, right, There's a renewal coming up. You got 5,000 licenses across your enterprise. Um, some people may or may not be using it at all. Uh, you've got to have some scrutiny against the way that's being deployed and used across your enterprise. And Nike's got really good scrutiny in some places and not so great in other places. And then there's of course the duplication problem and simplification. So we say, uh, standardization, simplification and modernization. Right? So the standardization is getting your solutions in the global catalog that we have that has a list of all the tech solutions and the platforms and the owners of all those tech solutions and platforms. You know, who's the business sponsor all those things. Right, that's in the catalog. That's the standardization you start reusing rather than recreating a bunch of wheels and then simplification, uh, is finding and looking across the enterprise. We've got six content management systems. Why? Is it just for, just for fun? Or is it because we have a license over here that is lucrative and so we got it free with some ah, suite or package? Or is it because someone just bought this and didn't know about that other thing? Right. So you have to do that analysis. And um, we, we used to be pretty um, liberal with the purchase of software at Nike. I mean it's a big company, it's got a lot of money. People would more quickly be able to get their business objectives completed, uh, if they just bought the software and ran with it. But you got to step back and say, hey, if it takes another extra two months because someone modified a foundational platform solution, uh, instead of buying this new software, then that's good for everyone. You have less choices, less problems. And so we work directly with sometimes vice presidents, uh, a lot of senior directors, lots of different people, um, you know, sometimes program managers, we find shadow, ah, it is what we call it, um, is a bunch of people that are just buying something after listening to a sales pitch and then learning that it could improve their workflows. And they just depend on the vendor to, to help them give them professional services and do the work. But it costs millions and millions of dollars and for, and when they look at it from their perspective, it's worth it. Right? Because if they speak they pay 2 million and they don't have the resource, the human resources or the skills to produce a solution in house, then it makes sense for them to just buy it. But if you don't know what's going on in the enterprise with the standardization, then that's what you're going to do. And so with the global catalog we have the ability for you to do platform shopping and you type in what capability you're looking for, uh, or even a specific tech solution and you can, you can click on that solution and then you can see in there if there's uh, other solutions that are good.

Speaker A: You know, as engineers being curious and wanting to explore new things, new languages, new tech. How do you balance sort of that conflict of standardization with explore exploration?

Speaker B: Yeah, we actually are taking a community driven approach on that. So uh, we have a set of technologies that all the principals, so distinguished engineers, principal engineers and any, anyone who really cares about excellence in alignment on which technologies are the best for Nike. So we have an RFC process where people can create a pull request and request a new technology to be added to our tool belt that's in the approved category. These are ones that we know they're used a lot. We use GitHub to interrogate how many people are using Python or Java. We have a lot of GitHub organizations. I don't want to tell anyone how much it is because it's internal information, but we have a lot. And um, we have a uh, open search cluster that has taken the data from all of the GitHub organizations and we enrich that data with many other pieces of data m, uh that are useful. Like uh, what uh, build server has this, is this been deployed? To which AWS accounts are these deployed to? Really cool stuff. So, so yeah, there's, there's many different uh, technologies that Nike use across the enterprise and this approved tech helps us gain alignment around uh, which technologies are best for Nike. And using that data from, from our uh, open Search cluster we can find out that Python is a very popular language or Java is a very popular language and then we can add information about how we should use it. So Java for example, we use Open JDK and there's a very specific version that we use and we're now moving to Amazon Corretto, uh, because that also makes sense for us. Right. And it always depends on your environment. Like if you weren't using AWS you might not use Amazon Corretto because there would be no real benefit to it. And so uh, using that bottoms up approach we get the buy in from the leaders that are going to then recommend those technologies to the people that they influence or work with and that's how we follow that process.

Speaker A: So last question before we wrap up kind of on the, on the theme of platforms. How are you, how do you define what one platform is versus another platform? And so what are your boundaries there? So you know, maybe we have 10 platforms. Well how did you, how do you break up those platforms?

Speaker B: Yeah, this is the golden question that will have many different opinions. I uh, love domain driven design so I recommend looking ah, this is probably not the best but uh, looking at a platform as a uber domain, right and, and try to understand what is the, what are the business units that are needed to support this. Um, how do they affect each other? Categorize your platforms by different version like types. So a core platforms, uh found a, a core platform, a foundational platform, experience platforms like these different platforms, you want to categorize those and you want to uh, try really to think about the communication patterns that exist in your, in your business and, and try to be as intentional about hey we can't just uproot people all the time just for fun. Uh, we've got to think about what, what's going to help this team be successful to produce value for the business on a regular basis. And sometimes that does mean you create a silo. Um and of course disciplines uh, are where you're going to go in the experience world. Like so uh, commerce, the commerce area. When you're doing uh, digital commerce there's a certain way that people do business. So it makes sense to logically group your tech solutions into say an experience rendering platform where you're doing all the experience rendering in a particular way. And then you're going to want to group all your foundational APIs and services into say a service platform and then BI and analytics. You uh, want to group all of your BI and analytics solutions into that type of a platform. Um and of course your mileage may vary, you know, like it depends on your uh, organization and whether or not it's amenable to that. Nike went through a massive reorg to align with platforms and uh, I'm just going to say it's messy, it's not easy to do there be dragons.

Speaker A: So yeah, yeah, well change is hard as you mentioned so.

Speaker B: Oh yeah, excellent.

Speaker A: Well before we wrap up, this has been an absolute pleasure, thank you so much for coming on. Do you have any last thoughts, any words of wisdom that you would like to share with, uh, listeners today?

Speaker B: Yeah, I really like the way that you are talking about people and how technology connect to me. I love technology, but I love people more. And I want to serve those people with technology and help them make their lives less complicated, not more complicated. I want to make sure that I'm listening to them and that they, uh, are heard and that we help them with their pain points. I love software engineers that love the deep details. I love deep details as well. But getting lost in details when the real purpose of a technology is to help people. I mean, you use a hammer to amplify your ability to put in a nail. You don't just use the hammer for fun. Well, sometimes you do when you're a kid, right? Uh, throwing hammers around. But technology is here for purpose and software is no different. And I would also recommend that people try to map, uh, their efforts in a very abstract world, the software world, to things like, uh, how would a mechanic think about this and how would they do this? Right. It's a more real world, uh, engineering, uh, discipline that is a lot easier, but at the same time you can map that over and say, hey, would it, uh, would a mechanic start screaming about, I've got the best hammer in the world. My hammer is the hammer you should use. And if you don't use my hammer, then why are. Then I'm gonna hit you, hit you over the head with my hammer. Like, don't, don't do that. Uh, please. It's not helpful. Uh, it's not good for the community. It's not good for, for anyone really. So put down your vim, uh, versus Emac war material and, uh, start coding and have fun.

Speaker A: Where can people find and follow everything that you're doing on the web?

Speaker B: Yeah, uh, simply go to jeffbailey Us. Uh, if you scroll down a little bit, there's links to where I show up. I'm usually on LinkedIn. Uh, I use it as a feed of knowledge and just continue to consume that knowledge. And it's, it's an amazing resource for that. But yeah, LinkedIn or my website are good places to go.

Speaker A: Fantastic. Well, Jeff, thank you so much again for being here today, talking about your journey into software, your, uh, aha moments, talking about how you view a principal engineer, innersource and Inner Source Commons, and your Nike tech modernization team and platform engineering. So it's been a really wonderful conversation. So thank you again so much for being here.

Speaker B: It's been a pleasure. Nigel, thank you very much.

Speaker A: Well, that's a wrap. Thank you for listening to Building With People for People. This episode will be my last for a little while. I'm taking a break to focus on family, and so the podcast will be going on a hiatus for now. As such, I want to take a moment to thank you for tuning in and listening to the wonderful journeys of our guests and sharing in the quest for what it means to build with people. I also want to give a huge thanks to each of our guests for making this journey possible. Y' all are so amazing. While there are too many wonderful guests to list, some of the highlights include the founder of htmx, Carson Gross, the incredible mechanical keyboard aficionado, and dev community builder Cassidy Williams, the React Testing Library creator and react wizard Kent Dodds. And the list just goes on. Be sure to check out all of our episodes at podcast, uh, unfilteredbuild. Com episodes. With that, I bid you adieu for now. So go build with People.