Jill Mead

Hi, my name is Jill, and five years ago this was me. This was my mugshot. Despite what you are probably thinking, I promise you I was not in jail. I did not get booked for too many speeding tickets, nor was I arrested for road rage. But I was in an interesting situation. You could say I was in a bit of a jam. My customers had it out for me. They were extremely unhappy. The amount of stink eye I received was enormous.

I had one of the most disliked governance processes in a Fortune 50 technology organization. You might be wondering what this has to do with my presentation. Here is the thing: I was living proof that my governance process could easily align with the future of DevOps, product, and Agile. Later in this presentation, I will let you in on five proven factors that can be applied to any governance product transformation. Without these pieces in place, I believe we would not have been as successful as we were. If I have anything to do with it, you are going to go from this to this.

My name is Jill Mead, and I am an organizational change strategist and project-to-product coach. This is Stink Eye on Steroids, and I hope you enjoy it.

The best place to start is at the beginning. I worked for a Fortune 50 retailer for about seven years, and I was thankful to be part of every phase of its transformation to DevOps, product, and Agile. There were three phases I would consider part of this transformation. Pre-transformation is where a lot of grassroots pieces happen: changes are happening in various pockets of the organization, but true momentum or significant change has not necessarily started yet. The middle section is the transformation period. In our case, it was roughly two years long, and this is where a lot of change happened. Lastly, there is the post-transformation period, where changes are still happening, just smaller in nature and more iterative. The mile markers were critical points throughout that transformation that made it what it was.

A few challenges among many that organizations have, and that the Fortune 50 retailer I was at was not immune to, were lack of support from executive leadership, a project-minded organization, and frumpy processes and procedures. The project-minded organization was more focused on deadlines and tasks than on value delivered to the customer. My focus today is those frumpy processes and procedures.

Here is where the story heats up. There is a deep fundamental problem when your processes take longer than it takes to actually engineer the solution. A value stream starts with an idea and ends in customer hands. In many organizations, it takes one, two, or even three years to deliver value to the customer, and that is the first time the customer sees it. The actual engineering work is not very significant compared with all the extra stuff around it: lead times, approval gates, approvals, hopscotch activities, wild escapades, you name it. Our organization was plagued with a significant amount of process fatigue.

Traditional governance processes were bloated, lethargic, dictating, costly, strict, and manual. This is where the story gets interesting. I want to introduce you to the painful process campaign. This is where our organization recognized that all of these processes and procedures were impeding its ability to move in the direction of DevOps, product, and Agile. Something needed to be done about that. The campaign was introduced primarily for the technology organization, though I am sure it involved business in some aspects. The community of technologists voted for the most painful processes and procedures. The point was to provide visibility, awareness, and pressure to those teams to change.

The top five most painful processes were ITIL change management, technology access requests, hardware laptop procurement, security processes, and risk processes. One of those was mine. I believe this campaign was a pivotal point, particularly for governance teams. It was a mile marker that helped transform governance processes and teams.

What is worse than having a product in a Fortune 50 technology organization that everybody hates? Being the product owner of a product that everybody hates in a Fortune 50 technology organization. That was me five years ago. What they do not tell you about being a product owner of a product that everybody hates is just how interesting your life gets. Customers randomly walk out of your meetings a few minutes after they start. Flying chairs become a business-as-usual activity. It got to a point where I did not even flinch when I saw a chair come through the air. Engineering customers created an emoji for me. And then there was the stink eye. The stink eye plagued me not only during the day, but at night. I could not run away from my customers; they were everywhere I was when I was in the office, not to mention in my dreams.

How bad was my bad process? It was really bad. Per one change record, I required 75-plus data fields. There were 100-plus business rules built into the change tool end to end. There was a 14-day lead time to get into the Enterprise CAB. We spent $1.1 million per year on Enterprise CAB, and in a full year we counted only one change rejected by that board. There were 100-plus clicks end to end, zero APIs available for automation customers, a 200-hour average change duration, and two to four approvals on one change record.

As an honorable mention, the CAB rarely rejected a change, yet we required a meeting before the CAB meeting. Five of our team members were involved in manually checkboxing and making sure people were ready before the actual CAB meeting. Customers would create one change for many changes, and the window would be outrageously long. For example, they would create one change that was seven days long and have 30 changes embedded in it.

How did it get so bad? I call it death by a million Band-Aids. Processes usually start out pretty lean, kind of like dating. Then, over time, year by year, Band-Aids continually get added to that process. Every time something bad happens, a Band-Aid gets put on top of it: another lead time, another data field, another business rule. Before you know it, you have this big, fat, lethargic process. The activity of adding and never taking away debilitates your customers.

Here is a truth bomb: more manual process does not equal a reduction in risk. Data quality and process quality tank. The more you add to people's plate, the less quality you get. People find the path of least resistance; I call these cow paths. They find ways around it or ways to lessen the burden. Manual actions lead to lack of consistency and increased chance of errors and impact. The more manual work you do, the less consistent things get.

Modern processes in the digital age are simple, lean, empowering, flexible, automated, creative, experience-centric, decentralized, and embedded. Every sports season has a comeback story, and this was our wild card moment.

We started with our team mindset, so we no longer thought of ourselves as a governance team. The way you think of yourself often impacts your behaviors, and we wanted to change that. Our new mindset as a team was that we were customer-centric, enabling, empowering, empathetic, collaborative, and guiders.

We were extremely visible, involved, and transparent with our customers. To understand the customers, we became the customers. We took a sabbatical in the dojo for three months to truly understand our engineering customers. We got into their tools and tried to understand GitHub. Those things matter, and they build major credibility with customers.

We threw our current process out the door and started fresh. The past has ways of debilitating the future, and at that point we had so much process fat that we needed to focus on building the new. I am all for incremental improvement, but this was not the case. Our goal was to create a great customer experience for all customers: not just automation customers, but manual customers who use normal change and manual customers who use standard change.

Next, we identified the key people with the right attitude and ability to help drive the change. I cannot stress enough how important it is to understand and utilize your players' strengths. A lot of governance teams have people who were part of building the existing process or product. There is a lot of emotion there, and we have to be sensitive to that. It often leads to resistance. We had major internal organizational resistance. We approached it by understanding the individuals on the team and what they brought to the table. In some cases, we had influencers who could influence resistant individuals. In some cases, resistant individuals were not going to make it to where we needed to go, and tough decisions had to be made. You are not going to be able to hire a full new governance team with a totally new mindset, so you have to play with what you have.

Next, we executed a creative organizational change strategy, and this was critical to our success. We developed relevant, provocative, consistent communication and engagement; that was a top priority. We did product marketing and branding at its finest. For example, as part of the change, we created various events where customers could come in. We called it a workout day and made it fun. We had treats, anybody could walk in the door, and we had tables set up. If there was a question about a particular piece of the process that someone was confused about, we directed them to that table to get the question answered and talk about that subject. The key message is that we were visible. We were there. They knew change was happening. We communicated consistently.

Here are the results. For the manual user experience, we took our bloated, nasty change process from the old totals to the new totals. Manual data fields went from 75-plus to 12. Business rules built into the change tool went from 100-plus to 26. We decentralized the Enterprise CAB. Average change duration moved down to eight hours, so support and help desk staff had a better chance to tie front-line impact to a particular change and back it out. Approvals went from two to four down to one. Clicks went from 120-plus to 22 end to end. Net Promoter Score was bottom of the barrel because we had been voted worst in technology, and it became 60.

For the automation user experience, the numbers spoke for themselves. We created a change API and exposed it to our customers. Initially it took time to get adoption, but over time it spoke for itself. There was no rise in incident counts, which was the biggest fear when we decided not to do an Enterprise CAB anymore and to decentralize it. Engineering customers made the decision to remove the flaming dumpster fire emoji. We did not tell them they had to remove it; they decided to do it themselves. We also created an inspiring domino effect across the organization. We were one of the first governance teams to lean into transforming and aligning our governance process to the future of digitalization, and other governance teams noticed and started changing as well. I no longer have fear of falling asleep in fear of the stink eye.

Here are my tips if you are a governance team wondering where to start, or if you are an engineer trying to influence change. First, lose the governance ego. In this new world, we should not have egos. We are no longer governance and no longer command and control. In the future, we are collaborative partners, and we need to meet our customers where they are.

Second, commit to an identity change. It is not about the process and tool change by itself. It is about changing the way you think. It is important for your governance team to think about its identity in this new organization. There are exercises and workshops you can do to ground your team in that new identity. Do not be afraid to communicate that identity to your customers. Rebrand yourself. There is nothing wrong with that.

Third, productize your governance process. Just because you have a governance process does not mean it cannot follow product management principles. Product management has many good practices, and it is important to adopt them. Use personas. Understand your customers, their pain points, and their challenges so that you know what you are building for. Do discovery, like we did. Spend time with your customer, in their space and in their tools, to understand them. That is critical, and you will gain a ton of credibility with that approach.

Fourth, do not be afraid to start over. Some processes in large and medium bureaucratic organizations have been in place for decades. Sometimes it is not worth rehashing the spaghetti mess. Sometimes you need a blank whiteboard and need to vision out what the future should be.

Fifth, put emphasis on an organizational change strategy. One of the biggest reasons organizations fail in transformation efforts is that teams just do not know about it and have not been clearly communicated to throughout the journey. Change management is a big deal. It is not just communication; it is engagement, visibility, being there throughout the journey, and letting customers know where you are in that journey. That was one of the areas we did exceptionally well.

As a bonus, persevere and stay strong. The journey is extremely difficult. I cannot tell you how much of an emotional roller coaster it was over the three years we took to transform this lethargic process. It was worth it, and I am glad my team and I continued. There were days where every meeting brought different feelings: super excited in the morning, sad the next hour, crying the next. But that is transformation. It is hard. If it was easy, you would be transformed already.

If you are interested in more intricate details of how we aligned our ITIL change management practice to the future of digitalization, I have an eGuide available. Let's talk. I love to hear from you. Feel free to reach out if you have questions or want to run something past me. Thank you, viewers. You are watching Stink Eye on Steroids, and I hope you enjoyed it. See you soon.