 to Kevin from DDEV now who's going to talk about combining DevOps and emotional intelligence. Yeah and this will be really interesting because I do not have my speaker notes or a timer so I'm just going to kind of wing it as I go but hi we're making the best out of what we have available to us. My name is Kevin Bridges. I'm the CTO and founder of a company called DDEV. We make local development tools and complete lifecycle kind of hosting platform as well. And through the course of putting together this company, I started in Drupal probably 15 years ago. I started around 4.5, 4.6 and was fortunate enough to be involved in a lot of really large early websites. So in Drupal 7 we made Popsci.com which I think was one of the first enterprise level websites eventually moved on to a site called examiner.com where we introduced Mongo into the Drupal core code base and basically most of one of the largest sites in existence at the time it was the top 50 US web property. Through the course of that I basically came to realize that there's this concept of a pendulum that's always swinging and I like to reference this a lot but for me that pendulum was initially you know when the internet was created it was more long lines of well let's just start doing things on the internet. Let's get our message out there. Let's go to Matt's script archive if any of you actually remember what that might be. Download a Perl script and put a bulletin board or a login form on our page. Eventually we got smarter and smarter and figured out that there's different patterns, different ways of doing things and that they're really successful. The ones that were really accelerating in this new world were the ones that were capable of identifying those patterns and gravitating the people that were doing the same type of work. That's what we started looking at CMSs. That's where Drupal came from. At the time it was in Juma and Magento and a couple others that I was evaluating. It ended up in Drupal and like most of you it changed for life but that was 15 years ago and we spent a lot of time working on those components that make up the website. You know the login forms, the bulletin boards, the shopping cards. I got that really well and then finally realized that we can do big sites. Once we started getting into the enterprise the whole new world of conversation started happening and that world revolved around infrastructure and revolved around handing off the work that we were doing to people that were capable of eating it alive, eating it money, having to deal with corporate networks, having to deal with the whole new world of things that most developers are very uncomfortable dealing with. Eventually people got smart and called it DevOps so that pendulum was swinging back in my opinion to being able to manage the other side of the equation. So we've got the front end, that's covered by Drupal, now we go back to the back end, that's what DevOps is and we need to understand how to do that pretty well. One of the things that engineers tend to do is they tend to neglect the human side of that conversation quite a bit. So a lot of times when you hear the word DevOps that comes across as being a very technical skill set, something that you need to be super smart about, something that you need to be super skilled with computers on the server side, things that a lot of people don't really do natively. But what is really important and what is the point of this talk is that humans matter more than the technology and if you can engage properly with both the technology and the humans involved in building that technology you're going to do amazing and wonderful things. So let's dive in. I can figure out how to use a computer. So why are we here? The company that I created has a vision statement of advancing developer communities and for us it's real simple and not so simple at the same time. It's advancing developer communities so we are 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 for us this is really important and I'll get to some of this in a little bit. We want 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 for us you know when we go and like look at the different communities that we're involved with we're not just involved with Drupal, we're involved with WordPress, we're involved with typo3, we're involved with SU, we're involved with Expression Engine. There's many different CMSs out there. There's many different communities out there and each of these communities from organizing events to you know getting their associations funded to being able to provide the services that they do. There's very common patterns in there. Some of those common patterns are technical like local development environments. If you're working with PHP then you need a quick and easy way to get started. If you're working with the community then you need by a governance model a set of guidelines to be able to make that community effective. And we specialize in taking those patterns just like we did early on in the internet just like we did when we started using Drupal just like we did when we started exploring DevOps and we share those patterns with the different communities to make them more effective. So again focusing on the human part of it and not just the technical part of it I think is really important because if you can do that you have the ability to realize the collective of what open source gives us which is you know a good group capability of solving problems to make us smarter and you can share that with other people. There we go. So basically what we're going to learn in this talk very quickly what DevOps actually is. We're going to talk a little bit about navigating complexity from a human perspective. We're going to talk about what emotional intelligence is and how it works inside of the DevOps paradigm. And then we're going to talk a little bit about what to do when things get difficult and show you a very quick example of increasing velocity with structure and empathy and what that actually means. So a lot of times when people get started you know they see I like to reference mountains a lot. I'm from Colorado so that's kind of where this is coming from. But typically when I have people come out and visit me in Colorado they see something like this and this is for us in Colorado a pretty standard height but a lot of times people see something like this. They think that they're going to be able to just run up the mountain that they're going to be able to just put in their best effort and put one step in front of the other and kind of get to the peak. And what they don't understand is that a lot of times it's a longer journey than it looks like. It takes a lot more work to get where you need to go. And many times people fixate on the size of the task in front of them or the problem in front of them to the point where you know a really good engineer might start coming up with all these elaborate solutions to solve this very difficult problem. And they might stress about it to such a degree that they start to kind of withdraw to get imposter syndrome to not really feel affected with what they're doing. And they tend to forget this simple fact that people need to know that their life is more important than the project that they're working on. And that's a quote that comes from a gentleman by the name of Randy Fay. And if any of you use D-Dev or any of the products you might know who Randy Fay is he's an incredibly passionate supporter of the project of the community. He's been involved in Drupal for a long time. Very active in the governance conversations that happened very early on in Drupal. Some things that some people might not remember. But if you get a chance you can kind of hear the podcast. This was a Drupal Easy podcast where you talk about this. It's bit.ly.com. It's a really interesting quote because I think that a lot of businesses tend to forget they focus so much on delivering value or delivering products on delivering services that they forget that they're climbing a mountain. It's not it's not a small task that's being undertaken and it's not something that's just going to end at a certain point and then give you a new starting point. So let's get a little bit into kind of what DevOps is because it's going to be important in this conversation. 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 where possible. So basically what this means is that DevOps starts off as a checklist. Real simple. You can do it on a piece of paper. You can do it on a stick. It starts off as a methodical way. I have to achieve that goal of reaching the top of the mountain but in order to do that I have to take a left at this turn. I have to take right at that turn. I have to make sure that I pack my water. I have to make sure that I have the supplies necessary that I know I'm going. Knowing where you're going is going to be a critical part of this because if you can isolate things, if you can make a checklist then you have the ability to not only know where you're going but you can automate it at a certain point depending on what it is and how much human touch it has. DevOps is not that one weird tip or magical pill that will solve all your problems. Installing a butt load of tools, boat load, I think is how I was supposed to say that. We're trying to make someone else's methods or strategies work for you. So essentially, you know, you can't go out and sail all of a sudden on the DevOps expert. I'm just going to solve all of my problems because I'm going to make everything work. It doesn't work that way. It's hard. It takes a lot of work. It takes a lot of energy and it takes a lot of effort. And the more people that need to evolve, the more difficult it gets because, you know, computers are very easy to binary. If a computer breaks, it's either because of the hardware field or I told it to do something to break it. If a person is involved in that conversation, it gets a lot more difficult, a lot more complex. You know, people are not computers. They're very, very involved. So DevOps is not easy. Again, I'm missing my speaker notes, so I'm kind of just winging this so bear with me. But it's completely and totally worth it. You know, if you take the time to understand where you're going, if you take the time to map out how to get there and you take the time to work with the people that you have on your teams efficiently and understand them, they're going to reflect that back to you and they're going to be able to give you their best. You know, a lot of times when you have a lot of really smart people in the room, they start working on a problem. And I think we've kind of seen this in some of the light shedding that you might see on Google about work. People tend to get really passionate, really involved and really want to do their best. And as a result, a lot of times there's conflict, which is kind of an interesting and ironic paradigm if you think about it. Because you have a group of people that are trying to solve a problem together, but they suddenly can't communicate. They're bickering. They're arguing. They're not understanding what they need to do. And they all just want to do a really good job. And being on an engineering team where that kind of tension exists is unhealthy. It's not a good place to be because it's not comfortable. People getting anxiety from that type of interaction. They're more focused on the challenges that they're going to have with each other than solving the problem. Eventually they'll get there if the communication is good enough. But if you are proactive and you take the steps to engage with people, help them understand where they're going and empathize with them, then you're going to be able to help direct people in a direction that's going to make them more productive than they were originally. So in order to do that, you basically need a map. You need to define the culture of what you're working on, what the rules of engagement are essentially, and you need to take small steps. So without a map, you really don't know where you're going. And that's the number one rule of being able to communicate is know where you're going. So the example that I tend to get there, which some of you may have heard yesterday, is if you take a dishwasher from a naval ship and you contrast that with a dishwasher that's working after school in the restaurant, you're going to go and ask those people what they do for a living. You're going to get drastically different answers. So if you ask the person that's working in a restaurant after school, why do you wash dishes? I get a paycheck, I go home, I don't even know why you're talking to me like that. Pretty common answer. But if you take the time to ask that naval officer what their job is, same dishwasher, they're going to say, well, I get up at four o'clock in the morning, I clean my kitchen, I wash all the dishes, I make sure that the pots and pans are ready to go. Everything's stacked up for the chefs to come in, so that they can cook the meals that my troops need to go out and win the war. They know what their mission is, they see where the ship's going, they know where their team is going, and they know exactly what their position in that organization is and how it affects people that they come into contact with. There's a subtle difference there, but it's a very important one, because if you're trying to create a technology project and you're incapable of properly articulating where it is that you're going, then people are going to go to their streams. They're either going to become super active, they're going to start thrashing and just creating work because they think they're helping and solving problems. So, well, I can have this filter here, and the user's going to have this particular issue. I made a better code than in here. Oh, I just thought of this really neat thing, and let me refactor some of this code. That's the kind of conversation that happens, and that's not tenable to be able to move something like an able ship forward in a straight line. So, it's important to have a map, it's important to define the culture. So, by that, I mean that you need to give people the opportunity and safety to be able to fail, to make mistakes, to admit that even though you defined a map, you may have been long in specific steps that are necessary to achieve where you're going, and you need to be going to work with the team to kind of modify it in real time. So, that's why culture is very important. Small steps is also super critical. It's kind of the concept of bad job. You need to be able to adjust quickly, and you need to be able to communicate those changes not only downstream but upstream. So, for me, I have to report to the board of directors. In order to report to that board of directors, there are certain things that they need to understand about the company. They need to understand what value their investment is giving them. They need to understand the products that are being built, the services that we're delivering, and the effect of those on the company. So, finding a way to translate both downstream and upstream becomes pretty critical, and I think that we've been able to do some pretty simple processes. So, essentially, everyone's lost without the map. We use a system that's called OKRs, objective key results. There's a book out there that is called Measure What Matters. It's MeasureWhatMatters.com. It's very good. It's a system of management that's used way to gain out of Intel way back in the day, but it's now used in Google and a lot of large organizations. And the premise of it is that you have objectives and key results. Your objectives are going to be three to five items that are identified at different levels on the side of the company. So, at the executive level, we may lay out three to five objectives of the company instead. Realize a recorder. We want to sign up 50% more customers. We want to increase revenue by 25%. We need very binary types of things where you can say for sure we either succeeded or we failed at this particular item. And it's important to keep them limited to three or five items because what's going to happen is you move throughout the organization. People are going to expand on that. So, you go to, for example, in a larger organization, you're engineering leaders and ask your engineering leaders to also come up with three to five objectives that they want to meet from their specific department. Then you sit down in a room and you evaluate all of the objectives from all of the company. You determine what's going to be reasonable during the quarter or whatever time period that you're working on. And then from there, you start to lay out a map that you can communicate to the rest of the company that helps everybody understand where you're going, where you're trying to get from that quarter. And out of that, they look through and they start to fill in those key results to support those objectives. So, again, you're only looking for three to five key results that support a specific objective. Each of those key results need to be binary. Then we succeed or not. And you don't ever change your objectives or your key results. So, for example, if I set an objective to achieve over a course of the quarter and we completely missed the boat, that boat just went off in a different direction and we needed to adjust, that's fine. It's okay to not hit your goals, but it's important not to change them in a course because you need to be able to learn from that experience and you need to be able to communicate that change in direction to the rest of the organization and help people understand it. So, again, creating an environment where it's safe to fail not only at the individual level but at the organizational level is a critical component of being emotionally supportive of the people that you're working with. So, what is emotional intelligence? It's 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. As a manager, the number one thing that you can do is have realistic and healthy one-on-ones with the people that you're working with. You have an, as an engineer or as a developer, it's also imperative that you reach out to people that you're working with that understand how they work to talk to them on a non-critical basis. You know, hi, my name's Kevin. How was your day? That's a very, very good way to engage with each other on the team and when you find yourself in a situation where there's somebody on the team that you may have conflict with or that may not work the way that you want them to, having that conversation on a regular basis and committing to it as if it's the most important thing in the world will go a significant way towards changing that attitude towards changing those interactions with that people and it's a super important thing to do. I personally don't like talking to people. I'm a very almost anti-social kind of person. So, me engaging with people on that level was very uncomfortable and it has been the single most rewarding thing that I've done as we've grown in size as a mother. So, definitely encourage you to talk because as weird as that sounds, just talking to people goes a long way. So, the next thing that you're going to want to pay attention to is handling conflict and pressure by understanding context while providing space. I think that's what that says. So, what that basically means is that you have to put yourself in that person's shoes to be able to communicate with them, to be able to understand what they're going through, to be able to make relevant recommendations to them, to help them understand where you're coming from and be able to move forward. So, a lot of times if there's conflict you have a couple of different options and this is what most of us do right out of the gates. It's too much. I can't deal with all the stress so I'm not going to listen to any of you. I'm going to go ahead and continue to do what I'm doing because we're all crazy or however you want to say that. If you can't put yourself in that person's shoes and accept their reality and then work from there as a neutral space then you're probably going to belong. So, when you go into these one-on-ones, when you go into these conversations with your peers and your co-workers, you don't want to go into that conversation with your biases, with your opinion of what the outcome should be. You need to go in a very neutral place, put yourself in that person's shoes and then start to understand them. And then once you do that, you have the ability to help them understand where you're trying to go and you can eventually get to a common place that everybody agrees on and it's drastically different. You no longer look like that. You've got a smiling happy person that's like, okay, well, you know, this didn't happen the way that I wanted it to or expected it to but I'm happy with the outcome and that's an important part of communication. We like to use a system and it's pretty simple to kind of keep in mind. I think we actually got this from Jam and Tracy over at Oakland Strategy Partners, but it's the concept of rain, right? And rain's real simple. If you're feeling overwhelmed, if you're feeling kind of down in the dirt or whatever, you need to recognize what's going on first and foremost. And what's going on is seldom what it appears to be. So, I may be focused on the fact that a delivery is not being met or deliverable is not being met, but in fact what I need to be focusing on is the person is having a personal drama. They might be going through some type of stress at home or there might be a virus that's affecting their day. You know, you need to recognize what's going on. You need to allow the experience to be there just as it is. So, what that means is in the world of improv, they kind of do an and then kind of scenario. So, essentially an improv, what you need to do when you go up on the stage and you talk to the person next to you is you immediately have to accept their reality for what it is. You can't insert your biases or your your concepts into their reality. You have to take that reality, you have to put yourself in it completely and then you can improv and you can become a part of what's happening. It's the same thing when you're dealing with people in a work environment. You need to first put yourself in their position to be able to communicate effectively. You need to investigate kindness. You know, I can't go into one of these one-on-one meetings or one of these conversations and expect a good result if I'm not kind in the process. I might be able to dictate that just, well you work here so you're going to do this because we pay you money. That's not going to go very far. That's not going to build any kind of rapport with the people that you're working with and you're basically not going to be considered a very nice person if you do it. However, if I go in there and I say, okay, well, I understand that your child is having problems or I understand they pass growing up on your bed or something like that, you might be able to make more of a connection. You investigate what's going on and you start to ask leading questions and you come across with kindness and it has a dramatically different impact. You want to focus on national awareness which comes from not identifying with the experience. So what that means is that if you find yourself in a difficult conversation, somebody might be going through a lot of personal strife, you don't have to own that strife to be able to communicate effectively with that person. You just have to empathize with them. You have to understand where they're coming from and then you give neutral and good advice in return. And if you follow that as a tenant of how you deal with people on a regular basis, you'll succeed in life. You'll succeed in business. You'll succeed with your clients and the world starts to be a different place. It's pretty interesting. It sounds kind of overly simplified, but it's amazing the effects that this type of communication have in an organization. So basically the other tenant of this is that your team of humans is more important than the velocity that you have. And I think I'm able to go back. There we go. So the mountain biker thing is interesting. Again, from Colorado, I do a lot of mountain biking. I do specifically downhill mountain bike riding which involves a lot of speed, a lot of jumping, a lot of danger. One of the most valuable things that you can learn in mountain biking also translates to other aspects of life. And that includes running the business and being able to get looked at. So that concept is that it's slow basically. You have the ability to approach downhill mountain bike race in two different ways. You need to go very fast and use speedo for compensating things. And when you do that, you basically lock up. So if I'm going low-fast down the mountain, I don't want to protect if you're on, I go to the jump, I tense up, I don't want to die, and then I go to the jump and I'm probably so tense that I'm going to crash. I end up not floating in the moment. However, if I completely relax and I understand the mechanics of what's going on, I learn this system that I'm engaging in and I relax a little bit. I get that flow state where suddenly I'm completely relaxed when I'm going over the jump. I'm using a significant smaller amount of energy than I was previously and it's much safer as a result of it. So I get that flow state. I'm able to achieve more by going slower. That's a very important concept in DevOps and when dealing with large teams of people or dealing with small teams of people, is sometimes you have to slow down to go faster. So what that means is, well, we've got 25 different things that we want to do for this OKR system, this particular quarter. Well, that's not going to work. We don't have the velocity to be able to do that. You need to be able to measure things like velocity to be able to answer these questions, but you need to make a conscious decision. There's only so much that's going to fit into that pipeline that allow you to flow properly. And if you put too much into that pipeline, it's going to clog it up. It's going to cause stress. Nobody's doing anything when they want to do the result of it and it's going to feel almost kind of productive because you have to slow down to keep that pipeline optimized. So measuring velocity, understanding the ability of the team to be able to function on that velocity is critical. We use something called Zen Hub, which is an add-on for GitHub. And basically what that does is it puts us into a scenario where we can work with product. We can kind of outline what the map is going to be. Product knows what the OKRs are, what the objectives are. They say, well, out of those objectives, we have these five features that we want to get in to support this specific objective. In these features, we have 10 use cases. These use cases are defined using a Gherkin testable format. So then I can plug that into an automated system, have those tests reflect what is being built in the products, and then create a reporting system that also goes back up to the executive level, to the board level. This is something, well, this quarter we're working on this feature. It has this number of use cases. I can derive that 0% is passing it to beginning of the quarter. I can create an automated dashboard which facilitates the communication from the engineering team all the way back up to the executives using very simple steps. Again, back to that checklist concept. You want to be very consistent in your vocabulary, very consistent in your messaging, and separate it so that it doesn't overwhelm everybody. When we first started making it, everybody was involved in every meeting. Everybody had an opinion and everybody knew what was best for everybody else. And nobody was wrong. So getting together, talking about it, finding a way to break that apart a little bit. Now we have a system where we have the product owners and the technical people. They have a conversation first that starts to align what they're working on, starts to align those use cases, and sets the rest of the team up for success. So once that first conversation happens, it's smaller. It's more manageable. As a result, we get a lot of the decision points out of the way. Then we expose it to the larger teams. It's, okay, here's the objectives. Here's kind of what we're looking for for the user stories. Here's the features that we need to support. What do you think about this? If necessary, we make something called an architectural decision record. And this is a media file essentially that gets stored in a repository of whatever code base we're working on so that when we do have a product to technology and conversation, and there are decision points that come out of that, we're going to use this technology, we're going to use this tool, we're going to take this approach. Those are recorded inside of the repository where each of the engineers are working on so that every single engineer has the ability to learn and understand why they're doing what they're doing. Again, over-communicating and connecting the dots so that people know what they're working on, why they're doing that is one of the most valuable things we can do. Otherwise, what tends to happen is you get, you know, speaking to myself as the other person, I go into something like that and be like, oh, this code sucks. I'm just going to rewrite it because I need to do this. And being completely disconnected from what the intent of the work that I'm working on actually is. And that's a dangerous question for anybody to be because it leads to frustration. The other thing to recognize explicitly is that having space for culture and lost velocity is a privilege. The type of system that I'm talking about, building is not something that exists natively in every organization. So, while it is a privilege to have this, it's also a right that you need to fight for. So if you find yourself in an organization or a team where you're not having this type of communication, first you need to take steps to try to fix that problem. If those steps are not receivable, you need to go find someplace else to work because that's not a great place to be. You're never going to be happy. You're never going to have a job satisfaction that you need. You're likely to have a lot of anxiety as a result of it. It's just not a healthy place. So go find this healthy place. It's made a privilege a part of your life because everybody deserves that. So just to summarize, because I still have no idea of my time allocations. Four minutes. Okay, so basically define the map. Take the time to understand the situation and the people involved. Help your team adjust and move towards the goals that you're setting. Be very communicative about the way that you're driving that ship. And build a space for innovation and clear thinking about challenges where it's safe to experiment and okay to fail. If you do these things, it doesn't matter what you're working on. It could be the, you know, you're the new rocket science of the world. You're going to change everything. Or it might be you're making a cake. You engage people properly. You treat them with respect. You communicate with them and you have a structured system to be able to do that. Record the results and communicate back and forth with most of the company. You're going to be successful at it. And that's a very important thing that a lot of people don't realize. So one more summary. DevOps is not magical fairy dust. Creative, create a culture of safety is critical. So creating, sorry, that's a little blocked out. And it's working progress. That's okay. So for us, we know that we make mistakes. We know that we make them continuously. We're not perfect. So we have to adjust continuously. I learn every day that I go to work. And I learn from the people that I work with. I learn from the tasks that we're trying to solve. I learn from the communities that we engage with. And all across the board, the entire thing works because of communication. So we cannot stress that enough. And that's all that I have. So any questions? Thank you. I thought that was great. And what you were saying really trying, I guess, like a lot of people have gone from working on quite a lot of things to multi-tiered or headless sites and are now working a team where we have probably four different disciplines, working set of disciplines. And whenever I come to things like this, I'm reminded of how much I miss the shared purpose of working on a single thing. And I wonder if you have anything to say about how you encourage the kind of behaviors that you were talking about, which seem valuable in teams whose shared purpose has become siloed in the way that often happens? We have a couple of approaches. And just to make sure that I understand the question is essentially along the lines of, you know, you're on a larger team, you're involved in a very specific discipline in that team. And how do you get back out so they become a bigger part of the team? Don't feel like you're on the sidelines. Yeah, exactly. So the way that we handle that is through structured sprint planning and retrospectives, essentially. So we did the ability at the end of the sprint for each person to give a demo of what they've been working on. That demo is facilitated by a project manager that goes through this together, a slide deck, and we record it. So every single scan up that we have, we go through the normal scan up process, we have a breakout. That breakout is recorded and put into Google Drive. So if you miss a meeting, you have the ability to catch up with it later. At the end of the sprint, you have the ability to demo what you've been working on, and then we get really creative with documents. So, an example, we might use Pyrex, we might use dinosaurs. The last one I think we're going to use, banks and shiny armor. And we just kind of have three or four little sections on the document where people can write in catastrophes for this past sprint, successes for this past sprint, things that you'd like to call out about other people on the team, items like that. So you have to have more structured follow-up to be able to extract the people that might be feeling isolated. So they have the ability to engage with the rest of the team. In addition to that, we found that just the tools that we made really helped with that. So tools like DDEV, back-end engineer, systems engineer, the ability to very quickly spin up something that a front-end engineer is working on. So we encourage collaboration as much as possible. So you may step in and offer to do a test of something that a front-end person is working on just because you can switch contacts fast enough to be able to do that. You don't need to understand all the technology. You just get one command and you can go and suddenly you can help. So it works both ways. You need to make the initiative to reach out to other people on this team. If you're not talking to someone, schedule a regular one-on-one with them. Say, hey, you know, we've got nothing technical or work-related. I just want to talk for a little bit to make sure that I understand how you work so that I can make sure that my work's doing the best that came for you. What that helps. All right, great. Thank you very much, Kevin. Can you hear me? Yes. So I'd like to apologize to SystemSeed for not putting you in the slides. I did it very late last night and I forgot, so I'm really sorry. We'll put the logo up now. But basically, SystemSeed have been amazing. They've been sponsoring the training and without them, the training would not have happened. So can we have a big round of applause for SystemSeed?