Host Intro (Gene Kim)

Okay, next up is Jonny LeRoy. I had the pleasure of meeting him earlier this year. He is currently SVP and CTO at Grainger, who we learned yesterday from Emily and Lucas was a company founded over a hundred years ago with over $17 billion in revenue.

Prior to his five years at Grainger, Jonny decided to study Greek philosophy and law, and then spent 15 years at Thoughtworks, and was actually part of the Google Calendar team. He hired my friend and co-author Jez Humble twice. His book Continuous Delivery was while he was working with Jonny.

In every interaction I've had with him, I've found him to be so incredibly thoughtful and inspiring and clearheaded. He'll be sharing some of his leadership philosophies on how to manage and constrain complexity, evolve architectures, because we all know how important it is because architecture so much dictates performance, and transform cultures and how we work. Here's Jonny.

Jonny LeRoy

Thanks, Gene.

Hey everyone. I'm Jonny, CTO at Grainger. I'm also the person who's standing between you and Kent Beck and Steve Yegge, so I'll try to keep us on track. But I do want to give you a few little nuggets of what I've learned and what we've learned in the five or six years we've been driving a transformation at Grainger.

For those of you who don't know Grainger, we are an almost 100-year-old B2B distributor of industrial supply materials. We have millions of products, millions of customers, and several million square feet of distribution centers across the world and across North America, around $17 billion of revenue. The majority of that flows through systems that I'm responsible for. Lucky me.

When you look at our business, it seems like our core business model is to help our customers find products and ship them reliably to them next day, order complete. But when you scratch at that, the real value proposition, what makes us sticky with our customers, is we help remove complexity from how they keep their businesses running.

We sell into big complex buildings, manufacturing plants, hospitals, conference halls, and so on. We sell into the folks who are trying to keep those businesses running. Emily and Lucas talked yesterday about some of the ways that we remove complexity by simplifying our customers' operations through managing their vending, making sure we have the right products in the right places so they don't stock out, and also lowering cost.

We also help procurement managers manage a lot of their complexity of how they have spend control, who gets to buy what, what are the right approvals, and how we integrate into their procurement platforms. Just a sense of that complexity: we have over 300 different ways that our customers can customize their orders.

So how do we handle that complexity for our customers? I want you to meet character one. This is MacGyver. He was from an eighties TV show. I grew up in the UK, so I didn't grow up with him, but he was known for ingenuity and problem solving. The phrase MacGyvering something is just to get it done. He was renowned for pulling solutions together from everyday objects, whether that's duct tape, wire, batteries, cleaning products. We sell all of those, by the way. We actually have 300 different types of duct tape, so you can imagine the information management needed to help customers reliably pick the right duct tape for their industry.

He embodies a sort of resourceful, can-do attitude. That's really what a lot of our customers have. They're the folks who actually keep operations running, and that culture imbues into our organization. We help keep them running, so we go the extra mile to get that job done for them.

But that complexity has to go somewhere, and often it ends up not just as duct tape, but as Excel, emails, swivel-chair integration, Access databases on shared drives. That complexity lands in our human processes and in our systems architecture that end up looking a bit like that.

I want to introduce you to our second character, Marie Kondo. Around 2011 she published a book, The Life-Changing Magic of Tidying Up. It's really about how to simplify your life and only keep things that serve a purpose and bring you joy and calm, and so treat your belongings with respect and find a place for each of them.

Really, I want to use balancing the lenses of MacGyver, of how we get it done, with a calm simplification. You need to stop chaos taking over your systems, and use that lens to think through the journey we've been on for the last six-plus years. I can't tell you everything, so I'll just focus on a couple of personal aha moments that are hopefully helpful.

Starting from the top, how do we simplify strategy? Since pretty much the first year I've been in the role, we ended up with pretty much this visualization of our strategy. We lovingly call it the burger because it looks a bit like a burger. Sometimes I'll work through each box with teams explaining what it means, but normally I just simplify it down to just two things: drive advantage for our organization, and reshape and modernize our landscape. To do that, we've got to evolve our talent and ways of working and our culture.

I keep repeating those two things over and over again, whether it's how do we prioritize new features against tech debt, when we are budgeting, how do we think about growth versus running a tight ship and productivity. One thing I've learned from parenting, and it's not give your kids Red Bull for dinner, as we heard from the folks at WEX, is you've got to repeat the same thing over and over again. The other thing I learned about parenting is: if you want to say the same thing over and over again... you're welcome, I'll be here all week.

So how do we drive advantage? We try to keep it really simple and understand what do we need to be world class at. Even our CEO says this: we have to understand our customers and our products better than anyone else, and help them find the right product quickly and get it to them smoothly and quickly and easily.

Sometimes that seems easier said than done, because how we've managed our customer and product information data over time was based on largely off-the-shelf systems that weren't really designed for the distinct characteristics of our business. So we've made it in two ways: we've made our business processes, and we've made customizations on top of those off-the-shelf systems.

As we've leaned into building custom software, we've really had a bit of a blueprint for success of how to unwind some of that complexity. It starts with really good business and tech partnership of rethinking, reimagining the process. You actually want custom-built software for that, iterating as you learn about the process and the software, and getting better and better.

That has two beneficial outcomes. One, it drives better business outcomes: faster review of our customers, faster review of our assortment or pricing or inventory, and better data that flows through into our e-commerce and also feeds into our AI systems.

The question that's really helped unlock the thinking of our business partners is this HMW question: how might you want to operate if you are unconstrained by your current technology? Often you need to ask that question a few times until people really stop thinking about their current world and their current tech. The key here is to evolve your business process and strategy hand in hand with the technology.

An example of that would be we spend a lot of time with our merchandising teams who are responsible for our assortment of products. With a couple of million products, do we have the right 300 versions of duct tape? Should it be 200, 100, 400? What do you need in different scenarios, in industrial conditions, and so on? How do you present that information? What are the right data points we want about these products? Really working with them to build that tech and then flow that data into our e-commerce systems has been a lot of the work.

The impact of that has been really strong. A lot of this is having the right assortment helps our growth, and having the better visualization and navigation of that product data really helps customer satisfaction. I showed a version of this slide to the board a month or two ago that actually had really nice and really impressive numbers that had lots of zeros on them. Sadly, I'm not allowed to share them or we don't share them publicly, but definitely line goes up.

I talked about simplifying, or about the architectural impacts of some of this complexity. Whose architectural landscape looks like that? Yeah. What's that thing in the middle for you? Stuff? For me, that's SAP. I did have a moment when the Exabeam folks were saying they were struggling with 15- or 20-year-old legacy code. I was like, oh, sweetie. We're a hundred-year-old company.

Anyway, how would Marie Kondo think about fixing this, simplifying this landscape? In my mind, you need a nice simplifying design philosophy. One of the best simple engineering design philosophies I know is the Unix philosophy. I would love to do a whole talk about the applicability of how that actually can feed into larger-scale systems and architecture. If you think about Unix, you've got these small single-purpose programs, text in, text out, piped into the next system. If you zoom that out, a lot of your enterprise architecture should look like that. Leaning on tools to help with automation and testing is really, really important.

That's part of the philosophy we've been using as we've been unbundling our e-commerce platforms. Historically we've had a large monolithic on-prem e-commerce platform. We've been unbundling that to have better product data, search, checkout, order history, and so on into small micro-ish services, cloud native, et cetera. After a few years of going down that path, we've been able to measure that work that just happens in those newer systems, because they're right-sized and because you've got better automation and practices, is three to five times faster than any feature that actually touches the legacy system. So there's real outcome there in throughput and speed.

But this philosophy isn't just applicable to custom software. It also applies to big hairy things like SAP, which is anything but a microservice. If you think about this view of what are you for, what's your single purpose, I sometimes hesitate to say this, but really in our overall architecture, I want SAP to be a highly reliable, quite expensive, dumb pipe, transaction processing engine. Once you realize that, then you can take the Marie Kondo approach and look for each component and say, does this give us joy? If not, should we rewrite it custom? Should we move it to commoditized SaaS, and so on? That mental model of what you want your systems to do helps drive how you unbundle them.

Even on continuous delivery type approaches, you can do that with big systems as well, off-the-shelf systems. Historically, our SAP deployments were at least monthly massive events. Lots of people took down the business, took a whole bunch of coordination, and a combination of the right automation and a shared DevOps culture across the whole of our engineering group mean that now we can do intraday, low-impact, regular, low-risk deployments. So a whole organization, whatever they're building, feels like they've got a shared culture.

As we are going through this ongoing unbundling, one big lesson is that you are always going to have transitional architectures, those shims, those indirection layers you have. My guidance is treat them as a first-class citizen. It's easy to say, let's get the target state right, our future state that'll be secure and reliable and resilient. But actually embracing that your transitional architectures need to have those characteristics as well is super important.

A lot of this is around how do we simplify engineering. There's a lovely phrase that came out of Microsoft, of all places, about the pit of success. I love this idea. If you haven't heard it, it's really how do you set up your landscape? How do you set up the ergonomics so that if you stumble and fall, you land in the right place? That's the pit of success. A lot of this is around platform building, tools, the right training, and so on. Make it easier to do the right thing. I think Eric and Phil will be talking tomorrow about some of the work they've been doing to make the lives of our engineers better and now make it better with AI.

If I think as a leader, there's a few things you can control and you can do. You only have a few levers. You can set strategy, allocate investment, assign leaders, and while not easy, those are some of the easier, more trackable things. That leads to good platform building and good coaching and so on.

The harder job of a leader is to create culture, to create and nurture that culture. In terms of a culture of continuous improvement, that's an area we've really leaned into and focused on: getting the right metrics, but then the right rigor of doing retrospectives. We call them operating reviews: how do you look at your metrics, look at the biggest constraint, how do you try to improve that? For me, it was surprisingly hard how much repetition I needed to bang the drum of, hey, you need to do this thing. Just do the thing, have the session, and then let's do the thing better. Let's use better metrics. Let's focus on one thing.

That really was harder than I expected, but we're actually seeing real progress. Over a couple of years, we saw the amount of teams double that were using good metrics-driven continuous improvement events, and then went from maybe half of those teams being in the higher or elite DORA tiers to three quarters of them being in that space. Yes, leadership is saying the same thing over and over again.

We've got a lot of things in place and actually hit a point maybe a year or two ago, thought, I've got this. I understand the job. We're rolling. We've got the right people. Everything's good. Everything's easy. Then I realized I work in technology.

A quick poll: has AI made your job more complex or simpler? Has it made it simpler? One person. It's made your life simpler. Anyone made it more complex? Okay. I see both, and I'm seeing this now as probably the Altman paradox of the productivity I get from using Slack's AI recap capabilities is completely offset by generating AI images for conference talks. So you win and you lose some.

How do we simplify AI? What would Marie Kondo do? How would she handle it? I think she'd tell us to go back to basics and focus on what brings us joy, or more importantly, what brings our customers joy. Our customer needs haven't changed. They want it to be super easy to find the right product, to ship them the next day, complete, remove complexity from their businesses. That hasn't changed. What has changed is how we do it, the tools in our toolkit, and some of these are quite strange new tools.

We've evolved the question now to talk to our business partners about, and you almost certainly heard this: how might you want to operate if you had access to unlimited interns? People question: are they interns? Are they early-career student employees? Are they PhD level? I don't buy that yet. Regardless of where they sit, I'm talking about AI now. AI agents and capabilities are enthusiastic, energetic, and fallible. They need oversight just like a whole group of interns.

A key lesson is, as a leader, business or tech, you are responsible for the outcomes, not the AI, not the interns. You need to take accountability for those outcomes. To do that, you need to understand the failure modes. How do they fail? How do they fall apart?

There's been lots of conversations. Maybe this is a dinner conversation for you all, but there's all the ways to talk about sociotechnical ecosystems and landscapes of humans and technology. Question for you: is AI more socio or more technic, or what does it do to that thing? Catch me for a bourbon later if you want to discuss.

When we think about how we're using and deploying AI across the organization, it really helps me as a leader to simplify things into a few buckets so I can really focus on how to reason about it. One area is where we think there's outsized advantage. We're centralizing those efforts, putting a lot of our ML experts, our PhDs after those pieces of work. Partly because it's big advantage, partly it's more complex, but partly because there's knock-on benefits.

We've had a whole bunch of work supporting our customer service agents, building a digital assistant that helps them, human in the loop, answer customer questions and actually helps them be smart to ask customers more questions to narrow down which type of duct tape they actually need. One of the benefits of having the right teams focused on that is what we were building there pulled on the product information that I talked about before that we've been building, but then sucked in unstructured data, wrapped LLMs around it and, you know, vector databases, MCP, all the things.

We're beginning to see some reusable assets, and that's feeding over into how we reimagine search and how we think about semantic search. We're beginning to look at how do we repackage that type of tooling to plug into things like enterprise ChatGPT.

Which brings me to the second half: how do you unlock creativity of everyone in your organization? This side, we're doing in a way more decentralized, organic way: get the right tools in the hands of the right people.

There's been a lot of talk about this MIT survey that went around of 95% failure of large enterprise AI initiatives. Interesting study, but I think it actually really buried the lede. If you read into that, the real kicker was organic adoption. Shadow AI was outstripping centralized efforts. It was having a 60 or 70% success rate. So my guidance is embrace it, with the right guidance and guardrails, but also get the right tools in the right people's hands.

We noticed initially we gave people a lot of Microsoft Copilots and it was like, yeah, cool, okay, I can do some stuff. A bit later, we got enterprise ChatGPT and the uptake was amazing. I don't think it was just timing. I think it was actually better products lead to better results.

One interesting nugget: when we gave out our first set of however many hundred licenses, half of them we allocated top-down. Exec leadership worked out some groups and people who they thought could use it well. Then we looked at who the actual users were. We looked at our firewall or Zscaler logs and found the people who are heavy Claude or ChatGPT users, and went to them and said, hey, do you want the real thing? This one you can use enterprise data. How are you using it?

Rather than going to them with policy and saying, what are you doing, we actually enabled them and tried to follow that desire path. Dozens and dozens of great use cases are coming out. We're seeing more and more sharing of custom GPTs. Now we're re-engaging from a centralized side to say, how can we give you more leverage?

A big learning here, and people have hammered this from other talks: rethink your processes before sprinkling it with AI pixie dust. Think about one of our processes where, if we're taking on a new customer, we can be given a spreadsheet of a thousand products that we need to match to say, do we have them? That process could take weeks for us. We managed to bring that down to days, if not minutes in some circumstances, but half of that work just came from process reengineering: do we understand the urgency? Do we understand the fidelity of that data? Then dropping some AI into a few areas. Reimagine first. Rethink your processes.

I won't drain this. Maybe this is a takeaway: what does the pit of AI success look like for you? This is one we're all working towards, but I would call out a couple of things. One, clarity on your processes. Are they observable? Do you understand what good looks like? What are the metrics of success? Are they interruptible? Can you drop AI into various places? Obviously have the right governance and guardrails, and then where can you provide high-leverage assets?

Did I mention something about parenting, saying being repeating the same thing over and over again? I can't remember. Sometimes I miss that one. If any of you are parents, you know that doesn't actually work. Your kids don't do what you say. They watch what you do and they copy your behaviors. They mimic you.

My final thought for all of you as leaders: how do you model the behaviors you want in your culture, in your company? For example, how did you as a leader model the get-it-done MacGyver behavior and attitude while still exuding the calm and order of Marie Kondo?

Thank you.