 button so I think we're ready to start. Hi I'm Ellie this is Kevin and we're here to talk to you about combining DevOps and emotional intelligence. We have a fair amount to say on the subject but we're going to try to fit it into 20 minutes so let's get going. Right over to Kevin to start. Yeah so if you're expecting some crazy technical talk it gets into the nuts and bolts of the technology behind DevOps you're not in the right room. DevOps is a twofold conversation it involves both people and not enough people talk about the people so interestingly enough we're going to attempt to do that a little bit. So why are we here? You know I'm the founder and CTO of a company called DDEV and we make some development tools that tend to help a lot of the development processes the workflows that typically are involved with DevOps and for us you know our vision is simple and not so simple at the same time. It's advancing developer communities and it's a very important concept for us as an organization. We consider ourselves to be a thriving part of the developer community working to advance developers and their communities beyond where they are today. Together we can paint a picture of what tomorrow can and should be and we strive to create a world where developers are helping each other grow stronger build faster and achieve solutions in a collaborative way. That's what DDEV is all about so we make tools to help on a technical level we make hosting platforms to help with the CICD types of workflows and then we also like to really pay attention to our teams. We're very passionate about open source and what we do as a community. Real quick just because a key component of what you're going to learn from what we're talking about today is understanding where it is that we're going so that we can all get there together. We're going to go through a little bit of what we learn or are planning to teach today. So first we're going to touch a little bit on what DevOps actually is what it is not. We're going to navigate some of the complexity from a human perspective that you might deal with on a team basis. We're going to go through what emotional intelligence actually means as it relates to DevOps and how it works with DevOps. We're going to cover a little bit of what to do when things get difficult. It's not always sunshine. There are legitimate challenges that people have to face and we're going to look at increasing velocity in development cycles with structure and empathy. DDEV is a very broad range of tools. We cover everything from local installations, local development all the way up through complex hosting scenarios. A lot of times that feels like climbing a mountain. You heard this analogy in Dries's key notes. He's been talking about this for some time. Getting to the top of that mountain it sometimes feels like there's a race that you're undertaking that you have to really dive in, that you have to really just give it your all and that you're going to get there just through pure perseverance. That's not always the case. One of our engineers, the gentleman Randy Fay, who focuses primary on DDEV local, had this to say about it. It's a very key tenet of how we run our organizations and something that I think that some people should pay attention to. People need to know that their life is more important than the project they are working on. This comes from a very passionate open-source supporter and project maintainer. It's a very important concept. If you'd like to hear a little bit more about how he describes that or how he frames that, there's a bit.ly link. It's bit.ly slash rfay hyphen DDEV. But it's a really important tenet and concept of what we're going to be talking about today. People matter and people matter significantly, especially when you're in the throes of complex technical situations or scenarios that you're trying to figure out or you're trying to create together and move in the same direction together or you're conversely fighting a fire that might have sprung up as a result of an outage or a missed deadline or or an executive that might have a different perception of what should be happening compared to the rest of the team. So I'm going to try to give a brief overview of what is DevOps. This is something we've talked about a bit. We started doing this presentation last year at Drupal Europe with how we work. Kevin gave a similar talk in Florida and then Drupal con Seattle. So this is the latest iteration. You might have heard that there are a plethora of things that you should do to achieve the mythical state of DevOps Nirvana, which would solve all of your problems, right? You might maintain the perfect culture, automate all the things, test everything, decrease feedback loops, rainbows, unicorns, uniforms, whatever. These are all really great practices, but it doesn't necessarily work the same way for everybody. And that's kind of what we're here to talk about. So our definition of DevOps is discovering what needs to be done, defining a clear measured path to doing it and executing that path using tools that suit your needs, decreasing complexity and increasing clarity to add maximum impact and automating wherever possible. I should also say that DevOps is not the one weird tip or magic pill that will solve all of your problems or installing a boatload of tools or even worse installing the newest tool that you just heard about because it's super exciting. And also not trying to make someone else's methods and strategy work for you. Your team is completely different. Your project is different. I highly recommend just taking advice from a variety of people and assembling it to suit your own needs. DevOps is also not easy. I would just like to say that a lot of people make it sound easy and we use words like it's simple or, you know, just do this or here's the simple next step. It's not always simple. And it's different for everybody. So how can we actually use some of these ideas to climb the mountain, so to speak? Sometimes things can be very difficult. There's a lot of complexity building up. The scope is maybe overwhelming and nothing is working for you. So that's when we think it's really important to have a safe space in which you can experiment and try new things and develop emotional intelligence about what's best for you and for each other. Looking out for your team members is a key component as well. So the next section is also me. Look at that. Is there some first steps in employing any DevOps-y system? You start out by defining the map. And that's just about making sure everybody's on the same page, laying out the steps to your work, making it manageable and making it visible to everyone involved so that you're in sync moving forward. And that often requires frequent adjustment. So you might need to change the plan. You might need to backtrack, you know. If you don't have a map, it can seem like you're making progress, but everybody has a different perception of what that progress is. So maps, maps are important. And defining the culture is also a key component that may or may not be a written document or something like that. And then finally just taking one step at a time in order to scale the mountain. Defining the map is, I think I said already pretty key. Everyone's lost without a map. So write that down, lay it out, get all the steps where everyone can see them. I think I already said a lot of this. Right. And just to build on that a little bit, one of the key things that you'll find or that I've found as I've transitioned from an engineer into a manager into the owner of a company that's running larger teams is that no matter how clear you think you're being, ultimately you're not being clear enough. So the number one piece of feedback that I've gotten as I've grown professionally is I don't understand what's being said. I don't understand the vision that's being laid out. So it's very important to come up with a systemic system to be able to walk through that, to be able to identify what's happening. And for us, a lot of times that translates into everything from OKRs, which is a Google concept, all the way down to the product vision, making sure that the user stories are well defined, making sure that there's a testing framework in place to be able to support the user stories so that you can validate what the system does or what it is that you're creating actually is so that that can be handed off to different departments inside of the company, to sales, to marketing, to people that need to understand what's going on. And I really encourage you to take the time to do a little bit of exploration around systems to slow down to be able to move faster because it definitely helps. Slow down to move faster. I like that. So the second part of representation is on emotional intelligence. I don't know how many of you really have familiarity with the concept of emotional intelligence. I just looked up a quick definition just in case Cambridge.org told me it was the ability to understand the way people feel and react and to use this skill to make good judgments and to avoid or solve problems. So this is also part of defining your culture. This is how we support the team and each other and often ourselves. I'm honestly still learning on this front. So honestly, doing talks is a really great way to learn. And this kind of boils down to some of the tenants that you get from open source. For me, open source really means that I'm admitting that I'm not the smartest person in the room, that I have the ability to learn from others and that collaboratively we're able to create things that are better than I'll ever be able to do on my own. When I was a younger person, I had the opposite view. I thought I knew everything. I was the smartest person in the world and very quickly realized that that's not going to get you very far. So emotional intelligence is not only being able to understand how to interact with the people around you but to really do introspection to understand who you are as a person and how you can learn from other people. And I think that's a very valuable lesson as well. So my turn handle conflict and pressure by understanding context while providing space. You know, this is a very interesting concept because a lot of times if you don't have the ability to that context that understanding of where you're going and how everybody plays into that, then it's very easy to find yourself in a scenario where one or two people might feeling be feeling stress points that aren't reflected evenly across the company. You know, we like to give an analogy that is along the lines of a naval ship. You know, if you go and you ask a dishwasher and a naval ship and contrast that with what you might get from asking a dishwasher in an after school job, what their role is naval person might tell you, well, my role is to wake up early in the morning to be able to get things done so that my company, my team can go out and win the war, do whatever mission they need to do. A dishwasher in a local store after school might just be, well, I'm here to collect paycheck. Those subtle differences in helping understand people where they are going and what they're accomplishing really pay off big dividends because you're going to get different performance from those people. They're going to interact with the people around them in a completely different way. One concept I think about a lot in this context is something called rain. I think I might learn to this from Tracy actually. Hi, Tracy. This is sort of a framework for understanding how to deal with overwhelming feelings. So it's just something to think about. It's an acronym. So when things get difficult, it's good to recognize what's going on. Allow the experience to just be there as it is. Investigate it with kindness and try for natural awareness. So don't internalize the situation too much. Don't let it become you, but rather observe it and try to learn. That's my interpretation. All right. And another thing to acknowledge is that your team of humans is more important than maintaining velocity. And at a board level or an executive level, you really need to understand that top-down adoption is critical to being able to do DevOps properly, to be able to deliver properly. And for me, I like to ride mountain bikes. One of the hardest lessons for me in doing downhill mountain bike riding is when I first started, I was using speed to overcome the obstacles in front of me to get over the jumps. And as a result of that, I was petrified, holding on very tightly and tending to crash or fall over, not doing things efficiently. There's this concept called flow in mountain biking, where if you kind of just let go, relax a little bit, and understand the mechanics of what's going on, what's around you, and what you're trying to accomplish, you hit that flow state and suddenly you're able to jump farther, go a bit larger distances or faster than you've ever been able to do before. And it's a very critical thing. In the previous explanation, you're working harder, you're working against yourself, and you're slowing down, things are more difficult as a result. In the latter state, you're able to just kind of relax, go with it, you're expending less energy, and you're accomplishing more as a result of it. So while some of these techniques might seem a little odd at first, it's really important to get alignment with everybody because you'll switch from everybody's kind of grinding against each other and creating friction to suddenly we're all working together to be able to create amazing things very rapidly. There's less burnout, there's less fatigue as a result of that, and better quality code along the way. Having space for culture and lost velocity is a privilege. It's not something that everybody can just inherently have. There's top-down expectations that need to be set. You need to work consistently with your upper management to help them understand that we need this privilege to be able to deliver properly, to be able to give you the value that you're looking for, and unless you support us in that, then we're never going to be able to achieve what it is that we can do for you. And if that person doesn't understand that, then you should probably go elsewhere and find somebody that does because your mental health will be significantly better as a result of it and you will just, you want to enjoy going to work on a day-to-day basis. You don't want to feel terrible as a result of it. So DevOps and emotional intelligence, just to kind of reiterate some of what we've done, you're definitely going to want a vision of where you're going. You need that to be well-defined, you need a map. You need to take the time to understand the situation and the people involved. Make sure that you're being empathetic to those around you. Make sure that you're really understanding their position, why they might feel the way that they do. Help the team adjust and move towards goals. It's a very critical concept. If there's a problem point, you need to stop, take the time to help people adjust and fix the problem. And you need to build a space for innovation and clear thinking about challenges where it's safe to experiment and okay to fail. That means admitting that you're wrong. You might not have the best vision. You might not have the best empathy. You might be making mistakes along the way and it's okay to admit that. There needs to be safety for everybody involved. You can't just lash out to the person that might seem like they're having the most problems. And when you work together, you can achieve great things. That's the entire purpose of DevOps. That's the entire purpose of emotional intelligence. And when you combine the technology from DevOps with the emotional intelligence, you can achieve things that make people just look at you in awe. And just to summarize, DevOps is not magical fairy dust. Creating a culture of safety is critical. It's a work in progress and that's okay. You know, at the end, things can look literally and shiny and beautiful. And it's really an amazing thing when it comes together. It takes a lot of work to get there. It doesn't just happen naturally. So we're essentially at time. And do you want to take these last two? That's pretty much it. Definitely come to contribution time tomorrow if you're still in town. I'm also a mentor. So please come contribute. We've got a first-timers workshop in the morning and then two different rooms you can join. And if you'd like to talk a little bit more about emotional intelligence, you can come by our booth downstairs with the DDEV booth. I'm happy to discuss any of this or go into some of the technical workings of how we implement this. And I think we have a whopping two minutes left if anybody has a burning question. Yes, two minutes. No burning questions. Awesome, we nailed it. We powered through that. Cool. Well, thank you very much for your time. We won't need to keep you any longer than necessary, but go out there and talk to each other, be empathetic, do great things, and have a wonderful day.