Our Product Manager, Ed Pearson, talks at WinOps 2018 about how to survive a DevOps transformation journey, & highlights some common mistakes made by organisations.
Date: 16th November 2018 | Duration: 44.51
How cool is this? I get to stand up in front of you lovely people and talk about DevOps. It’s that cool I’m going to take a picture of you all. Right. Get a smile. Cool right. The real reason for the picture. Anybody who leaves during the next 45 minutes I will hunt you down!
So first thing an apology or more of a clarification. The talk is titled Surviving a DevOps journey, probably the worst title I could have come up with. Because if you’re in the middle of a DevOps transformation, or a digital transformation, and you’re seeing it as a journey that has an end. You’re doing this wrong.
The idea of a DevOps transformation, or a digital transformation, is that we’re trying to build organisations that can react to changes in the marketplace. That are agile and are able to transform and continue to evolve as the marketplace and the environment that they’re operating in change. So it’s a dreadful title. I do apologise. I’ll try and come up with something a little bit more accurate next time.
In terms of questions, happy days. If anyone has any questions feel free to interrupt me. We’ll see how we go on answering them. I’m conscious that not everybody’s overly comfortable putting the hand up in an environment like this and answering questions. I’m on Twitter. My DMs are open. Feel free to send me any questions you have during the talk. When we get to the end we’ll have a look and hopefully answer the questions. This serves two purposes. For anybody who’s on the introverted end of the spectrum, it gives you a safe way to ask questions. It also means that when I stand here and I look out and everybody’s sat there on their phone I can kid myself that you’re all sending me questions and not just surfing Facebook or whatever.
So as was just mentioned my name is Ed. I’m a DevOps product manager at the DevOpsGroup.
Three parts to today’s talk. I’m going to start off with a bit of an introduction to DevOps and digital transformation just to make sure that we’re all on the same page. And then the bulk of the talk is 18 months in digital transformation. What are the five key things that I’ve learned along the way that I wish I’d known when I started off on that journey? Then to wrap things up some personal notes and some takeaways which hopefully will make things a little bit easier for you.
So, DevOps is changing the world. We’re living in an unprecedented time at the moment. Technology is evolving as quickly as it ever has. Organisations are responding to that. If ever you do a talk like this and you Google how to give a good talk the first thing they always tell you is to start with a story. All good stories start in the pub.
So once upon a time in a pub about 140 miles back down the M4. I’m sat there with my wife. It was March of this year and it was snowing and the weather was foul and the dog was grumbling and wanted to go home. We started having this conversation about basically how grim it was and what we really needed to do was go on holiday.
So one thing led to another. And out came the iPhone and out came Airbnb. Over the course of the next pint, we had found ourselves this lovely villa in Croatia. We’d booked it. We figured we better try and work out how we’re going to get there.
So still in the pub, still enjoying a pint. We booked ourselves some flights on EasyJet. Then had that clash of reality going I’ve booked myself a holiday. I should probably book some annual leave. So logged onto PeopleHR. Booked myself some annual leave. All is good with the world. A little bit of parking to make sure that we can park at the airport. Then given that this was a bit of a whim, a little bit of travel insurance. Just in case we need to cancel this at the last minute.
So we’re sat in the pub. We spent an hour. We had two points. We spent a small fortune but at least we now have something to look forward to in the summer.
So fast forward a couple of months. The sun’s now shining. We’re heading off to Croatia in a couple of days and suddenly you get that realisation you don’t quite have all of the things that you need to go on holiday. But don’t worry because Amazon Prime has your back.
Then we may have neglected, because we booked this in the pub, to book a hire car. But we found a nice online place that lets us do that in a couple of minutes without too much drama.
So everything unfolds as you would expect. We get to the airport, we park. We get ourselves out to Croatia. As we land, we turn on our phones and we get a WhatsApp message. So we booked through Airbnb. Brilliant host on Airbnb. I would share her details and the villa but frankly, I don’t want anybody else to know about it! But we got a WhatsApp message from her which basically said don’t worry about waiting until 4:00 to check-in. Come straight across the island now. You can check-in when you’re ready. But before you come you probably want to go to the supermarket first otherwise you’re going to come all the way to the villa and then basically go all the way back to the airport.
My knowledge of Trogir is not that good. So I have no idea either where the villa is or where the supermarket is but not to worry because Waze has your back. So we get to the supermarket. We do our shopping. We pay on Monzo because frankly why would you go and change money before you go on holiday these days.
And by this point, we’ve been travelling for about twelve hours. The kids are getting a little bit grumpy but somebody packed the Amazon Fire TV Stick. And remembered the password for Netflix.
So it gets to the evening. The kids are settling down watching the telly. Myself and my wife, we head out to the hot tub, which is overlooking the sea, with a bottle of beer. And this cunning notice that actually this hot tub has Bluetooth speakers embedded in it. So quick google to find the model of the hot tub. Download the instructions to figure out how to connect your iPhone to it. We can sit in the hot tub looking out over the sea listening to Spotify. Life feels pretty good at this moment.
We spent a week in Croatia. We went to a lot of restaurants. We ate out a lot and when we did it was TripAdvisor that told us whether or not it was a half-decent place to try, or whether we should avoid it. And when I got tired of driving because frankly it is a wonderful country but the driving does leave a little bit to be desired. We had Uber to get around.
So for anybody who says that DevOps is not changing the world. The view from my hot tub following a cold wet March evening in Cardiff would beg to differ. So the world is changing. DevOps is changing the world. But what actually is DevOps?
We have a definition that we use, as I think most consultancies do. So when we talk about DevOps we talk about a set of patterns and practices and behaviours that are correlated with high performing I.T. teams. It’s a bit wordy. So what does it really mean?
So DevOps is the way that as organisations delivering products and services we are able to deliver with both speed and stability. All of the evidence now tells us that these two things are no longer a trade-off. That the slow and safe model of delivering software into production is behind us. We’re operating in a different world.
So we can expand on that a little bit and we can talk about DevOps. It’s the art and science of high performance I.T. And what I really like about this definition is we talk about the science of DevOps. That this is a technology-led initiative but it’s also an art. We’re dealing with people. There are lots of cultural elements to this and we don’t have all the answers. This is a constantly evolving discipline. So for me, this really sings to what DevOps really is.
And the purpose of this introduction is really to get us to the point where we understand that organisations need to change. And it was John Kotter who I think sums this up probably the best. When he talked about how the hierarchical structures and organisational processes we have used for decades to run and improve our enterprises are no longer up to the task of winning in this faster-moving world.
If you have an organisation or you work for an organisation that’s still working in the same way that you worked ten or 15 years ago and you’re trying to compete with young fast-moving upstart companies that don’t carry that legacy of technical and organisational debt then you’re not going to succeed. This problem is not limited to those industries that you might traditionally expect are being disrupted.
There was a report that came out of IDC earlier this year. Where they started to try and map which industries were being disrupted by which organisations. I love this slide. Our marketing team lose their minds a little bit when you put it out because they go nobody’s going to be able to read it. People at the back can’t read the slide. That’s kind of the point. There are so many companies and organisations disrupting so many markets that actually you can’t get it legibly onto a slide. And this really is the tip of the iceberg. So what do we do about it now?
So the answer to surviving this level of disruption is DevOps. There are lots of organisations now talking about digital transformations. I’ve been lucky, I think, to have been involved in one for the last 18 months. And over the next 30 minutes or so hopefully will go through five things that I wish I’d known.
So the first thing that I think is probably the most important thing to a digital transformation is the role of leadership. So quick show of hands how many people here consider themselves in a position of leadership within an organisation? OK. So 10 percent maybe.
I love this definition of leadership. It says if your actions inspire others to dream more, learn more, do more, and become more, you are a leader. And one of the things that are really important when we start to talk about leadership within a transformation is leadership exists at every level of our organisation. So it’s not defined by our org chart. It’s defined by this statement. By the way that we’re interacting with our colleagues and the teams around us. But why is leadership so important?
So for anybody who’s had the misfortune to hear me speak before, I’m a big fan of DORA and the State of DevOps Report and the research that comes out of the US every year. And talks about how DevOps is affecting the industry. They give us this diagram, once a year, which maps out the things that drive high performance I.T. and organisational performance. And the one that I just wanted to shine a light on, quite literally, is transformational leadership.
So what this actually shows us is that we know that DevOps as a set of patterns and practices is reliant on lean management and technical practices around continuous delivery and continuous integration. But what’s really interesting is we can’t have any of those things without transformational leadership. It really is the thing that underpins digital transformation and high organisational performance.
So it’s important. But when we talk about leadership what do we actually mean?
I think if we’re going to talk about leadership we need to talk about what is the foundation of good leadership? And for me, this comes down to two things. This comes down to courage. And it was Brené Brown who, I think, summed this up really well. She talks about in this day and age if we’re going into to work in these organisations that are being transformed and to use her words not mine. You are going to get your ass kicked. It’s not a case of if, it’s a case of when. This is hard you’re going to get knocked down. Courage is going into a situation knowing you’re going to get your ass kicked but you will get back up and keep moving forward and take that team with you.
And humility I think goes hand in hand with that. So we’re moving we’re operating in a complex world. Traditional command and control management really doesn’t cut it. We need humility in our leaders. We need leaders who accept and acknowledge that they don’t have all of the answers and are prepared to push the decision making to the people with the most information. So as a leader, you need to be able to put your hand up and say I do not know. But we’ll figure this stuff out.
So if we take humility and courage there are five pillars of transformational leadership which came out of some research which was conducted in 2004. I think they are as applicable today as they were when they first came out. So the first one here is intellectual stimulation. This encourages people to see changing environments as opportunities for growth and development. So what we’re really talking about here is we’re talking about promoting that growth mindset in the people that we work with.
The second one is vision. So a leader should have a clear vision of where that organisation or team is heading. And I think that’s a really important distinction. And we’ll keep coming back to that idea.
Personal recognition. Praises and acknowledges the achievement of goals. I think we’ve all sat in those meetings before where that manager, to differentiate from leader, has taken credit for the decisions that you made, or the work that you did, or the direction that you helped to shape. Transformational leadership is not about that. It’s about offering personal recognition where it’s deserved.
Inspirational communication. Transformational leadership is about being able to communicate with our teams and take them on that journey with us.
And finally supportive leadership. So these are leaders that demonstrate care and consideration of followers needs and feelings. So really caring about the people that are in your team and helping them to bring their whole selves to work. We’re asking people to operate in a really difficult environment when we take them on these transformation journeys. So how do we make that safe and be supportive of them?
I think if you take those five pillars and you have a foundation of humility and courage you have transformational leadership. So that’s all right in theory. But what does it actually look like in practice?
So I thought I’m at a Windows-centric conference. If you’re going to talk about leadership. There’s probably only one person that I could think of to talk about. So for anybody who doesn’t know who this is, Satya is the CEO of Microsoft. He’s been in post for a few years now and I think it’s fair to say has revolutionised the organisation. I say that as somebody who started out back in the day as a classic ASP VB6 guy. In the not so good days when Microsoft was certainly not the cool tech giant to be pinning your colours too.
Is anybody here familiar with a product that came out Microsoft called Tay? Yeah. Couple of hands. Okay, so Tay was an AI project at Microsoft. The idea behind Tay was that it was to improve human and computer interaction by providing a way for computers to interact in a human-like way.
It was a really interesting project. It was actually a bot. The mistake that I think Microsoft probably made was the data that they were using to train this AI bot was Twitter. Which is pretty much the cesspit of humanity in terms of moderate views and such like. So basically Tay was launched and within 16 hours was quickly taken offline as it turned into a racist homophobic bigot.
But what you need to do when we talk about this story, which is quite funny unless you happen to have been the product manager behind Tay or one of the developers working on that team. You’ve not just hit the front page of Reddit. You’ve not just been Slashdot. You’re now New York Times, BBC, Guardian. This is not just the Reg having a bit of a snide dig at the fact that you’ve kind of cocked up. This is front page news. You go into work the next day thinking writing could be on the wall. I wonder if Oracle are hiring. You get into work the next day and you have an e-mail in your inbox that says this. It says keep pushing and know that I am with you. The key is to keep learning and improving. That is transformational leadership. That is a CEO who has the back of his teams.
When Satya was pushed on this he went even further. He said this; it is crucial for leaders not to freak people out but to give them air cover to solve the real problem. If people are doing things out of fear it’s hard or impossible to actually drive any innovation. So it’s quite a high-level example. We talk about leadership. We’re talking about the guy who runs one of the biggest corporations in the world.
The question I think you need to ask is what does leadership look like in your organisation? So this is probably my favourite slide because during the transformation that I was working on I had a real pleasure to work with an engineer whose name is Nathan, and he actually sent me a message last night to say that I was allowed to use his name. So I’m really really pleased about that. So Nathan had been involved with us, with a client that we’re working on. We spent probably six months, maybe a little bit less, doing some engineering work there. Which was all about proving the art of the possible. It was all about getting features to that MVP state.
For any engineers in the room, you’ve probably all been there. We got to MVP state and they were like we now have a bucket load a technical debt that we need to sort out. Plus all the legacy technical debt that we inherited. What we needed to do was we needed to try and find a way to get this team to focus on the right things that actually meant that we could start moving forward at a sustainable pace.
We ended up with a meeting which was about 15 engineers, all fairly seasoned and grumpy and opinionated as some engineers are. None of none you obviously. The meeting was set up by one of the scrum masters. The idea was we need to come up with our strategy for resolving technical debt going forward. It was quite an uncomfortable meeting because we were really trying to hammer home to people that we needed to start addressing some of this technical debt. It was really interesting that it was Nathan who took control of this meeting.
We actually got this e-mail from one of the people in the meeting that said; Nathan took the lead from the start and kept everyone on task. We did have a few points of contention across teams but Nathan patiently explained his perspective each time. He was uncompromising on our goal of improving quality but pragmatic and open to others ideas.
It’s kind of what you’d expect from your senior engineers or your lead engineers. This guy was three months out of college. He was a long way off being a senior engineer. But for me, he exhibited all of the qualities of leadership that we expect to see in people many years his senior.
We’ve got Satya at one end of the spectrum. We’ve got graduate engineers at the other. There’s this perception that the leaders are born and some people just have these innate leadership characteristics.
It was Vince Lombardi who said leaders are not born they’re made. What we need to do is we need to try and work in organisations and create a culture where we can cultivate people. I’m going to illustrate that with another story of somebody who I was very lucky to work alongside with the same client.
So young lady on the screen is an intern who joined us back at the start of last year named Charlotte. She originally came in as part of an engineering team. She had a real aptitude for coaching and during her time with us, she pivoted into a coaching role. Following on from a period of training and mentoring we actually unleashed her. I don’t think would be an unfair phrase. Into one of our internal teams that were trying to get to grips with some of the Agile ways of working.
What was really interesting for me was when Charlotte left to go back to university, the team actually asked us if we had any more agile coaches that we could backfill her with. Such was the impact that she made on the team as a result of being in that environment that coaches and mentors and grows people into those roles. For anybody who’s met James Harvey, who is our Head of Academy, will not be surprised that he wanted to get a name check but this was the feedback we got. I think what’s really important is leadership exists at all levels of our org chart. Anywhere in our teams. We just need to give people the opportunity to unlock that potential.
So leadership for me the most important thing. The next thing is about creating a vision. So any transformation, any change, start with a vision.
The key here is to create a vision for your context. There weren’t that many people in the room who put their hand up when I asked them if they would consider themselves leaders within their organisation. So I’m going to suggest that I don’t have many CEOs here who are setting organisational strategy. This applies if you’re a CEO setting organisational strategy or you’re a team lead within a cross-functional team. Or whether you’re simply a member of a community practice or a community of excellence. This still applies. It’s still possible to drive organisational change by starting with a vision.
And what we need to do is create that North Star. It’s not all about telling people how we’re going to get somewhere. It’s telling them where we’re trying to get to. What does good look like? Why are we going on this journey? Ultimately what we are trying to do is create this sense of excitement. Change is hard. Digital transformation is really hard. But if we get people excited about how good their life will be when we get there you’ve got the makings of a successful transformation.
Because the reality is most people get scared when they can’t see what the future holds. They don’t need all the details. They just need to know where they’re going and how their job will be better when we get there. So there are lots of ways that we can help a vision to flow down through an organisation.
Because what we ultimately need to do is we need to take that vision at the top which is the organisational or team goals. And somehow we need to try and connect that back to the work that people are doing on a daily basis. If we can do that, getting people to make those fundamental changes to their ways of working, or their technical practices, becomes very very easy.
One of the ways that we use, and I’ve used with clients and I really like, is to use a methodology which is called OKRs. It stands for objectives and key results. And what it allows us to do is take that top-level vision and actually tie into the work that people are doing on a daily basis. The best way to illustrate this is an example.
So we’ve got a typical org chart here. At the top of the organisation, we’ve got our CEO and down the bottom here we’ve got individuals, or maybe small teams of people. And potentially some teams or some departments in the middle. The way that OKRs work is that they allow the person at the top of the organisation to define a destination, to tell you where they want to get to, and how they’re going to measure it. How do we know that we’ve got where we’re trying to get to? Through the dotted lines, as we flow down the org chart, the implementation is decided at the next level down. So this is not a command and control approach. This is very much a strategy and vision.
So if we started off by saying that we’re a software company and we sell pet food. We want to be the number one online supplier of organic pet food in the UK. This is our CEO. Three months. This is where we want to get to. And I will know that we’ve got there if we get 38 percent market share. Go.
So now you’ve got some poor product team going oh 38 percent. Well, we reckon if we provide an excellent customer experience we can get to 38 percent market share. We’ll know that we’re providing excellent customer service if we increase our customer conversion by 25 percent. So now the teams know what it is they’re trying to achieve.
And then we get down to our slightly grumpy devs at the bottom who are really cynical about most things that come from the top of the org chart because they know what really needs to happen in order to do this. But they’re kind of looking at it going customer conversion I reckon we can do that. The problem is our checkout process absolutely sucks. We know we’re losing customers left right centre because this thing keeps crashing for reasons X Y and Z. But mainly because it’s just flaky and it’s legacy tech and it’s not particularly well written. But if we got clever about this and we increased our unit test coverage by about 40 percent. We reckon we could stop losing customers in the checkout process. Which is going to increase our customer conversion which hopefully will drive us to 38 percent market share.
So suddenly the engineer who didn’t want to write unit tests, because frankly couldn’t see the point in writing twice the amount of code because his code was good and it wasn’t his code that was creating bugs in production. He can draw a direct line between the work that we’re asking them to do within the teams and the organisational objectives. And if we go back to the previous slide this is a very clever way of connecting the work that people are doing to that vision.
So the third thing. Leadership vision. Customers are at the heart of what we do. Now you may believe that you operate in an industry that isn’t going to be disrupted by Amazon.
But the fact is not that Amazon is going to potentially disrupt your industry. It’s the fact that Amazon has had such a dramatic shift in the expectations of our customers these days that every market is being disrupted. If we cast our mind back a few years ago Amazon was selling books online. They’re now selling everything online. I can now get pretty much anything I want tomorrow. If I’m lucky and I live in a big enough city I can get most of the things I want today using Amazon Prime Now.
The customers who are used to using Amazon Prime and Amazon Prime Now are not going to see that it is reasonable for their mortgage application to take eight weeks. Or their online booking system for their GP to be something that I can only do on the phone after half past 8:00 in the morning where keep hitting redial. The level of expectation in organisations, and in industries, now is so divorced from what the customer actually expects and are becoming used to. These industries are now ripe for disruption.
The best example I’ve seen comes from a customer. Before I say this, anybody work in insurance? Okay. Sorry. Typically insurance not the most customer focussed industry in the world. Historically it’s a thing that we have to buy.
A great story which came out of the US. A US insurance company called Lemonade. Highly focused on customer experience. Selling what is essentially a thing that nobody wants to buy. And the story they tell is of a chap called Brandon who for whatever reason needed to put in an insurance claim for a red jacket. For a parka that had become lost, damaged, stolen.
Lemonade went through the usual insurance company process. They reviewed his insurance claim. Cross-referenced it with the policy to make sure that this item was covered by the policy. Ran 18 anti-fraud algorithms on it to make sure that there was nothing untoward going on. Brandon was a good guy. Everything was above board. They approved the claim. And because they are customer focussed, customer-centric, they sent wiring instructions to the bank. I’m going to leave that there for a second. Three seconds after he submitted the claim the money was in his bank. So if you can explain to me why I still have two fax things my insurance company. God only knows. But if customers are used to this level of experience what are they expecting from your company in your industry? The problem that we’ve got in I.T. is we’re not used to listening to our customers.
Traditionally we’ve been kept as far away from our customers as we can possibly be. One of the reasons was because the way that our organisations have typically been organised has been along the lines of something at the top. Where we have the business on the far left and we have a customer on the far right. And in order to get something into the hands of our customer we go through this kind of theatre of the idea gets to the PMO team who spin up a project and then we get some BAs to flesh out what we need to do. And then we pass it off to some architect who tell us what from their ivory tower they think we need to build to meet the need. Which then gets passed to the devs who have a bit of a laugh and say no that’s not going to work. We got a bit of backwards and forwards between architecture and devs. The devs build some things and the DBAs do some deviating and the QA team test it. They send it back to the devs because frankly, we’ve never got very good at building stuff right the first time. And we send it back and say our code is fine your testing it wrong. And they so no no no it really isn’t working.
And months have gone by it doesn’t matter because here we’re doing Scrum. We’re agile as you like. We’ve got two weeks scrum we’re turning this stuff around really quickly. We’re going to send it back to that QA team. Eventually they kind of roll their eyes a bit and go well we need to get this thing into production because we’ve been going for about nine months by now.
So we throw it over to service delivery and we go off and have a launch party because we’re all good. Service delivery figures out how we’re actually going get this thing into production. Then we throw it over to the poor Ops team. And everybody goes to the pub while these people try and work out how to make this thing actually run in production. Finally, the customer who wanted something 24 months earlier gets the thing that they no longer need or want. Because we spent so long handing work backwards and forwards between these silo teams. Is it any wonder that the devs now have no real idea what the customers want when they’re so far removed from them.
So when we talk about DevOps one of the things that we look to do is we look to build what we’re calling cross-functional teams. Where they’re optimised for flow. Where we’re taking a very small idea and we’re letting a product owner prioritise that on their backlog. And then through some form of Agile delivery methodology, we have a cross-functional delivery team that takes a selection of people from the above model. Iterate really really quickly. Developed something of value and gets it to the hands of our customer as quickly as they possibly can.
So I was at a conference earlier in the week. Anybody here using scrum? How many people have got definitions have done? How many people’s definition of done is working software in the hands of our customers doing something valuable? So two maybe three people. That’s the only definition of done that matters. So what we’re trying to do is we’re trying to get the people who are responsible for the work, the people who understand. So the people who deliver the work to understand what it is that the customers really want.
We do that by reducing handovers between teams. By removing the queues of work that kill the flow of work through organisations. By working in the smallest possible batch size we can to deliver value. And by doing this we improve our cycle time. So we go from six to 12, 18, 24 month cycle time to something much much much much shorter. Which allows us to make really really good decisions on what matters for our customers.
So it gives us an organisation model which typically looks something like this. So quick show of hands who here identifies as a dev? And most of the rest of you identify as Ops people? Yeah looking at this going you typical dev doesn’t have a clue what you’re talking about. It’s not like that in my world. I’m building out infrastructure. I’m building out monitoring platforms. It’s not the same.
What about if we do this? And we have a customer service desk and a triage team to deal with incoming issues from our customers. Under that, we’ve got our cross-functional delivery teams who are delivering to the business’s customer. But all of the people who sit in that traditional Ops world are delivering, in cross-functional teams, products which are consumed by the delivery teams. So you still have a customer. The way that you work is exactly the same as those people are interfacing with the public customer. Your understanding of what their needs are. You’re working out how best to deliver it. And you’re doing it quickly and iteratively so that you can get feedback from them.
So this idea that we work in an infrastructure team where we build out environments. If we start to think about that as a team who build an environment product which is consumed by our delivery teams the model that we talk about on the previous page works. That allows these teams to be more agile and more iterative and to consume new technologies more quickly. And the end result of this is working software in the hands of our customers delivering value sooner.
We’re at point four or five. I’ve just been told we got we’ve got 10 minutes. The next one for me. This is really important. Change is hard. Any sort of change is hard. Organisational change is really hard. What we need to do is we need to care personally and there are two ways that I believe that this manifests itself.
So the first one is we need to understand what really matters in an organisation. Because if you’re going to go and try and change an organisation and change the way that people work if you don’t understand what’s important you don’t know how people are going to react. So we’ve got this idea of organisational currency. And that can be any manner of things within an organisation. But this is the thing that defines people are doing a good job within your organisation. And that could be budget, team size, job title, the amount of time they’ve been there.
If you go into an organisation or you are an organisation where success as a manager is defined by the number of direct reports you have. And we start talking about building an operating model where we’re flattening the org structure and we’re moving towards cross-functional teams. Suddenly the things that these people have built a career around are being taken away from them. If you don’t replace that with something else you are going to get resistance. So the same applies to the technical definition. So a really good example of this is try telling an Exchange administrator that we’re moving to office 365.
Cultural. This is the manager who is responsible for getting things done. They shine a light on command and control management. They just manage to get their teams to deliver. And now we’re talking about agile ways of working. We’re talking about empowering teams. We’re talking about pushing accountability, one’s responsibility, down the org chart. It’s a really uncomfortable place for this person to sit.
And it may well be that they were the functional expert in a particular area of the business. Or they used to work for Company Y. You need to understand what the things are that you’re about to change and take away from people. What the emotional attachment is going to be that they have with it.
And it comes down to this. Change is really really personal. People spend a lot of time at work and are invested in the work that they do within the organisations that they work for. I was talking to some change people at a conference a couple of weeks ago and the story of Charlie came up.
So, Charlie, we’ve probably all met somebody who fits this bill, joined the organisation as a lead developer in 1998. Built out the parts reconciliation middleware application that was launched in 2001. Been enhancing, maintaining, and supporting that ever since. Charlie is our resident cable expert. Gotta love Charlie. Charlie is really suspicious that these microservices can stale and frankly does not believe for a minute that Java is performant. Anybody recognise Charlie? Anybody Charlie? Okay. Charlie is not a bad person. What’s wrong with this story is how we are perceiving Charlie.
If we flip that around Charlie joined the organisation in 1998. Has an in-depth understanding of all of our core middleware. Has a better grasp of the nuances of our business logic than anybody else in the business. Understands what it takes to scale and integrate our systems. Knows where the bodies are buried. And he’s excited about the technical challenges ahead.
What’s really really important if we’re going through an organisational change is we need to understand what people value. And we need to let them understand what we value about them. We don’t value Charlie because Charlie is a great table developer. We value Charlie for all of those other reasons. So we need to stop defining Charlie in that particular way if we’re going to take them on a journey with us.
And having done that we really do have to acknowledge that change is hard. Let’s not pretend this is all going to be rainbows and unicorns. Any digital transformation is going to have its ups and downs.
And in fact, there is this statistic which you will no doubt see time and time again. The brutal fact that is about 70 percent of all change initiatives will fail.
Frankly not helping. Okay. We’re taking somebody on a difficult journey. We’re asking them to commit to it. We’re asking them to become emotionally invested in it and we’re also saying you’re probably going to fail anyway.
The thing that really annoys me about that quote is that actually if you read the follow-up article it’s not even true. And actually, it was founded on some misinterpretation of some statistics. What I really like is what Nick Tassler wrote when he said change is hard in the same way that it’s hard to finish a marathon. It requires significant effort. But the fact that requires effort doesn’t negate the fact that most people who commit to a change initiative will eventually succeed. And the key on here is commit. If we can get the people in our organisations to commit to that change we stand a much much better chance of succeeding.
So can we stop pre-empting failure?
The final point for me on this. We’re taking organisations on a journey we need to learn to tell stories. If you’re running any sort of digital transformation the most important question you are going to have to answer is So what.
So before we can tell a good story we really need to understand where we are today. Spend some time to quantify the pain that we’re feeling. Understand why we’re asking people to change and what’s the journey that we’re taking them on. Do we understand in that context what’s important to our business?
And the final point here is are we doing anything with the data that we capture? Because most people are looking at it going it’s really hard. How many people have retros? How many people have to post-it notes of stuff that is broken and they want to change? How many people do anything with those post-it notes? OK, there’s your data. There are your pain points. Those are the reasons you’re looking to change.
And then once we know why we need to change we need to learn to tell stories and celebrate success. So here we have one of our cross-functional delivery teams. And they’ve just had a really good six months. And in the last six months, they’ve reduced the time to create an environment from four weeks to an hour. They’ve increased the first time acceptance of environments from 37 percent to 92 percent. They’ve increased their unit test coverage from 32 percent to 85 percent. Hey, and we have automated the life of our deployments using Octopus Deploy.
No one cares. The stark reality of you telling stories like that is nobody gives a monkey’s what you’ve been doing in the last six months.
What we need to do is we need to tell stories to the business in a language that they understand. So over the last 12 months, we’ve reduced the time to implement and deploy new features from nine months to four weeks. This has given us eight months of time where features are running production when they wouldn’t have been before. So we managed to deploy feature x y z in four weeks. And it now generates one hundred seventy five thousand pounds of revenue per month, for us to become the number one seller of organic dog food in the country. And we’ve got an ROI of six million pounds in eight months.
That’s the sort of story that business cares about. Not that you using octopus deploy. You managed to automate your environments.
So understand what your customers care about. If you’re in a product team that customer is the end customer of the organisation. If you’re talking about one of these platforms what do your product teams care about. They probably don’t care about tooling and technology. They care about how quickly they can get their test environments and how quickly that their regression packs run.
So, in summary, my top five takeaways. Leadership matters and leadership exists at every level within an organisation not just defined by your hierarchy. Start with a vision and use that vision to connect with people to the work that they’re doing on a daily basis. Understand what matters to your customers, be those internal or external. Care personally about the people that we’re taking on this journey. Learn to tell stories. Those stories may be stories to peer teams of yours about the successes or failures that you’ve had. Let other people learn from your failures. We talk about the CALMS model of DevOps about sharing. We need to share the pain as well as just the success. And finally, I promise this is the last bit. So the personal bit.
Change is hard. I sat down with the same bunch of change people, where we were talking about Charlie and asked people how they were finding transformation. And it was kind of depressing.
It was challenging. It was lonely. It was exhausting. It was uncertain. It was frightening. It was stressful.
It kind of left us going well what can you do about it?
Don’t think that you’re on your own and that nobody else is doing this stuff. DevOps as a movement is standing on the shoulders of giants. There’s a whole host of resources out there if you just know where to look. Find a community. Speak to the community. I have an amazon reading list which just has a whole load of books and resources that you may or may not find useful.
And if you’re going on a transformation journey, whether you’re the CEO of an organisation or a team leader or a junior dev, and if you get that I don’t know if I can do this. Imposter Syndrome sneaking in. This was my favourite tweet of recent times.
So I think this really does speak to anybody who’s involved in transformations. Brad Stulberg is a sports psychologist. Works with a number of top forming teams. And he put this out when talking about Imposter Syndrome. A fraud is something that just about everyone feels at some point. There are two primary ways to share this feeling. If you aren’t acting authentically start acting authentically. So those transformational leadership skills that we talked about earlier, start embracing those in your ways of working. Finally, remind yourself that no one has all of their stuff together. That’s just part of being human.