 I'm Tiffany, I use she, her pronouns. I'm a sysadminit puppet, but when I started six years ago, I was actually the coordinator for the consultants and I quickly automated myself into boredom and my manager was like, hey, we need to implement some software, would you like to do that? And not knowing I was supposed to say no, I said yes, and that began a journey of many changes, large and small, some great, some terrible, and I have gotten a massive amount of scars from some of these hard lessons and I am here to share what I have learned so you can roll out changes and end up with different scars because we're in tech. Change is constant. You roll out a new tool, a new process. Hopefully you get to iterate a couple of times but all too soon the business pivots to something else and you gotta rip it out and start all over from scratch. Now when this is awesome, it's the best feeling. Like who here has had a successful change where they're like, try this tool I built for you or let's do this new way of organizing the way we work, right? It's so validating. You're like, you feel like you can improve the world but then when it doesn't work, who's had that one? Yeah, the people trying to roll out the change are just completely baffled, that people are resisting this obviously good thing. The people resisting the change wonder why you're trying to shove something down their throats and then they end up just not doing the thing and they subvert the process and you end up with a bunch of shadow IT which means that the thing that you were trying to improve in the first place doesn't get done and then in like six to 18 more months we're just doing it all over again because you never solved the problem because the people didn't adopt the change. Okay, to be clear, this talk is not about how to shove a terrible change down someone's throat. This talk is about how to ensure that you are creating a good change and how to communicate the obvious awesomeness of your change to people. Just as we are a bunch of computer nerds, there are a bunch of nerds that like change management and they have several different frameworks that they use to evaluate whether a change is going to be successful or whether it's going to fail miserably and leave you sad. The framework I'm going to use throughout this talk is called ADCAR, which is an acronym. It is an acronym for these words. But the slightly longer version than these words is people need to first be aware that a problem exists. They need to desire to fix the problem. They need to know how to fix the problem, be able to fix the problem and also be reminded constantly because we are humans. All right. So yeah, we're humans, we're not computers. We've not yet entered the dystopian alternate reality where we can just get force pushed directly into someone's brain. So until that point, here we go. My favorite part of a change is ensuring that we're getting the right change in the first place. So stakeholder interviews make me so happy. It helps you to understand, you're building your awareness and desire case. It helps you understand what the people that you're working with see in the world because we all work in our own worlds. We all have edges, right? We're like gears and we interact with other people. If we're just changing ourselves, then that's on you, right? But we're talking about our coworkers, maybe our friends and family getting them to wash the dishes or whatever. This is the closest we can get to being in their heads. So sit them down, get a representative sample of your stakeholders. Who's going to be impacted by the thing you're rolling out? And start asking very open-ended questions. Start asking like, hey, this process we've got, I've noticed some problems. What's your experience with it? What are the things that keep you awake at night? What do you wish it was like? One thing I wanna be clear on is don't guide them towards your solution because let's be honest, you've probably already got an idea of how to fix the thing, right? Don't tell them that. Let them just free form talk about it. So that first change that I rolled out. Our problem set was that our sales folks used one tool to store information about our customers. Support used a second tool for all of the support tickets on those customers. And our consultants used yet another tool, which meant that if you wanted a complete picture of a single customer, you had to go into three different tools. This led to a lot of awkwardness and pain sometimes. You can probably imagine. So I would talk to one meeting full of like three or four support people. What are the things that keep you up at night? What are the things that we absolutely cannot change? Also ask, yeah, wait, hold up, I got a slide for this, don't I? Aha! Ask them about the problem space and write it all down. What are the things that you hate? What are the things you love? What are the things that need to stay the same? Write it all down and then ask them to help you sort it by importance. Because yeah, it would be great if we could use our computers to wash our dishes for us, but that's probably not an appropriate change for a content management system. So ask them what is the most critical stuff? Get them to help you sort it for you and do not create your solution. Do not be like, oh yeah, we're totally gonna roll that out. Don't make promises. Because you're going to be interviewing a lot of people and that idea that you have in your head might have to evolve. So don't promise something to one person if you're going to have to change that. Because people just, it's the real world. There are differing needs. This is not a requirements gathering session, be very clear, you're just trying to understand what they need. Because any change you make should be fallible. If you cannot make a thing that will actually make people's lives better, you shouldn't do it. So that's why you really need to understand the things that cannot break for them. Once you've interviewed everyone and you've got an idea of how you're going to implement your fix, your tool, your process, whatever you're doing, go back to those stakeholders. Because inevitably you're not going to be able to make everyone perfectly happy. Otherwise none of us would have jobs, right? Like this would have been solved if we could make everyone happy at once. So when you go back to your stakeholders, explain what they wanted and be like, hey, you asked for that thing? We got it for you, it's going to be amazing. And that other thing, your idea was great. It was your idea first, but give them credit. It's like Ikea furniture. But also tell them the things that you couldn't deliver. But most importantly, explain why you couldn't deliver that. Say, I understand that you really thought that this was going to be a great thing for us to fix. But it turns out that sales had a competing need. And we evaluated it and determined that they had the higher business impact. And therefore we are delivering this first. You can help soften this blow by being like, but here are some ideas for how we can address your need in the future when we iterate. Are you still cool with this? Because if they say, no, man, you're ruining everything. They're telling you right up front, it's going to be a hard change for you to sell. So really seek how you can get them on board with your change so you can create evangelists. Because if you're making a change and you're not creating evangelists, you're creating enemies. Who wants an enemy for their change process? Awesome. Oh, also look out for new stakeholders. Storytime, that first change that I did, it was like if Wikipedia and Facebook had a baby and made it wear a tie, that's what it was. It was great. And because we were sucking in information from a couple of places and we were showing it in this one, and we were going to be replacing our old wiki. And this wiki was terrible. Everyone hated this wiki, it was slow, it was bogged down, nobody could find anything. I'm like, this is an easy win, I'll just ship it. And everyone will be like this. But there was more than just sales and support and consulting that used that wiki. There was engineering, there was HR. There were so many more stakeholders than I had accounted for in the beginning. And the reason that change actually ended up failing in the end was because I didn't go back and say, oh crap, we added new stakeholders. I need to find out what they need from this new tool. So don't end up with that scar. Okay, so you've identified your stakeholders. You've built out an amazing tool. You are ready to launch. Start with the tigers. What are the absolutely terrifying things that are going to happen if we do not do this change? You really want to go for an emotional impact here. I know that it's tech and so we're like, oh man, emotions are weird. I don't want to make an emotional case. An emotional argument is one, not lying. Man, didn't that suck? Is an emotional argument and it's not lying. It sucks, remember? I like to think of it as your change is code. If you want your code to compile and run on a human machine, you need to make an emotional argument for why. You need to start here. Because if you just start off with like, please unzip your sleeping bag and consider putting on shoes and then unzip your tent and then move in an orderly direction, north-westerly. Like they're already halfway in the jaws of the tiger that's invading the camp. Like tell them, oh God, it's a tiger. Like numbers are nice, but something stories are more visceral. Images are great. One thing that I like to do is spreadsheets are okay, like they convey information, but they're not really emotionally moving. Maybe consider taking a pile of Hot Wheels cars and being like each of these represents a Tesla that we are wasting in money by not doing this. Maybe if you are saving them time with a new pipeline just to say, okay, we're gonna sit here for 10 minutes, which is the current length of time that it takes for our tests to run. That would be miserable. But then you're like, and now it's 10 seconds. Yay, everyone's like, oh man, that's a test. Okay. So really good arguments for what are tigers? Our recent pain. Do you remember that time where you spent two weeks, try, no it wasn't two weeks, it was two days, trying to rewrite a module for a customer, but it turns out that one of the consultants already had written it like, oh, you could have not had to deal with that. Oh, other people's pain. Like, mm, yeah, Equifax, that was fun. Sure, hope that doesn't happen to us, right? Future threats, these are government mandates, like, hey, we gotta comply with GDPR. Getting hit with government regulations is a pretty threatening thing. It's a good tiger. Competition, if we don't adopt these changes in practices, then we're just not gonna survive in the market. And my personal favorite is existential crisis. Misalignment with self-identity. So for that first one that I did, it was really easy because I was like, hey, we're an automation company. Why the heck are we having to go through these manual processes to find information about our customers? Is that who we really are? Does anyone here want to be called a hypocrite? Like, I get like stomach knots just thinking of that one. Okay, so maybe you're like, yeah, we're a customer focus, top of the line. All right, you've pointed out the tigers. We also need to see the glorious puppy, laden future that lays ahead of us once we adopt this change. Again, you're really going for an emotional impact. As much as I wish that people really cared about data quality, they don't. What they do care about though, is going home on time and like not stressed out because they didn't have to stay late reworking a project for the customer because you missed the deadline, because the first time you did it, you didn't get it right because the data was bad because your data quality was crap. Like, going home on time is what matters to people. Make it about them. Make it an emotional argument again. Easier work, less work. The work you're doing is going to be more interesting. These are all really good arguments. To be clear, continued employment does not mean do it or else I'll fire you. It's more along with those like, hey, if we've got regulations or if our competition is coming for our lunch, if we do this change, we will stick around long enough to be able to continue working with each other and we like that, right? If they don't like each other, this is a terrible argument. The greater good, like if you've got a green initiative or if you're doing something that will improve the community around you, those are good arguments. And again, that self-identity, our little Wikipedia, Facebook, business baby allowed us to not only track what everyone was saying about the same customer, but it also allowed us to have the fun stuff. Be like, hey, now we can coordinate magic, the gathering tournaments and karaoke parties. And who likes karaoke? All right. Okay, so we know about the tigers laying in weight. We know about the kittens and the puppies in our future. And now, third step, knowledge, how to do your change. Never, ever start here. If you start here, people will zone out, they'll get bored, they'll panic. These are all terrible things and you're getting people to hear what you're telling them. Who's seen someone come up and say, hey, we have added a dropdown menu to JIRA to track the origin of bugs. Please, when you're creating a JIRA ticket, select if you found it or if a customer found it or if there was this, whatever. And then like six months later, they don't have the data they want because no one's used the thing and nobody even remembers what that dropdown's for. It's not because they don't know how to use a dropdown. They just don't. Oh, oh, okay, I'm gonna tell another story here. Got the military background, so the tigers for me were always like, do it or else you'll do push-ups. But it ends up, one of the very first things my manager asked me to do was, hey, we need to move the consultants over to be with this other part of the company. Can you make that happen? I'm like, just ma'am. And so it was perfect. I'm like, okay, so this is the optimal layout for the way our teams work and if we move our desks in this specific order, then we won't have log jams in the hallway and boom, this is gonna be the most perfect, smooth move across the office that has ever happened in all the two months we've been here. And so I sent out this email with all the how-to's and the why. And I was like, because we were told to. And they're like, but I have such a great seat here. Like there's the window, I'm like, yeah, but there's windows on the other side too. Like no, no, no, but there's this tree and there's this bird and like this bird and I'm like, we're friends now. I'm just like, what's going on? All right, never, ever start with the details. Much to James's point earlier, we do not all learn the same. We all have different learning styles. So I really want a lot of us learn really well from reading. I really want you to fight your inner, read the freaking manual list because not all of us learn that way. So I tend to write my docs as I'm making my change and process or tool or whatever I'm building. But there's also people who learn better by hearing. There are people that learn better by getting hands on. There are all sorts of different learning styles that we need to account for. So if you're not into like this kind of mode, maybe you're more visual, boom, gotcha. This looks like a lot of different ways to present the same information, doesn't it? Who's going to like write seven of the same how to use my tools? Cool. My favorite thing to do is to combine stuff. So when I launch a new tool, my favorite way to get this part done is to hold a class. So the people that learn best by hearing hear me talking about what to do. The people that learn best by getting hands on, get to walk, go through it hands on, and get immediate feedback. People that learn best in groups are surrounded by people and they learn best that way and that will actually help stuff stick in their brain. But I'm also recording the thing. So the people that learn best on their own can take a step back and do this on their own time. Boom. I think that's all of them. Consider recording a live class. Get the help of a Doc's friend if you've got one because they'll help you make your talk better. All right, also ability. Even if people read like how to use Kubernetes, like it's not necessarily, they might not believe that they can do this, right? People might be afraid. So it's really helpful to give them someone that they know and like and say, hey, you wanna be like Mike. You wanna walk them through story-wise, like what are the steps that Mike does to be as successful as you wanna be? And it's not just Mike troublesheets, give them playbooks, that kind of stuff. That being said, the easiest changes to adopt are the simplest. In change management, Parlensis is often called clearing the path because every little bit of friction that someone comes up to in your tool with your new process is a barrier to entry. They will feel bad about themselves and abandoned. Who wants to do something that makes them feel bad about themselves? Try and make things as simple and smooth as possible. Even if we know how to do it, even the geekiest of us get tired and we like our fiddly bits. We don't wanna have to memorize all the knobs that it takes to make like finance software work, right? Like we just want to go in and say here's my new direct deposit account, boom, the end. So when you're going through the ability stuff, give them a success story, clear the path. If management says that you can't use a tool, you don't have the ability to use a tool. I learned that one the hard way too. My favorite part on this is subverting imposter syndrome. A lot of the reasons that changes don't work is because the people don't know why they should change or they know how to change and why they should but they don't think they can. One of the tools we rolled out was an HR information system and the reason we chose it was because it was so simple. Anyone could be like, I need to change my dependence. Oops, I accidentally did it perfectly because it was so clear. We're like, yeah, cool, ship that. But there was this one part. The time management portal was time warped from 1993 and it wasn't necessarily terrible because the people who had to submit time sheets were like, oh, okay, it's ugly but I can figure it out but the management, there were secret handshakes and fiddly knobs and if you didn't do it exactly perfectly then there was no way to approve your time sheet or it looked like you approved a time sheet and then it didn't happen. Yeah, it was terrible. So everyone knew to go to Confluence when they reached a trouble. Oh, what's going on like that? We didn't have a lot of those pages because the tool was so good except for that one and it's like, hey, if you're here, it's not you. It's the tool. Here's a gif of a baby monkey. Please look at it for as long as you need to because you're probably really stressed because it's not you. And then like after that gif of the monkey then we had all the screenshots and fiddly secret handshakes and knobs. Yeah, again, people don't like feeling bad about themselves. Hooray, you launched it. Everyone is aware of the terrible things that'll happen. They desire to make their world better. They know how to and they're able to fix it. We're done. Who's had a change where like it all went pretty well and then nobody, like they just withered and died like your soul. We are all human. We all have lots and lots of things going on in our worlds. And so we need to be reminded. This is DevOps, so we like metrics. One of the great things about metrics is when things go up and to the right and you say, hey, that change I did, things are going up and to the right. People are like, oh, that's good. Oh, crap, I was supposed to do that. So metrics are a great reminder. So is iteration. Iteration is one of my favorites because you can launch something that's mostly baked and then you can come back very quickly and be like, hey, that tool, we heard that you didn't like this one aspect and so we fixed it. They're like, oh, oh yeah, that tool, I should go do that. But you're also sending the message that we are committed to this. It's not just a one and done. We are going to iterate and we're going to listen to you and we're gonna make it better for you. People are gonna be like, oh, wow, they really like me. And I'm like, nice, I should maybe be nice back and do that thing. Oh yeah, and also actually just put it on your calendar. Commit to doing the iteration. Follow-up checks, if you're able to see who's logged in or which teams have implemented your pipeline, go and check on them. And if they haven't, they're either afraid or they're busy. The fix for both of those is help. Offer it. And then onboarding, new people are a font of enthusiasm. Hack that. If you can get someone who is new and terrified that they're like not going to be the genius that they said they were during their interviews, but they're able to succeed right out of the gate with your change, they're gonna be a huge fan and they're kind of gonna be like, man, that tool's really cool, right guys? Right y'all? And that will, one, increase your adoption. They might even become a new evangelist for you. And yeah, also if you're able to end of life support for the previous way of doing things, do that. We don't always get that benefit, but if you can, use it. Summary slides, okay, so if you like to take pictures of summary slides, now's the time to get out your camera. What did we talk about today? We talked about the ad car model, which is awareness. Point out the tigers, what are the terrifying things that'll happen? Puppies, desire to fix the terrible thing. Knowledge on how to fix the terrible thing, ability. And reinforcement, because we are all human. We forget things, we need help. If you have enjoyed this topic and would like to learn more about it, here are three books that I thought were super useful. That's an interesting color. I'm assuming you've all taken your, nope, okay, cool. I keep telling myself I'm gonna come up with like a short knock-knock joke that I'll remember to say during this slide, but I don't, so laugh and pretend that it was a great knock-knock joke. All right, thank you very much, Boston. Is it Q&A stuff or are we good?