 All right, we're gonna get started. Good morning. Thanks for coming. This is a presentation that I'm extremely passionate about and I'm grateful that you took an hour out of your day at DrupalCon to come and see this over other presentations. So yeah, Viva la revolucion, how to create a DevOps transformation at your workplace. Who am I? Also, please evaluate the session. I'll put this link up at the end of the presentation. So yeah, who am I? My name's Amina Stani. I'm the senior manager of infrastructure services at Acquia. I've been at the company for over six years. Five of those years was spent in operations team. That's the team that handles all of the infrastructure that keeps all of our customer sites online, available 24 by seven. And over the past year, I currently lead site reliability engineering and the infrastructure services tools team. So why are we here? What brought you folks into this room to listen to this talk? Well, I'll share with you why I'm here. Three years ago, I went to DevOps days in Boston and I went to the talks and I spoke to people that were also there. And after that experience, I was in a park and I was sitting down on a bench and just reflecting on the last few days and I started to feel a certain sense of dread. That something wasn't quite right about how I was doing my job, about how my team was doing their job. And I felt that something needed to change but I wasn't quite sure what was wrong or what to do. And I came to this conclusion at the end of this pondering and this thinking that there is a problem that is so massive that I have to do something about it that it cannot be ignored. So there's opportunities and there are problems. So let's talk about the opportunities. What are the types of things that can take place that could motivate you to start a major change or to think completely different about how you would do your job? There, the world is changing. There is new technology coming out every single day and all of them present opportunities to us to grow our businesses. We have potential for self-driving cars, virtual reality, machine learning, rockets that can land themselves. It's a crazy world out there and some of those things pose opportunities for us to grow our business. But there's also the problems. Earlier this week there was a news report about an engineer who worked at Uber who committed suicide last August. He experienced extreme burnout and that burnout and that experience and the culture that he was in drove him to make that decision. Knight Capital, which is a financial firm, in 2012 they had a code release. They pushed code and over a period of 40 minutes their entire business was destroyed. And of course we have security vulnerabilities and disclosures that happen all the time. We had the massive outage from Dine, the DNS provider and it created ripples throughout the entire internet and of course businesses like airlines such as Southwest Airlines, their entire business can grind to a halt due to an IT issue. So there are definitely problems that we in our space have to solve in order for the business to continue. Technology is center to our business today. And there are lots of indicators that can show us something isn't quite right, something is wrong. If people start to leave or quit that's an obvious point that something is wrong. Does your team or other teams have to spend all nighters doing stuff? Are they always performing heroics day after day? Is that something that you're seeing in your business? Are you seeing lots of outages, lots of firefighting by teams? Are you seeing lots of manual labor and cumbersome processes to get the job done? What about your software releases? What about your cadence of software releases? Are you releasing daily? Are you releasing weekly? Are you releasing monthly? What happens when you release? Does it cause pain to the customer or pain to you? And of course being that companies are usually consisting of multiple groups of people with multiple skill sets and different goals or is there tension between them? Do they have alignment in what the mission is? If there isn't, there can be tension, there can be arguments, there can be fighting. And finally in my personal case was that we in Acquia enjoyed rapid customer growth. And the thing that I started to see was that the tools and the processes that we had weren't necessarily keeping up with the pace of the growth of the customer. So something had to happen. Enough is enough. I'm sure that there are probably a few of you out there that have had similar thoughts and have wondered, you know what? I love the company that I'm in. I love what I'm doing, but there's this problem and I can't ignore it and it consumes a lot of my thoughts and my thinking. So maybe you come to this conclusion. Maybe if I take it upon myself to be that person, to create that change, to be that catalyst that starts the transformation in the business, we can see it happen. How many of you out there had these thoughts in your mind? Wonderful, and that's why you're here. So I have to issue a warning. This process, this journey, this journey that I am on for the past three years, it is not for the faint of heart. This is a full-on contact sport and you have to be prepared to be bold, to take risks and sometimes fail. One does not simply go into Mordor, yes. So to start a transformation effort, it requires a lot of things. This is not easy and it isn't something you can do quickly. You can't just set up Huppet and Ansible and a few other tools and say, yep, I am doing the DevOps. No, this type of change requires a massive amount of time and energy. It requires you to think differently about how you do your job and to learn about how other people do their jobs. You have to step out of your comfort zone and communicate with people in completely different floors and completely different departments in your company. And you have to be willing to learn all of the aspects of the process of delivering value to your customer, whether it be software or service or what have you. You have to be able to gain an intimate knowledge about what you do and you have to be convinced that this is the right thing to do even when you're dealing with the hard times and the struggles as you move through it. You have to have data, which is your weapon to convince others. If you don't have data to persuade people, they're not going to do anything regardless of what you say. You also have to be patient. People are going to resist you. People may ignore you. People may even fight you and you have to acknowledge that and work through that with grace under pressure. And finally, and most importantly, you have to be willing to lead. There's a difference between management and leadership and it is this. Management is a set of processes and tools that you use to maintain the status quo. The state that you're expecting out of your team. Leaders are willing to throw out the entire process and start fresh regardless of the consequences because they understand that in the long term we need to meet our goals. And luckily, there are companies and businesses that have gone before us. We are not the forerunners of this change. Amazon Web Services, they decided to move to a service-oriented architecture and now they're one of the biggest cloud providers in the world. LinkedIn had similar struggles. Etsy had to break down their silos between their engineering and operations teams and do some significant changes in order to improve how they do business. So they have lots of blog posts and presentations about how they've done their transformation and we can learn from them. But there's also a person that I think we all can learn from. This gentleman is John Cotter. He is a professor emeritus at Harvard Business School and he is the foremost mind on change leadership. Now when I say change leadership, I don't mean like change management where like you're doing a release and you're scheduling one, no, no, no. I'm talking about changing organizations, changing companies. He wrote a book called Leading Change which most of this presentation is based off of. So those management minds can give us engineers or middle managers or what have you tools to change the entire business. So we're gonna go through the process of what it takes to start a DevOps revolution in your company starting today. The first thing you have to do is identify the threat. What exactly is it that you're trying to solve? What are the symptoms of the problem leading to? And we can start by asking two very basic questions if at the moment you're kind of vague in what's going on. First off is how we're failing our customers. Have you talked to your customers recently? How do they feel? What do they think you're doing well and what do they think you're not doing well? That might give you very clear clue as to where your problem may lie. How are we failing each other? Are we arguing with other teams? Are we throwing things at the wall, over the wall at other teams? Are we not responding with urgency when people ask for help? How are we failing each other? And this process may not be straightforward, but one tool that you can use to understand your end to end process and delivering value to the customer is something called value stream mapping, which is basically the process of seeing every single step from the beginning to end in doing something. With that knowledge, you can then infer or determine where your bottlenecks are, where things are slow, where things are waiting, and that might give you some clues as to what part of the organization or where in the organization they're having trouble. Of course, you can always ask your team, simply say, hey, what's good and what's bad? What is it that does not make you happy about your job? And if you ask enough people, you might actually find some trends and repeat problems that you can then use. You can ask peers from other teams, which is very important, especially teams that work with you day to day and providing value. They may have some constructive feedback that might point to a theme that you need to address. And finally, and most importantly, ask your customers, what are they thinking? What are you doing well? What are you not doing well? The second step is to gather intelligence. You need information in order to persuade people that something is wrong. Full stop. So let's take a step back and let's think about things from the perspective of business leaders. Because ultimately, these are the people that you're trying to persuade to make significant change. So there's a gentleman named Eli Goldratt, who wrote a book called The Goal. And the quote here is, the goal of organization is to increase throughput, meaning the number of features, the number of widgets, the number of customers served while reducing both inventory, which is the amount of money in the system that has not yet been realized as value add and operating expense. The time we spend at our jobs. Distill that to two things. What we're really talking about is time and money. So if you're able to gather metrics in terms of time and money, you are going to be able to speak in the language of business leaders because that's what they think about. They think about time and money. So let's get briefly into the world of what metrics would we care about and start measuring and we can start persuading others. The first thing is lead time. The moment that a request is made to the moment that it's completed. Those that are in support organizations or operational organizations understand this completely. It's the age of the ticket in the system. How long did it take for a request to get done? Also, touch time, which is how much human effort was spent in doing something. If there is a particular step in a process that has a massive amount of touch time, that might be a wonderful place to start in trying to improve your process. Next is operational load. How many of you are on call? Okay, so you guys are responsible for the operational concerns of your service. So if you are able to measure the percentage of time that you're spending getting paged or doing the manual effort to keep your service moving forward, that's operational load. And if it exceeds, let's say, 50%, you're probably not in a good place. And finally, unplanned work, which is a part of operational load, but for those that read the Phoenix Project, they would understand that unplanned work, we're talking about outages, essentially, things that the business did not prioritize. Unplanned work is the silent killer of our industry. And we have to be aware of it. We need to monitor it and measure it and do things about it. So let's talk a bit more about what the Phoenix Project mentioned in reference to unplanned work. Every organization, I believe, every organization does four things. Number one is business projects. That is your job. You're producing features, you're doing the thing that the business wants you to do to make money. The second thing is internal projects. That is how you improve, how you do your work, setting up continuous integration, automating away a manual task. Those are examples of internal projects. The next one is operational change. That is you performing a release. That is you swapping out servers or doing any of the stuff that could be disruptive to the availability of your service or your business. And finally, again, unplanned work. Again, the silent killer, the thing that wakes you up in the middle of the night and prevents you from doing any of the other three things. If you're able to measure these things, you would be able to understand their proportions and is a wonderful weapon in persuading others. So I could talk about this for a full hour, but that's not what I'm here to do. So there is actually a presentation that I did at Dublin last year. You can pull it up, take a look, watch it, and you can learn more about metrics. So the goal, the mission here in this stage is to gather weapons grade data capable of persuading senior leadership. That is what you have to do, because if you can't reach them, you can't make the change possible. So the next step after gathering intelligence is you need to sound the alarm. And what I mean about sounding the alarm is to establish a sense of urgency. A sense of urgency is something I'm going to repeat a lot in this presentation. People have to feel that there is a problem and that they need to be, need to feel motivated to solve it with you. Without it, you're not going to produce the change. The creating a sense of urgency, this step is the most difficult and the most important. And it will sometimes take the most time. At Aquia, as I started this DevOps transformation process, it took me two years to establish a sense of urgency. Most of the time was spent learning what to say and figure out what metrics to gather. So that's why it took so long. I was starting from scratch. I didn't know any of this stuff. So I had to learn everything. So I'm sure you folks have seen this comic from time to time. It's a warning to all of us. Do not underestimate the power of complacency and the forces that maintain the status quo. And there are complacency really is your enemy here. And there are many sources of complacency that you have to be aware of and eventually address. If there isn't a current problem that's affecting your business at the present moment, then people are gonna think, well, why is it a problem? It's not affecting me right now. If your organization doesn't have good standards or metrics in terms of measuring how a team is performing or how the business is performing, then you're not gonna be able to provide the appropriate feedback to them to make them improve. And if you're not talking to your customers, if you're not talking externally to your teams, you're just in your own little bubble and you think everything is great and you're not thinking about how your actions or your work is affecting others. Next, you also have a culture where people don't wanna talk about the problems. They want to avoid it and not mention it because it's uncomfortable to them to do the tough conversations. And if you're already stressed out, human nature will just make you say, look, I don't want to deal with this right now. Can we talk about this later or not at all? And finally, which in a way is most insidious is when leadership continues talking about that, like the happy talks, like, oh yeah, we went and we had 10% increase in revenue this quarter and everything's great, but if they're not talking about the problems, then everyone is lulled in a sense of, yeah, everything's cool, but it's not. In order to establish a sense of urgency, you have to be bold. You can't be quiet, you can't be meek. You have to take risks. And there are multiple ways to establish a sense of urgency from where we are as leaders, as engineers, as individual contributors. The first thing you can do is you can make your work visible. So in Acquia, I implemented a combine process which I'll talk about later, but it allowed us to visualize work going through a particular team and then we're able to generate metrics on that work to show how they're performing and identify where the tough spots are and where the bottlenecks are. So if you make your work visible and the type of work that you do visible and you share it with management, they're gonna see what's going on and it's gonna equip them with the tools to make decisions. How many of you jumped in on something you know was going to explode to put in that last second fix? Many of you. You wanna start a sense of urgency? Don't do it. Let it blow up. Now, let me be clear. There are certain things you don't want to have blow up. You have to be very tactical about the thing you want to blow up. But let it fail. Because if you let it fail, not always. If you're in a culture like that, that's probably not a good thing either. But if you let something blow up, controlled explosion, you're then able to say, hey, we have a failed process. We have a failed technology. We need to fix it. Why haven't we paid attention to it? It's clearly something that we can't just have hanging out unattended. Oh, snap. Let's try that again. Sorry about that. I let that fail. And you know what? I didn't get fired. So it's wonderful. So how many of you are managers in the room? How many of you are like C level managers in the room? So one person. So with that power, you can do something very interesting. You can say that for a particular department or across the company, you can set a performance target that is impossible to achieve where you are right now. What that does is it's going to motivate people to think very differently about how their job is being done and to force them to think outside of the box in terms of how to achieve that target. Again, the goal here is to persuade senior leadership to act. You can't do this, any of this, without senior leadership buy-in. So Ops Kanban. So yeah, in 2015, April, 2015, I was in operations, I was a manager. And we didn't have very good visibility into our work. And we were responsible for doing tickets that serve many organizations inside of the business. So I decided to implement a Kanban board. And this Kanban board had metrics around it. In particular, how many tickets got done for a given day. And I did something very bold. In terms of figuring out what tickets should be brought onto the board to be completed for a given day, I got the leaders of every single team that Ops serves in a room and had them decide what are the most important things that Ops should do. In the beginning, this resulted in a lot of arguments because they started to get frustrated because they were able to see that Ops wasn't able to do as many tickets as they wanted in a given day. And they had to start asking questions around why. And that created urgency across the organization because they understood in that particular moment in time that the Ops was a bottleneck and they needed help. So let's say you've put together data and you've brought it to your manager and you've brought it to anyone that would listen and you started to establish a sense of urgency and you're starting to get people, senior organizations to say, you know what, that is a serious problem, we need to go fix it, congratulations, first off. But next, you need to build a coalition, a group of folks around you that can work together to make the change happen. You can't do this change stuff alone. The cult of personality is not sufficient for you to make the change happen across organizations, especially for companies that are large in size. So what makes an effective coalition? What type of people do you want on your team? So again, over and over, you need senior people in the org, hire the better. If you can get a middle manager, fine. If you can get a director, wonderful. If you can get a VP, you're almost there. If you can get the CEO, you did it. But you need that position power. You need management to buy in and what you're talking about. You need expertise. You don't just want a group of engineers, you need perspectives across the business, sales, marketing, support, onboarding, all of those business competencies you want in the room with you, so that way when you put together initiatives, it benefits everyone. You also need credibility. You want to surround you with people that are trusted and that have built a positive reputation in the business. If you have someone that has a bad reputation, it actually could backfire on you. And finally, leadership. People that are willing to shake things up and not just hold on tightly to their fiefdom so that way you're able to make the necessary change. You have to have a group of leaders, not managers. So with this group of people, let's say you put together your dream team, what do you do with them first? Well, if you are an executive, you can do this magical thing I heard about called off-site and you take all these people and you put them in a hotel or something for two days and you spend time with them and you build relationships with them and you're able to create an environment of trust among these people. But for us mere mortals, we have to be a little bit more creative so you can bring people together for lunch, you can get drinks after work and have conversations about this stuff. And it's important throughout this process that you continue to reinforce urgency. There's a problem folks, here's the problem. What do we do to solve it? And you are ready when the group of people have a general consensus around, yep, this is the problem and this is what we need to solve. So the next step, being that we're talking about revolution, is we need to pen our manifesto. And what I mean by a manifesto, I'm really talking about vision. So what is vision? Vision is a picture of the future with commentary as to why people should join in and assist you. And there are multiple qualities that make an effective vision. First off, the vision has to be imaginable, has to be easy to understand and for people to conceive of. Next, it needs to be desirable. If you say, hey, our vision is going to be we're going to charge the most amount of money to our customers and we're going to pay our employees the least, no one is going to buy into that vision so don't do that. The next thing is feasible. It has to be actually achievable in a reasonable period of time. It has to be focused. It needs to be clear enough to aid people in making decisions but it also has to be flexible enough for people when going on uneven terrain to be able to use your vision towards making decisions that they've never made before. And finally, it needs to be communicable. If you can't communicate your vision in less than five minutes, you're not ready yet. So you guys are probably thinking, whoa, I mean, I think you just pulled a bait and switch. I'm at a DevOps talk and you're talking to me about vision and management and this is kind of boring maybe. Why are you talking to me about this? All right, well, let me sell you on this. If you put together a good vision that motivates people to change and do things differently, what you get is less meetings. How many of you love meetings? So none of us really love meetings. So by having a clear vision, people are able to make decisions independently and they can simply say, okay, this thing I want to do, is it in line with or not in line with the vision? You just saved thousands of dollars of meeting time by simply having a clear vision. So what's the process of creating a vision? Again, you have to maintain the sense of urgency because it is a reasonably long process. If people start to drop out, you're not gonna get the full picture and a vision that is as comprehensive and affects everyone. So a single person starts generally by writing a draft. Probably one of you, you would write the draft. Congratulations. And you're gonna take the data that you collected in the previous steps and you're going to work on the things that you need to see change. And you're gonna have this back and forth process between you and your coalition. When I went through the process, most of the people said, I mean, this thing is too long, no one's gonna read it, make it shorter. And I had to make it real short. You have to use your heart and your head. In order for people to change their behaviors, you have to tap into their emotions. We're not robots. So you have to use data as well as emotions. And this might take some time. It can take weeks. It might even take months to go back and forth and refine it into something that makes sense. And again, if you can't communicate this in less than five minutes, you're not done yet. So let's talk about DevOps at Acquia. So I'm gonna share the vision that I, with my change coalition, put together in terms of transforming the company from the inside, namely engineering. So I wanted to put it together in a simple single sentence. So that way it's easy to understand, but just like poetry, it's packed full of information that allow people to understand what I'm talking about. So the sentence is, we will do our jobs like Iron Man, not the Incredible Hulk. So there's a difference between these two characters. Iron Man is using technology. He's using data to make decisions and the effect of his work is very, very efficient. Incredible Hulk uses strength and rage to get through problems. And you can see the difference between those two characters and why you wanna be like this and not like that. So yes, we want to work like Iron Man, not the Incredible Hulk. And we wanna be able to, we believe that we can achieve this vision through six values. The first one is eliminate toil. We felt that it was very important to eliminate sources of repetitive manual work that provided no long-term value to the customer or ourselves in our careers. No capes. No capes means that we don't burn the candle from both ends, that we figure out ways to work in a sustainable manner to get the job done, to work smart and not hard. To deliver with empathy. When we deliver services and when we deliver products to our customers, we think about how our changes and our actions impact the customer as well as the teams of others. On your service, the engineers that built the service are the most equipped to solve the problems that occur with the service. On your business, you gather metrics about your part of the business and you use that information to guide decisions about how to make your business more efficient. And finally, own customer success. We at Acquia are the experts when it comes to highly scalable Drupal websites. Customers come to us for the expertise and we should be willing to communicate to them and provide them a path to success based on what we know. So that is our vision in a couple minutes. It didn't take very long. So you have your vision, you got it penned, you spent the time, now you have to recruit your army. You need more than just your change coalition to work, you need everyone in the business to work. So you gotta recruit your army. And what I'm really talking about here, frankly, is propaganda. That's what we're talking about here. We are going to engage in a propaganda war and we're going to use every single tool in our arsenal, all five senses, all the time to get people to start thinking the way that we want to think according to the vision. And here's some example posters that I made last year. We were going through stuff which is like World War II style things, like don't burn out, ensure operational readiness and more continuous improvement. So this was an exercise in trying to figure out ways to expose people to the vision and its values. And there are many ways you can communicate the vision and it is important that you use as many of them as possible, but above all, keep it simple, silly. Like keep it simple, make it easy to understand, don't use techno babble, make it appealable to everyone in the company. So you can communicate in person with your meetings with your boss or in the meetings with your subordinates, you can communicate the vision to them. You can do info sessions. I did an info session when this initiative started multiple times across all the time zones, had Q and A's and did that stuff. Also team meetings, communicating with your team and reinforcing the vision. You can do it in a written style. I usually send emails once every couple of weeks when things are really going on, talking about DevOps and talking about, hey look, we're making change, things are happening, here's the progress, and all of that stuff. You can also have a knowledge base that people can consult. Next, visual, like office posters, t-shirts, whatever, just to bombard them with the visual stimuli of what the vision means. And you have to repeat it over and over and over and over again because they're looking at data all the time. So you have to create a better signal to noise ratio. And when you see people or things or actions take place that are inconsistent with the vision, you have to address it right then and there. Because if you see conflicting actions taking place as you're communicating the vision, you're not gonna get the change you want and people are gonna become complacent. And above all, you yourself, the leader that started this thing, have to be the living embodiment of the vision. If you start doing things that contradict the vision, they're gonna look at you like you're crazy and then they're not gonna do anything at all. So as a leader, you have to be accountable to your team and to your peers to continue to maintain the vision through your actions. So while office hours. So 16 weeks ago, I started office hours at AQUIA where we simply talked about DevOps and answered questions about SRE, Agile, whatever. We started to put together a core group of around 10, 15 people. They started to appear all like every week asking questions and really asking for information and we had a very interesting dialogue. Very interesting things came out of this. We started to have weekly sessions outside of it talking about root causes analysis. We're starting to have game day sessions where we're simulating outages in our services to figure out what's going on and to teach others about incident response to generate empathy. So yeah, the office hours process that we started was very effective for us and I'm looking forward to seeing how we can expand the influence through this process. All right, so you've recruited your army, you've got them all amped up and they're like, yes, we're gonna go take this hill. But the first thing you gotta do is you gotta remove obstacles, make it easy for them to do the work. And what kind of obstacles we're talking about? Well, there are several. It can be process-based. The way that you do work might need modification. There might be lots of wait time and a lot of frustration in how work is done today. It might be incentives-based. Teams might have completely messed up incentives or goals or KPIs. That result in them working against each other. It could be an organization problem where you have handoffs between teams for processes and good and you might have to clean that up, make it better or even remove teams from a process entirely. And finally, it could be a people-based problem. There are folks that are extremely negative. There are folks that will resist you and you might have to address them either in working with them personally or in extreme case. As a manager, you might have to work on a path for them to exit the company. So we've removed the obstacles. This is where the real work gets done. All of this stuff that I've been talking about has been preparation. Now we have to act. So the goal now is to seize swift and tactical victories. Now there's something that we have to understand. This whole process and everything that I've been talking about, the underlying thing that we're really trying to do here is confidence. We have to have people being confident that yes, this idea is awesome, I wanna get behind it. It's the currency of change and you have to maintain a solid buffer of confidence throughout the whole process for you to be successful. So you have to create short-term wins. So you got everybody amped up, now you have to direct their energy to something that is achievable in a short period of time to provide credence to why you're doing it. So you and your coalitions needs to choose initiatives and projects that are achievable in the short term. Like a quarter at the furthest. And if you can do more like two or three at once, that's wonderful. Concurrency is wonderful if you can have multiple groups in the company doing similar change efforts according to the same vision. Sending status updates and reinforcing that change is happening is really important, especially as you reach milestones. And when someone and when a team succeeds in one of those initiatives, you go to the rooftops and you just celebrate and you praise that team and you say how they acted towards the vision and that is so important that you reinforce, things are changing, things are getting better. Look what we've recently done, it's very, very key. So a short-term win that we did at Acquia was something called Ops Portal. There was a very interesting problem that we had in the organization where there are teams that ask things of the operations team and they ask it in their language and they're using JIRA and the way that you submit a ticket is you put it in a big text box about what you want. Unfortunately, people don't speak the same language across all teams. So I built a system with the assistance of infrastructure services tools team that creates a simple portal that lists all of the capabilities that the Ops team does and presents them with a list of options to select in terms of being able to submit that issue. And what happens is that a ticket gets filed in the issue queue with all of the information necessary to solve the problem in the language of the operations team. So by strategically building a service that serves as a very thin proxy between the people that's asking for help and the people that are actually doing the helping, a very interesting thing happened. The average amount of time that it takes for tickets to get done through the portal is half that of any of work types that are not used using the portal. So just by improving the communication between teams using software created a short-term win for us. So let's say we created the short-term wins. And what do we do next? We have to keep going. We have to press the attack. We have to sustain acceleration. So you went and you did these victories. So you invested a little bit of confidence and you got a whole bunch of confidence back. You have to reinvest it back into new initiatives. So your team needs to pick the next set of initiatives, the next things that need to change in order for your business to be more efficient and faster and more successful. So it's like wheels within wheels. You're doing the same process. You're creating urgency around the new problem and you're getting the data and you're rinsing and repeating and you're setting everything up and things move. At this stage you're gonna want to expand your influence to other teams. The start of your change might have taken place in your own department. But now you're gonna wanna work with the other departments that are helping you in the process of delivering value to the customer. So you wanna start influencing them and getting them to join in. And it's very important because if you aren't getting the other teams in your business to join in, eventually they may become an obstacle that is very hard to address. You might have to break down silos and that, you know, bridging together, putting together bridges between teams and relationships between teams and making it possible so that certain steps in your process are entirely removed. Things that are completely unnecessary. And at this stage also, you want to be able to delegate some of the work away. You're gonna want to mentor a group of people that are designated change agents in your organization that understand the vision, that believe in it, and are willing to make change where they are. A way that AQUIA is doing that is through Site Reliability Engineering. We took the senior operations folks and we distribute them across the entire engineering organization as needed to improve the state of services and improve how business is done from an engineering point of view. By them holding on to the vision and communicating the vision to others and doing things consistent with the vision, they are making change everywhere. Never ever say mission accomplished. That is probably the worst thing you can ever do. You're never done. You're always working. You're always finding the next hill to take. You're always moving forward. If you say, oh yeah, things are good, I'm gonna go and chill out now, you're gonna backslide and you're gonna go back to the old way of doing things and you don't want that, especially with all of the work that you've done. So you have to keep your foot on the gas and just keep moving. And this stage, it will take time. It can take years depending on the size of the company. So finally, the last step is to change the culture. Changing the culture is hard. You can't just magically, yep, we all think the same way. So that is why it's the last step in the process rather than the first. So there are ways that you can institute change in your organization that endures in the long term. One of the things you can do is you can change the core values. How many of you have core values that are listed somewhere in your organization? Okay, some of you. So if you think that your core values are bad and they are impacting the culture and how business is done and you wanna change that and you're at this step, you can change them. You can change what values are important to you and what values are important to the business. And then when new people join the company, they are now indoctrinated with those new values. But yeah, culture change happens last. You can't do it first. It requires a lot of work to get there. And you have to continue to create those strategic wins and to continue to break new ground and to continue to emphasize the vision everywhere you go. And you have to ensure that the vision is communicated everywhere and the urgency is maintained the whole time to prevent complacency. Sometimes turnover might be necessary. You might have some focusing organization that are of the old guard that think that we should do things the old way. And if you're at this stage of the game, it might be a good time to see where they fit in the organization if you have the authority to do so. Sometimes you have to make those hard decisions in order for an organization to move forward with a new vision that has at this point been proven to work. And finally, all of you revolutionaries out there, you have to create a succession plan. Someone is going to have to work after you leave. You may get hit by a bus. You might find a new opportunity, but you have to make sure that once you leave that the legacy lives on and that work continues happening. Otherwise, you're just gonna create a cult of personality and then the moment that you leave, everyone goes back to the old way. So you need a succession plan. So, SRE practices. At AQUIA, we're now at the stage where I personally have the ability to make changes to how things are done. In particular, engineering practices. The first thing that we started to do was the concept of blameless postmortems. Every time we have an outage that is major, if there is a site reliability engineer embedded on the team, it is required. 100% KPI for them to perform a blameless postmortem with the team. And simply what you're doing is you're figuring out what went right, what went wrong, and what was lucky. And taking that information to determine what actions have taken will prevent the outage from happening again. Operational responsibility assessments. So this actually came from Google. There's a process where every quarter you look over your service in terms of how you operate it, how you do on call, how you do alerts, how you do capacity planning, and we're evaluating every quarter what the maturity of each of those things are. And by making that a mandatory process in engineering for the services that SREs are involved in, you're able to assess the risks and make judgment calls about the risks. And then finally, launch readiness criteria, which is a very, very new and recent thing. I'm working with engineering right now to put together a very concise list of steps that have performed, demonstrates that a service is ready for launch. This again enables us to address risks and to eliminate sources of unplanned work. So here's the summary. John Cotter put together a set of eight steps, and I've kind of shrouded them in this revolutionary speak, but I'm gonna go ahead and talk about what he spoke of in the book, Leading Change. The first step is to create a sense of urgency. You maintain that at all times. You have to ensure that the peers that you work with and your team understand that there's a problem and that action is needed now, today, in order to solve it. You also need a guiding coalition. You have to put people around you that are diverse enough and are experts in their fields so that way you're able to make a change across the work. You need to put together a vision and initiatives. You need to be able to tell people where you're going, why, and how. You need to enlist a volunteer army. You can't do it on your own, and you want as many people in the organization to join in as possible. You have to enable action by removing barriers, finding obstacles, either organizationally or a problem person or whatever, and taking those barriers away so that action can actually take place. Once you have that, then you can create your short-term wins. You can pick the tactical places that you can go and change, and once it happens, you're able to go and convert that confidence gain into even more wins by sustaining the acceleration, to keep the foot on the gas and continue changing things as time goes on. And then finally, you're able to institute change. You're able to go and actually make core to the business, core to the values, core to the day-to-day procedures, how work is done that is consistent with the vision that you've created. So this presentation is just about over. I wanted to introduce you all to some references that you can use to start your own revolution at your company. The first one is Leading Change by John Cotter. This book is the skeleton of this presentation and I highly recommend you reading it. It's a very good book. It's not very dry and it's very understandable and I think you'll get a lot out of it. The second one is the goal. This talks about what is important to a business and how to deal with constraints and things that slow you down in delivering value to your customer. And finally, the Phoenix Project. How many of you have not read the Phoenix Project? This is the DevOps Gateway drug. You need to get this book and you need to read it because this is the book that opened my eyes to how I need to change where I work every day. So this is a wonderful, wonderful place to start. So, yeah, that was a funny photoshop, someone did it with me. Most of us are probably engineers in this room and I've shared with you some practices and tools that are usually reserved for only management. So I've given you some interesting weapons for you to be able to take to management what is needed to change your organization from the inside. I know that where you are and where you're sitting, there may be a lot of problems. You might feel that you are losing hope, but if you care about the business that you're in and you care about what you're doing every day, then I say, stand up, go through this process and become a better professional and engineer in the process. Viva la revolución! Well, we have a Q&A session for a whole hour in room 305 at 2.15 in the afternoon. I'm sure some of you will have questions. I'm sure some of you will wanna share your personal experiences and your struggles. I don't know everything. I can't solve every problem, but I might be able to lead you to a resource or a technique that might be very useful in making the change happen. And please, yeah, evaluate the session. I'm really excited to be here. I'm really excited to share this information with you. I wanna become a better speaker. I wanna speak at future Drupalcons, so please let me know how I did and what I can do better in presenting. So yeah, that's me. And you can drop me a line and any of those means of communication and let's keep the conversation going. I would like to open up for questions. So one of the things you talked about was collecting metrics and data to justify change? Yes. Can you give some examples of what kind of metrics you collected and how you measured them? Sure. So a lot of the information I presented at Dublin, which was the people metrics talk, but I can talk about that a bit more at length. So again, the four types of work, the business projects, the internal projects, the infrastructure change and the unplanned work, I started there and what we ended up doing was we got operations to track their time on all of the tickets that they did and that was a struggle because tracking time is kind of painful, but we gave them incentives. We sometimes gave out bonuses of like, you know, a $100 gift card if they tracked all their time and we got them to do it consistently. And with this data, we were then able to find the ebb and flow of the proportion of unplanned work that the team is taking on and then with that information, we're then able to break that down into the types of work that is causing the unplanned work and then using that to tell, let's say, product management that, hey, look, there's a certain theme that we're seeing that's causing a lot of non-value add actions that require the change necessary. And also being able to show senior leadership the amount, you know, the return on investment on a team's activities is also very, very powerful. So we started there. And of course, we track things like what's the average time it takes for ops to get a ticket done or how many did they get done in a certain day and why and that type of stuff. So you're able to zero in on this team, see the metrics, ask questions and generate urgency around the data. But without the data, we couldn't have done it. Thank you for the question. Hi, thank you for a really interesting session. The thing that sort of struck me is how you were talking about the heroes and capes. We're a fairly small development shop, so we, the tech leads responsible for the builds have basically been sort of forging their own ground with local dev environments, you know, all that kind of stuff. And pretty much everybody's in agreement that we need to standardize that it's just, you can't ad hoc it every single time. That's right. But some of these folks have been working a lot of time on weekends and nights getting their multi-dev Drupal for one guy, this perfect flavor of Vagrant over here for this one. And everybody agrees that we should standardize, but how do you address the issue that every superhero is probably gonna see their solution as being the obvious one that you should standardize to? Be part of that question. How do you remove capes without using kryptonite? It's a very good question. So how large is your team? Okay, so a reasonably small to medium-sized team. So we're talking about an issue of personalities, right? Yeah, that can be pretty tough. So one of the things, I think every engineering organization is gonna have a little bit of bike shed, you know, going on because we're hiring very intelligent, smart people. They pride themselves on solving problems. They wanna be in the spotlight where they're solving the problems. So one of the things that you can try doing is to try to divide and conquer. One of the things we're doing in infrastructure services is designating tech leads on certain initiatives. So you have the continuous integration initiative, the monitoring initiative. You can break it up into separate ones and then you can distribute the technical leadership of that particular thing to that person. And that requires a lot of trust because you're giving that person the power to have the last word on the subject while at the same time being open and receptive to the feedback that the rest of the team is giving them. So that helps with removing the obstacles where people are just infighting over how things should get done. So I think a divide and conquer method would be very useful. But on top of that, you're building accountability to them that, okay, I'm giving you the leadership, but now you're responsible for the outcome of that initiative. So you need to really think about it and you need to think about the cost. You need to think about the upkeep and all the stuff that would detract from a success. Thank you for your question. Hey Amin, I work with Amin by the way, we're at Acquia. I wanna, this isn't so much a question as a comment to say that, so I'm on the professional services team at Acquia. That's right. And as we've gone through this transformation as a company, it's infectious. So when Amin and the team first started this effort, I remember looking over and saying, oh yeah, the operations team really needs to do that. And as it's rolled out, it's been, I've realized, and seen it happen across the company and the mindset change across the company, which is really, really important. And I've seen it start to infect professional services. We've done a lot of things over the last year that are philosophically aligned with DevOps, even though we're not like, professional services isn't managing an infrastructure every day, right? I did wanna say to your question, one of the things that's worked well for our team is instilling a culture of humility and also making people own the things that they're building. So you might have people on your team that philosophically think my solution is the best solution. If they have to own it and own rolling it out to their team, yeah, it humbles them, yeah. That's it. Thank you very much. Any other questions? Cool. Well, it looks like we ended this right on time. Thank you so much for coming and spending some time with me so that I'm able to share some stuff. I hope this was helpful. I hope this gives you the tools necessary to create your own change initiatives. And yeah, this afternoon, we have a Q and A session. Very informal, feel free to come on in, ask questions, share, and maybe we can learn more about how we can change our businesses from the inside. Thank you.