 I think the sponsors and the organizers of this event deserve a round of applause, too, because I'm sure everybody here has learned enormous amounts in the last two days. So we have a round of applause for our organizers. So I hope that you learned something. And I know that you're probably sitting here thinking, wow, now you're going to tell me about how I go back to my company. And I get them to implement some of this stuff. And I'm kind of sorry about that. But I'm going to tell you about my experiences and what I've done and what's worked for me might not work for you. I'll do my best. I'm an operations engineer at Workday. Workday is relatively new to Boulder. If you want to talk to me about Workday, interested in the company, come talk to me after this talk. This talk is not a Workday talk. This talk is about leadership. And it was originally titled Leading Change as an Individual Contributor, because I think that a lot of folks don't see their own ability to affect change in their organizations. And so I wanted to talk a little bit about my experience and how I've been able to accomplish that. I tend to work with development teams who are new to continuous delivery. They're new to continuous deployment. Sometimes they've never heard of it. And so I spent a lot of my time educating folks and working towards what I think we're all trying to do here. So what is grassroots leadership? It's from the bottom up. DevOps Day is a great example of it. So it's a group of people organizing around an idea and trying to find other folks who are interested in leading the charge and making something different. Doesn't require authority in most organizations. Doesn't always require that your project be prioritized. It only requires a willingness to help others by facilitating often. That's very often how I'm helping other people is how can I help? What can I do? Can I create meetings? Can I take notes? Can I start the ball rolling in some direction? And the quote at the bottom is attributed to many people, but it is truly amazing what you can accomplish if you don't care who gets credit. I had a conversation with an engineer, I don't know, it was a month ago, who was complaining to me about involving a particular person in a project. And their complaint was that that person always takes credit. And this person's in senior management team and to me, that's great because I'm not in this for credit. I'm in this to tell a story and they can't take that away from me. So I can leverage those people who want to take credit. Great, come in, attend, help. I'll get you to do work. So why would you want to do this? You might not, but in my past, about eight years ago, I became a manager and I thought at the time that being a manager meant leading a team, making decisions, getting things done. And my team grew from three people to nine people to 12 people. And I got crushed. First time manager wasn't able to deal with the complexities of the environment and everybody expected me to make decisions because I had put myself in this position of making decisions. And I re-quoted from management and I said I never want to be a manager again. I'm going to go back to be an individual contributor and I'm not going to do this ever again. But I still did want to affect change and I still wanted to be able to go into organizations and tell them what I learned and make things better. And so I did. And over the years, I've sort of become more effective at this, still learning, I think everybody does. And I just want to say that sometimes it doesn't work. Sometimes you're in an organization and you're trying to do something that they're not ready for, missing dependencies. You can't, you shouldn't do continuous deployment before you do continuous delivery or before you do continuous integration. I mean, you can, but you might be sad. If you're in an organization that makes this impossible, there's organizations that are very top down focused. They don't want people from the bottom making decisions. And if you're in one of those organizations, I'm sorry, this might not work. And it might not be the right idea right now. It could be a super great idea to bring Docker into your organization but depending on your product, it might just not be ready for it. It might not be ready for that sort of technological shift. As I go through this process though, my goal is always to find the right solution for the organization. I'm looking for what's right for them. And sometimes that means that my idea is not right and that has to be okay. There was an open space yesterday about changing corporate culture. And so I tossed this slide in there because I wanted to address one thing. I think depending on the size of your organization, you may or may not be able to take this very far up into the organization. Larry here, he might care a little bit that you got the DevOps, but he probably doesn't care that much. He cares about very different things. Most CEOs care about very different things. There's some midpoint in the organization where people start to care a little bit more about the things that you're interested in, the things that you care a lot about. And you can probably affect change up to that point. And oftentimes you can make your life a lot better in the process. So there's some guidelines that I have that I've learned over the years. The first one is change is really hard, don't be a jerk. If you've worked with me before, you've probably seen me be a jerk about it. It takes a long time and lots of folks have lots of struggles with change. And I'll talk more about what those might be, but if you're a jerk about it, Jeff Hackert has some great talks about this that I'll have a link to at the end of this. No one listens to you when you're a jerk. So try to be helpful. My favorite phrase is how can I help? And I don't know. I like those two phrases a lot. They give other people the ability to come up with ideas and they help me not be so responsible for the outcome. Second one's really important is consider the impact on the influence that other people have. If you're in an organization that's doing something a certain way, then changing that has an impact on some people. You may not realize it. And this is part of what I'll talk about, but the agency that an individual has in an organization is really important to them. They care a lot about that. Picture me, I'm the SVN guru in my organization. I'm not an SVN guru, and someone's talking to me about bringing Git into the organization. Now everybody comes to me every day and they ask me SVN questions and it makes me feel important and I identify with that. And I think that that's a really cool part of my job is that I get to help other people out. And if you change to Git, I don't care at all about the technical merits of Git. I care that I lose that ability in my daily work to feel awesome. So be sensitive to other people. It doesn't mean that it's not the right choice, but it means that you should understand that these things exist and that other people are impacted by them. Third is related, but understand why the current state exists. There may be a lot of good reasons why today you're not running inside containers. One of those reasons might be that two years ago they didn't exist. Another reason might be that it's just not a good idea. It might be that somebody tried it six months ago and you didn't know that. There's a fascinating journey that you can go through at most organizations by just trying to understand from the inception to now how their release and test and deployment process evolved. I went through this with a past organization talking to developers about how did they get from this eight week release cycle to what was at that time a one week release cycle and we were working on continuous deployment. The various phases of that are fascinating, but you also learn how decisions get made through that process. How do people get things changed in the organization? What are the catalysts? It's a neat journey. And the last one's changed is hard. It takes a long time. You need to be patient with other people. There's organizations where people have been there a very long time. Their jobs are tied up in how things work. It takes a really, really long time for some people to come around. That's not to say that you shouldn't be trying to make things different, but you should be patient, okay? So when you wanna bring in something new to an organization, you have to start out by seeding that idea. Usually, for me, it starts with some idea in the shower or wherever I'm at. I'm like, hey, this sounds pretty cool, or it's a hackathon or whatever. So when you come up with this idea, you can just build it. And if you have an idea that you can just build and be awesome, then go do it. Like this talk isn't anything about that. This talk has to do with you needing other people to help. And if you need other people to help, then you need to talk to other people and understand how they view the problem that you're trying to solve. Do they see the same issue that you see? Do they see the same potential solutions that you see? That's a good place to start. Demos at hackathons, if you have hackathons, are a fantastic place to sort of spread the fact that you've done something like this. Second thing you wanna do is talk to those who might disagree. This is a super important step because back to understanding why things are the way they are today, the people who put those things in place might be people who disagree with you. The other thing is when you're sitting there talking about this awesome new thing that you're building or this awesome new process that you came up with, be really careful about bashing the way things are because the people that can help you understand why the things are the way they are are the same people that probably made some of the decisions that led to the way things are. So if you're sitting there talking about how crappy the current thing is, you're turning these people off, who can help you? Third, understand why things are the way they are. You'll learn that from talking to people about what they disagree with, what they agree with. Some of those people are gonna share with you why things are the way they are. But I've said this twice, it was in the past slide, it's super important to understand why things are the way they are. Doesn't mean you shouldn't change, but when I'm talking to someone about now it's okay to do this new thing that we wanna do whereas two years ago it wasn't okay to do this thing that we did then or the route we're doing now. You need to understand what changed. What's different now than what's two years ago that made that okay and this is okay now? And you might need to build your own prototype. So this goes back to hackathons. Many, many of the things that I have done and over time have been ideas I had that I couldn't really express to somebody. Hey, it'd be really cool if we had the ability to do this. Now again, it's pretty good, sounds neat, you know. When you build it and you show it to them at a demo and you come up with a use case that's actually compelling that is much more powerful at getting folks to join your plight, right? Help you out. And it's a good way to find people who are willing to help join your team and help affect the same change that you wanna affect. You should demo. And usually it's embarrassing, but it's good. I've had a number of cases where I built something that was not a feature, it wasn't scheduled work, it wasn't prioritized projects, but at the normal sprint demo, I demo it, right? We don't have a hackathon, I didn't do it during a hackathon, I did it in evenings or an hour or two before work, I was working on this thing. And so that was my only chance to show it to people and those things, some of them have turned into tools that large portions of the development team have used. So it's really important to share what you're working on, what you've done, tell your story. So as you move forward in this, if your project is of any substantial size, you're probably gonna need to talk about early adopters, you're gonna need to understand more about how people are gonna use this thing that you want to build. Maybe you built something, you put it together for your own use case, and now you're using it, maybe you wanna get a second person to start using it or a team to start using it. You're looking for these folks who are early adopters. You should be looking for these folks during your demos, you should look for them in those conversations that you had. But when you bring on that first early adopter, you need to be really aware of this trough of disillusionment. I don't know how many people feel like they've brought in a new project and understand what the trough of disillusionment is, like that period of time where stuff just feels like it's not gonna work, right? So you come in, you know, like I have this fantastic new idea, we are gonna do this awesome stuff with whatever it is, and everybody's super excited about it, and you sit down and you start doing it, and suddenly that awesomeness really fades because you're like, oh, this doesn't work, and that doesn't work, and this is broken, and that's broken, and oh my god, this makes it slower, and that's the trough of disillusionment. And not only are you going through this as the person whose idea it is, but your early adopters are going through it too. They've put their project, probably on the line, to help you out by adopting whatever it is that you're trying to get them to use. Let's say you're coming up with some new deployment process and you have a development team who wants to adopt that. If your deployment process sucks at the beginning, which it probably will, they're gonna be impacted by that. And so part of this process is being aware that this exists, but the other part of it is giving your early adopters super amounts of credit for helping you out in this process. So in the past, when we've done this, talked to development teams, they've become an early adopter. When I talk about at demos what it is that we're doing, ideally they're talking about it, but if I'm talking about it, they are the most awesome team in the world. And if something goes wrong, it's all my fault. And that's an important tool in making it easier for them to adopt and put up with this period of time where things are not good. So once you get past this trough of disillusionment, things are starting to go better, you've got an early adopter who is finding success with whatever it is that you built, you gotta keep telling that story. So this is more than a demo, this is giving talks. If your internal, if your company has internal talks, if you can do it at demos, you can do it at post hackathons, talk about what you did. How did you get there? Where did you start? Where did you end? What were the problems? Be honest. Be super honest, because there's more people if you've got a good idea sitting in your audience who are waiting to hear about how this thing can help them and they wanna understand, okay, what's in it for me and what is it gonna cost me if I try and try this thing with you? Expanding support. So this is sort of the success disaster part of the story where you have your early adopter, you maybe have two early adopters, they're going along pretty good and now all of a sudden you've got 15 teams who all wanna do this. And scaling from the point where you've got one team doing this to 15 teams doesn't happen when you are one team supporting them, right? Deployment processes and deployment tools are a particularly good example in this case because usually there's a ton of support from a tools team or something like that to an early adopter and then as time goes on you really want those development teams to be able to change it in the way that they need it to change and you don't wanna be responsible for doing that and you really have to manage how many early adopters you bring on before you have those problems solved before they can actually contribute to solving their own problems. And so mostly this is about pace, keep, push back a bit on the early adopters. It feels great when 15 teams are like, hey, we wanna use your stuff but make sure that you're supporting the first, second, third teams that you're supporting and understand that for every additional team you bring on if that first team who took a big chance on you and up took your stuff, went through that troffa disillusionment, if they're still not completely on their own at this point you have to support them and moving on to a second early adopter gives you less time to do that and moving on to a third and a fourth even less, right? So be really careful about how fast you do this and ideally the goal is that you don't. You help a couple early adopters and then you make it possible for other people to onboard themselves. And that's really what the last bit's about. In particular with tools teams, something that's really, really hard is building a tool and then not being responsible for it into eternity. And I would caution you against being put in that position, our organization has a number of tools where it's like, oh yeah, this really important tool that I use every day is down. Who do I talk to? There's one guy, 6,500 employees, one guy who has to deal with it. And it's bad, you don't wanna be in that position, right? So as part of your expansion, as part of taking on additional early adopters you really have to think about how do I move away from this project? You came up with one good idea, you built it, you got people to adopt it but you really need to move past that point and come up with other ideas, support other things. If you really wanna be in the business of supporting this, then great but I would caution you against that. And then here's a couple more blog posts that I think are relevant to read. The first one I really like, it talks about effectiveness and engineering effectiveness at Twitter. And what I really liked about that blog post was the fact that in reality, things play out, right? You have all these different teams who do different things and they build different tools in different ways. And as your organization grows, that becomes really, really hard to scale. And part of this process is allowing that to occur but then managing it. And that post does a better job than I can. Second is a post I wrote for SysAdvent which goes into a bit more detail than this talk does about this topic. So you're welcome to read that. And last one is Jeff Hackertalk that I really, really enjoy and that I think goes into a bit of detail about dealing with change in organizations and how not to be a jerk and Conway's Law. My contact information at this point, I have no idea how much time I have left, probably a fair amount, but I'm open to questions. Great, thanks.