Host Intro (Gene Kim)

Gene Kim: The team from Grainger. Last year, for those who were here, we heard Jason Yip give a fantastic talk about a company founded over a hundred years ago. Grainger has over $15 billion in revenue, and they started fulfilling their CEO strategy of technology-enabled market share growth. Jason talked about the unified target operating model, and he mentioned the mysterious KeepStock team who were doing amazing things.

This year, leaders from that team are presenting their work. Emily Rosengren is Senior Director of Product Engineering, and Lucas Hinz is VP and Group Product Manager. Together, among other things, they are responsible for KeepStock, the tens of thousands of onsite vending machines that enable organizations to keep materials available for use in hospitals, warehouses, and industrial facilities.

They will share how they overcame problems of vast and disconnected COTS systems, siloed teams, and sometimes a strange relationship between business and technology. What I love about their approach is how they chronicle their disciplined progression over six years and how they created value for everyone. Here are Emily and Lucas.

Lucas Hinz

Lucas Hinz: Hi, everyone. I am Lucas Hinz. I am Group Product Manager at Grainger. I report to the Chief Product Officer, and this is my partner, Emily Rosengren. She leads product engineering at Grainger and reports to the CTO, Johnny Leroy, who is giving a presentation tomorrow at 11. That is my shameless plug for some Grainger discussion.

To be clear, this presentation is not the AI-focused discussion. Eric Chapman and Philip Sears will deliver that one on Thursday, and I encourage you to attend that one.

If you would indulge me for a moment on behalf of our marketing leader, please give a little woo or an appropriate hand gesture if you have heard of Grainger. They will be very pleased with that response, so thank you for that.

For those who did not woo or raise a hand or give another gesture, Grainger provides products and services to the maintenance, repair, and operations market. We refer to it as MRO. The tagline for Grainger is "For the ones who get it done."

Oftentimes, the ones who are getting it done are not meant to be seen in an organization. They might be frontline healthcare workers. They might be on an assembly line in a production facility. More often than not, they are facility maintenance, maintenance managers, transportation managers, and safety managers. These people are not meant to be seen, because if they are seen, that means there is some kind of major problem going on. Grainger's role is to humbly serve these humble roles and make them successful so we can help keep their operations running and keep people safe while we are doing it.

Our customers are looking for two things. The first is a flawless experience finding and getting industrial products. I like to say that the thing that breaks today is not the thing that breaks tomorrow. A small ten-person machine shop might call Grainger and say they need drill bits, thread taps, machine screws, and thread locker, and we have to take care of that. The next day, they call back and need paint because they are going to re-stripe the parking lot. They also need supplies for their break room. The point is that the use cases, business needs, and business context are highly variable both within and across all the industries we serve, and we frankly serve all of them.

There is nothing whimsical about MRO. Our customers are not out there shopping. They are solving problems, and they look for partners like Grainger to help them do that.

The second thing customers look for increasingly is a partner that can help them spend less time on things that are not core to their business. They want to get better at what they do. That might look like providing services around safety or metalworking. It could mean helping them streamline procurement processes, because they do not just work with Grainger; they work with hundreds of other suppliers. Or it could take the shape of providing a service and the requisite labor to deliver that service so they do not have to do it.

That is exactly where KeepStock fits into the equation. KeepStock is Grainger's customer inventory management service. As I highlighted before, our customers are trying to solve problems. They do not want to spend time on the website, talk to salespeople, or be on the phone. Just like they do not want to waste time going after industrial products, they do not want to spend lots of time managing inventories of these products. That is precisely where we come in. We take a storeroom like this and make sense out of it. We help them navigate the complexity they have, offload that complexity from their operations, and make it our own so that we provide a compelling service.

KeepStock is material to the Grainger business in terms of revenue and what it runs through our supply chain, and it is growing at a healthy clip.

What will happen today is Emily and I will walk you through a five, maybe six-year journey we have been on with KeepStock to evolve the team supporting the technology in KeepStock from very reactive and project-oriented doers to fast-iterating strategic partners for our business.

To pull off a service like KeepStock, you need a pretty sizable field-based team. You have to cover every sort of square mile of the country. Our customers are all over the nation and frankly all over the world. But it also requires a tremendous amount of technology. We have vending machines, kiosks, scanning equipment, mobile apps, web apps, and more. You name it, it is part of the technology stack in a very complicated arrangement to pull this off at scale for our customers.

We will describe this journey through three distinct phases. We will share reflections through the product lens and the engineering lens, what we think made a difference, and the metrics that substantiate why we think the way we do.

In the beginning, we really were not organized as products. We were busy chasing competitors. We were slow to the race in terms of navigating this valuable service for our customers. Business partners would often identify a gap relative to the competitive set, specify which technology could help us shore up that gap, and throw it over to the technology group to bring into the technology space.

Do that enough times and you get dozens, if not scores, of off-the-shelf software stitched together. You have a technology team that is largely integrators and script writers, not necessarily strategic partners and thinkers. Besides interoperability challenges, the distance between our technology team members and the actual users of the systems was too far. That created real challenges as we navigated problems with our technology.

Emily Rosengren

Emily Rosengren: From an engineering perspective, things were pretty messy. As Lucas mentioned, we had a lot of different off-the-shelf systems, and the team wrote a lot of custom glue to make them work together. We had a pretty fragmented and complicated landscape. We had everything from Svelte and TypeScript to Perl and .NET and Java and everything else in the middle.

We were really lacking alignment on a technical vision. We did not know which way we were heading, so it was really hard to drive any improvement in what we were doing. We also had issues with stability of our systems. Our systems were regularly going down under the expected load, which is obviously not awesome. Our delivery was unpredictable. We had some great engineers and some good things were happening, but at the end of the day, the business thought we were slow.

At each step in our journey, we will talk about some of the metrics that we used to drive improvement. As we do this, you might notice that we are going back to front. If you think about where you might start with driving improvement in a delivery process, you might say, "I need to start at the beginning. I need to make sure my product ideas are really good and that they are solving the right problem."

While that is true, if you cannot actually deliver and keep your systems up, it does not matter how good your ideas are. So we actually did the opposite, and it might be a little bit unintuitive. We also found in this journey that driving the improvements we needed to make in the earlier stages of the process took really strong collaboration and trust from our business partners, and building better capabilities to deliver and support our systems gave us that trust to help work with them differently, which was really critical later on.

At the start of our journey, we focused on how we were delivering and how we were supporting our systems. From a support perspective, we had a lot of issues, and they were hard to resolve and pretty impactful. Lucas mentioned those thousands of field team members that support KeepStock. When our systems are down, they are at customer sites and they cannot place the orders they need to. That is not great. They pull out notebooks, write down what they need to order, and hopefully get it right later and try to do it properly. Or maybe they skip our systems entirely and go directly to SAP and try to place the order just to do what is right for the customer. None of this is great.

From a delivery perspective, we were also pretty inconsistent. We had some systems that we deployed a couple of times a month, but some systems were getting deployed only once or twice a year, and those were big events that generally did not go awesome.

To get better at this stage in our journey, we did three main things. First, we ran what Grainger calls the design group, where we brought together a cross-functional team from the business and technology to really look at KeepStock as a business and get aligned on what we needed to be doing and how technology should support it.

While that was happening, we looked at the engineering teams and shifted some of their ways of working with a focus on three key areas. First, we looked at incremental work breakdown. Second, we looked at how we were measuring delivery to get more consistent about how teams could think about driving continuous improvement without dictating a framework or methodology on them. Third, we introduced some XP engineering practices to help improve our pace and quality.

The last thing at this phase that I think was really critical was aligning on our technical vision. At this phase in our journey, it was pretty high level, but it was really enabled by the vision we came out of design group with. We all agreed that there was a particular off-the-shelf system pretty critical in the nexus of our technology that was not going to serve us well going forward. So we aligned on replacing it incrementally, and we started to strangle it out with any new piece of work that we did. This was really powerful for giving our teams a way to incrementally drive improvement and change with any new feature that we built.

Lucas Hinz

Lucas Hinz: You probably caught up on the weather theme here. We went from a lot of storms to, I like to think of the appreciative side of this, partly sunny as opposed to partly cloudy.

We have clear vision. We have an engineering prowess that is emerging that can make that vision a reality. We have, at this time, very clear metrics for how we are going to create value for customers and for the Grainger business.

One critical thing we needed to institute was regular roadmap review with our senior executives to ensure that all the way up to the CEO there was clarity about what we were tackling, in what sequence, and why.

The moment that, for me, in this phase of the journey was a crowning achievement was when our Grainger technology group partnered with our business partners to address an audience about this size. It was about half of the field-based team members, their managers, and supervisors. We co-presented a view of the vision, why we were going in that direction, and most importantly, how we were going to get there together.

Our business partner actually crafted a slide with a minimally viable experience at the center, and he was explaining to the field how we would go from where we are today to this grandiose vision very iteratively. That really stuck. It has proved incredibly important to have that buy-in from business partners, especially when there are thousands of people's lives and livelihoods on the line, to have that understanding and shared support.

Emily Rosengren

Emily Rosengren: From an engineering perspective, at this phase in our journey, we have all the teams aligned on engineering practices that help enable continuous delivery. We are doing them with different levels of skill across every team, but we are learning and getting better every day. Our teams are better organized for autonomous delivery, and we are able to go much faster.

But there are still some challenges. We start to notice that in a couple of teams and in some pockets, delivery metrics look good; they are breaking down work into small chunks, but their predictability about when they will deliver a particular feature is really pretty poor. Sometimes they are breaking down work into small chunks but losing track of what they are actually trying to deliver. So overall, we are still not as predictable and efficient as we would like to be.

You can see that in our metrics. We start to look further ahead in the process. We look at design and start looking at the time it takes to start a feature and actually get it in the hands of our users. We see that it is highly variable, and we also start looking at the rate of rework of our features and see that it tends to be pretty variable at this time as well.

But our delivery and support metrics look much better. We are now able to deploy to production. We are averaging about 30 deploys a week of a lot of different smaller systems. We have gotten much more predictable for each individual change that we are rolling out. Our life supporting our systems has gotten better too. Our systems are more stable. They are staying up more and they are faster to resolve issues when they do occur. But we obviously still have work to do.

Lucas Hinz

Lucas Hinz: I think we have competing clickers. I was going to do a quick countdown. I want you all to think of your favorite word that starts with the letter G. On the count of three, say it out loud. It does not have to be a shout. One, two, three: governance.

Kidding aside, we will talk about two elements of a lightweight governance framework that we put in place. We have nine teams running in KeepStock, building at a pretty breakneck pace. The mandate was that each of the nine teams needs to have a team-level roadmap. More importantly, that team-level roadmap needs to ladder up to the strategic roadmap that we are reviewing with senior stakeholders every two weeks. Not too novel, but very important.

Alongside that, with every major feature we mandated that each of the teams needed to decompose their work into detailed story maps. Those needed to align to the team-level roadmap, which in turn aligns to the high-level strategic roadmap. What this created was that for any piece of work anyone was working on in KeepStock, it laddered all the way up to the things our senior leaders cared about, aligned with the vision we were pursuing.

With good metrics in place, clear vision, roadmaps galore, story maps galore, good work decomposition, and engineering prowess, we started looking further upstream. The real step we took was helping our business partners, really teaching them how to participate fully in the software development lifecycle. The intent was to engage consistently and make sure our problem definition, work selection, and accountability were very clear.

There is nothing particularly novel about it. Anyone would recognize it maybe as a Kanban board. On the far left, you have problem definition. On the far right, work is done and we are looking backward and understanding what went well and what did not. In between are all the stages of decomposition.

The important thing is that it created visibility and accountability for our business partners. Every two weeks, just like we are reviewing roadmaps, we are looking at our work queues and understanding what is getting in the way. We also ensure that prioritization is aligned all the way up to the strategic roadmap. Again, it is not particularly novel in the sense of, "Hey, it is a Kanban board," but the clarity it has produced with our business partners and the improvements it has made to our work selection and problem definition are outstanding.

What that looks like today is that we measure every aspect of how we are delivering value. As you think about the Kanban board I just showed you, we measure every component of that. For the first time, we are in a place where we are measuring time to value from a problem statement that is maybe a little fuzzy and muddy to where we have reified a component of the vision. All of that is measured.

That matters because we want to hold ourselves accountable. We need to help operations partners plan thousands of people in the field, lots of people's lives, to adjust as we go. But the most important part is really about driving continuous improvement in our process, which we continue to do to this day.

Emily Rosengren

Emily Rosengren: From an engineering perspective, we are also focused on how we continue to improve and get better. Some things you see now on our team that you would not have seen five years ago are that we rotate engineers quite a lot across different teams, both to help us deliver and to stretch them for different development opportunities. We are also focused on looking at our production support process and how we use our issues to drive better decisions about how to build our software going forward.

If you look at our metrics overall, we are now looking across the whole software delivery process from way before things even get to technology. We now have metrics that show us everything from a business stakeholder saying an idea is important and they want to do it, to having it in production and being able to look at that together and talk about how we can improve and get better.

We obviously have to continue to focus on the things in the other parts of our process. We need to make sure that we still deliver, and we need to make sure that we still support. We need to keep looking at all of these things and drive improvement.

There are a lot of problems that still remain. We are much better than we were five years ago. We are delivering at a pace that I am not quite sure Grainger has seen before, which is super exciting, and it is fun to see that impact the business in tangible ways. But we definitely have challenges.

These are three that we would love to talk to folks about more if you are interested. One is maintaining alignment both within the technology group and with our business partners as our pace increases. Second, navigating competitive pressures. We have a clear strategy and are working toward it, but our competitors are not slowing down either, so we need to balance that as well.

Everything we have talked about today has really centered on working and prioritization within KeepStock, within one business unit. Going forward, we know our systems are going to need to interoperate more and more with other business units. We need to be able to prioritize across domains and work more effectively with them.

Thank you all for the time today. I am looking forward to learning from all of you throughout the next few days of the conference. Thank you.