Rob England

So I'm working down in New Zealand as a DevOps consultant with a number of large... well, no, small government ministries in New Zealand that we consider large. And I've been consulting purely in the DevOps space for a couple of years now.

But some of the thinking behind this goes back decades, to just that whole experience of watching people being shed by the organization, people being heaved over the side unnecessarily, and seeing good IP walk out of the organization. So it's a topic of interest to me to see how can we bring as many people as possible along on the transformation journey and have no one left behind, or minimizing the number of people left behind, and being as humane as possible about the transformation in DevOps. It's very easy to talk about the overall change to the organization and sort of forget the individuals. So I want to just quickly talk about some of the thoughts behind that for you.

It's not just my own personal experiences here. The Ministry of Social Development in New Zealand is one of my major clients, and if anyone went to San Francisco in November, the previous DevOps Enterprise, then David Haverson talked there about that journey, and that's been an interesting one. So that's my own personal experience. A lot of that went into that, and I talked to David and a number of others about this topic.

But also in New Zealand, Westpac Bank, who are an Australian bank, their New Zealand subsidiary has completely transformed with DevOps through the whole of IT. And in fact, all our banks are rocking and rolling on the DevOps journey in New Zealand.

And then also, Gene lined me up with a couple of other people to talk about this, to get an American context on it as well. So you all know Jason Cox from Walt Disney. I had the privilege of talking to Jason about this. And Scott Prugh from CSG International. They're a huge billing organization providing services to all the cable companies in the US. So I got a US perspective on this. I didn't get a British one. Sorry, my apologies for that. But I think we have a few more cultural connections than the Americans.

And then also, just a lot of observations of other organizations. I've been to every single one of the DevOps Enterprise conferences, as you said. So that's the strength of this conference, is people's stories, so gathering that.

And I should also talk a bit about my own personal transformation here, because this is a picture of me just a couple of years ago and... seriously, really. And part of the whole DevOps thing, the power of the DevOps movement, is that it's a hippie thing, man. And so this is real, right? I grew the hair literally as part of the brand to be a consultant in DevOps. Don't laugh, I'm serious. That's part of it. And I think it's very much a human-centric approach, and that's part of the appeal to me. So having this empathy with people who are being affected by this journey is important to me.

So there's a couple of aspects to this. One is understanding that work's changing, and this has always been a part of IT. So I was running professional development programs several decades ago for a software company and trying to get this message across to product jockeys: that if you align yourself to a specific technology, then your career lifetime is limited. And the same is true of every technical role there's ever been.

You may not realize that back in the sexist days when the typewriter was invented, only men were entrusted to be typewriter engineers, and they were highly valued roles that would come out and operate the machine. And then it becomes a commoditized thing, and eventually it gets automated out completely. So the same is true of all the roles we have in our industry. So it's been a thing all along that all of us must reinvent and grow and move on. But the pace at which things are happening now, and particularly the pace at which DevOps transformations I see are sweeping through organizations, they put terrific pressure on individuals to move on.

So there's some questions I use that you might find useful to try and trigger people to move on, to give them a little bit of a gee-up. Look me in the eye and say, "Will your work be better in a year? Will you be producing better results, and will you be having a better time in a year?" And if you can't say to me yes, then you're not continually improving. So the whole fundamental of continual improvement is just nonexistent in the organization.

Are you working sustainably? Can you keep working the way you are indefinitely? So this whole idea of sustainability without accruing technical debt and cultural debt. Again, I like to ask a manager, look me in the eye and say your people can keep working the way they are now forever.

Does IT deliver value faster than the business is ready for it, or is IT a constraint? That's the fundamental of DevOps, isn't it? That's the why of DevOps, is to be faster than the business.

And then if that does trigger people to start wanting to move, then what's a great day at work look like? What does good look like? But I love this phrase: what does a great day at work look like?

And how would your behavior change when you trust me or someone else is another good one. Not how would you like other people to behave, but how would your behavior change if you're exhibiting trust? So I use these kind of questions to get people to realize they have to move and to start moving.

And then of course, the other thing with people is go for the personal value, obviously. What's in it for me? And talk about the possibilities that the transformation presents to people in terms of a better life at work, and in terms of their own personal growth and opportunities to learn new things and to move on in what they're doing. And obviously, it looks good on the CV.

And then finally, there's the whole get on the bus. So if your organization is in the middle of this transformation, then you really want to be aligned with the future of your organization and of the industry.

Another thing that's powerful to move people on is to drop exemplars in. Find people who exhibit the behaviors and the skills that you want, and drop them into teams that need a bit of a hurry along. So either hire them in or move them from other high-performing teams into the lower-performing teams, but then hold them up as a model and point to them as the kind of behaviors you're looking for in the transformation. And even performance-review people against the exemplars was one of the things that came out of the interviews I did.

So leadership's important in terms of getting people to move, and it's amazing to me just how much a new leader can change an organization. Who's seen that, right? That in the space of a year, you can really see the impact of a leader, and it's always fascinated me how much that one person can make a difference in an organization, how quickly.

Unfortunately, one of the things I discussed with a couple of people is that the negative impact's easier than the positive impact. There's an entropy effect here, that a bad leader can do more damage in a year than a good leader can do repair. But nevertheless, a good leader can make a lot of difference in a year.

So a leader's role is to empower people to devise change and to reorg. And the other thing I counsel my clients to is: don't reorg too early. So we're very good, I think, as managers and leaders, in wanting to start with a reorg. And I love this phrase that... I forget who it was gave it to me, I'm sorry, but: reorg when the teams tell you to. Changing the behaviors, changing the way we work, and then allowing the teams to recognize the reorgs that are necessary, rather than using it as an instrument for change. Although we'll talk in a minute about sometimes we do.

So my consulting, I like to talk about that I do nudge consulting. And I think when we're trying to move people along, this idea of nudge is very powerful. Rather than beating them all the time with a stick, it's recognizing the opportunities, recognizing the moments when it's the time to give a nudge and to direct things in the right direction. And if that's done carefully and with good timing, then you actually don't need a lot of effort to trigger some changes in organizations.

So there's all sorts of potential nudges there, and formal reorg is one. So there are times when I would counsel a client to use a reorg as a way of moving people along. Although, in general, as I said, my preference is not to rush into it.

We can change the policy and rules that people are working by and how we measure them. We can deep-end people. So I watched a client who had infrastructure people who were very resistant to the DevOps movement. And so the CIO, they had a big internal infrastructure program going on within the infrastructure team, just paying down a whole lot of technical debt. So it was fairly low impact. It was all within IT. They were just upgrading a whole lot of gear. It was a $50 million project, and so he said, "Right, you guys, use Scaled Agile Framework to manage your project."

And all these infrastructure engineers were like, "I've never even heard of that. I know the dev people are doing it over there, but I haven't even seen it."

"And by the way, your first planning increment is in two weeks' time."

Right? So just deep-end them is quite... That was his nudge, and then he just disappeared off and left them to it to sort it out.

So nudge is a powerful mechanism. So work moves on. We need to move people along, and so getting them to move is part of the challenge. But the big thing of interest to me is making sure that once we get them moving, that they come along on the journey, that we get everybody safely through the transformation. And that might mean they exit, but we want them to safely exit the transformation. We want to look after the people as we go along.

So you know that old saying, you're either on the bus or you're off the bus? That's fine, but let's make sure no one goes under the bus, right?

So you've all seen this curve, the bell curve of people. And it's important to understand that there's a human rate of change. We can transform technology in an instant. We can transform process fairly quickly, in weeks or something. But people, the rate of change of people and of culture and of behaviors and of organization, is measured in years.

And getting management, especially senior management, to understand that can be very challenging. So driving this idea of a human rate of change and understanding that you will have these innovators and early adopters who are right on with anything new, and they're straight in and they're working the new way and they're enthused, and it's very easy to create the illusion that you're on the move. Whereas if you've got this great bulk of the majority who may be ambivalent and just talking the talk, but not necessarily on board, and you've got the conservatives who take a long time to understand and adopt new ways of thinking. So we've got to keep in mind this idea, and we've got to embrace the diversity of our people. We've got to not expect everybody to be innovators and early adopters. Just because they're off doesn't mean everybody should be off, and we have to understand that it takes time. It takes years to move a culture.

So patience is a word that I find myself using an awful lot in DevOps consulting.

"It's been weeks now, and they're still not..."

It's like, yeah.

Someone was complaining to me about some senior managers the other day, and I said, "Look, I set the goal that by this Christmas, they'll start echoing some of the language back to us. So the fact that we're not seeing anything yet, just chill."

We've got to set ourselves those sort of aspirations. If you want to shift a manager, then...

He actually said to me, "Which Christmas?"

So evolution, not revolution too, is another idea to keep in mind. The irony is lost on a lot of organizations that we're trying to move from big bang waterfall projects to agile iterative development. Hey, so let's do the move in a big bang way. It's like, which bit did you not understand about...?

So I think it's very important to make the transformation, to make the transition in an agile way. To iterate our way towards the new way of working, to increment our way towards the new way of working.

So Jason talked about how he has to constantly curb his passion. That he'll hare off and think that everybody's with him, think everyone's on the bus, and he'll turn around, there's no one on the bus. Right? And if you have to then turn around and go back and get people for a second time, to reboot that whole change initiative because you've moved too fast and you've tried to do too much at once. He said that it's an order of magnitude harder when you come back. They're like, "Oh, you again."

So we have to move in an iterative way, not only because we want to be agile, but also because we're giving people time to come along with us. So we want to keep them on the bus as much as possible.

So yes, we want to disrupt. Yes, we want to deep-end them occasionally and say, "You guys got to all go and use Agile," or something. But modulate that level of disruption. It's very easy for some senior managers to be really keen to turn up the disruption dial, right, and do a lot of damage. So we want to be very astute and subtle about how we use disruptive forces to move people, and make sure that we don't get ahead of them.

Give them space and time, and create safe spaces for people to have the time, where possible, to get on board with these new ideas. So in a legacy environment, you've got all these legacy systems that will be there for quite a while, and they provide safe spaces for people to keep working the way they did while they see and experience the new ways of working and slowly assimilate those.

Several of the CIOs I talked to talked about having to cycle back constantly. To be managing by walking around, to be checking in with the teams, to be making sure, modulating the pace of change to make sure that everybody was coming along.

You might have seen this model before, the Kübler-Ross. Someone used it in a presentation yesterday, I think, was it? And the key word in this one, in this conversation, is anger.

So one client, the first meeting I had with the guy driving the DevOps initiative, he was actually quite shaken because he'd come out of a meeting where people were shouting and storming out and slamming doors and lots of anger. And I said to him, "Jason, you've got to embrace anger. In fact, you should welcome it, because if somebody's angry, they've moved from total disengagement to negative engagement with you. But they are engaging. So they've started on that emotional journey."

So Jason, in another meeting later on, we walked out and he said, "When that person was being all angry, I looked at you, and you were just sitting in the corner smiling quietly, right?" And I was just sitting there going, "Anger. Good."

It's very easy when we see anger to despair and react angrily. Right? But if people are angry, see that as a good thing. They've started on their emotional journey.

And then ultimately, people blossom. And this is what gets me going in this whole DevOps consulting. This is the payoff for me personally, is watching people blossom as we transform. They start behaving as if they've got permission and empowerment to do things.

And suddenly, people that you think are the most negative of people... There was one DBA I can think of who, in a meeting, just said, "Oh, yeah, I've automated moving everything from the new integrated dev environment into the I-test. So now we can just do that by running a script." And he just dropped that into the conversation, and he was this really negative guy, and everyone just stared at him. It's like, where did that come from? But it was because he now felt empowered to do this stuff, like he wouldn't be mocked or slapped down for doing it.

And then people are victims of the system, right? So those release team, they're the problem. They're really negative and aggressive and bureaucratic, and they lock everything down. And as we change the system so that that release team isn't the last line of defense before production, who have this sewer of code flowing down at them. As we start driving quality into the code flow, and as we start shifting left and driving accountability left and fixing everything in the flow, suddenly that particular release team I'm thinking of go from being really negative, aggressive, bureaucratic, lockdown kind of people, to being people who are organizing and supporting the trains of work that we're flowing out, and are now active participants in the DevOps transformation.

Unreasonable systems create unreasonable people. And so there's a litmus test of what are they like outside work? There's one manager in another client who's frankly an asshole at work.

"What's he like outside of work?"

"Oh, at a barbecue, he's great. He's a wonderful guy."

And I said, "Well, okay, I'm pretty sure that we have a victim of the system. I'm pretty sure that he's in an unreasonable position, which causes him to behave unreasonably. He's not being his authentic self, because his authentic self is the one you see at the barbecue."

So people blossom. You take the system off their back, you give them permission, you empower them to do stuff, and it's amazing, people that you did not think had the potential change. And so the key about this slide is that you can't prejudge people. You have to wait to see what the transformation does to them to understand who is and isn't really coming along.

And I think organizations have a duty of care to the people who work for them. I think that's a pretty easy statement to make. So, as Scott said, we need to make work safe and healthy and eliminate the chaos around people so that they can be working in a place that they feel comfortable and happy to work in.

So we want as few people left behind as possible. We have this duty of care to make sure they come along. And it's interesting, the cultural differences. I won't go into it; you can make a guess. But in some of the CIOs I talked to, we're talking about, we'll lose as much as 5% of the people with the transformation. And others were talking about 20 or even 40% of the people falling by the wayside as we make the transformation. So obviously I prefer to be down near that 5% end of the dial in terms of people not coming along.

So management's role is to coach, develop, offer opportunities. So the whole servant leader thing, if you're not familiar with the concepts of servant leader and letting go of command-control and moving to servant leader models where we empower people to decide their own work and we support them in doing that. So coaching managers to be coaches and making sure they're supportive of the people. So they're on the bus with us, don't go underneath the bus.

And there's some managers who don't really care about that. And so it's important, I try and engage the HR department in every organization I'm in to make sure that they are an integral part of the transformation. And a lot of IT managers will resist that. They don't want those people in. But they will, in most organizations, have a lot more attention to the interests of the individuals.

And then it was really interesting, the bank, Westpac. I interviewed a number of people in Westpac, and they talked a lot about how they identified, supported, and welcomed those who don't want to come along. They actively said all through the transformation, "If you're uncomfortable with this, if you don't think you're part of the new way of working at Westpac, that's cool. In fact, those of you who stand up and say, 'I don't want to be part of that,' we thank you. We are grateful to you for identifying yourself, and we will give you huge amounts of support to help you to exit the organization. And we will do that as gently and as humanely as possible."

And that was interesting to me, because I've seen other organizations where it's, well, bugger you then, and quite aggressive about those who don't want to be on board. So I loved the way they said they make the exit graceful.

And then making sure that there's enough cultural change programs and staff training to ensure that there's inclusion and investment to bring people along. It's very easy, again, in IT, we race along and we focus on the engineering and we focus on the processes, and we don't necessarily focus on the investment we need to make in our people to bring them along on the journey. So there's a whole bunch of thoughts to you about the organization's duty of care to make sure we bring people along safely on the transition.

So to summarize, work's always moving on and we should already have that thinking in our culture, but we don't. That's something we need to teach people, not just in the DevOps context. But we want to make sure that we are protecting everybody in the transformation and not actually injuring anybody.

I wrote the Phoenix Project Simulation Game, if any of you have seen that, based on the book. And we reduced a change manager to tears one day in doing the... And it was quite upsetting for me. We had to do an intervention with the guy and calm him down because he'd just seen his whole world, everything he valued, crumble before him in the simulation game, and he was very distressed. Right? And so we need to keep an eye on that and protect people as we go along.

And then ultimately, let people blossom. Empower them, give them the permission, give them the space, give them the time, give them the safety so that they can get the system off their back, so that they can start behaving in whole new ways. And as I say, not everybody blossoms. There are some people that are beyond redemption. But it's amazing how many people completely change when you change the system in which they work.

So Gene likes us to finish with a couple of questions. And so the questions I'm still struggling with are, one of them is, how do you keep hope alive? So quite often in an organization, they're in this experimental phase and we haven't yet committed to the new way of working and doing the transformation, and we're still just looking at Agile and looking at DevOps and trying a few things.

And so I've got one client where I'm in that situation, where I'm driving all this awareness and this enthusiasm and people are getting all fired up, but the organization hasn't yet actually committed to a transformation in the way we work. And so the struggle for me, and the thing I'm interested in ideas on is, how do you keep those people simmering and keep them bubbling along until we do commit to a transformation?

And then the other big one is designing the transformation engine. The team who are the heart and soul of the DevOps transformation, the team who are driving the strategy and pushing the work and designing the future models or triggering the design of future models, that central group who are your DevOps transformation team, or whatever you want to call them. How do you design that? What are the different models for that? I've got a couple that I've tried myself, but that's my work, is doing that.

So if anyone's got thoughts on that, I'd be delighted if you contact me. So there's my email, or you can find me @theitskeptic, because that's my alter ego, is a blog that some of you might have heard of. So that's me on Twitter. But reach out if you've got any ideas.

Otherwise, thank you all very much.