 All right, everybody, I am going to get started because 30 minutes is not a lot of time and I want to make sure we have some time for Q&A at the end. I'm Mike Madison, and today we're going to talk about how to stop blaming your boss. If you don't know me, I'm a manager and architect in the professional services team at Acquia. That means I'm working with Drupal 8 every day doing enterprise builds. I'm also one of the organizers and the technical lead for Drupal GovCon, and I'm one of the maintainers of Acquia's built and lunch tools. If you're interested in BLT, there's actually a BOF later this afternoon, so definitely check that out, please. If you're a user, if you want to be a user, please come chat with us. A couple other just quick announcements. Registration and session submission for GovCon did open this week. So if you're at all interested, this is a free camp. It's one of the biggest camps east of the Mississippi, and it is free in Bethesda, Maryland every summer. So please check us out, and they did ask us to throw this slide up about code contribution sprints on Friday. So if you had a chance to look at the agenda for my talk here, none of this should be super surprising, right? This is how do you take what you're doing every day and use those behaviors to try and institute change in your organization? And if I had to boil all those other bullets down to like two high level things, it's how do you evangelize what you want to change within your organization, and then how do you drive towards that change in your organization? And I specifically bolded the word you on this slide because I just cannot stress enough that this talk is not about your boss. It's about you. So if you're here looking to blame your boss, go away. This is about what you can do day in and day out to actually start making those changes in your work life. So I was on a project a few years ago, and I think this project actually really personifies the problem I'm getting at in this talk. So I was not the architect or even the lead developer on this project. I was a back end dev part of the larger team. And as I was onboarding onto the team, I was hearing about the roles, what everybody's doing. We had a QA dev, this was good. We were doing two week sprints. The backlog was well groomed. The architect was doing code review. The tester was actually testing like these are all good signs. I'm like, okay, this is looking like we're going along. Customers even involved in doing UAT, which is even better. And then I actually started looking at the code and I'm like, what the hell, there's no automated tests in this repository. Like everything else was great, but there's no automated tests. So I asked the developer, I'm like, okay, so you're doing QA but you're not automating QA, why? Why aren't you doing that? And the architect said, well, we don't have time. It's a really short project. It's a really aggressive timetable. We just don't have time to do tests. And if you know me, I'm a pretty big advocate for at least having some level of automated test coverage. And I had a choice in this moment of how I wanted to react to that architect on that project to raise my concern with the lack of automated testing, right? These are people I knew and respected. These are people I had to work with beyond this project. So I had to kind of take my personal reaction to what I saw as a not awesome situation and think about how I wanted to try and drive that project towards change in a way that might not implode future relationships. So I had some choices, right? I mean, my first choice was I could have gone off on the architect. Like what the hell, man? Why aren't we doing automated testing? We have to do this. This is our job and just not reacted very well. Option two, I could have been much more tactful and much more polite and like swung the best practices hammer and just really like brow beaten him and the team until, again, either things went south or they agreed with me. And more than a few people have taken that approach on projects. I'm sure many of you have worked with people who have thrown their weight around or their experience around to get what they want. And they may get what they want in the short term, but longer term that method you're always gonna hit somebody bigger and louder and more forceful than you are. This is a short term solution at best. And again, they may work. But for me, what I did in this case is I did some work. I showed them it was possible and then I worked with the team to actually build consensus. And that's not sexy, that's not exciting, but it does work, right? So in this particular scenario, I actually took some time after work one day. I like sat on the couch and watched a bad movie or something and I wrote some B-hat tests. I used what I have learned as best practices for using B-hat with the team. I actually extensively documented what I did. I provided examples that were commented out in a code that they could use themselves, the team. I demonstrated a couple days later what I did to the team. Like I didn't like try to ninja a pull request in and slip in these tests without telling everybody. I showed them what I did. And I actually got buy-in from the rest of the team to finish out what I had done. So that when they themselves started doing pull requests and working with this, they were now helping to contribute to this situation. And through the end of that project, actually, the rest of the team, including the architect, contributed automated testing to the project, helped to maintain the test base. And I do genuinely believe we delivered a better code base to the client at the end than we would have in the first place. And I genuinely believe that the second bullet here is a lot of the reason that this worked, right? I did not go back to the team and said, okay, guys, you now have to go do all this extra work that you didn't do initially. I did some of that work personally to allow them to see that it could be done. The fact that I provided the examples and the documentation meant that even some of the folks on the team that weren't really strong in B-hat no longer had that I don't know how to be had excuse, right? I mean, just like copy and paste this and take this. I mean, there's no effort required at that point. And again, I got team buy-in and we as a team went back to project leadership in the client and managed up instead of waiting for the client or the architect to come back and give a mandate for something to happen. So if I have to give you one takeaway from this story, it's that if you want to effect change at any level, right? The most direct and fastest way for you to affect that change is for you to actually roll up your sleeves and be willing to do some work to do it. And that's not to say that if you do work 100% of the time, you're going to get your way, you won't. But having some evidence that what you want to do is possible is a much harder thing to argue against than yet we don't do that. The other thing I want to talk about here in this case is how much time did I really spend writing B-hat tests? And the answer is not much. The reason for that is I learned a long time ago, like I come from a freelance background. And I learned very quickly that when you're working with a platform like Drupal, when you're working with a platform like WordPress, everything you do, there's a really good chance you're going to do it more than once. So if I write a bunch of B-hat tests for some customer over here for my nodes and my permissions and my workflow and blah, blah, blah, blah. There's a really good chance that the customer over here that I'm working with later is going to have different tests. But tests that use a lot of the same guts and underworkings and so on and so forth. So every time I solve a problem, I'm thinking about, how can I use that problem again in the future or that solution again in the future to save me time? So when I sat down in this particular instance to write B-hat tests, it's not like I spent 40 hours over a month or whatever like jury rigging in B-hat tests. I mean like I literally copied and pasted what I consider to be best practice B-hat tests and changed them to work for that project. It was like a movie's worth of effort. I also want to stress for Drupal, right, a lot of organizations aren't down with the open source contribution thing, right? They should be, but not every company is. That's fine. Think smaller than that, right? If you're writing something that isn't appropriate to contribute back to open source, that doesn't mean it's not appropriate for you to reuse it in your organization. My last job, we wrote a custom authentication module to do single sign on with Kerberos. It's a super specific thing to use with our active directory at that old job. Never going to contribute that, like it wouldn't work off the network. We used it on every single project that we did at that company. Once we built it once, we had it working and we shared it and maintained it across all of those projects. So when I say there could be a module for that, keep in mind, if you think bigger than what you're working on right now, frequently you can reuse what you're working on, architect for reuse. And these could be any number of things, right? This could be what local environment are you using? So if half of you are using Doxon, half of you are using Drupal VM, like figure it out. Like maybe you're not going to win that argument, but standardizing around a local environment is going to save your team time, effort, and money. Make sure you're deploying the same way. Think about how you're storing code. Think about continuous integration, automated testing, etc., etc., etc. Anything you can do to standardize and reuse an approach from project to project to project is going to give you a much, much stronger platform that word gets thrown around a lot. But much stronger platform to stand on to try and adopt change and best practices. So I do like to tell this story and I take no credit for this story because this all happened at Acquia before they hired me. But on our professional services team, we were running into this exact same problem, right? So as Drupal 8 was in its infancy, as people were coming to Acquia to hire us to do like pro-level enterprise builds, we had architects who were running in 19 different directions solving the same problems in different ways. We were setting up our projects differently. We were using different strategies for configuration. We were solving the same problems over and over and over again differently. So the professional services team, Matt Grasmick, who is at the con this week, by the way, so high five him if you see him, actually started working on this open source project that today will standardize your template for project creation, give you a whole bunch of automation commands for deployment, continuous integration, VM setup, etc., etc. And was BLT what it was today when it first started? No, absolutely not. It was very simple, but it has grown into something much larger. It's been downloaded, I don't know, over half a million times. It's something that has very much taken this notion of reuse, recycle ideas, and build upon that little by little as you get larger and larger support. So my second takeaway is assume that every problem you solve, you're gonna have to solve again. And how many times do you get five projects into something and go, man, this is exactly like this, or this is exactly like that? I mean, it happens all the time. So if you just assume when you solve a problem that you're gonna have to do it again, you're hopefully saving yourself some pain. So let's pretend that you do now have some common B-hat tests or something like BLT in your back pocket. And you've decided it is the best solution in the world and it's time for your organization to adopt it. There's still a gap there, right? Because just because you've started standardizing or even your team has started standardizing, that doesn't mean that your CIO's office is gonna go for it, or the SharePoint team suddenly gonna flip over their table and decide to start using Drupal, right? There's still a gap from getting your head and your team in the right space to starting to build that support. And if I had to boil this down to one suggestion, it would be don't be this guy. Now, if you haven't seen the IT crowd, it's getting a little dated, but it's free on Netflix, you should go watch it. But also if you haven't seen the IT crowd, like Moss is the epitome of everything an IT guy does wrong. Every conversation he has, he assumes that the person he's talking to knows as much or more about what he's talking about as he does. He refuses to talk to people at their level. He basically calls everybody who isn't at his level stupid. He's pretty antisocial. Which by the way, if you're anti-social, that's fine. But he's aggressively throw you out of his office bad. And anybody that tries to interact with him just usually runs away because it's such a terrible interaction, they never want to talk to him again. Don't be that guy. Do talk to people at their level. So if they come to you, and by the way, we're not talking about your solution, your platform, whatever, we're just talking about relationship building here, right? If you have somebody that's non-technical and comes to you and you see him in the hall, coming out of the bathroom, heating up lunch, and they ask you a question, answer it at their level. Talk to them, be a genuinely kind human being, and take the time to reach out and have an interaction that they can understand. If you are working with somebody on a project and you agree to do something, do it, right? Don't agree to do something that you're not willing to take on and do. And this is actually a big one. I've found repeatedly that the most direct, fastest way to build confidence in your ability is to actually deliver what you say you're going to, right? Success speaks louder than just about any other action. Say yes more than you say no. To this day, I still have people from previous jobs that email me and ask me questions because the people they work with always tell them no. Hey, I want to do this. No, I'm not a yes man, but I will say yes much more than I say no. When I say no, it actually means something. We say this a lot in consulting, you want to become a trusted advisor. If you're a trusted advisor and you go to somebody and say, hey, I have this cool new way that we're starting to build projects. We're automating our tests. I think it'll really save us time and money. The people that are listening to that argument are much more likely to listen to you and trust you in that context if you have a proven success record and you have a good relationship with them and you've built something, right? Be in the smart guy or the smart lady on a project doesn't necessarily get you a ton of cred when it comes to completely changing your approach. But if you're a trusted advisor, if these are people that normally come to you for help, every now and again you're gonna have the opportunity to go back to them to try and get support for new things and exciting things and changing things. And this last one I can't stress enough. Remember you're not the only smart person in the room. It is really easy to see that something's not working. It's really easy to see that you're doing something wrong. But if you're just another person sitting on the sidelines sniping in saying, this is dumb, we shouldn't be doing this, that's not gonna get you very far. So other people know the problem. You wanna be the person that tries to bring a solution to the table. Identify the problem, that's fine. But identify the problem and then say, here's what I think we should do about it. So two takeaways here. Remember that organizations, literally the building isn't gonna stop you from doing what you wanna do. It's the people that work there that are. So if you're gonna try and affect change, you have to have relationships with the people in order to drive that change. And I can't, this is something that just is always a factor. You have to be patient. If you start a new job and you walk in and on day one and you're just like, wow, none of this is right, we gotta change everything. If you don't have trust, if you don't have relationships with those people, you're not gonna be able to start driving that change. Nearly as much as you might, after you've built trust, after you've worked with them and you've built up that track record. So definitely be patient and pick your battles. So let's talk about this a little bit, new directions and new approaches. So we've got this idea, we've started building some trust, we've started building some direction to actually get there. But we're not all in alignment in how to solve the problem. All right, sometimes problems have wonky solutions. When I first started freelancing about 15 years ago, I read this book. So it's been out a while. And there's a story in it about the MTA, which has a soft spot in my heart because I worked with them for a couple years. And it talked a lot about how New York City cleaned up a lot of their safety and violence and crime issues in the late 80s and early 90s. And it's a fascinating story because it's not they hired more cops. It's not that they arrested more hooligans. They bought some paint, right? So there's this idea of the broken window fallacy or theory, right? If you're walking down the street and you see a broken window, you're going to assume that where you are is less safe. You're going to assume that where you are is a crappy part of town. And in New York, a lot of that was represented by graffiti, specifically graffiti on the MTA's trains. And they tried to combat this problem for years. How do we stop people from painting our trains? Fun fact about the New York MTA, there are so many trains in New York that they don't have a place to store all of them. So if there's a blizzard, if there's a flood, if there's anything that ever shuts down the entire subway system, they have to physically park the trains in the tunnels because there's no yard big enough to store all the trains. So it's not like you can put the trains someplace and lock a gate and keep people away from them. I mean, if you can get into the tunnel, you can get up to the train cars to spray paint them. So what they did was at several of the turnarounds in the cities, they set up paint stations. If a train came in and it had graffiti on it, it did not go back out until the graffiti was painted over. They let people in. They let them paint them. They didn't care. You want to spend eight hours vandalizing my train? I'm going to spend 20 minutes erasing it. The vandalism stopped. I think it's one of the most brilliant solutions to a problem I've ever heard. I never would have thought of that. And if I can leave you with anything today, even with the best relationships, even with the most brilliant idea, sometimes you have to back up and think like an architect thinks. And you have to think that a solution that's going to get the most traction may not be a solution that anybody else has ever talked about before. Right? If you have a Drupal team and a WordPress team and a SharePoint team, everybody thinks theirs is the best. You can't just always assume that I'm going to somehow convince you to use Drupal because Drupal's better. I mean, we're at a Drupal con. I think I have a friend of the audience on that account. But my point is that sometimes you have to find a completely different angle, even if you do have the right relationship and you do have the right approach and you do have the right platform, you still sometimes have to think outside the box to get that done. So I wanted to make sure we had some time for questions. In conclusion, if I had to drill this down to like three very minimal thoughts, work to become a trusted advisor. That has nothing to do with your boss. I mean, hopefully your boss trusts you and it could very well be that you're building trust with somebody in a position of power, your direct boss, your boss's boss, whoever that might be, but become a trusted advisor and think about all things that are entailed in that. That's not just manipulate people into doing what you want them to do. That's genuinely build a relationship with people, which may be a little outside your comfort zone. I'm lucky, I'm extroverted, green badge, right? Come talk to me. But not everybody's like that and that's fine. Trusted doesn't mean you have to be out all the time interacting with people. It just means you need to have the right interactions when you do. Design what you're building for reuse. Once you've got these relationships, if you've got a good team, if you've got a good foundation, every time you build something, you should have the opportunity to improve on what you did last time or reuse what you used last time to help further your cause that much farther. You may end up with something like a distribution, right? There are many organizations that start small and end up with their very own Drupal distribution, open source or otherwise, that they use every time. You don't have to start there but you never know, you might end up there. And finally, like I said, look for that non-obvious solution. There are so many opportunities to drive change in organizations that a lot of people probably do see. So look for something that maybe is a little different than what other people have tried and you never know, you might get a little bit more traction in that situation. So with that, we've got some time. Please use the mic if you have questions. Love to talk about them. Anybody? It's a nice way of telling them they're wrong. It is. What is a nice way? Well, so you still want to have some evidence to back up what you're talking about, right? We've got the other thing. Yeah, yeah. But the thing that I think you have to be comfortable saying is that is wrong. This is something I do with customers and projects and clients all the time. We're gonna do X. Okay, well, why do you want to do X? Because we've always done X. Okay, so what I've seen with X is usually that you get this far and then this goes wrong. You don't want to just say, oh no, you're wrong or you can't do it that way. You want to try and tie it back anecdotally to something you've experienced or something you've seen. And frequently, as a consultant, I frequently tell people don't do something and then they do it anyway and then what I said was gonna happen, happens. Don't say I told you so. Then you say, okay, now can we revisit this and figure out how to get back out of this and stop it from happening? Right, you may very well tell somebody that something bad is gonna happen and then something bad is gonna happen. Then you take that point, improve the relationship and try to build your way out of it from there. Thank you, it's a good question. Anybody else? Yeah. So women, before you start the project. Mm-hmm, yep. So the team in the back of the scene of Daljok will have a community culture in this assignment that will continue to have their talk and the other team will have a talk so we're going to avoid discussions on the line. Yeah, so the question in the comment there was just, shouldn't the architect and the lead dev be building an architecture document and gathering consensus at the beginning of the project to make sure that everybody's on the same page? And yeah, I mean they should, but I think what you're describing is a very healthy team dynamic and there's a lot of organizations and a lot of teams that don't have healthy team dynamics. There's a lot of organizations that don't hire architects. There's a lot of organizations that literally just say, hey yeah, go build this thing, have fun. Like here's some money, here's some time, I need this thing figured out. So yes, I mean like that is the perfect situation. The architect, the lead developer sort of prescribe what they want. They give the team the opportunity to comment and sort of storm and norm. That's very agile, right? Let's have continuous improvement. Let's figure out how we can work together. That should be your goal, but in my experience there's an awful lot of organizations that either aren't agile at all. So continuous improvement is incredibly alien to them or they're not set up to give their development teams or their individual contributors the opportunity to sort of push back and say, I think we should be doing it this way. Yes. Yeah, so the question there was just, best practices with B-hat tests, right? I mean so the best, I think the least controversial best practice with a B-hat test is it should be running on all of your continuous integration builds. It should be running prior to your deployments. And in this case, since we didn't have any tests at all, we weren't doing those things at all. So in that case for me, the line in the sand was, I want to make sure that every pull request has B-hat tests running. I wanna make sure that if the pull request is not past B-hat test, it doesn't get merged. When we merge, we want an integration build to circle around and run the same test again against the entire code base, not just the pull request. That was the short-term goal there. The longer-term goal was to actually have as close to 100% coverage as possible for the custom features and functionalities that were actually built on the site. Best practices there I think are probably a little more open to conversation, depending on who you're working with. But for me, it's making sure that if a form has custom code to do a form alter and change some behaviors on the form, theoretically, there should be a test to make sure that the right level user can go to the form, do whatever it is they're trying to do, see the expected behavior, and also do a negative test. That's just a good testing practice in general. You shouldn't always just test the positive. You should also test the negative because if all my tests are just testing as an authenticated user, that will never test a problem for an anonymous user. Anyway, I'm happy to nerd out on BeHat test after if you have some more questions there. Yeah. Yeah, can you talk a little more about that managing? Yeah, yeah. So the question there is, how do you manage up? And I'll be blunt. Sometimes you can't, right? I mean like, I have left companies before because I couldn't. But I definitely find that one trusted voice is better than an angry voice. A group of voices on a team all saying the same thing is better than one trusted voice. So if you're building consensus on your team, if you're going back to your management or your team leader, whoever, and you're trying to have these conversations, you know, I always say look for the victory you can find. So I work a lot in the government space, as I said. Something I hear a lot from government stakeholders is we really want to use Drupal VM, but we can't because we don't get pseudo access on our laptops. That's one you probably aren't gonna be able to manage up. Right, doesn't matter how much you tell them that we have to be able to do this. Like that's probably something even your boss can't change. Right, if your government organization does not allow you to have root level access on your computer, I don't know how high up you'd have to go to get that changed. In that case, I would abandon that fight and start looking for the next best thing, right? If I can't have a local environment or if I can't use Drupal VM, what can I do to give me the same thing that a local would? What's the next best thing? And then, you know, have a fall back point, right? And I found really great success with that compromise model. But it requires you to be able to sort of step back and not just get upset that they're telling you no. It requires you to sort of see the forest or actually in that case, maybe see the trees in the forest, not the whole forest, and understand, am I even talking to the right person to manage up what I'm trying to fix? And again, that's where relationships really come in handy. Give me just a sec. I thought I saw a hand over here. Nope, okay, go for it. If I can tag onto that comment. Yeah. That question. When you knew that next best thing, because you can't do the good thing, of the best practice in optimal way, I recommend start making a log of bullet wounds. These are the pain points we are enduring and the extra cost and the extra production by doing it the hard way, the best practice way, to eventually achieve that track. Took me eight years, but I got that from the lab. Yep, that's awesome. Congratulations to you. No, anyway, just for the recording, he was saying if you do have to have a fall back point and if you do have to perhaps not do the best practice, keep track of what you have to do to work around that because it may help your argument in the future. Make them understand. Yeah, for sure. Other questions or comments? Yeah, nice at least for the exit interview, that's good. All right, well, I think we're at time anyway, so thank you all for joining me. If you are interested in build and launch tools, like I said, we are having a BOF later. I think it's from 315 to 345, it's on the schedule. So, love to see you there. And I'll be around a little bit if you wanna talk some more if you have some questions. Thanks, everybody. Have a good one.