Host Intro (Gene Kim)

So in 2017, I started hearing about the amazing technology work being done at Home Depot, the giant retailer which at the time had revenue of about $100 billion, employing hundreds of thousands of people with over 5,000 technologists.

But there was something very curious that caught my attention. Apparently the group that was blazing the trail in the elevation of product design and engineering practices wasn't the e-commerce group, which is often the case. Instead, it was the equipment rental group, which seemed like such a strange place for a revolution to begin.

So in 2020, I finally got to talk to Paul Gaffney, who was at the time their SVP of Information Technology from 2014 to 2017, and it was truly an eye-opening and mind-expanding conversation. And even that is probably a massive understatement.

It turns out that the amazing story of equipment rentals was just the smallest tip of a vast iceberg of the profundity and deep thinking behind how Paul leads technology organizations. There's so much to learn from how he has led technology functions at Staples, Office Depot, and then later Dick's Sporting Goods and Kohl's, especially how he models and interacts with his business counterparts, which routinely included the CFO and CEO.

So after retiring from Kohl's, he is currently in a period of quiet contemplation and reflection. Here is Paul.

Paul Gaffney

Thank you, Gene. Thanks, everyone. It is an honor to be closing out this morning. The title is "Human Complications and Complicated Humans in Digital Transformation," though I am here to give you some tools. The tools that I'm going to try to give you are tools that I have come to learn are effective, and they're all about people.

I think there's plenty of opportunity at this conference to talk about technology. I actually think there's a tendency among technology folks to gravitate toward technology. What I hope to share with you all is that I actually think what needs our attention more than technology are people.

Let's start with the goal: why are we all doing this? Over the past decade, I've had the privilege of serving some large organizations as they transformed their approach to using technology to improve their business. Along the way, I get questions all the time in town halls from technology folks: Are we doing Agile? Are we doing DevOps? Are we doing TDD?

I think people who know me know that I've repeated this so many times that I'm past the point where I'm sick of saying it. That's generally a good benchmark for when people might be starting to listen: none of those things are actually important. The goal of all of our businesses is to get better results. And hopefully the goal of all leaders is to make sure that the people they're serving are having fun while doing that.

So my answer to every specific question — are we doing this, should we embrace that, should we be on this cloud or this platform, should we have a single pipeline — always gets back to: is it going to deliver better results, and how do we know? And are you going to have some fun while doing it? I suspect most of you share this goal, but I wanted to start with this to make sure you all know that if this isn't your goal, you're not going to like this talk.

I do believe, and I have found, that raising products to a higher level of impact than projects is the most durably important theme in this journey to continuously delivering better results and having fun while doing it.

When I started talking about this at Home Depot in 2014, this was sort of a fringe thing. Nobody talked about this. There were sort of secret memos about this move from projects to product. You've probably noticed this is now a thing. Everybody's doing this now, and unfortunately, when something becomes a thing, it means all things to all people.

What I mean when I talk about moving from projects to products is really, as a technology leader or as a business leader, understanding what business your company is in and understanding an idealized software expression of that business.

We've had folks up here from Fidelity and Disney. I've got deep experience in retail. Each of those businesses are a little bit different. Fidelity: one of those fundamental things is place a trade. Disney: one of those fundamental things is ship content. Retail: one of those fundamental things is look up a price, make an inventory promise. That software expression of the business that you're in — that's what I mean by products.

If you could have a map or a list, you could sit down with the CEO and say, "Hey, this is what this company does. These are the 20, 30, or 40 things that this company does." The precise way to approach this is in the work of domain-driven design, but that's a little bit esoteric. This is quite basic: what does this company do?

That's what I mean when I talk about shifting from projects to products: shifting to this fundamental software expression of the business that you're in, and then organizing your technology around that fundamental software expression.

The problem is that's not the way any of our companies grew up. If you happen to be working in a company that started with a software expression of the business the company is in, you are one of the luckiest people on the planet. Most of us grew up in companies where our systems are a product of the annual project exercise.

Anyone still conduct the annual project pageant? It's the exercise where people have lots of PowerPoints about why their idea should get some budget and why their project should be launched. People compete for whose pitch is the best. You only have to do that for two or three years and you end up in disaster, and most companies have been doing it for 30, 40, 50 years.

The systems in most of our companies are the cumulative consequences of the winners of the annual project pageant. How many people ever saw someone win the project pageant where they said, "Hey, I'm going to clean up some of the past mistakes"? There's not even a winner category for that in the project pageant.

So you have to change that whole method. I'm not going to get into all of those things today. You do have to change the funding model. You do have to change the way you organize people. Those are all important. What I'm going to get into is what you're likely to encounter along the way.

What I've seen about all of this is there are lots of specific techniques, but all of the issues are really people.

I've had the privilege over the past 20 years to meet tens of thousands of people, and I've in fact met two people. There are two kinds of people: those who divide the world into two kinds of people, and the other kinds of people.

This is going to be a bit of a caricature. It's a caricature for a reason. I have met essentially two people. They exist on a continuum. These are not real people — Chris and Dana, I promise I will never out you. They're composites, rooted in folks I've met along the way.

At one end of the continuum is Dana. Dana is a serial winner of the project pageant. Dana has deep expertise. Dana believes they know things. And if only the rest of the organization would do more of what Dana knows the organization should do, the organization would be more successful.

Chris exists at the other end of the continuum. You sometimes meet the real people in crisis. I first met Chris in a war room. Serious problem going on. Dana was in the war room as well. Chris's attitude in the war room was, "Hmm, what might I have done to cause this problem?" I knew Chris well; the likelihood that Chris had done anything to cause this problem was zero.

But Chris's attitude, and the attitude at this end of the continuum that I want to give you tools to help shift more people toward, is: how can I be helpful here? Dana is in the war room trying to figure out who we're going to blame for this problem. Dana is creating a culture of fear of disclosure. It's only Chris's conviction about Chris's own sense of self that compels Chris to overcome the fear of being ridiculed by Dana to share what has been going on.

A lot goes on at the ends of this continuum. I have a great degree of sympathy for Luke; I'm so happy I'm not dealing with the inventory problem in American retail right now, because there are a lot of Danas who believe they know. The reality is no one can explain American consumer behavior right now, and Chris is much more effective at dealing with these situations.

Dana loves to plan and execute the plan. Chris recognizes that we live in a world of increasing entropy, and we have to condition ourselves to sense and respond and not care about executing our plans, even if that puts our personal bonus goals at risk.

I'm going to try to give you five tools for dealing with these two people, though really this exists on a continuum. I think these tools are a complete toolkit, but I'm not certain. I think all five are required, and I encourage each of you to think about where your own capabilities are on these. I'll go through them in increasing order of difficulty of implementation. I think they're all equally effective.

The easiest of the five is honesty. The reason it's easy: it's the only one of the five where you don't need anybody else to cooperate with you. You can be honest all by yourself. I'm not just talking about being truthful. I'm talking about knowing the truth and being able to share it with folks who matter.

When I got to Home Depot in 2014, I thought we had a technology challenge: that we were going to have to teach people how to be better software developers and learn modern skills. No, we actually had all of those things. We just had a bunch of stuff in the way, and one of the things in the way was the result of decades and decades of the project pageant.

Back to that simple software expression of the business. You can probably all do a first draft product list for a retailer, because everybody in here shops. You know what you expect from a retailer, and when you don't get it, it's because you've encountered a system built for the retailer's org chart, not for what you wanted from the retailer. Simple things like: look up a price, tell me how much inventory is on hand, let me reserve some of that inventory.

I discovered quite quickly that we had over 20 different ways to look up a price, and over 40 different ways to look up inventory. Not the result of people being bad people — just the inevitable result of the project mindset.

It turns out I also quickly learned that the CFO and CEO didn't know this. They would have known if we had built cockamamie stores. They would have known if they could walk into a store and see seven different implementations of the paint department. They would not have allowed that. But they didn't know that we had over 20 ways to look up a price. Had they seen that, they wouldn't allow that.

I had to be the voice of honesty to them. Technology organizations feel like they need to protect the rest of the company from the problems inherent in the legacy software architecture. Stop doing that. Tell the truth. It will set you free. It will help your CEO and CFO understand why certain things the company is trying to do are difficult.

I had the luxury of being an active participant in the Home Depot strategy process from 2014-2015 through 2017. One critical element of the strategy was to win with the contractor. Home Depot is an everyday low price retailer: the price on the shelf is the price, and you are conditioned to believe you don't have to wait for a sale, the same way Walmart practices business.

Now we're stuck with this conundrum: we've got to offer different pricing to contractors and not pollute the everyday-low-price value proposition. The intervention required was bulk pricing. When contractors want and need to buy things in substantially larger quantities than a consumer would, can we give them a deal? If you've been following the plot and you know we have more than 20 ways to look up a price, you can imagine the complexity of trying to layer bulk pricing into all of those 20 things. That was honesty the CEO and CFO could understand when I was asking them to help put an end to the project way of doing things.

You can do it all by yourself. You have to understand your business, though, so that you can bridge the gap between the way things are and what they need to be.

The second tool is alignment. This word is used a lot; I'm going to use it in a very precise way. This is the answer to the question: why are we working together? What are we working on?

My best story of this is a fellow named Demetrius Walk, who goes by D. At the time I met D, he had a super important job at Home Depot. Home Depot has been reliably regarded as a company that grows sales and grows profits faster than sales. That's a magical recipe for value creation in any business. D had a critical role in making that happen. He ran the part of the stores that asked: how do we make sure the customer experience on the floor of the stores is maintained well, but spend less time and money doing that?

D was a master of the project pageant. He lived at Dana's end of the spectrum, but I could sense he had potential. D would start each year with a list of things he needed from technology so he could deliver his results. It quickly became apparent we were at the point of diminishing returns on those things.

We managed to get D to take the technology organization and have them live with his team in the stores. All of a sudden we got interesting feedback: D was not actually attached to his list. He just thought that was the way. Very quickly, through discussions about why we are here, the framing changed. We aren't here to build this list. We're here to take hours out of the tasks of bay maintenance.

Once D shared that different framing with this entire team with many different capabilities, lots of interesting ideas came up, and D and that very important part of the business at Home Depot got two, three, four, five times more productive. The folks in the stores, the 500,000 people who had to do these things every day, finally felt like they had a voice in tools that would actually help them have fun while taking hours out.

The third tool is to have clear standards and processes. In moving from projects to products, you're often displacing substantive decision rights, and in particular you're very threatening to Dana. Dana knows, Dana decides, everybody else does. When moving from projects to products, you're taking those decision rights away from Dana. If you're doing this right, you're largely giving those decision rights to the real customer — the one who actually pays the company money. None of this internal customer crap; we'll talk about that another time.

Your biggest friend is clear standards and processes around how those decisions that Dana used to believe they got to make are now going to be made differently.

The best example I have is Norb Savage, who unfortunately died young and is no longer with us. Norb was a spectacular product manager. The team at Dick's Sporting Goods now gives out an annual memorial award, the Norb Savage Award, for the team that has done the best job truly understanding an end-customer need and finding the way to solve that need.

The Dana crowd at Dick's Sporting Goods was absolutely certain about what new tools needed to be in the hands of Dick's store associates. Some of us weren't so certain, Norb in particular. What Norb did was lay out: here's how we're going to go about this. He did it in strong partnership with the team running the stores. We're actually going to spend time in stores and test every single one of these ideas.

Norb brought great clarity. He invented a fantastic approach to outcome-based roadmaps where everything anyone thought should be done gets on that roadmap, but it gets color-coded. One color code means this just came to someone in a dream or they read it in a magazine and have absolutely no validation. Norb was kinder about describing that. The colors you wanted to get to meant: yes, this is an intervention where we've actually done some scientific experimentation; there's some evidence.

Norb did a masterful job of helping folks shift from the "I know" world to the Chris world of "we don't know." We have a lot of experience, but we don't know, and we have to engage in practices that help us actually know what's going on. These clear standards and processes — this is how we validate or invalidate ideas, this is how we sequence things — lead to the next tool.

The next tool is very simple. We're all essentially in the software business, so I encourage all of you to figure out how much time you are actually interacting with software. PowerPoint is not software. Keynote is not software. The annual project pageant is not software. How you feel about things is not software. Software is something actually running in production.

My best story on this one comes from Dick's Sporting Goods as well. There are a lot of software vendors who show up with PowerPoint and marketing materials. This is getting better, but in most of my life most software salespeople don't actually want you to see the real software until you buy it. There are reasons for that; mostly that it doesn't ever work.

We had a search vendor who promised the moon about improvements in search results. We also had an internal search team that was very much over on the Chris end of the spectrum: they believed they didn't know, but they had built great processes for knowing. The human tool here is to try to stop the discussions that are based on anything other than software.

I got a sense we were wasting a tremendous amount of time arguing theoretically about whose approach to search was going to be better. I was willing to just have the two have a competition. The competition had to be based on software and objectively measurable results. No one should care who wins, because the winner is going to be the one that delivers better results. Chris was already there. The search team said, that's fine; if we lose to this vendor, that's fine, because we're here to deliver better results for the company.

The last piece is in order of degree of difficulty. This is not easy. There's a lot of inertia on the project end of the spectrum. There is a lot of inertia in people who have climbed the corporate ladder, experienced being told what to do, and now believe they've obtained the position where they're supposed to be able to tell other people what to do.

Dana and Chris are also acronyms for the dominator end of the spectrum and the collaborator end of the spectrum. True progress comes from moving people to an environment that is more purely collaborative and less hierarchical. But as you do that, you're fighting a tendency toward hierarchy observed for thousands of years. Aristotle writes about this. We live in a society that tends toward hierarchy and doesn't naturally foster collaboration.

You as leaders must find a way to be graceful and to persevere in the face of this. I have little index cards with this written on it. I tend to bring them with me whenever the stakes are high.

One of the highest-stakes situations I found myself in was at Home Depot. The team running the stores, which had become very complicated, decided we needed to implement a warehouse management system to run those stores. The stakes were high because I knew this would be a natural disaster of epic proportions.

Using all of the other tools I've described, we found a way to get that team to pay attention to what we were really trying to accomplish. The TL;DR is that at the Dana end of the spectrum was the plan to implement a multi-hundred-million-dollar warehouse management system to run every single Home Depot store. At the other end of the spectrum was a printed eight-and-a-half-by-eleven sheet of paper, which is exactly what the half-million people who work on the floor of Home Depot every day actually needed as the first intervention. This one ended up costing about $60,000, and I could take you into a Home Depot now and show you that, and the folks on the floor could tell you how it's making a difference for them.

I believe the only reason we made that happen is that we had created an organization that had practiced all of these tools and was getting better at talking to people about what we should be working on, and not getting caught up in the trap of, well, someone else has decided what we work on, so I'm going to spend all of my energy on how we do things.

Gene asked me to share what I'm looking for. I have observed, as I hopefully have successfully shared with you over the last 25 minutes, that this is a real struggle in our community. We are drawn into discussions of the how — pipelines, platforms, techniques, and tools — because when we bump up against the what problem are we really solving, and how do we know that is what we should be working on, we run into problems that aren't solvable with technology.

We run into problems that are challenges of leadership, human interaction, and understanding how our company makes money, and how our approach to software helps or hurts that money-making proposition. What I'm looking for help on is I'd love to hear your stories of how you've bumped up against this, what the results have been, whether you found a way to break through, or whether you got so disturbed by that interaction that you had to go back to working on pipelines.

I want to know these things because I've seen a lot, but I don't think I've seen everything. There may be some things I've seen that can help you and help this community move to this next frontier.

I do believe this is the most important move for the technology community: to move beyond leading technology and to move to being a trusted voice at the table about how technology can actually deliver better results for the firm and make sure everyone's having fun along the way. I will be hosting a Q&A later today, so if you have some stuff to share on that topic, I would look forward to seeing you. Thanks very much.