You Can’t Automate Cultural Change

00:00 — Jamie Parker
Company culture is kind of a big deal. It takes work to get it right, and more so when it needs to change. Last episode, we heard World Wide Technology's story and how they had to win over their engineering teams to participate in a broad automation framework. After a lot of trial and error, automation became part of their company culture.

00:23 — Jamie Parker
That's all well and good for a tech company with a culture open to change, but it's not a given for every company. Whether it's out of inertia, obstinance, or fear, organizations often put themselves in their own way. And without cultural change, automation won't get very far. This episode we hear from consultants at Deloitte and how they help their customers build a culture where automation becomes part of their processes and how it helps them bring down barriers.

00:58 — Eddy Krumholz
The intent is really to build a culture of innovation and automation that can fuel and sustain the automation strategic vision for years to come.

01:09 — Jamie Parker
Eddy Krumholz helps clients navigate the changing IT landscape in his role at Deloitte. Over the years as a full stack developer, he learned how to automate manufacturing processes, cloud architectures, DevOps processes, and even automated some of the work for the International Space Station on behalf of NASA. Very cool. Shifting the company culture is part of his job, but culture is a hard thing to change. It's not just bringing back Casual Fridays and Taco Tuesdays. There's an imperative to change how people work together and sometimes there's pushback against those changes based in fear.

01:46 — Eddy Krumholz
I would say just in general, it is a journey because a lot of organizations are more resistant to get there for a variety of reasons, right? It can be, "Hey, if I automate, does it mean that I'm going to lose my job? If I automate, will there be any other ramifications to the organization?" I think that there is some natural speed bumps along the way, but the angle of human capital and culture is super important when you're adopting this, right?

02:14 — Jamie Parker
Culture is all about how we interact with each other, how we present ourselves, and what we prioritize as an organization, and all of that is subject to change, but it's also a strong force against change. David Linthicum has seen that strong force at work. He's the chief cloud strategy officer at Deloitte. He's also an author, podcast host, and all around IT industry expert.

02:38 — David Linthicum
If you look at most IT systems, they still have very manual processes. There's some automation, but not a lot of automation. It's typically siloed and fragmented. There's no overreaching orchestration of these automation systems, and they're leaving a lot of money and value on the table.

02:54 — Jamie Parker
Unifying those teams, breaking apart those silos, orchestrating that work, it's a monumental effort. David and Eddy have found that newer companies building cloud-native systems are more likely to seek out automation solutions often because they've seen that working without it hampers productivity, but some companies might not be able to see it that way at first.

03:17 — David Linthicum
Older systems have a tendency to have a different take, and so in other words, if something's been doing basically as manual processes for the last 30 years, suddenly when you show up to automate some of these systems, in many instances, we're extending automation out of the newer systems into the cloud. There can be a bit of pushback on that because you're changing something that has been long since gospel within the organization is what they're looking to do. And so it's a bit of a cultural shift for those sorts of cultures where in the newer stuff, it's usually demanded.

03:49 — Jamie Parker
They're used to doing things a certain way. The system works. It needs a lot of care and attention, but it delivers what it needs to. However, the organization has new priorities that require using new technologies.

04:02 — David Linthicum
People may push back on that. You're going to have to spend some time explaining to them and providing them with the understanding as to why this is occurring, and that's being an agent of change, which I always joke, I shouldn't have got a computer science degree. I should have got a psychology degree because you end up going to that in terms of dealing with the human beings and how they really accept it. But it's always different depending on the team and the culture that you're dealing with, the company that you're dealing with.

04:28 — Jamie Parker
That changes when that system is being extended into the cloud and new workflows need to be set up to combine the monolith with a distributed system, and that's going to shake things up.

04:39 — David Linthicum
You got to remember, we're not good at building distributed systems, even though we're building complex distributed systems in the cloud these days. We're good at building single monolithic systems where we're dealing with a single operating system, a single database. Now that that's been out the window for the last 30 years. And we like to manage those things as if they're monolithic. So we'll cut off a certain amount of experts and a certain amount of toolsets, and we have different silos of people and organization. In many instances, I see those organizations that are organized around systems and databases, things like that. They're not organized around the function, so you have the Oracle group and the DynamoDB group and things like that. That's the wrong way to do it. You're just building silos within the organization, but they're doing what they know best, to manage these things as monolithic systems, and they may have all these various organizations don't communicate one to another. That can't exist anymore.

05:27 — Jamie Parker
Silos, barriers, territorialism, those all feed into a lack of communication. We've all had emails go unanswered or teams deflect responsibility when a project doesn't fit their fiefdom. When your teams aren't coordinating while building a complex distributed system, that system is going to be disjointed and prone to errors. Projects get stalled, risks aren't taken, and that sought after innovation becomes unattainable. It takes more than the right set of tools to succeed. Coming up, Eddy and David are going to tell us how they help their clients increase the odds.

06:12 — Jamie Parker
Deloitte has developed a framework with which to structure the planning and rollout of their IT modernization projects.

06:19 — Eddy Krumholz
At the firm, we have a framework we call PACE, which stands for process, architecture, culture, and engineering. And when you enable automation, you should really take a look at all these four angles, right?

06:32 — Jamie Parker
Process encompasses workflows, the ways people work, and how they interact with the organization and with their devices. The architecture component is about considering the elements of the IT system and how they fit together. And the engineering is about looking at the specific tools to use within that system. David and Eddy both mentioned a lot of people focus on the engineering aspect to the detriment of the rest of the framework.

06:58 — Eddy Krumholz
So take in consideration that as a backdrop as well as the cultural parts of being, which ultimately is the biggest blocker for most organizations to adopt automation frameworks at large, just simply because organizations are used to doing certain things in certain ways, and typically when you do automations in an organization, it ends up mimicking the organization's structure or communication structure as well, which doesn't really buy you much.

07:31 — Jamie Parker
That's often the silos David was talking about earlier. This phenomenon is referred to as Conway's law and it takes concerted efforts to overcome. We're about to hear some of the elements that companies include in their automation frameworks. Don't worry about remembering the exact details, but do pay attention to the breadth of processes that need to be coordinated in concert.

07:53 — Eddy Krumholz
To me, an automation framework is a structured set of guidelines, practices, and tools that provide a foundation for organizations on designing, implementing, and executing automated processes, and in some cases can be other things like tests. It serves as basically a systematic approach to automation, promoting consistency, reusability, maintainability, and scalability on all tasks.

08:24 — Jamie Parker
A lot of people use software testing as their first automation projects. That entails creating and executing test cases.

08:31 — Eddy Krumholz
So there are several components when we talk about automation framework that people should include. So we talk a little bit about test design techniques. Those are important things like behavior-driven testing, test data management.

08:45 — Jamie Parker
So there's also management of that test data. How is it collected? Where's it stored? How is it processed? What goes into the report?

08:52 — Eddy Krumholz
Other elements that are also important are reusable components. So automation frameworks typically encourage the creation of reusable components or libraries so that you can avoid duplications and then promote more efficient automation. Another element is configuration management because you can have different environments or different settings, so you need to allow for the same type of automation to be executed in various scenarios.

09:19 — Jamie Parker
And the list goes on.

09:21 — Eddy Krumholz
Logging and debugging, error handling and recovering, parallel execution, cross-browser, and cross-platform testing. And then popular automation frameworks, particularly in testing.

09:34 — Jamie Parker
No single team is likely to have the answers to all of those requirements. And as we heard earlier, many times those teams don't communicate with each other. That needs to change to have any hope of success. That's why culture change is an essential component of the process. It needs to reach all levels of the organization from the top to its base. Their motivations might not be the same, but they have to find some overlap.

09:59 — Eddy Krumholz
On one end, you're promoting knowledge sharing from the top by providing adequate training to employees and particularly ones that are involved in automation projects. And also from the bottom up, you also provide that no fear kind of, if you have an idea, bring it. Make sure that you enable experimentation and that you account and budget for those things and then enable that knowledge sharing to propagate across your organization. Some use centers of excellence or communities of practice, which are great ways to enable some of these knowledge sharing techniques.

10:36 — Jamie Parker
And while Eddy and David come in to offer advice, frameworks, and paths forward, the bulk of that work is going to need to come from within.

10:45 — David Linthicum
The reality is that people who are in the mix of it, people who are actually doing the work, are the ones that are going to need to figure out how to fully automate it. So we're taking some of their resources and some of their time and having meetings and doing tests in place and meeting with vendors and doing some proof of concept prototypes where that's typically not going to be part of their jobs. And it's going to be an ad hoc thing. So we're going to reduce your responsibilities for a certain amount of time, say six months, and we understand that productivity is going to slow down in half because we're taking some of your time away from doing this, but this is something we absolutely see as a viable responsibility of the company. And so that's kind of how it works. And so it's always going to be a beginning, there's going to be a middle, and end. It should not be ongoing.

11:26 — Jamie Parker
It's extra work, which often entails learning new skills. That's not a big deal. We all need to be constantly learning in this industry. What makes it difficult is that the learning and the building also entails slowing down productivity until projects are complete. Only then can they hope to see the benefits kick in. So we've identified that culture needs to change. Eddy and David have laid out the work that needs to be done, and they've got a few ideas on how to encourage the cultural change necessary to make the framework work. It's all about communication.

11:58 — David Linthicum
So it's a matter of breaking down those barriers and get people communicating one to another, not necessarily physically colocated. There's no need to do that. But the ability to have a collaboration infrastructure and the willingness to collaborate that didn't exist prior. And they're going after this common objective. So in other words, we're telling you as the CIO of the company, we need to automate how we're doing something across different silos that are occurring, say across 20 different silos. You guys need to figure out how to make that happen. We're going to put a project management in place to make it occur, but everybody needs to participate in making this a success. So it's kind of a forced fit, enforcing their hands, but again, to the point we made earlier that I think in many instances, people who exist within these silos see the value of automation.

12:43 — Jamie Parker
Giving people avenues to talk to each other and encouraging them to take advantage of those opportunities is huge. So is giving people opportunities to test and share their ideas.

12:55 — Eddy Krumholz
The second was the realization that an innovation culture really is established with a top down leadership vision and a bottom up innovation action. So innovation culture doesn't happen in one direction, it's bi-direction. Another thing that we recommend for the organization to consider is ideas like crowdsourcing, to democratize innovation, and also to demonstrate that everyone has a role to play on the innovation agenda.

13:26 — Jamie Parker
But people aren't going to take advantage of those opportunities unless they know how to use the tools to do so. Some might do their own research, but if the ultimate goal is widespread adoption of automation in your workflows, why not make it easier for everyone to learn these tools?

13:41 — Eddy Krumholz
Other considerations including education and training to support the innovation culture. Because in some organizations are very brick and mortar and that has never been part of their DNA, but that doesn't mean that they cannot be. So enabling these help also start shifting the mindset. We had innovation coaches across the organization, and we also made the point that we needed a new way of working to help establish the foundation for this innovation of culture.

14:12 — Jamie Parker
Sometimes you should tell your employees to be showoffs.

14:16 — Eddy Krumholz
The second thing that we did on the innovation culture side was to launch an automation strategy roadshow. And these help really brand. And in some cases, in some organizations, there have been failures on this. So you can also use this for repositioning. The automation strategy emphasizes innovation, creativity, and imagination by identifying really novel and compelling automation use cases.

14:44 — Jamie Parker
It validates the employee's work, which encourages them to continue to automate, but it also shows everyone what they could do themselves and then give them a space to try.

14:55 — Eddy Krumholz
The third thing that we created was an innovation lab, basically called an incubator, that was focusing on targeted innovations that have substantial impact potential. And the last thing that we did is we built an innovation storefront and a dashboard that we were using to publish these results, like I mentioned earlier, highlight any major innovations. And we had featured like automation success stories.

15:25 — Jamie Parker
With all these strategies, ways to share, ways to learn, they're hoping to inject automation into everyone's routine.

15:32 — Eddy Krumholz
Automation is not only an elite group, but everybody's involved in this. Having the right rewards is very important, and a lot of organizations learn by copying others. So for example, in this client, they have multiple business units that decided to choose different parts of IT automation, and they have successes that then they copy from each other. So initially it was spotty, but as more and more people are innovating and they're adopting what other people have innovated on is creating more of a wave and this wave continues to grow because success breeds success. If everybody's afraid of doing automation, then automation never happens. But if you have the right framework and you involve the people and you reward people for doing so, you have a great chance of success.

16:27 — Jamie Parker
Cultural change isn't something to fear. You can't automate that kind of adjustment, but there are systematic ways that can make those transitions more likely to succeed. Establishing a framework, starting up ways in which automation skills can be learned, and successes can be shared–these all make a difficult, scary prospect more attainable and approachable.

16:50 — Jamie Parker
You can read more at redhat.com/codecommentspodcast or visit redhat.com to find out more about our automation solutions. Many thanks to Eddy Krumholz and David Linthicum for being our guests. And thank you for joining us.

17:05 — Jamie Parker
This episode was produced by Johan Philippine, Kim Huang, Caroline Creaghead, and Brent Simoneaux. Our audio engineer is Elisabeth Hart. The audio team includes Leigh Day, Stephanie Wonderlick, Mike Esser, Nick Burns, Aaron Williamson, Karen King, Jared Oates, Rachel Ertel, Carrie DaSilva, Mira Cyril, Ocean Matthews, Paige Stroud, Alex Traboulsi, and Victoria Lawton. I'm Jamie Parker, and this has been Code Comments, an original podcast from Red Hat.