Josh Atwell

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 in the title. We're going to get together and we're going to go together.

But that's not what's happened that I receive frequently outside. There's a lot of people out there that would like to tell people, "That's not really DevOps. You don't understand what SRE means. You think DevOps is just a title. That's not okay. You can't be doing that."

Well, I talk to a lot of people, and one of the things I loved recently was this: the definition of DevOps is going to continue to change because it's about the outcomes. 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. And in this, I'm so confused as to why people would shame other people and tell them that they're doing it wrong.

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 like that. And when you shame someone, some powerful things happen to a person: they close off. They'll disconnect from their community. They'll stop sharing because there's a lack of trust. And this is common also with abuse, common outcomes.

We're DevOps. 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.

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. They may be motivated for their own gains.

It's important for us to keep in mind also that this is really, really new. All of this started in large part because of 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, needing to do this. It hasn't been a critical component of what they need to do, and the risks have been really low. Now they're just trying to modernize, or there 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 up an instrument, that first step is always the most difficult, and trust me, not everybody's doing Agile yet. 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 these 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.

So make sure that you work to align your language and the outcomes. 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. So I do this a way that I work with customers.

I start with development. Development, they want to go fast. 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.

But we need to remember our operations people, very important. They're building out the platforms that support the underlying track. Without this, nobody's driving anywhere. 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.

Ah, the fabled DevOps engineer. Lots of scorn around this one. The reality that I see is that these individuals are really good at taking the toolchain and all the things that help accelerate a developer, accelerate the race. They're paving the track.

And then we have our SREs. Our SREs are focused on making the driving experience safe, and when there is an accident, safely cleaning up the track, putting in new safeguards so that we can continue to go fast and not slow down. Because the objective is still to go fast.

So this is not complicated. It's not complex. It's just understanding the role in getting to those outcomes and aligning yourself. None of this is wrong. It's all part of DevOps, and it's really important for us to look at people pragmatically in the work that they're doing.

I love Kelsey Hightower. He talks a lot about complication, and 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 get into it.

I just messed that up, but that's okay, I'm done.