Managing change resistance

Marc (00:06): Should we try to build the perfect platform?

Darren (00:08): I mean, sure, if you don't want it to be used. You want a platform that fits everyone's purposes as best as it can. And it won't be perfect, it will never be perfect.

Marc (00:20): Welcome to DevOps Sauna season four, the podcast where technology meets culture, and security is the bridge that connects them.

Marc (00:37): Welcome back to the sauna. Hi, Darren, how are you today?

Darren (00:42): Hey, Marc. I'm doing okay, a bit busy, how's things on your side?

Marc (00:45): Fantastic. But there's something that I'm seeing a lot in history and in my current customer engagements that I wanted to have a conversation with you about, and that is the resistance to change.

Darren (01:00): Yeah, I get that a lot. I think this is one of the few topics we can talk about that's not even specific to technology. This is a topic that touches basically everywhere change happens, which is usually everywhere. So it's going to be a bit of a bigger topic, maybe a bit more wide reaching than usual, very technical or very process oriented things.

Marc (01:21): Yeah, there's one way that I can look at this that helps to spread the spectrum, which is modern command and control hierarchies, everything from project and program management, PMO, program management offices. A lot of this came from the way that governments worked and the way that big projects worked, and things like Manhattan Project, kind of set modern project management. But a lot of this stuff still comes back to things that were command and control hierarchies for labor.

Darren (01:50): Yeah, and the modern world has developed in a way that doesn't really support such architecture anymore. Well, I don't know, maybe there are some managers out there who think it does support architecture, but we have like spread our workforce, we have remote work. So all this spreading of the workforce, and people taking more responsibility for their own tasks, it's maybe a bit of a tangent, but it's interesting how a lot of the way we look at these things still reaches back 70 years.

Marc (02:22): It sure does. And this concept of the knowledge worker is one of the paradigms that modern management needs to be aware of and have a good grasp on. Because what we want to do is we want to move the conversation to how do we get the best out of our knowledge workers who have domain specific expertise. They know how to add and create value within your organization. And we want to give them interesting problems to solve because that's their job. And when those people are upset that they aren't able to do this effectively. We have this pets and cattle thing that we talked about in software a lot. So it may be that somebody has their pet tool that they really, really love, but a pet requires taking care of it individually. When you think of something like a herd mentality, like a whole suite of tools that are used across a broad organization, it's more like cattle, we need to make sure that there is enough resources or food and water for the cattle, we need to make sure that they have places to run and places to grace. So in the tool environment, it's about making sure that we are able to have scalable tools that can support many different types of workflows that are standardized enough that you are able to have security, compliance, and the ability to really do the work that is at hand, which is taking this knowledge worker, domain specific knowledge and using that to create value for the enterprise.

Darren (03:47): Yeah, and I think that actually leads into an interesting topic for discussion because one of the things about change resistance comes from that knowledge worker, in my opinion, it comes from their tooling bias that they've built up over the time of becoming a knowledge worker of learning these tools, learning this tool chain, and then wanting to stick to it. So you raised a knowledge worker as a driving force for this change. But it's also in my opinion, one of the largest sources of change resistance. It's a knowledge worker who's set in their ways who is very specifically looking at tooling as pets. And this is their pet tool, and they want to keep this tool and they know how to do everything in this tool. And then again, we circle around to the unfortunate Jenkins in the room where it's a tool that I don't want to be abusing constantly.

Marc (04:42): How much can we do this abusing Jenkins before we get someone to send us a nasty comment?

Darren (04:48): Yeah, I think someone's going to comment at some point, but we do have to outline that if you're picking a tool because you're familiar with it, rather than it being the best tool, then you have made it poor decision. But at the same time, one of the best tools is the one you know how to use. So it's like a weird balancing act. And I think walking this path is the way through change resistance. Because you have your known variables, you have the tool and you want to you have the tooling that's good. And being able to give the developers something they can use, and more importantly, being able to involve them in the process. Because there is this tendency, in my opinion, to have like a boys versus them mentality of we're developing this platform to developers using it. And what we say goes because we're developing it, and that's bad. Like, I just stated, if you don't involve the developers from the start and involve them in the iteration process. And this goes for every change management. If you don't involve the people who are required to change in building and taking ownership of that change, all it's going to happen is you're going to end up with a tool that's either resented or not used.

Marc (06:02): It reminds me of a related story where we, the directors of the company, we went into the boardroom, and we were involved in creating the strategy of the company. And we felt that we understood it quite well. And we were very committed to the strategy of the company. And then when we went to the auditorium in order to present it, and we started to look for the execution of the strategy. A few months later, we realized that people didn't really seem to understand it, and certainly weren't committed to it. And it's like, well, were they involved in creating it?

Darren (06:37): Yeah, I think that if you cut people out of the the actual iterative process, you can't be surprised if they're annoyed and resistant to using the end result.

Marc (06:48): Yes. Absolutely. And we have a couple of Nordic friends that have cultures of consensus. And one of the things that I think is really important to illustrate is you need to have everyone's voice heard. And I believe that you also need a leadership with a vision that says there's a vision that we have for what we want to do. We want to be able to release five times a day, or we want to be able to release any pull request because it allows us to serve our customers like this. When you have that kind of vision, it helps to answer a lot of questions as to the why. But then when people also have their voices heard, then they feel like, okay, I gave my voice, I still wanted to do things this way. But now at least I understand that I was heard, and it aligns with the vision, the choices that have been made.

Darren (07:34): Yes. So you have like a golden path, you've got the leadership that to have the direction and the feedback loop to improve the direction. But I think it's important to iterate the fact that you weren't managing change, you will never be able to please everyone. The idea of pleasing everyone, you have to deal with everyone on your platforms. That's a pipe dream, that will never manifest. So we can pull examples of that any tech company that allows the use of Linux, for example, what you end up with is several hundred different people wanting to use several hundred different tool sets, wanting to use their own distributions of Linux and security team who have to say, okay, this, we can allow. This we can't, then most of these requests, we don't even have the capacity to acknowledge because it comes back to the old joke about IRC and how. It doesn't matter how communication technology changes, there will always be one fin still using IRC to connect and talk to their coworkers. And the burden of that IRC user can't be put on the developers of the platform, it can't be put on the people forcing the change because one person who cannot modify themselves to the working methods to the platform as it's changing is not indicative. And that's, I think, an important thing to say by saying you need the leadership there. You need the leadership to be able to discern when something is valuable feedback and when something is just one person being particularly attached to a tool set, particularly attached to the way they are working. As you say, cattle not pets.

Marc (09:18): I’ll name drop here. So Jarkko Oikarinen from Oulu. I had the pleasure to work with in Nokia days, the inventor of IRC. I assume OuluBox is still out there somewhere, but my heart's off to you for having basically changed the way that the internet communicates. It was nice for you to drop that in there.

Darren (09:37): It actually raises another question. Well, is there room for inflexibility? Because I know in a lot of these change processes that are related to technology, we look at things like finance. And finance has like IFRS, the International Financial Reporting Standard. The US has the what is it generally approved accounting protocol procedure, something along those lines. Yeah, flexibility in those cases, I understand is rare, and usually involves breaking the law. And I think there's a rigidity in that mindset, but I think we're in danger of taking into technology. Because we're seeing like EU directives around security around the governance and use of AI. And as these come into play, it's going to be interesting to see how it changes the landscape. So I just wonder you, Marc, what do you think about flexibility? Should there be room for inflexibility?

Marc (10:38): This is one of the things that I get up on a lot. The first thing is that we need to get good at change. And we need to understand that if we're not changing the tools, if we're not changing the processes, then we're not growing. And if you're not growing, you're dying. It's binary, it's one or the other. So then, in terms of flexibility, agile went wrong when the real flexibility given to developers was just what tools are you going to use? And how are you going to run your team internally, compared to the whole rest of the enterprise? That is choosing a different set of tools and a different way of of running their team. And none of this can pass like an ISO 27001 audit. You can't have everybody doing things differently. And Management 3.0 came out, like nearly 15 years ago now and said the concept of having minimal constraints, and I think and in SAFe, this is called guardrails, I'm not really a SAFe guy, there's a joke in there. <laughs> But what are the minimum things that people need to do in the same way in order to have a secure, compliant and efficient way of working. And that's, I think, grown over the years in terms of these fragmentation that's been caused by everybody having their own instance of Jenkins, except for those guys over there that have GitLab running under their desk and a server hit by the cleaning lady with a vacuum cleaner every day. IT doesn't even know about it, but there's a significant portion, a very important software that is built on that open source product, rather than using the paid enterprise version with all of the bells and whistles for security and whatnot. So the thing about this flexibility is, I still want to come back to something I mentioned before is I want to move the conversation away from we think that we have the special needs. And we need to have a special tool in order to achieve that versus I want interesting problems to solve for our business. And I want to know that there's a platform team that is making sure we have the state of the art tools always available because not only do I want to have the best possible developer experience, but I also want to know that my skills are being based upon the latest technologies and things that are actually going to be marketable. One of the things here, you have too much flexibility, everybody does things differently. You don't have internal portability within your company, I can't go and work in another team and understand what's going on. How do you onboard that? Everybody has a different on-boarding procedure or a different development environment. So for me, the flexibility should be how do we solve problems creatively, have an ability to experiment in production, have an ability to have the psychological safety that if I make a change, it will have a limited attack surface. What's the other way of looking at attack surface? Like the Ground Zero type of thing or the blast radius, right? So if I make a change in production, it will have a limited blast radius as to how many people that it might impact. So I have the safety to be able to do experiments in order to understand better the requirements that I'm supposed to be building for the business. I want to push this conversation in that direction and say, if you really need to have such flexibility that you have to run Jenkins when the rest of the world has moved on to GitHub or GitLab and runners or actions, then I think that you're having the wrong conversation in your organization.

Darren (13:59): Yeah, I think when it comes to the source of inflexibility. So if the inflexibility is something imposed on you from an outside influence, like a governing body, something like the ISO 27001 standard, something like a reporting standard or security standard, that's the place where inflexibility can't be avoided. But if it's coming from inside your own team, if it's the people there who are creating in flexibility, that's where your largest resistance to change is. It's not inflexibility due to a requirement. It's inflexibility due to an unwillingness to be part of the program, to be part of the change. And I think you touched on a couple of important things here. And one is this server that's under the desk that keeps getting hit by the cleaning woman. And you've mentioned this like three times now. So clearly, we need new cleaners. 

Marc (14:52): Sorry for that. 

Darren (14:54): The second thing is that I think it's important to underline that ownership of the platform. 

Marc (15:00): Yes.

Darren (15:01): I think we touched on it before, but I don't think we quite went into it because the ownership of the platform is key here. And you said it yourself at the start that move the conversation to interesting problems to solve. And the loads of my work is just defined by which problems I find interesting to solve. And I'm sure it's the same for many other technical people. I'm trying to avoid the word nerd out there. But it's the same that if I have an administrative task, I don't want to do it. And if I have a technical interesting tasks, I want to focus on that. And this is the key thing to develop ownership of the platform in such a way that the people using the platform, the people making the change, take ownership of it, and find it an interesting problem to solve.

Marc (15:51): Absolutely. I will clarify my story that I had a customer, a large enterprise customer wireless company in the United States. And the cleaning staff was not generally supposed to be cleaning the server room. However, one of the rotating cleaners who happened to be a nice lady, her key worked on the server room. So when she would go in to do her work, she would try her key where it worked. And she would do her cleaning operation. And there happened to be a power strip of machines that were outside of the regular rack systems that you find in the server room. And she would randomly unplug one of those and plug in her her vacuum cleaner and do the work. And then she would plug it back in. And then the customer was telling us about our unstable situation, and that the machines were randomly rebooting once every week or once every two weeks. A different machine would be randomly booting and we didn't know why. So I've transferred that story to the real life that many developers have to have a shadow IT in order to run the tool of their choice under their desk, which is a real life problem that we see. And that's taking a lot of ownership. But I want to take this ownership thing into a slightly different idea that we look at research and if developers spend 40% of their time on maintaining their tool chains, then this is one of the things where I think the ownership is a little bit too great, potentially. And it's one of the opportunities were platform engineering teams who are helping to create self service environments for developers that they are able to make changes if they need to. And one of the flexibilities here is, for example, to be able to try a different tool in a runner. So if you are building your software, and you are responsible for you build it, you run it, and in terms of you develop it, you compile it, and you execute it in production, and you have responsibility for that. Having the flexibility that developers can still take ownership of a pipeline in terms of branching it or forking it off, making a few changes, trying some different things. And then potentially making those generally available through a platform engineering team might also be something that has a lot of validity, but it comes down to as well, many organizations from finance to manufacturing, and AI, and lots of different companies can run with a very similar tool chain today, and using one of the big platforms, and then a handful of others. So it's difficult for me to understand why the most critical area of flexibility would be in the tool selection today compared to doing things that actually create real business value. And that's one of the things about the ownership as well. I would be so happy as a developer if someone else were able to maintain all of that stuff. And I can just come to my desk and start solving really interesting problems for the customers, see those realized in production in near real time, get feedback on those through monitoring that I have access to, and then be able to tailor my interpretation of my requirements in order to make sure that the customers are getting the best value. And I think that that's one of the highlights of DevOps is being able to realize that, and we're not going to realize that if everybody has a different way of working and is maintaining their own tools all the time.

Darren (19:19): Yeah, I think you're 100% right there, but what you're saying there is the tool, or the platform, or the more generally the change, the thing that they're changing into needs to be extremely good. It needs to be something that adds value. It needs to be something that reduces the load of, let's say, this 40% that developers are spending on their tool chain that, but they still also need to have a voice. They need to have a say in it and they need to have ownership of it. So would you say it's then quite a difficult line to walk? Technically speaking, I come from a very technical point. view that, sure we can outline all the best tools, we can talk about the tools and implement them and then give it to people. And it might be perfect, but it will be sterile. And no one will use it because no developers have had feedback. So what would you say towards that making it so good it can't be ignored?

Marc (20:20): There's two at least areas here. The first one is, is there a management strategic company level thing that the change will enable? So for example, being able to do changes that are effective in production on a daily basis versus having releases twice a year. And I think many developers can understand that they want faster feedback. And that as a part of that vision, having reducing their cognitive load by having faster feedback on their changes, and the ability to see those running in production also brings a pride of craftsmanship, the delivery, lower the impostor syndrome, things like this. So the management needs to buy in and understand the investment, and needs to say that this is going to change. And there needs to be some bravery in that decision to say that we're really going all in on this, and we're going to make these changes. And these are the reasons why. And then on the other side, it is how people are involved, and how the ownership of those things are stepped up and taken care of where if you have a platform team, they can't throw things over the wall to developers, they need to constantly be working with all of the development teams to make sure that they are enabling the things that are necessary. But the change leadership here is so important as well because it's so easy to fall back into the previous ways of working. It's so easy to say, okay, we've gotten into a new paradigm, be it a new tool chain, or onto a new platform, or using just a couple of tools differently. Moving from Azure DevOps to GitHub, it's even something like that. But the change leadership needs to understand what the reasons are, and keep an eye on the ball there because otherwise, you end up just replicating the previous pathologies in the new paradigm. And we don't really want that either. But if I try to put my spin on the summary, it's that I want to see it so that change is a constant improvement. It's not just big bang all in approaches, but we need to get used to change because if we're not growing, we're dying. And then on the other side, there needs to be some bravery and some mandate that we're going to be in this together. And some people are not going to like it, but they're going to work through the situation and see the value of it, or they can go try to find some other place to add value that either is growing or dying itself.

Darren (22:55): I mean, that's a bleak summary in that case. But I do agree, you're going to end up in a situation where either enough people will change that others who have been sticks in the mud are being dragged along, or they are going to look elsewhere. And in my opinion, that's entirely okay. Like not every company will work the same. But you do raise an interesting things. I think it's mostly interesting that we left it for quite late in this discussion. Actually, in my opinion, the biggest and probably earliest things you need for change management. I can talk about this from a security standpoint. The whole pushing of security methodologies is always met with resistance because it always adds overhead. And the best security tools are the ones that can do it invisibly, basically without requiring anything from the developer. And as a security person, if you don't have the backing for management, it's so easy just to be ignored. And I'm pretty sure it's the same when it comes to managing change resistance in deploying platform tools in any change resistance. If you're just one person trying to push a change, you're easy to ignore the actually weirdly comes back to the whole command and control infrastructure we're talking about before, if you don't have to leverage from above to push these issues. I feel like you're not going to really get very far with it. So you can end up building a great platform that no one's using because the bu-yin's not there.

Marc (24:31): I've sat in a meeting that had a senior vice president and a developer in it, where the developer said that he would not support the change unless it had Jenkins. And if you can imagine what somebody who's responsible for a few billion euros worth of revenue thinks when an individual says that the whole change program that's been planned can't go through because of a single choice of a single tool. It's quite interesting. On the positive side of things, I really liked that we set a vision, and we're going to make a change in order to stay ahead. And keep everybody's skills current, enable change in our organization and do this for the right reasons. And I think that it answers a lot of those types of questions. Okay. So since my summary was so bleak, my way or the highway, evidently, I'm not accused of that kind of thing very often, I'll ask you for for some summary then Darren. So is there room for inflexibility?

Darren (25:34): I would say yes as long as it's not coming from inside your teams. 

Marc (25:39): All right, who owns the platform? 

Darren (25:40): Everyone. If the developers aren't in on the process, then it's just going to become something they resent.

Marc (25:48): All right. Should we try to build the perfect platform?

Darren (25:50): I mean, sure, if you don't want it to be used. You want a platform that fits everyone's purposes, as best it can. And it won't be perfect, it will never be perfect. And if you think it's perfect, it will be out of date in three months. So you have to iterate.

Marc (26:04): Are there some known variables to look out for?

Darren (26:07): Don’t use Jenkins. Generally speaking, I feel like you should avoid tooling bias. You should also try to avoid as you were saying, the pets versus cattle syndrome, these tools are the things that serve a purpose, they shouldn't be decided on because you like them.

Marc (26:26): All right. Do we need buy in from management to continue?

Darren (26:30): 100%. And probably is one of the first things you do.

Marc (26:34): All right. So thank you for that. I'll add a couple of things, which is, I like what Darren mentioned a couple of times that you just can't please everyone. And one of the things that I think is also really important that I think we've talked about a couple of times Darren is let's, even though we don't need to build the perfect platform up front, but when we have the mandate and the buy in and we involve everyone, let's hope that we're going to end up with something that's so good that it can't be ignored. Okay. Thank you, Darren, for this discussion. I know that everybody that's out there, change management's, you're growing or you're dying, and I hope that we gave some useful tips on and considerations for doing that within your organization. Thank you, Darren. 

Darren (27:20): Thanks, Marc. 

Marc (27:21): All right. We'll see you next time. Let's get back to hacking. We'll now tell you a little bit about who we are. Hi, I'm Marc Dillon, lead consultant at Eficode in the advisory and coaching team and I specialize in enterprise transformations.

Darren (27:38): Hey, I'm Darren Richardson, security architect at Eficode, and I work to ensure the security of our managed services offerings.

Marc (27:46): If you like what you hear, please like rate and subscribe on your favorite podcast platform. It means the world to us.