 So, this talk here is about changing culture in a very large organization. So, I guess if I turned my clicker on it, it would actually work. There we go. My slides are on the internet. I'll get them to conference organizers as well. But if you remember, speakerdeck.com, so it's not speaker net, it's not slide share, it's speaker deck. And then Jim Holmes. And I think the most recent version is up there. I changed slides minutes before talks, but I think I got a fresh version up there. So, that's really the only thing that you need to remember about the slide deck. I'm Jim Holmes. I am a executive consultant. I have both my own company, Guidepost Systems, and I work for a consulting company out of Columbus, Ohio. Used to live in there there called Pillar Technologies. But you can email me with questions that you might have about the talk, about the subject. I absolutely enjoy talking about a number of different things. So, if you have questions that come in your mind afterwards, please just drop me an email. I'm also on Twitter, A. Jim Holmes. I'm not B. Jim Holmes, I'm just A. Jim Holmes. And I blog at frazzledad.com. So, frazzled meaning excitable, worn out, exhausted. I have two children and while my wife was in the military, I was at home with both of them as they were young babies up through school, which is why I'm frazzled and also why I have a lot of gray hair. All right, so, oh, I also wrote a book called The Leadership Journey, which is on Lean Pub. So, some of the things in this talk are covered in that book as well. But if you're looking for help on understanding how to become a better leader, how to become a leader period of kind of small to medium teams, you might find this book interesting. But you're here for a story. So, whoever said storytelling was important, here's a story. About three years ago when I came to work for Pillar Technology, they brought me on to help with one specific customer. And it's a Fortune 10 company. So, if you know the Fortune 1000, Fortune 500, this was a Fortune 10 company. So, something like 220,000 employees scattered across 90 different countries on every continent, although I actually don't think they had anybody in Antarctica. And if they did, I didn't wanna go there. So, I wanna make sure everybody understands here's a pie chart showing my involvement in overall cultural change at this company. I was one person amongst a consultant, amongst 220,000, and it's a little difficult to see my impact on the change. So, here's a little blow up. And I wanna, I throw this out here because I want you to understand the context. I was part of a small bit of change across a huge organization. I like to think I had a little impact, but mostly it was being around people that were energized and had good ideas. I gave them some help and some ideas on how to do things. And we ended up having some really significant change across the entire organization. So, that's kind of what I'm here to talk about. So, three years ago, I was brought onto a project and they said, oh, you're the automation guy. We just need some help writing web driver. All right, so I've been consulting for a long time. I've been doing testing for a long time, development, whatever, it's never just about technology, right? There's so many other things and that's part of what the story is about is talking about the various issues, roadblocks, other things that we had to address. So, one of the first things we ran into when I got into this program was bureaucracy. And so, how many of you work for what you would call a large company, say several thousand or more employees? Okay, half two thirds of the room. So, you were probably very familiar with bureaucracy problems. I didn't get my laptop, my work system that I was supposed to be working on as I was coaching and writing code for 10 days. I didn't have a system to work on and I got my system in 10 days and other people on the team said, I can't believe you got it so fast. What? So, bureaucracy at this organization and by the way, I can't mention the name of this Fortune 10 company because it's a big global company. We had non-disclosure agreements but it was a very large auto manufacturer who makes really awesome sports cars that are named after certain horses. We'll just leave it at that, okay? But I can't say the name. Forward. So, bureaucracy here was horrible. Infrastructure, servers would take months if not years to get for your team. And I'm not even talking physical servers, I'm talking virtualized servers. So, the notion of being on a agile team that controlled your own environments, laughable, totally gone. Those systems were not even managed within the team. You had to file tickets to look at logs on your development system. That kind of makes it difficult when you're trying to rapidly iterate, when you're trying to do test-driven development, when you're trying to troubleshoot things, you file a ticket and three days later, somebody will say, yep, we got your ticket. You got my ticket, what about my logs? Oh, that's gonna be another week, look at the SLA. So I'm hearing a lot of painful laughs out there. Is this unfortunately familiar with some of you? Yeah, so there's some nodding heads and some hands going, yes, that's me. All right. Continuous integration, continuous development, continuous delivery, laughable. Jenkins was not allowed. There was a vendor locked in tool that was centrally controlled for all builds. So again, I had to file tickets to get a build job definition done. And kicking that job off was a nightmare. So the idea of fast feedback loops of trying to get a team to work quickly, solve problems very fast, it's just not there. So at the heart of every problem are we humans. We're wonderful, awful people who have our own set of struggles and our own dynamics. This large organization had their software development skills that were born out of, remember this is a manufacturing company. So everything, even though this is the IT side of the house, all of the culture and mindset came from managers who had come off of literally production lines building automobiles and thought they understood how to run software development. Now there's interesting experience that you can draw on but we'd run into all kinds of skill problems. Now in addition to this general philosophy disconnect, there were just poor technical job skills. And I'm not talking just about writing bad web driver code, I'm talking about not understanding how to build effective test cases. About not understanding how to say determine good boundary value test values about simple basics of testing or software development. So I drop into the middle of this and find that not only are people not empowered to change how they think, how they work, they're not expected to. So how many of you here know the phrase, oh we empower our people to do good things? Okay it's a common phrase, we empower you, we wanna give you permission. That's nice, how about expecting you to do better? There's a big difference there, there's a big difference there. So forget the expectations, these people weren't even empowered to change. Who here knows the term FUD, F-U-D? Nobody. Okay this is gonna be your big takeaway from the session. FUD, which is a very inter, who here knows of Maslow's Pyramid? So a couple hands go up. All right, Maslow's hierarchy defines basic needs and it's this very interesting philosophy of kind of what drives we humans and how you can move up this pyramid to actually get to a point of self-actualization where you're feeling that you're happy and you're overjoyed not just about your job but about life in general. But down at the very bottom level of this, if you can't solve things lower in the pyramid Maslow said forget about trying to get to the top to the pinnacle. And at the very bottom is simple survival. Am I gonna have a paycheck? Can I feed my family? Can I feed me? Do I have a house? Part of the people problem in a large organization, actually even in smaller organizations as well, when you're trying to change something, you have people resistant to that change. And that change, that pardon me, that resistance can often be captured under the term FUD and this stands for fear, uncertainty and doubt. And it's a very powerful notion. I'm scared to change because I'm worried about will I still have a job? Test automation in particular drives a lot of fear. You're asking me to automate myself out of a job. No, but we'll have to, I laugh about this but I run into this all the time over many years. But their first reaction is, how am I gonna feed my kids? And that's not hyperbole. That's not me trying to overstate or make a humorous or dramatic point. This is basic human instinct. So we talk about pupil problems, trying to inject change in this large organization. They're uncertain of what is supposed to be done. They're doubtful that they themselves can do it and they're fearful because they're not sure if you're trying to be sneaky and change things where they'll have to go find a new job. So five thumbs. Maybe may not be a term you understand but the concept is sure there. So one person, the Maharaja or the Raj builds their power around their domain that they know very well. They build a castle, they build a beautiful temple around their power center. And the problem is that first off, they wanna hold on to that power and secondly, it's generally not as great a temple or castle as you might think. And so there are all these problems where people are trying to protect their particular issue. Centers of excellence, architects, infrastructure owners, right? Policy and compliance guideline people who don't directly contribute to your day-to-day delivery value but can impact it because you have to break down the walls of that five thumb. So also at this particular organization we're a huge number of cultural issues. I mentioned that it's a auto manufacturer. So think about mechanical manufacturing. There is great predictability there, right? So if I have a supplier of ball bearings, I can measure defect rate of those ball bearings across millions and I get a predictability rate that's very reliable because it's based on engineering data, right? And the same thing for putting out cars on the assembly line. We understand that through these many cars we should have these many defects or problems and it should take us this long to resolve them, all these sorts of things. Does that apply to software? No. But they had an entire branch of about 30 people who gathered defect rates and would tell you what the predictability for defects for your project should be. And I sat down with them and they're awesome, nice, engaged people who wanna help stuff and I said, so this is really interesting. I get from the manufacturing side how you can come up with predictability rates. How do you differentiate between, say, a mobile project where somebody's focused mostly on developing apps for tablets and for the onboard system in the auto versus somebody who's building a back-end API service versus somebody who's building a database layer? And they said, oh no, it's just all software. So all those defect rates will be all the same. I only had that meeting once. But this was a problem, right? Because there was this mindset about predictability and other things that was totally understandable because it came from the manufacturing side but people just didn't understand about bringing it over to software. And then meetings, meetings, and more meetings to the point where it just got very painful to like attend any meeting because there were all low value with few outcomes. There was also the issue of not being honest with themselves about what it was gonna take to change because everything was there about delivery. Deliver, deliver, deliver. Oh, are you gonna change? Nope, we don't have time to change. By the way, all these images I have, the different places I stole them from the internet so I do have attribution there. All right, so the first version of this project that I'd been on had released once in three years, shipped to production once in three years and that was not in common. Now, this was not a tiny little website or something. It was a fairly significant piece that involved day warehousing, a lot of other things, but one time shipped to production in three years with over 250 bugs in production. That was 250 open bugs, by the way. All right, so how do we go about changing that? First off, it's not easy, but what I'm hoping this session turns into is something that will give you a number of the failures that I had, a number of ideas about ways to look for places you might be able to help change at your own organizations and some ideas around that. Does anyone here know the tale of Don Cahody, the man from La Mancha? Okay, so this was a Spanish novel written in the 1600s so I don't necessarily expect you to have read it, but the story of Don Cahody is very interesting. One of the characters in this book, Don Cahody himself, is known for tilting at windmills. So it's the 1600s, he rides on a horse, he puts on his armor, he gets one of those big lances, and he attacks windmills. And you're thinking, this is really crazy. Well, it's kind of point of the story. Don Cahody loved battles that were futile, that couldn't be won. And there was this expression when he'd see a windmill off in the distance, he had his sidekick, whose name was Sancho, and he'd yell, Sancho, get my armor, and that meant that he was gonna go after a windmill in yet another futile or pointless battle. So not everything about cultural change at an organization has to be like Don Cahody. It doesn't have to be this pointless battle. You can indeed make change, but there are ways that you have to think about it. This is a picture of Archimedes who invented the lever. Well, he didn't invent it, but he spoke about it. So Greek philosopher, Greek scientist, mathematician, whatever, and he said, give me a long enough lever and a fulcrum, that's the point that you place the lever on, and I can move the world. Now, if you could actually put a fulcrum out in space, I mean, this is actually a true scientific principle. You can move any object with the right size lever and the right fulcrum. So big organizational change may seem like this thing that you can't accomplish, but you can indeed, you just have to reframe some things. So first off, roadblocks. I'll talk a bit about, so let me take a quick tangent. I've been thinking about this talk for months, and I still don't feel like I've got the delivery exactly nailed because what I'm trying to do is both illustrate the situation I was in, the wins and the losses, and also give you good ideas that might help you change your own environments, and I'm really hoping this doesn't just come across as a tale of woe and sadness and grief about all the failures I had. I'm trying to make sure it's somewhat positive. So roadblocks are gonna be a fact of life no matter what you do, and roadblocks to me are about overcoming inertia. How do I get something that is set in place or stuck in the mud? How can I get that thing to move? And there's a lot of different things that we have to think about this. So those organizational policies that I mentioned are one of the first things you'll have to look at. Now in our particular case, and this may be the case with you as well, there may be certain legal and regulation requirements that mandate how certain things that happen. At this particular company that I was at, in the US, labor laws report that you treat company employees differently from contractors. So this large global organization had hired in thousands, tens of thousands of what they called agency folks, some for like staffing people. Look, we've got a project, we need 50 developers and 20 testers for the next two years and they'd get that staff from a different company. Make sense? And it's a model that I'm probably a number of you are engaged with right now. Well in the US, you can't actually train or provide training to those agency staff like you do your employees. And this is due to silly labor laws. Now can I as an independent contractor from outside the company change that policy? No, I have zero chance, right? So I have to figure out how to move around that one particular policy. Again, some of these policies may be based in labor law. Some policies around say deployment to production may be mandated by regulation. In the US we have things lost from Congress that came down around financial messes we've had in the past that mandate a separation of concerns that actually impact on how you can deploy to production because every nation should have their Congress or parliament or whoever deciding on how I can deploy to production, right? So we have to recognize those things. We have to determine how to deal with them. We also have to deal with those fiefdoms, those groups or individuals who have gathered power and influence over a number of years and are concerned about losing that power. Architects in this particular organization were a very strong group of mobsters or gangsters. I may have some strong opinions on this. They would not tell you, but they viewed their job as slowing progress to make sure that it aligned with what they knew and how they knew to do things. So when you come in and talk about wanting to install Jenkins just so that you could get your local development environment going faster, there was a huge concern because you were taking away from their domain where they controlled all of those services and they'd lost sight of what their role really should be and this was one of the hardest things that I had to deal with not just on my own program but as I got into other programs was learning to have conversations with these architects and get them to understand that things needed to change. The company was struggling very badly because of its inability to react quickly. I mean, when it's taking a year to get a server or 20 days to get someone a system, how in the world can you deliver software fast, right? You can't. So the point became the discussion with the architects of Loosen up a little bit and get in your mind that you can become known as the go-to person in this entire organization of 100,000 IT people. You can be the one person to help people quickly navigate and solve problems around how do I get my infrastructure quickly? What services do I really need from the central service group and what can I do without? And how can I quickly identify those and adapt to them? And it took probably a year and we got about 75% of the architects that we interacted with on a regular basis to understand that. The other 25% were just not gonna change. They were incapable of changing. They couldn't see kind of past their little castle that they had built up. But this is one of the things, one of the roadblocks that you have to start to identify to deal with. So I talked about people, I talked about FUD. They're worried about losing their power. They're worried that they aren't good enough that as things change, right? We're involved in technology. Is the technology you're working with right now the same as you worked with two years ago? Likely not. So people get really, really scared of that. How am I gonna keep pace? So one of the conversations you have to have to ensure these people will not just be a roadblock, but jump on, is learn how to talk to them and learn the things that they need to feel safe. Do you need more training? Can you come to lunch and learns? Can you sit down and pair with me and I'll show you how this works so you're more comfortable with it? And then just flat out poor skills. As I said earlier, many of the skills of individuals if not entire organizations were 20 or 30 years out of date. No understanding of test driven development. No understanding of software craftsmanship principles. You wanna talk to exploratory testing, no idea. Couldn't even do basic test case generation for testers. So it was a really bad spot. So how do you get around that? You start to do things like helping them assess their own skill level, right? But when you start to talk about, hey, I'd like you to take this assessment and let me know where you think you are on this. What's one of the first things you're gonna immediately run into? Fear. Oh my God, if I'm honest on this assessment, it's gonna show how bad I am. Well, no, that's not the point. I wanna help you get to a point where you feel good about your own skills and you are contributing in an extraordinary fashion to this team. All right, so what's that take? That takes you stepping back, understanding their fear, understanding where they think they are on that Maslow hierarchy and constructing your ideas, right? Okay, I got an assessment, but look, here's what this assessment means. If you think you need help in this area, here's the five things I'm gonna do for you. You have to have all of that together when you first bring that up. Otherwise, what are you gonna do? You're gonna explode their fear. But if you say, I've got an assessment, you're gonna do the assessment, and then I've got this list of things that will figure out what works best for you to help you get to where we need you to be on the assessment. More importantly, not just the assessment in your actual job. Lots and lots of issues around that because we're humans, right? So some people are gonna hear that and they're gonna be okay with it. Some people hear it and they're not gonna believe you. Some people are gonna hear it and just not accept that they're good enough. So you'll get 80% success rate. This is a number I'm making up. And you're gonna have 20% that you're gonna have additional struggles with. But identifying those roadblocks and learning how to deal with them is crucial. So advocates, remember my slice there on the pie chart of .002568, exactly the amount of influence I had? You likely, especially in a larger organization, cannot make organizational impact by yourself. You need helpers. You need helpers at many different levels in many different areas. So one of the, if you're trying to make some change in an organization, one of the best things you can do is see if somebody else is doing something that's close to what you're doing and can you pair up with whatever that initiative is? If there's an existing initiative running already, that means somebody has budget. Cause everything at some point is gonna come down to money. And if it's not just cash, it is a willingness to commit time on the schedule and the resulting opportunity cost that comes about when we say, we're gonna take four hours a week to do training. If I'm taking four hours a week to do training, what am I not doing those four hours? I'm not shipping, I'm not delivering, I'm not writing new code, I'm not doing testing. I'm doing things which are gonna make that better. But so many managers, so many executives don't think of that long-term thing. They look at the immediate short-term gains. But if there's an existing initiative, that means somebody somewhere has gotten some approval for money and time on the schedule to do stuff. So can you be part of that initiative and use that initiative's power, if you will, to help you get the change you're looking for? We, on the IT side of the house, have for many, many years had abject failures to understand the business side. The business side has had abject failures to understand us. They just wanna lock us in a room and slide pizza under the door and get software out through the mail slot, right? Okay, but we also have to admit that we have also, pretty much forever, not paid enough attention to what's going on on the business side. So we don't understand the goals. We don't understand the revenue model. We don't understand who the real customers are. And we don't understand how some of our managers and some of the executives that they work for see success for themselves or for the organization. It's very easy for us to say, I just wanna sit in that dark room, get pizza under the door and write code and do my testing. And that's all I wanna know. But you're doing a disservice to yourself as a human if you don't understand that bigger picture. By understanding the business, it's easier for you to advocate for the changes you want. We're trying to not improve velocity because velocity is kind of vaporware and this weird thing that's intangible and different. Can't be measured across teams. Don't care about velocity, but when I can talk to management about cutting failure demand or about cutting waste or about cutting rework, all of a sudden their ears perk up. When you tell a manager or an executive that you think test room development and better testing collaboration across the life cycle will help cut rework, this now is music to their ears. They don't understand web services, XML, JSONified, XSLT, they don't understand all that techno blah blah, right? What they do understand is over the last three years, we've had a 30% rework rate. That means effectively we've lost one year out of the last three in fixing quality issues. All of a sudden their eyes start to perk up. Oh, and by the way, that's an actual story that I've had talking with CEO of a company where I was the director of quality and trying to make sure he understood why I was asking for changes. But when I talk to that CEO and I say, you have lost an entire year, what do you think about that? And like after his head exploded and he stopped yelling, then we had a good conversation. But by learning the business, you can be a better advocate for yourself. Find levers, archmedes, right? Give me the right lever, the right fulcrum and I can move to the world. But you have to find those levers and it's both at managers and executive level. So when I say managers and differentiate that between executives, I don't know what your hierarchy is in your organization, right? What I'm trying to kind of indicate is leaders around your team and then leaders well up in the business organization. The larger that organization is, the bigger the change you're trying to affect or have roll out, the higher up you have to go. And the thing is, if you're looking at something that you're trying to impact an organization of thousands, your manager may be the most awesome person and he may be a great, he or she may be a great advocate to have on your side. Can they make those impacts? Highly, highly doubtful. Which means you have to start working up that hierarchy and get to a point where you can reach executives who have influence and can say, yes, it must be done this way. And do you think you personally are gonna get face time with that executive? Likely not. And I'm not trying to downplay this and make it negative, rather what I'm trying to do is set the stage so you understand how can I find the people who need to make some decisions or who have some impact here. Okay, I need to talk with literally, or not I need to talk with, the CTO who oversees 50,000 people is the person who has to make this decision. I don't think I can send them an outlook, invite for an hour. Probably won't go, right? So how do I find how to influence that person? I'll have to talk to my manager, make a case to them, help their manager understand, help the department exec understand and eventually percolate it up. But finding those levers is critical because again, the more people you're trying to influence, the more people you're trying to change the beer, a change you're trying to have, you simply can't do it without that high level support. We talk about grassroots efforts, agile talk about self organizing teams, and that's all really awesome and I'm not downplaying that because it's important, but if you think that five self organizing teams are somehow going to change how everything happens across a group of 50,000 people, you're diluting yourselves. I probably came out harsher than I meant that too. So let me say this again, and hopefully in nicer fashion, it's just not gonna be effective, right? Certain things from the grassroots, you can absolutely use the success stories and you should, but it's not gonna be enough to have this grassroots effort quickly and effectively percolate across a whole organization, all right? So you take those stories and use that as an example, use it as business level, but you have to then go find the right people. That means finding change agents and those change agents may be the executives, they may be people down on your team because you're gonna have change agents for different sorts of things, those grassroots level, right? So rolling out three amigos conversations. Well, I don't need the CTO to sign off on that, right? We can just start doing that down at the team level. Who can I find on the team that likes having effective conversations? I get a few of those excited people, we'll figure it out and we'll go from there. That's great change agents. Maybe I'm looking to do departmental lunch and learns. Well, I need to find somebody who can help me get excited and make some things happen at the department, right? Finding the right change agents helps you because you get advocates, you get champions, you get somebody who you can commiserate with when you're running into roadblocks and failures because that's gonna happen. Okay, so the big thing is to keep yourself sane and you keep yourself sane by setting reasonable, rational, attainable expectations, all right? I can make, I can get all fired up about bringing mob programming to the entire IT organization of 50,000 people and it's likely not gonna happen or it's not gonna happen as fast as I'd like or it may not happen exactly how and where I'd like, right? But if I come up with a great idea and I run it through some colleagues, through some managers, through some other things and we set the right expectations, then when I run into struggles, I'm not getting so frustrated because it's taking six months to get one meeting with that CTO and nothing's happened. Setting rational, good expectations also ensures that you are not wasting your time doing things that simply can't be attained, all right? I happen to like C-Sharp because I've been in .NET for a very long time. At that large manufacturing company, they were the dictionary definition of bad enterprise Java. Well, okay, so I thought they'd be more effective if they moved over to .NET, a lot better tooling, blah, blah, blah. Is that ever gonna happen? No, it's unreasonable expectation. But what can I change there that is more reasonable? Well, I can start using inside of the Java ecosystem. There are tools that I can use to help them with better software craftsmanship. I can look at hooking up a Jenkins server even if it's just this little one computer that I may or may not have borrowed from one of the managers who wasn't using it. I don't know who moved it out from under their desk that one day, but it just suddenly appeared, hooked up next to a monitor and there's a Jenkins server and then we can start bringing in things like SonarCube and unit testing and some other things, right? That's reasonable expectations. In any change effort, regardless of how big or how small, you're gonna have failures. We're humans, right? We run into problems, we don't think things well enough. I've only had eight cups of coffee, sorry. By my way, my jokes don't get any better, so if you're looking for better laughter a little later on, it's just not gonna happen. So you are gonna run into failures and the thing is to take the feedback, why did that thing fail? So the company that I was at was a manufacturing company, right? An automobile manufacturing company. Long history in manufacturing. They've been going since 1900, all right? I found out when I was trying to get prototypes or spikes done, that the permission for that would get always, always get shot down. Look, I'd like us to spike out running Selenium Grid so that we can get our tests to run a little faster. No, we don't do prototypes, we don't do spikes. And so a lot of months of anger and a lot of whiskey were involved and all of a sudden in a tangential conversation, somebody said, oh, you know, they're big on experiments here and all of a sudden this big light bulb came on over my head. It's a manufacturing company. When you talk about prototypes or spikes, they think that you're just gonna waste time. But if I frame something in the scientific method that you learned in school as an experiment with the hypothesis, with test criteria, with an expected outcome, with a plan, I took that same exact idea for Selenium Grid. I swear to God, same idea, rephrased it as a scientific experiment, put it back to the same manager who disapproved it and they said, no, this looks great. But I learned from a failure there, I learned more about how the business culture worked, learned how to reframe and after another six or eight months we finally got Selenium Grid working. So here's the thing, you will fail, it will be frustrating, it will take a long time, celebrate your wins. If you get a Jenkins server up and running, yay, put it up on a dashboard, put it up on an information radiator. If it's something small, celebrate that. If it's big, have a party and I'm serious. So I mentioned that first version took three years to release, one single release, right? 250 bugs in production. On V2, we had the first ship released to production in six months. No, actually it was nine months. Okay, now to me, maybe to you that's crazy because it's insane, three years down to nine months, holy crap, that's big stuff. And we shipped again in three more months after that. And then the third release was a month after the second release. And I felt the bosses were not trumpeting that so well enough. They were not recognizing this extraordinary change that we'd had. So we were in this big open room, kind of cubicle land, kind of team working area. And the bosses, a line level manager, his boss, and then even a low level executive all sat right behind a big whiteboard that was actually about this size. So one evening after all the bosses had left, I drew that right behind their desks. Cause this showed value that we were delivering. And we had zero bugs in prod. I may have been trying to rub the other teams nose in their 250 bugs, but won't go there. But this was a huge, huge win. The bosses come in the next morning and they're kind of like, who put that up? I was like, I don't know. They knew who it was cause yeah. All right, so current state of that team, of that project used to be stovepipe teams. Oh, it's the development team. They come from the developer center of excellence. Here's the testers who come from the center of excellence. Single team, every single story gets three Amigo conversations on it at multiple points. If you don't know about three Amigos, that's a whole separate conference talk or see me in the hallway and I'll tell you about it. Devs and testers were pairing effectively all the time. The testers had actually become more test technical and better at their jobs. We didn't file bugs. Cause when something got found, the tester or whoever found it would go talk to a developer and they'd fix it right there. And you want to talk about people freaking out? You didn't file a bug report. How are we gonna triage it? What's triage? It's fixed already. It's out in production. Next problem. Zero bugs in production. Huge. Value going out to customers on a regular basis. Nowhere near continuous delivery, right? But was it three years between releases? No, we were down to a couple weeks. Huge win. The testers were happy. We had some testers that we had to say goodbye to cause they just were unwilling, right? So I talked about FUD, I talked about resistance change. They wouldn't change. I'd say goodbye to them. So here's a few helpful things. I talked about learn the business. I'll stop my foot about that. As a software professional, there is little better you can do to help yourself and help your organization than learn what the organization does. Learn more about people. We humans suck. We're grumpy. We're resistant. We don't like change even though we may talk about, oh, I think change is great, no. All right, so here are some great books. Don't go writing these all down. It'll be on the slide deck that's up on speaker deck, okay? But there are some great books and philosophies out there that can help you learn how to interact with people, learn how to influence them. And I don't mean this in like a bad salesman kind of way, right? This is learning how to persuade for a better good. I'm not a big one on asking permission. Like I'll just draw stuff behind the boss's desks. I will find people to steal is a harsh word. I'll say reorganize resources that I might need, such as an unused computer system that I can use for Jenkins server. Now, if it involves budget and policy, okay, don't go breaking the law, but there are a lot of other things that I can just do. We didn't ask anybody about stopping the idea of filing bugs, we just did it. We didn't ask anybody about throwing in three amigos conversations, we just did it. Good intentions and results and results trump a lot of process. So again, slides are up on speakerdeck.com slash Jim Holmes. If you wanna take a picture, this is the one thing to take a picture of. And I'll actually wait until I see the cameras go down before it advance to the next slide. But I will emphasize if you have questions, find me out here in the hall. Email me, my email's on the next slide, but people are still taking pictures of this one, so I can't go to the next slide. Urban, press the button already. All right, you can find me on Twitter, I will warn you, my Twitter feed is unfiltered, so yeah, that's okay. Yeah, I wrote a book on a number of things about leadership. There's a lot of communication stuff in there. I think it's helpful I've had some good feedback on it. With Lean Pub, you actually have 45 days where you can get your money back if you don't like it. But let me know why you didn't like it, okay? So, thank you very much. I hope you got something out of this. Enjoy the rest of the conference. That's me making all the noise, sorry. Thanks Jim.