Las Vegas 2019

Lightning Talk: Ending DevOps Shaming And How to Embrace Everyone's Journey

Lightning Talk

JA

Josh Atwell

DevOps Journeyperson, Splunk

Transcript

00:00:03

Let's roll that beautiful bean footage go. I thought they would pick up on that. Sorry. Hi, I'm Josh. And I want to tell you, I love this community and I love this conference because everybody here it's, it's in the title. We're going to get together and we're going to go together, but that's not, what's happened. IRSE frequently outside. There's a lot of people out there that will like to tell people that's not really dev ops. You don't understand what SRE means. You, you think dev ops is just a title. That's not okay. You can't be doing that. Well, I talked to a lot of people and one of the things I loved recently was was this right? The definition of dev ops is going to continue to change because it's about the outcomes, right? It's what we're doing at the end. It's not the methodology of how we get there, but a lot of people get wrapped up in the methodology.

00:00:54

And in this, I'm so confused as well. Why people would shame other people and tell them that they're doing it wrong. Right? I think it's mostly a lack of empathy, but I think there's also this desire to show people the error of their ways, because we liked that, right? And when you shame someone, some powerful things happen to a person, right? They close off they'll disconnect from their community. They'll stop sharing because there's a lack of trust, right? And this is common. Also with abuse, common outcomes were DevOps, right? It's not very DevOpsy to move people to be excluded from a community. We want to bring people into the community because we know as a community we're stronger. Okay? So it's important when you see this to put a stop, because if we're not doing it right, somebody else is going to step in who may not have the best motivation to help an organization or help a person along their journey.

00:01:50

They may be motivated for their own gains. It's important for us to keep in mind also that this is really, really new, right? All of this started in large part because the emergence of mobile phones and the way that we want to connect with other people, we're only 10 years into this six years into this event. And not everyone has been disrupted early enough to like needing to do this, right. It hasn't been a critical component of what they need to do. And the risks has been really low right now. They're just trying to modernize or there there's, hasn't been a need to change. It's also important to keep in mind when we work with our fellow, journeyers that the first steps are usually the hardest. If you want to take up a new language or you want to take them an instrument, that first step is always the most difficult.

00:02:36

And trust me not, everybody's doing agile yet. Right? Lots of people still taking first steps. And we also always think about this destination we have in our mind, when we go on a journey of what it's going to be when we get there. But there's so many unknowns there. So when you start on this journeys, you're already in a place of insecurity. So as journeyers, we need to embrace other people and be mindful of their journey. It's different. They have different customers, different application types. They may have different budget. They may have poor leadership. You've all had these conversations here. We need to have them outside to make sure that you work to align your language and the outcomes, right? You want to be talking on common ground. You want to make sure that when you're listening and communicating back, you're communicating the same way.

00:03:22

So I do this a way that I work with customers. Uh, I start with development, right development. They want to go fast, right? They do not want to put a foot on the brake. They want to go as fast as they possibly can to get new features and new capabilities out to customers. Well, we need to remember our operations people, very important. They're building out the platforms that support the underlying Trek, right? Without this nobody's driving anywhere, right? The code just sits on the shelf. And they're often working with old stuff that wasn't meant for this and having to adapt it and trying to adapt the new stuff. Uh, the fable dev ops engineer, lots of scoring around this one. The reality that I see is that these individuals are really good at taking the tool chain and all the things that help accelerate a developer accelerate the rates, right?

00:04:10

There's they're paving the track. And then we have our SRAs. Our SRS are focused on making the driving experience safe. And when there is an accident safely cleaning up the track, putting a new safe guards so that we can continue to go fast and not slow down, right? Because the objective is still to go fast. So this is not complex complicated. It's not complex, right? It's just understanding the role in getting to those outcomes and aligning yourself. None of this is wrong. It's all part of dev ops. And it's really important for us to look at people, pragmatically and the work that they're doing. I love Kelsey Hightower, right? He talks a lot about complication and like, you know, we're doing this to ourselves. So rather than telling everybody that they have to keep changing and doing different things, look at the model of how their organization works. So go out there, practice empathy, respect the constraints of others and be a journey guide. Talk about how you got to where you are. And remember opinions are like noses. Everybody's got one, but you don't want to stick. You get into it. I just messed that up, but that's okay. I'm done.