Rob England

Good afternoon, everyone. Let's get started here.

I'm Rob England. As you can tell, I'm not from your country. I'm from New Zealand, and I'm a consultant there in Wellington, have been for 12 years. So I can't really tell you about my organization in the same way that a lot of speakers do, because my organization consists of me and Cherry here in the front row.

But I've been involved in strategic transformational consultation in the DevOps space for the last few years, and I describe myself as an anti-cryptoequinologist, meaning I'm interested in horses, not unicorns. So I'm working with major government departments rather than startups and so on. I'm a co-organizer of the Wellington DevOps Meetup, so I'm involved in the community. I'm an instructor with a whole lot of courses around this space. I have a blog called The IT Skeptic, which is how I'm networked in with this community. So probably about three people in the room have heard of that blog.

But there were some nice torrid debates in the early days of DevOps with people like John Willis, and Gene used to be very polite until I finally got it.

And I'm not a tech anymore, so I've had the technology surgically removed. I did see Jenkins once, so I think that qualifies me as knowledgeable in the space. But that's the area I'm operating in.

So I'll start with an apology. I've got 20 slides and 30 minutes, so I'm breaking the first law of speaking there. But I did want to give you an overview of some ideas to take away in this space, because it's one I'm very passionate about, which is surviving DevOps, getting people through that transformational journey, and making sure that we get people through the other side.

So this is feedback from a number of organizations. I've done a large amount of work with the Ministry of Social Development in New Zealand, and those of you who were here last year, one or two of you will have seen David Habershon present from the Ministry.

Did anyone go to that presentation? There's one hand.

But it's on YouTube. He did an amazing presentation about what the Ministry has achieved, and it is extraordinary for a government department. I'm very proud of them.

And I'm now engaged with the taxman in New Zealand as they are starting on a similar journey. I've also had a lot of discussions. A number of you will have seen Davy Olivier on Monday presenting from Westpac.

A few people go to that one? A few more? Yeah.

So Davy's a very inspirational leader, and I've had many conversations with him and with Dave Corlett and some of his other key people. And then I also had the opportunity, thanks to introductions through Gene, to talk to Scott Prugh, who's here today, and to talk to Jason Cox at Disney and to talk to them about some of their experiences on this journey and get some feedback in the American context.

So they're the main primary sources of my thoughts for this, along with a few thoughts of my own that I've created along the way.

So this is also about my own personal journey, because this is me two years ago, and as you can see, this is me now.

I come from a service management background, and I was consulting in ITIL and things like that for a long time. And at a major ITSM conference in February this year, I got up in front of a couple of audiences and said that the difference between ITIL and DevOps is that DevOps works.

You could hear the ripple go around the room, right? I then quickly unpacked that statement, but I am finding that I've transformed my own thinking and my own behaviors as much as I'm engaging in that journey with my clients. And that's been very rewarding and exciting for me.

So what I want to talk about is what Gene Kim calls humane IT, right? This concept that, or for me, there's three principal outcomes we're talking about here.

We want to lift everyone. We want to take everybody on the journey. And for those who don't choose to come along on that journey, we want to treat them with dignity. We want to exit them gently from our transformation.

And along the way, another thing that has been an observation of mine over the years is we don't want to avoid waste of institutional knowledge and expertise. So we're really good at getting impatient with people or underestimating people, or frankly, having a contempt for people, and pushing out of the organization great lumps of really important institutional knowledge that we should have retained in the organization.

So for me, they're the three key outcomes I'm looking for with this stuff.

So I'm going to talk about two things. I'm going to talk about how everything is moving on and how we get people moving on. And then, as we catalyze that movement, how do we bring everybody along with us?

So our work is changing, and I talk about this being the IT Renaissance. I think this is the biggest transformation in the 30-something years I've been in this industry, and easily the biggest transformation.

So there's a lot of change going on at the moment, but change has always been a function of this industry, right? And every role has changed in the last decade and in the decade before that and so on. It's always been a necessity for us to move on, but now more than ever.

So you can look back to history and see the same cycles going on and on through history, that every job is a high-status job with super-qualified people that gradually gets commoditized and then eventually gets automated or otherwise obsolescent and disappears completely. And whether it was steam engine drivers or typists, lift operators, or all of our technology roles, they go through this cycle.

And so the cycle is getting faster and faster. And anybody who feels comfortable in one specific role and thinks they're going to live out their life doing that one role is in a bit of trouble.

So we've always had this necessity to learn and move on, but the pace of that is accelerating.

So, a few things I'm going to leave you with is things like I have a set of questions that I like to put to individuals and to managers to get them thinking about the necessity to move. Remember, I'm talking about horses here rather than unicorns. Unicorns, they're already moving at blinding magical speed. But in horses, just getting some movement started is one of the big challenges.

So these are some good questions, and I won't run through them all because you'll get the idea. But having these basic questions that you can look at people and say, "Answer me this," and create that sense of perhaps a little discomfort and greater awareness of the necessity to move.

A second factor that's powerful in getting people moving is, of course, what's in it for me and talking to them about the individual necessity to move. And so I talk about a better life, a better day at work. I talk about the opportunities for personal growth.

For people who work in horses, we're opening up huge new vistas where they can study and immerse and learn new things. You'll notice I left technology off there. That's an unintentional mistake from my own biases. But you could put a fourth bullet on there, that there's these huge areas of technology people can immerse in.

But I think there's also all these ideas around studying Lean and Agile and transformational leadership for the leaders and so on, where we're opening up whole new areas of thinking for them and new spaces where they can grow.

Then there's it looks really good on the CV, of course, and its alignment with the future. So painting this picture for people that this is not a new way of working, but it's the new way of working. And even if you choose not to get on board in this organization, sooner or later, everywhere you go, it's going to follow you.

Another powerful tool for getting people moving is exemplars. So hiring in or dropping in people who exemplify the behaviors that you want in that team. And so when you're doing performance reviews and so on, you can just say, "Be like Bob." And when you're sitting down with people, "How should I be doing it?" Well, that's pretty easy. Here's a person who exemplifies what we want from the team.

For the leaders, this is a big issue at the moment. We were just talking about this at lunch, that I think there's a... I'm seeing a lot that tells me that right at the moment, this is one of the most pressing issues we're dealing with in the DevOps sector, is this understanding that you can get the people moving and you can get the executive buy-in, but getting all the leadership to move is actually one of the really hard problems.

They're like, "I get it. Go and fix the people, but I get this stuff." And you're sitting there thinking, "No, you don't." Right?

So coaching leadership on the need that, in order to effect change, leaders have to change. And coaching them on that necessity is an area of fascination for me at the moment because it's a pressing issue in both of the clients I talked about that I'm consulting with.

So at the highest level, I'm intrigued by the way that a leader, the highest leader, can impact a whole structure below them so powerfully. I think everybody's probably seen that. And I've also seen that they can have a negative impact much more easily than they can have a positive impact. It's easier to chop a tree down than it is to grow one.

And so leaders who have a positive impact are treasures to be cherished, their ability to lift up a team. And then driving these behaviors into leaders to empower teams, to turn up, be present, and to understand that you let the people who do the work design the work are, to me, key areas of coaching for leaders to bring them along on that journey.

There's a strategy that I use myself in my consulting. I talk about doing nudge consulting, and I think this is a powerful model for DevOps product owners or DevOps leaders, or whatever you call them in your organization. I'm always coaching those people, the people empowered with driving the transformation in the organization. I'm always coaching them to a nudge strategy, meaning don't try and get involved in everything all the time because you'll kill yourself.

Understand the overall movement and look for the opportunities to intervene and nudge and push in a new direction just at the right moment with the minimum of effort. And so there's a whole lot of areas where we can apply a nudge to an organization to get it going.

And one of the CIOs I work with is the master of... We had the acronym yesterday, which we also use in New Zealand, which is JFDI: just do it. So he's the master of the JFDI. Every now and then he'll come out with a management decree and he'll just say, "Do it. We're going to do this." And everybody runs around going, "Oh my God, oh my God, oh my God." And some things happen.

So you can overuse it, but he's the master of it. These are a number of strategies that can be used with discretion and not overused, but there are times when you just need to give things a little push. And if you master that art, then you can actually minimize the effort necessary to keep the momentum of change going.

So if we get people moving, then now we need to bring everybody along. I like to say, there's that old saying, "You're on the bus or you're off the bus." Fine, but let's make sure nobody goes under the bus. So let's make sure that we either bring people along and don't leave anyone behind, or we gracefully and with dignity exit people off the bus, and we don't actually damage anyone, break anyone in the process.

And that's important. My very first slide, the most important thing in this space, something that I'm constantly coaching to clients, is patience. There's a great deal of, "We're going to go this way, and we have to move at this great velocity, and we need a quick transformation," and so on.

Well, that's great, but the human rate of change is measured in years. It's not measured in weeks or months. And in IT, we can drop software so quickly, we can even change practices and processes so quickly, but I think we lose sight of just how slowly cultures change.

And so there is this normal distribution of humans that says that you've got all the fizzy innovators and early adopters at one end of the curve, but you've got this majority, this mass that moves more slowly, and you've got, they're sometimes called the laggards, but that's very pejorative. I like to say the conservatives at the other end of the curve who take a while to get their heads around this stuff, right?

So it's really important in terms of respect for our fellow workers that we embrace the diversity of rates at which people can change their thinking. Those conservatives perform an essential role in the organization to put the brakes on some of the more wild ideas as some of the others, right? And to test ideas, and to test ideas under fire, and really test the strength of new ideas.

So one of the nice things about working with horses is that you've got all this legacy. And if we're going to change, let's change, we'll see in a minute, in an Agile way. So as change rolls through the organization, there are old areas of the organization that survive for quite a long time. And so we often have the opportunity to kind of park people or leave people alone for a while while we transform over here.

And it's really important, I think, to do that, to give people the opportunity wherever possible to have the time to get their head around what's going on and to absorb those new ideas.

Then the second key thing, I think, in this space is evolution, not revolution. It amuses me where there are some organizations in Wellington that have chosen to move to new Agile ways of working in a big-bang, waterfall way. And I kind of wonder which part of the story they missed in doing that, right? And I choose not to work with those.

The whole point is that we should evolve and iterate our way into the new ways of working in that very way, in an Agile way. So it's really important that we go forward incrementally and in an exploratory way.

I'm having a bit of a challenge with people saying, "Tell me what it looks like in two years. Tell me what the operating model is. Tell me when we'll see the defined benefits." And it's like, we don't know. I don't know. I can't tell you what these 600 people are going to do and what they will look like in a year's time. And anybody who can tell you what those 600 people look like in a year's time, you need to walk them out of the building because they're just making it up, right?

So we must evolve forward in an Agile, iterative way.

A deep part of this, another deep principle related to that, is that DevOps is hippie, man. As you saw, I grew my hair solely to be a DevOps consultant. And because I'm trying to communicate this idea that DevOps is different, and I'm starting to be called the DevOps hippie around Wellington, right? This crazy guy who goes around waving his arms about.

Because at its heart, the bit of DevOps that gets me juiced, that gets me really excited about it, is the humanity of it as a movement, right? Is the return to the values that we're actually trying to make people's lives better, as Gene says, right? We're trying to make people feel good. There's a lot of peace and love in this stuff.

But also, there is that hippie thing of being a little bit subversive and challenging the orthodoxy. So all of those aspects, to me, really excite me about the whole thing.

Related to that is this idea of there's a certain antithesis to the big corporates in the DevOps movement, isn't there? And the whole ideological thing about open source and stuff, which of course is actually a little silly because the big corporate solutions have real value and a real place in the whole model. But we do embrace these ideas of making it easy to get involved, of openness and accessibility and inclusiveness and so on.

So this is a real challenge for horses. The previous thing about, "We don't know, man. We'll tell you when we get there, and it's a journey, man." They struggle with that. The old-school managers and the senior executives really struggle with that conversation.

We went along to a sales opportunity recently where an old colleague of mine was trying to engage us to come and help with DevOps. And pretty much the conversation got down to, "Tell us what you're going to do, tell me how many weeks it'll take, and how much money you want. And what will be the outcomes?"

And I said, "Well, I'm not going to do that. I don't do that anymore. If you want me to write you some bullshit business case, then I will, but you'll know and I know that it's theater, that I'm just making it up. I can't tell you what the outcomes will be, how long it'll take, and what it's going to cost."

And actually, boom, we didn't get that engagement.

But as we walked out, I said to Cherry, I said, "It's a win-win. Because if he buys that, I want to work with him, and if he doesn't buy it, I don't." Right? So there's a whole new movement afoot.

So we want to make sure we get everyone on the bus if we can. There's some key things that I got from talking to these leaders around being careful to modulate the level of disruption. You can over-disrupt and just alienate everyone. You can run ahead of the team.

So several leaders said to me, "We all got on the bus and all the innovators got on the bus with me and we were all excited, and we started the bus and we drove off, and we turned around, there was nobody on the bus." Right? "And then we had to sort of cycle back and gather up all the people we'd left behind."

And one of the earlier quotes from Jason says, "When you have to reboot, it's 10 times harder than the first time you got everyone on."

So it's important to not actually rush off ahead of the group, and make sure they are actually on the bus. And then, like I said before, give them space and time as much as possible to think and to absorb and to understand that not everybody are innovators and early adopters.

So you're constantly checking back to make sure they're on board. And Davy said to me that pretty much everything he did through their one year of transformation was just him cycling back constantly. While his lieutenants did all the actual effective driving of the change, his role was to just keep making sure that everybody was coming along.

So you have to even modulate your passion a bit and understand that you're one of the innovators, you're one of the early adopters.

So something that I won't talk about in the interest of time, but everyone aware of All Day DevOps, the recent 24-hour conference thingy, right? So I presented on All Day DevOps, and I talked about exactly this topic, the lizard brain, the deep emotional part of your brain, and the need to appeal to people at a lizard level, as well as at an intellectual level. So there's a whole presentation on that if you just want to go and look at All Day DevOps.

Another key thing to remember, I think, in getting everybody along, and I've coached on this several times, is that anger's good. We like anger.

So one of the DevOps owners that I'm working with got really distressed at some of the waves of anger that he was dealing with. And I talked about this curve, which you'll all be familiar with variations of, and I said, "When somebody's angry, they're engaged. They're already on the emotional journey. They're engaged negatively, but they're engaged. That is so much better than disengagement. That is so much better than complacent status quo."

So once they're angry, we're engaged, and now we just have to get them through the rest of the journey.

And we were in a meeting, and as we came out of the meeting afterwards, there'd been a whole lot of anger, and he said to me, "I saw you sitting in the corner smiling. You were enjoying that."

And I was like, "Yeah." Because he understood that I'm happy to see anger. Well, you know what I mean.

Another key thing to remember, I think, is it's very easy to dismiss people. It's very easy to say, "That person is a negative person. That person, I don't like their behaviors. They don't get it." And we've got to keep reminding ourselves that people blossom. Right?

And people are victims of the system. So unreasonable systems create unreasonable people. And I'm constantly being told, "Oh, that person's an asshole." Right? And especially people in change and release, right?

But the reason for that is because change and release in a traditional system put people in totally untenable, unreasonable positions. Right? Where they're faced with a deluge of low-quality work and they're the last line of defense between that and production. And no wonder they behave in negative ways, because they're also quite often held accountable for the low quality of the things over which they have no responsibility.

So as soon as you change the system, lots of people change their behavior. Some don't. They're just assholes. But the question to ask is, what are they like outside of work? And quite often I'll say, "What are they like?"

"Oh, they're really nice at barbecues," because New Zealand, right? Or at the pub. But at work, they're terrible.

Well, perhaps you should consider that they're a good person caught in an unreasonable system.

And the other thing that makes people blossom is this feeling of permission, of empowerment. So they're sitting there. What was that quote yesterday? "I thought that drudgery and pain were normal."

They're sitting there in this world of drudgery and pain, and so of course they're not doing interesting, innovative things. But the moment you start giving this message of hope and this idea that they have permission to experiment, they have permission to innovate, that it's safe to try things, and that they're not going to be whipped for failure, then people again blossom. They come out and go, "Wow, I'll have a go."

So don't dismiss people unnecessarily and thereby waste all this institutional knowledge that you're just throwing away.

So we also, of course, I would remind you, have a duty of care to these people. These people work for the organization, and they're loyal to the organization, and the organization should be loyal to them.

So we want as few people left behind as possible. We want to make sure that as much as possible, we bring the existing people along as members of our community. And so management's role is to coach, develop, offer opportunities, and, as I say, don't waste skills and knowledge where we can help it.

The interesting thing, and I've heard this from all the leaders, but particularly at Westpac in New Zealand, they talked about honoring and respecting the people who put their hand up and said, "I don't want to get on the bus." And so they made it really clear that if you call it out and say, "I'm not part. I've tried. We've had a few months and I'm just not on this journey," we will respect that and we will honor that, and here's all the things we're going to do for you to exit you gracefully and gently from the organization.

And we're going to help you in every way possible because we thank you for having the courage and the honesty to say you don't want to get on the bus.

And that's different from a lot of organizations where it's, "Well, bugger you then. You're off." Right? And so it's having that approach, I think, is very powerful because then the people, they don't stay on board as a little source of poison. They see it's okay to get off.

And sure enough, cultural change programs and staff training, so make sure there's every opportunity for people to change and blossom and grow.

So the key things I want you to take away is that you've got to get this message out that work is always moving on. You never have the opportunity to sit in a role for a long period of time in our industry. And now more than ever, it's really moving along. We've all got to reinvent.

A model I use for one of our clients who is... They're telling everybody, "We're going to drop staff numbers over the next couple of years. We are going to reduce numbers." And so when you've got that kind of overall strategy in the organization, then, again, duty of care, I find it really important to say to people, there's going to be a sorting hat. Right?

And the sorting hat is going to be, who are the people who are already reinventing? Who are the people who are exhibiting the behavior of being willing to reinvent themselves?

And so getting that message out to people that work's always moving on, and in the interest of your own preservation in this industry, you need to be constantly reinventing yourself. In horses, they haven't always had that message. Right? One of my clients, the average age of IT is 54. Right? So they've been sitting there for a long time doing pretty much the same thing, and getting this message through to them is important.

Make sure that they can be on the bus or off the bus, but we get them off the bus safely and carefully, and then let people blossom. Understand that when you give them the opportunity, and when you get the system off their back and change the system to a better system, that people you never expected...

I've got some wonderful anecdotes of people that everybody had written off as a little ray of blackness, just completely transformed themselves into some of the most energetic, enthusiastic, positive champions of change.

So we end with some questions that we could use some help on, and mine are a couple of real doozies that I'd really welcome feedback from people on.

How do you keep hope alive until the organization feels ready to change? Right? So I come in as the hairy hippie, and I do the yah-yah DevOps, and everyone goes, "This is fantastic. Are we doing it tomorrow?"

And I'm like, "Well, no, we're still in an exploratory phase, and management will consider the..."

And so it could be 12 months before a great big horse organization says, "Right, we're going to commit to a new way of working." So how do you keep hope alive in that intervening space? And I do run experiment programs where we foster experiments in all the teams to try and keep that energy going. But I'm interested in any other feedback on that.

And then the big one for me is, what are the patterns or models for that transformational engine? For that inner circle, that owner, that group of people who own the transformation through the organization, who are the driving force of it. What are the best ways of designing that group and their structure and their ways of working and their practices? Because I've tried a couple of things and they work, but I'd sure like to know that I understood all the practices in that space.

So there's where you can contact me. Also, The IT Skeptic blog can be found if you just Google it, and thank you very much.