Digital Transformation

Pete Anderson, Courtney Kissler, Adam Furtado at UXDX USA. Video: https://www.youtube.com/watch?v=4xHfn6fk8Oo

Readable transcript: edited from the recording's captions for readability (fillers and false starts removed, punctuation and section headings added). Wording is the speaker's own. Timestamps are positions in the video. Names marked [?] could not be verified against the audio.

Why do a digital transformation at all

[00:00:00] Rory: There's been a lot of talk today about changing practices, about shifting from projects to product teams, more continuous delivery, more of that agile, before agile became almost a dirty word. What I want to talk about today is the big efforts that companies are going through where they're talking about their digital transformations. But I want to do it differently to what a lot of companies do. They'll say, "Let's do digital transformation because we want to be agile, and we want to be like Spotify and Google," and those kinds of things. My opinion is you should never start from the technology. So my first question to our group is: why do we need to do a digital transformation? What's the business value in doing a digital transformation? I'll start with Courtney.

[00:00:50] Courtney: All right, thanks, Rory, I'm super excited to be here. I think that most organizations are trying to stay relevant, and the industry that I'm in, retail, is one of the ones that is always being disrupted. It's how do you maintain enough of your agility and ability to respond and react to what your customers are needing and wanting, having that ability to operate with the right speed, and really set up your culture. That's the other thing: it is not about technology. It is about the culture and the ways of working, and how you're thinking about delivering against what you need to remain competitive in this market, because customers have a lot of choices, and if you can't get that right, I think the rest of it falls apart.

[00:01:58] Rory: Great, so it's about the adaptability and reactivity. Pete, do you have anything to add on that? What's the business value of doing this?

[00:02:06] Pete: Yeah, absolutely. I could echo some of Courtney's comments from the retail side. During my time at Target, that was definitely the story that we were telling. Since then I've had experience in banking, in a fitness organization and in a government organization actually, and a lot of them are pretty similar in that they're responding to shifts in market needs, so they need to be able to get to market more quickly. You need to be able to pivot more quickly to respond to future needs. There is a tech component to this: if you've got antiquated tech that is filled with debt, ultimately you've got to be able to help modernize the stack in order to enable some of those things that we're pursuing.

[00:02:57] And then, to Courtney's point, just avoiding further disruption. I think everybody that's established, that was comfortable, hopefully is uncomfortable by now and expecting to be disrupted. So how do you disrupt yourself before somebody else can do it to you? And then ultimately, one big thing that stood out to me while we were at Target was the fact that if we're trying to create a differentiated experience, we want to own it ourselves, and it's a product. The digital transformation that goes with product is getting yourself to a spot where, if it's a commodity, great, we can partner with somebody to do it, but if it's something that's differentiated in the marketplace, we want to have our own code, we want to have our own experience, we want to own that and be able to push it forward so that nobody else can do it.

[00:03:48] I always joke around with folks that are, quote unquote, product owners for vendor applications, saying, "You're helping them develop their roadmap for your competitors too." If you don't own it yourself, you're not so much a product owner. Those are the things that stood out to me.

[00:04:06] Rory: Great. It's a good example of looking at that survivability and the uniqueness of what you're bringing. Adam, looking at it from the US Air Force point of view, do you have that same need to prove the value? When you were trying to do your transformation, how did you sell that internally?

Preparing for inevitable wrongness at the Air Force

[00:04:34] Adam: It's interesting. From an Air Force or a Department of Defense perspective, we're not building a product to sell, necessarily, but the concepts are the same. I like to think of it as: I want to make sure my organization is as prepared as possible for our inevitable wrongness. If you think about digital transformation from an Air Force perspective, we want to make sure we're prepared to win a war with Russia or China, which sounds kind of weighty to talk about. If we put the weight of that aside for a second and think of it as strictly a product problem, we're preparing for a scenario that's never happened before. We don't know what it will look like, we can't really predict it, we have no experience with it. So we know we're going to be wrong with whatever we build to solve this problem.

[00:05:17] How do we ensure that our organization is prepared for that inevitability and has the ability to sense and respond to whatever change happens, on the battlefield in our case? It's all about continuous delivery, and do we have product and design professionals that can identify where things go wrong and how to respond to that in the right way to get closer and closer to right? That's a normal problem everywhere for all of our product organizations, just a slightly different lens within the DoD.

[00:05:47] As far as selling it, that's what we sell: we can't afford not to work in this way, because everybody agrees on the problem now. We're at a place in the DoD and the government where everybody understands that the government's in a tough spot. It's actually pretty interesting when you think about the term "good enough for government work." We've always thought about that in a sarcastic way, but really it came from World War II. Our factories were churning out things for World War II, and we had exactness and preciseness in building those things, and over time that just got cynical, because the government just became more and more bureaucratic and hard to maneuver. So I think everybody aligns and understands the problem that we're in now. When we sell digital transformation, it's about how do we change systems of work to be able to maneuver with the inevitable pace of change that's coming, so we can be prepared for that day we hope never comes in reality.

Avoiding the zealot trap: user champions and outside voices

[00:06:40] Rory: Great example. Just as you were talking there, there was a point from Teresa's talk earlier in the day. She was like, "Don't be that advocate, don't be that religious zealot who's like, 'We have to do this, it's going to improve everything, and there's the one true path.'" How did you avoid being a zealot, but actually convince your management to start down this path and do something here?

[00:07:07] Adam: This is why you're a great moderator. I screwed this one up; we talked about this before. When that happened, I did become that kind of evangelist to a degree, and it became a problem over time. When I would go talk to stakeholders about our need to move to a more agile mindset and all these product things that we're all talking about here, it got to a point where I became like Charlie Brown's teacher. I'd walk into a room and these stakeholders were just like, "Okay, here comes Adam's 10 minutes of agile talk. We'll just space out for a bit and get back to business afterwards."

[00:07:41] I struggled with connecting and meeting stakeholders where they are, and I learned that over time by being not as effective as I would like to be. But one of the ways that I tried to solve it is by finding user champions to do that work for me. How can I get somebody who's actually understanding and receiving the value that we're creating to go tell our story about why this is a better way of working? That way our stakeholders are getting it from them, rather than me selling my own work with my own inherent biases and incentives and things like that. So I got somebody else to do my dirty work, I guess, is the answer to that one.

[00:08:18] Rory: Lovely. Courtney, a similar question to you. You were mentioning adaptability and reactivity. They can seem a bit hand-wavy, and I don't mean that dismissively, but how do you get past "this is a super important thing" to the nitty-gritty of getting buy-in to start making change?

[00:08:43] Courtney: I think it starts with starting small: finding someone that you can connect with who will get in it with you. I had a business partner at one point during the transformation I was going through at Nordstrom who was willing to roll up her sleeves and get in it with me, and really try to figure out what it was going to look like for us to operate differently and achieve better outcomes. A lot of us who have been in this mindset for a while know that it's better, either because we've been through it personally or we've seen others go through it. We know it's a better way of working, but getting others to see it is hard. So finding someone, and I love Adam's example: you've got to find someone who can then also be a voice, so it's not just you.

[00:09:43] I've also connected others with peers in the industry that have gone through it. For example, funding models are hard in our world. Find a CFO at a company who's already made the mindset shift, and connect your CFO with that CFO. That way it's not me saying, "Our funding model's flawed and it needs to be different." It's someone else saying, "Oh, I've seen what it looks like to change our funding model, and it's better." So trying to figure out how to influence in a different way. And then once you start to get results, amplify those. Again, going back to what Adam said, allow the amplification of that to come from a different source, so that people see that it's not just us, as the change agents or the passionate ones, being the only voice saying that this is a better way to get better outcomes.

[00:10:46] Rory: I love that example, even going external, outside the company, to get that experience. That's a great example, thanks. Pete, do you have any insights on selling it and trying to get it off the ground?

North stars, product values and humility

[00:10:59] Pete: It's funny that Courtney talks about bringing people in from the outside world, because at Target that was one of the things that we did. We had an annual conference that we stood up, and the only rule that I had for speakers to show up at Product DNA for Target was that they didn't work at Target. We wanted everybody's voice to be an external voice coming in. So it's a great tactic, I love it, and it increased engagement for us every single time we did it. You could see that it would literally increase the energy of the product organization for at least a quarter before it started to fade again, or at least go back to "good God, I'm busy." So I reinforce that one.

[00:11:34] The other thing that I'm trying to do from company to company is really looking at the unique north star for each organization. For the Department of Human Services, it's all about how do we become better stewards of taxpayer dollars and get more services to the human beings and the citizens of Minnesota, in order to support their actual needs. That's an exciting thing to go after. It doesn't say anything about agility or product. It's, "This is what we're trying to accomplish," and then we're going to use some different ways of experimentation to get there.

[00:12:10] Same thing with the fitness org. They had to go through all kinds of hoops during COVID to get incredibly innovative in a heartbeat, and it blew up the way that they were working before. For that particular situation, we're saying: how do we harness the innovation that we just came up with without having to inflict a bunch of tech debt on ourselves? How do we operationalize the mindset but make the operating patterns a little bit safer as we go forward?

[00:12:39] And then same thing with the bank. The bank's big vision from a digital perspective was saying, "The folks that are going to disrupt us enable our customers to do whatever they need to on their platforms." So our north star is basically: how do we get a DIY platform where our customers can do anything they can do in a branch, electronically and more easily than they could in a branch, and drive toward that? Ideally, if you're getting them aligned around those types of visions, you're not emphasizing the tactics all the time; you're trying to emphasize the destination that you're going after.

[00:13:16] The only last thing I would say is that I'd reinforce what Adam said earlier about humility, basically, is how I interpreted it: let's assume that we're wrong, and that it's inevitable that we're going to be wrong. We've used a series of product values, seven values with trust underneath them all. Passion, curiosity and empathy are the head and the heart values, and then bias toward action, kinship and focus are the delivery-centric values, and then humility is dead center, the core of all of it, to say: let's assume we're wrong, and then see how all of our processes would change if that was our underlying assumption. Would I fund things the same way? Would I interact with my partners the same way? Would I interact with my customers the same way, or maybe start interacting with them to see if I'm right?

[00:14:07] And underneath all of that is the trust layer: we can't do all those things above it if we're not willing to trust each other to do each other's jobs, or do our own jobs, basically. That's the end of my preach. I get going on the values and I can't stop.

Start small or big bang?

[00:14:22] Rory: No, it's a great point, and it actually touches on my next question. You've got the values, you've got your north star for your company, you've got your buy-in because you brought in a CFO from somewhere. But organizations are huge, so do you do everything at once? Are you going to be overwhelmed? Courtney, you mentioned at the start: start small. Can you elaborate on that? You've got the buy-in; how do you get the ball rolling?

[00:14:56] Courtney: In my experience, start small definitely matters. The boil-the-ocean or big bang approach I haven't seen be as successful. What I've tried is to take a couple of teams. One thing that I think is important when you're going through the transformation is that a lot of organizations assume that not every team needs it or can go through it. I'll give an example. When I picked two teams at Nordstrom, we picked our customer mobile team, because it was visible and important and we weren't delivering as fast as we wished we were. We also picked a mainframe team, because there were all these assumptions that our mainframe team would just forever be antiquated and legacy, which is not true. We applied the techniques around value stream mapping and product ownership and all those techniques to both of them, so that we could show that it was relevant regardless of what technology you were working in.

[00:16:08] And then leadership matters. I think we all know that that's true, but there was a readiness component. You needed the leaders who were in the hierarchy of the team to all be bought in, through actions and not just words. How are leaders engaging? Are they engaging in a way where they're really helping the teams, or are they making the decisions on the team's behalf? So making sure that we had the leadership engagement, but also had the right structure in place so that teams felt supported and not micromanaged.

[00:16:44] I tell this story about gemba. I believe in gemba: go and see, be close to the work. I had some of my peers say, "Well, that's micromanagement," and I said, "No, it's go and see, not go and tell. You're not there to tell the team what to do. You're there to problem solve, and you're there to show up and be someone supportive that they can use to unblock things." So I think starting small, having leaders be ready, having leaders engaged in the right way, and really showing that you're there to be supportive is what I've seen work.

[00:17:26] Rory: And I'm going to go for a bit of controversy here, because I actually know, Pete, that you have a different view. Do you want to share your view?

[00:17:36] Pete: It's one of those things where I don't even know if the differing view is just a different experience. I've had the luxury of being involved with a few of these, as has Courtney, but a couple of them were done to us and a couple of them I was helping do, so it's really interesting to look back. At Target, as much as it extended over a multi-year period, it was for the most part a big bang. One day a bunch of project managers turned into scrum masters, after some preparation, and the BAs, I can't even talk the old language anymore, the BAs turned into POs. And magically we had a slew of scrum teams across this entirely large product taxonomy, with the exception maybe of security and infrastructure in the first wave. It was massive, and we had layoffs in the operational spaces that sat between technology and business every three months for three years, until we got down to 35% fewer human beings in the organization.

[00:18:42] For the most part that was a big freaking bang, and it's hard to argue with the outcomes that they've accomplished over time. We had 35% fewer people and double the productivity from an output perspective. From an outcomes perspective, you had increased stability, a much better ratio of contractor to employee in the development teams, so that you started to own your own code and have an engineering culture, and, oh by the way, the stock quadrupled over a four-year period. So it's tough to argue with that. I can tell you, as a human being that went through it, it was not easy to go through, it was painful, and there were a lot of people that were impacted by that along the way.

[00:19:26] Then you've got the flip side. Right now I'm going through one with the Department of Human Services, as I was talking about earlier, and my only goal for that initial pilot, to start landing some of these concepts, is full-stack exposure, from business leader down to business individual contributor, and technical leader down to technical individual contributor. There's no way in the world that DHS could magically do what Target did at scale. So I see benefits and risks in both approaches.

[00:19:55] In order to do what Target did, and this reinforces what Courtney said around leadership, they had a CIO that was willing to say, "There are 800 priorities. Guess what, now there are 80. There are 820 [?] of these that have to be on the sideline for now." That takes a whole kind of leadership to land that message and actually have it stick and not get shot along the way. The CEO fully supported them as well, and without that leadership there's no way they could have made the progress that they made. I'll stop there for now; I could probably talk about three other places too. I honestly think that there are pros and cons to both approaches, and the big takeaway for me is that it's context specific. There's no textbook. If there was a textbook for how to do this, you wouldn't have this panel discussion. You've got to be aware of the environment within which you're working in order to figure out how best to drive it forward.

Kessel Run and the frozen middle

[00:20:53] Rory: Right. Adam, you can play tiebreaker. How did you approach this?

[00:20:58] Adam: Definitely small and grew, from our perspective, mostly out of necessity though. It's rare, in my experience at least, that you're handed a big bucket of cash to go do a big bang transformation. We had to experiment a bit. We'd do something in the shadows and not tell people, and then just celebrate it when it was successful and let people take credit for it, and do some social engineering. So I think it was a little bit more piecemeal and grow, using mitosis to our advantage: once people were able to feel this different way of working, they'd share it with others.

[00:21:38] But the leadership conversation really resonates with me here. I actually think, at least in our experience, for the people on teams, this way of working is just obviously better. It's more exciting and engaging and fun, and you get more out of it. We have people on our team who worked for major defense primes in the US, who had been working on projects for years and years that had never been to production before. They didn't know what it was like for things they worked on to actually be utilized by somebody. Now all of a sudden we're continuously delivering multiple times a day. That's exciting. Your work matters more.

[00:22:06] The place that we've struggled is that initial first-tier product leader, in creating that. What we have are project managers who have spent an entire career being promoted and taught how to do things like track cost, schedule and performance from a procurement perspective, or go get their PMP. I think leaders sometimes overcomplicate their roles. The idea that this complex system can fit in your head and on your chart is irrelevant. This project is not for you to understand as one person yourself. Your entire job is to resource and support your team so they can sense and respond to change. I think we overcomplicate it, and I think it's really hard for people who have lived in a project mindset to all of a sudden switch and be like, "Oh, I'm not as important anymore. My job is just to make these people more effective, and that's it," and people may not even notice that. So incentives get broken and all of that. I think that has been the hardest part for us: navigating how to get people to go against their best interests, against what's gotten them to where they are in their careers now, to fundamentally switch. It is just painful for folks.

[00:23:19] Rory: That's a great point, Adam. I've heard it called the frozen middle. It's the head of dev or head of design or whatever, and they're used to having their team, and they can tell the team what to do, and they allocate their team out, and that's their power structure and that's how they work. Now they're being told, as you were saying, that it's more that you're leading, you're showing by example, you're giving strategy. How did you personally deal with that friction in the Air Force?

[00:23:53] Adam: We just didn't use that model. When we started Kessel Run, we had the unique ability to start over, even from a business model perspective, which not everybody always has the ability to do. We were lucky in that sense. We went directly into cross-functional teams, and even had balanced leadership teams that were all working together, including the acquisition or procurement side of the house, with the business and product and engineering. So we forced it to happen, and we had the right people in the right places to do that.

[00:24:26] But we didn't solve the rest of the organization. Imagine a 1,500-person organization; Kessel Run at that time was 40 of them, working in a new way and being successful. The large majority of the organization, and from a fractal perspective the DoD is the largest employer in the world, the large majority of them are still working in those functional silos, and it's really hard to break that. To be honest, we haven't had that much success, even yet, in taking what we've done at Kessel Run and in other places, in these small innovative projects, and scaling it across the deep systems of the government.

[00:25:04] In a lot of ways I think we're in this period where people are happy about these kinds of projects happening, and they like to think we're innovative, but they're treating these projects as over here at the kids' table: "Oh, you guys go do your cute stuff over there and be innovative, but the real work's going to happen over here at the adult table." So we've really had a hard time transitioning that success into large, deep system change.

[00:25:22] Rory: Great. And Courtney, have you managed that kind of deep system change?

[00:25:38] Courtney: Yeah, sorry, I have construction going on at my house, so I'm feeling really bad. I feel like it's loud, and I hope it's not, so I'm trying to stay on mute anytime I'm not the person talking. Apologies. Okay, well, good. So yes. I think it's just, again, this ongoing challenge and opportunity to continue to gain alignment. How do you really bring together the teams and try to lead by example in how you're showing up as a leader, and really drive those behaviors, and be open to just learning along the way and continuing to evolve as you go through this? Sorry, now my dog is whining. Or my baby was crying in the background earlier.

[00:26:46] Rory: Pete, you've seen it from multiple different angles. Is this a common thread?

[00:26:52] Pete: Absolutely, absolutely. This is one of the things that I'm really, really passionate about right now, actually, and I'm trying to figure out some ways to almost productize how you tackle that middle layer of the organization. What I've observed, basically, is that you get the senior leaders that buy into, quote unquote, transformation, because it's, "Hey, I need faster to market and I need less cost, and that all sounds good. I want that, so go do that for us." And then, to Adam's point earlier, we get the teams trained up, and they're like, "Yes, I know this project stuff has been painful for years. You're my savior, I love doing this, let's go do the work."

[00:27:33] Meanwhile, nobody has really invested in the middle layer to the degree that we invest in the individual contributors at the team level. I don't see that same investment at the middle layer when it comes to coaching people from managing to leading, and from directing to providing a vision, and those types of things. To me, that's part of the reason that I'm so passionate about those values that I shared earlier, because I truly believe that we can take each of those values and translate them into behaviors for each layer in the organization and for each function in the organization.

[00:28:08] In order for us to be under a product mindset, what does that mean for our senior leaders? What does that mean for those middle managers and how they show up for folks? What does it mean for the folks on the ground? And then also, what does it mean for the supporting functions around risk and finance and all these other shared services, so to speak, that are operationally focused? They have to show up and behave differently as well. So I'm trying to get it to a spot where the values aren't just the plaque on the wall. The values are things that drive behaviors, and then we believe that the behaviors are going to drive change.

[00:28:40] If you can internalize that and equip that layer of the organization with, "Hey, success is different now, but holy crap, it's more fun. You can actually develop people and see them grow in front of you, and be able to establish a destination and then get stuff out of the way." When I think about the systemic problems, that layer is the layer that should be changing these enterprise processes that are conflicting with the mindset that you're standing up on the individual product teams. For me, that's one of my favorite gigs. If you can change one thing and then have a trickle-down of 80 teams celebrating the fact that you just changed that, you get to be the hero, man. You didn't have to direct anybody to do it, you didn't have to do anything else; you were just helping people. It's a pretty basic concept.

Accountability without RACI charts

[00:29:35] Rory: It sounds lovely, and I'm going to play devil's advocate here. The pushback that I get is, "We can't adopt that," and it's from those kinds of people, because what they're saying is, "If we do this, it's going to become chaos." They're invested in maintaining the status quo, because they've obviously done well in the status quo to get to where they are. How do we tackle that problem where they say, "Look, if I suddenly let go of control and I give it all to the team, who's accountable? Who's going to make sure?" In the old world we've got RACIs, and it's, "This person's accountable, I'm going to solve this." In this new world, I've had the feedback from somebody: "Okay, I'll let go of everything and just watch it all go to pot."

[00:30:21] Pete: My argument there has always been that, number one, you're living in a fantasy world if you think the current world actually has accountability built in, because the siloed model was created so that people can go, "Well, it's not my fault, it's their fault. The design was bad, the developers didn't do it right, this didn't do it right, that didn't do it right." To me it's actually one of my favorite exercises, because I'm a recovering program manager and project manager at VA [?]. Once you're there, you're always there to a degree.

[00:30:53] I've basically gone through and done RACI exercises within an agile environment, and I think it's just hilarious. I do it on purpose, so that they can see how ridiculous it looks on paper. Yes, a product person is accountable for prioritizing the backlog, so great, he gets the A, or she gets the A. Who else is involved? Well, the Rs are all the way across the board. It's comical to me, when you look at a cross-functional team doing work together, that the whole concept of a single throat to choke is kind of an antiquated process.

[00:31:27] Accountability, yes, we can simplify it to say product owns the business viability, technology owns the architecture and where we're headed, and UX controls the experience. But in the old world, accountability for outcomes didn't really exist. The accountability was, "Did I complete the project plan, via triple constraints?" I'd much rather have accountability for the business impact of what I do, and that's a whole different cup of tea. I'm not sure if I answered it for you, but that's it.

[00:32:04] Rory: It's an interesting angle, and I like the business accountability, because that's one where I've seen pushback as well. Courtney, from a technology perspective: are our teams ready to take business accountability if they don't really have ownership of releasing and all these things? Do we have to start with the technology first before we can start doing this cultural and team stuff?

Business and technology lines should be blurred

[00:32:27] Courtney: I think that these transformations are company transformations, and I think often there's a spotlight put on technology, like, "Oh, tech, just go figure it out," and "We don't need to worry about the business outcomes," or "The business teams don't really need to worry about the technology work required to get better outcomes." I truly believe that where the lines are blurred is where I've seen the most meaningful progress. Like Pete's example, the siloed approach in technology is really also business and tech, and there should not be this boundary. It's arbitrary.

[00:33:16] Now, I do believe it is critical to be clear about what outcomes you're trying to achieve, because then you can set guardrails, and that creates empowerment, and then it doesn't turn into chaos. And it is important to be clear on who's making decisions and how you make decisions, because I've also been in scenarios where, if you're not clear about those roles, people just spin. So being specific and clear, I think, is high value. But having the technology work that you're doing lined up to a business outcome is also energizing and exciting. We can connect the work we're doing to business outcomes, which hopefully people get excited about: "I'm doing work that's strategic, and I can see it show up," whether it's in your customer experiences or however you're thinking about it.

[00:34:21] But I have been in scenarios where I've started in tech, because the organization was not ready to talk about a company transformation. You can make progress. You can do automation of your deployment pipeline, you can improve your quality, you can do a bunch of things that are important and culturally invest, but it'll stall at some point if you don't have the business teams aligned on where you're going and the teams connected in a shared way around what outcomes they're trying to deliver.

Final advice: context, coaching, toolboxes and unlearning

[00:34:57] Rory: That's a great example, and I'm just conscious of time; I could keep chatting forever. I'll just leave on one of the things that you mentioned, Pete, the underinvestment. If you were giving some advice now to people, what would you invest in for your teams? How would you bring your teams along? What would be the thing that you would do? Adam, sorry, just some uplifting final bits of advice.

[00:35:19] Adam: I think maybe Pete said it earlier: context is important. Understanding the context of the business that you live within is incredibly important to decision making. You can't just pull frameworks off a shelf and become Spotify overnight. Those things don't work, and they're irrelevant in a lot of ways. You want to learn patterns but apply them to the context that you have. That's a good way to make your team feel empowered, to make them feel like their context is valuable in the decisions that you're making. So find ways to extract that from your teams and apply it to this new way of working. This shouldn't feel like a new project or framework that you just learned at an offsite last week, or at UXDX, and you're going to go apply it full scope. Figure out how to take what works, learn from your teams, and have it be a two-way conversation. I think that's a good takeaway.

[00:36:18] Rory: Great, thanks. And Pete, do you have any advice?

[00:36:24] Pete: A couple of things too. There have been a couple of patterns across the different efforts that I've been involved with that seem to be helpful. One of them is obviously just coaching in general. Each of the transformations that I've been involved with has had a team of coaches working together, and I emphasize team simply because I've seen centralized teams tackle change versus distributed, quote unquote, teams, where you basically have folks that have the same skills but they're all in different parts of the business, and they're not co-located together to support each other. It's a very different kind of momentum. This work is hard, and asking people to change is hard, so we also need to support the change agents within the organization and make sure that there are enough of them that they have their own community to be supported.

[00:37:12] And then the other thing: a product toolbox is one that I would highly recommend. I don't care what's in it, but some type of universality of language and a curated set of tools for people when they're first learning how to do these things. We created one that was called a playbook at Target, we had a toolbox at U.S. Bank, and we've got a toolkit at Kiock [?]. They all look at what are the types of activities that I do when I'm defining products, when I'm doing product discovery work, when I'm delivering a product and when I'm assessing the impact of what I'm doing, and then how do I scale up a little bit without having to go to a paid framework or whatever.

[00:37:53] Those have been really helpful just in getting people's heads wrapped around what's being asked of them. I've learned this through failure. When I first started, I still am an idealist, but I was a hyper idealist: "Hey, you used to have checklists, you don't have to have checklists anymore. You can just think for yourself, and you should be excited by that." Half of them said yes, and half of them said, "I think you're wrong." They basically said, "I need a checklist, darn it. Help me out on what the heck I'm supposed to do. I want to do it right." So the playbook to me is a happy medium. It's not governance; you're not required to use the tools, but they're curated for you. They are recommendations: if you're solving this type of problem, these are some things that you can leverage to try to tackle that problem, and if you know why you're using that, then you can go find something else as well.

[00:38:45] Rory: I've seen a lot of companies shift their project management office from telling you what to do to being supportive. A similar exercise: the PMO is a product, basically, where your customer is the team.

[00:38:58] Pete: That's an exciting one. When you start seeing PMOs start leading transformations, then you know something is changing in the world. That's a good thing.

[00:39:06] Rory: Right. And Courtney, we're well over time, but I'd love to hear your advice as well.

[00:39:09] Courtney: I agree with what's been said. I think that shift, call them centers of enablement or accelerators or whatever you want to call it, that shift in how we're getting the work done and the way that engagement happens. My other thing, and I learned this myself, is what I had to unlearn. I've been in the industry a long time, and there's a certain, I'll call it the playbook or toolbox, that I've collected over the years, and I've had to take some of that and unlearn it, because if I stay the course with that, I'm actually not demonstrating the new ways of working. That has been a huge unlock for me. And figuring out how to continue to be vulnerable and okay with "I don't have it all figured out," and how do I just set and lead with intent, and then be open to the ongoing learning that's required to keep the momentum and to keep my sanity.

[00:40:29] Rory: I love that example. Not enough people say "I don't know," and I think it's a superpower in some places.