Damon Edwards

I'm Damon Edwards, and this talk is about talent.

How many folks out there think their company is concerned about talent, about being able to have and attract the right people? How many of you have been hit up on LinkedIn by a recruiter recently? Right. Yeah, exactly. So obviously, talent's on everybody's mind.

So if we're going to talk about talent, let's actually have a definition. I think there's really formal definitions, but the one we're going to use, I think the one everyone's actually talking about, which is the people who have the skills necessary to make your business successful. Right? So when everyone says talent, that's our shorthand for that longer sentence.

A little bit of a warning. This is not an HR talk. I don't know really a lot about HR, so I'm not going to talk about that. This is not a talk about skills development or how to take an individual and elevate them to a higher level. This is a talk about technical management. How do we take what we do and create the conditions in which people, as a herd, as a team, can flourish? So that's the point of view we're going to talk about here. A lot of things in HR that are great, a lot of things in skill development that are great. That's not my bag, so we won't be talking about that.

So I think why I'm up here: Gene calls me the accidental analyst. I get to see a lot of companies. So today I'm the co-founder of SimplifyOps. We make a pretty kickass job scheduler and runbook automation platform called Rundeck. Some of you might use it.

I was a co-founder of DTO Solutions, a specialist consulting organization focused on operational improvement, DevOps consulting. I do a lot of work in the DevOps community. I do a podcast called DevOps Cafe. Any of you guys listeners out there? Yeah. Oh, wow. Hey. Fans. I love it. So John Willis, who you saw earlier yesterday, it's on iTunes. Please go and download it. We love doing it. It's like a Charlie Rose sort of situation.

And Gene talked about that. So the point is, I get to see a lot of companies, and I get to see good things, bad things, big companies, small companies, and get to see what makes them tick. And I consider myself lucky for that. So thank you for those who let me on the inside.

So executives everywhere, they say, "Well, we can't find the talent that we need to be successful in our transformation." This is a common theme that we hear time and time again. And really this is emblematic of this kind of buy mindset that pervades in our industry. That if only our recruiters could hire the best like those darn unicorns do, we could be one of them too. It's just that we have to go out and recruit, recruit, recruit. That's how we're going to improve the talent in our organization.

And it reminds me of this story that you might have heard before, but Adrian Cockcroft, he was one of the luminaries that took Netflix to the cloud. Now he's at Amazon himself, the home of the cloud. And he was at a special gathering of Gartner, I think, of these Fortune 50, Fortune 100 C-level executives. They're like, "Adrian, we can't find the talent we need. Where do you find all the talent that you have in your organization?" And his answer was, "I hired them from you." Right?

And it's kind of funny in its flippantness, but it was kind of shocking to him because his mindset of, well, this is how we develop our talent. And it's also a giant warning because if you're trying to go against those companies, not only are they the places that people already want to work, they have this little thing called paying top of market, which means they'll always pay one dollar more than you will. Right? And they're dedicated to that. So you got Netflix, the Googles, the Facebooks. So trying to take a buy mentality and beat them in the talent game is really going to be a fool's errand.

So instead, I like to think about the companies we see that were the ones that aren't complaining about not being able to find the right talent. How do they do it? And it's just different. Instead of that buy mindset, it's a grow mindset. Right? So they're out there thinking more like farmers rather than hunters. We're using this grow as a purposeful metaphor here.

And they kind of have this three-step, simple process in their minds. Number one, grow the talent. Right? Number two, retain the talent. And number three, if we have enough happy talent, they'll attract more happy talent around us. It's the same mindset you see the high performers using all across the industry.

And really the key part here is focusing on, well, how do they create those conditions? How do they grow that talent? If you think about what a farmer does, they're tilling the soil. They're obsessing about the weather. They're mending the fences. But they can't make that plant grow. They can't make the individual plants grow, but they can create the conditions in which the plants can flourish. Right?

So how do they do that? And again, I want to go back to saying this is not an HR talk. I don't know how to fix and develop those individuals any more than the farmer knows how to fix and develop an individual plant or an individual animal. But what is my wheelhouse, what is my bag, is talking about all the crap that's around those people. All of the friction, all of the pain, all the things that get in the way of their life.

And now anybody who's in this room, I guarantee you your life's probably pretty good. You're individual contributors, fellows, VPs, SVPs. Life's much better. Think about the people down in the trenches, whether it's in your remote development centers, other places in the industry. Life's not always so rosy. They'll tell you it is. But think about what is their day-to-day life like.

All the extra work in progress, all the rework, unclear priorities, bottlenecks, conflicts, meetings, meetings, meetings, and more meetings. The pain that lives around them. So if we're going to have this system where these people can flourish, how do we clear that mess away so people can do the stuff that they want to do and the company wants them to do?

So anytime anybody asks about, well, how do we transform our organization, I always think to this little gem from Urban Meyer, who's one of the winningest college football coaches of all time here in the U.S. And think about it. He's got to take a bunch of 17-, 18-year-olds every year and mold them into winners. And it's a cohesive unit, and it's a pretty tough thing. So he studies a lot of military leaders, corporate leaders, coaches.

And this great quote, which is, "Average leaders have great quotes. Good leaders have a plan, but the exceptional leaders have a system." And if you think about the organizations we see, it holds true for the DevOps movement. The average organizations talk about their DevOps aspirations. The good organizations execute on a plan to go after their transformation. But the exceptional ones, it's systemic. They've baked it into how they work and how they live, and day in, day out, they're getting good at getting better, or they're getting better at getting better. It's a systemic thing that they do.

So if you're going to create these conditions where people can flourish, you need a system to do that. So if we're thinking about a system, a system needs a goal. What are we working towards? And we talk a lot about the business side in the DevOps conversations. What are we going to do for the business? Well, we're going to have faster time to market. We're going to have improved quality, or we're going to cut costs. Those are all good for the business.

But let's think about what's our goal for our people. How do we know if our people are having those conditions in which they're going to be able to flourish?

So, my podcasting partner, John Willis, an idea near and dear to his heart is that of burnout. We've seen this kind of tragic effect in the industry, and it hit John really hard. He's done a lot of writing and thinking about it. And one of the things he brought my attention to was Christina Maslach, who's a professor at Berkeley across the bay. And she's the foremost expert on occupational burnout. It's nothing to do with IT in general, it's just in the industry and the world in general.

And in their research, they talk about the six burnout... I think it's six. Yes, six. The six burnout factors. What are the warning conditions, I guess they call them? And it's things like work overload, lack of control, insufficient rewards, breakdown of community, absence of fairness, value conflicts. And I could go through all those for hours, but I know we won't have time. But again, think about our people in our far-off reaches of our organization and think about, are they suffering from any of these things?

So that gives us a pretty clear academic formula for when people are not flourishing, when things are systemically bad. So John and I started thinking, well, what if we look for the inverse of that? Does it give us a pattern of what it would be like for people to flourish?

So leveled work, a very lean concept. Do people have a sane, stable, sustainable pace of work with limited work in progress, with plenty of slack time? As an organization, are we empowering people to control their destiny and make decisions that make things better for themselves and others? Do we provide sufficient rewards? Not just monetary, like we're going to pay you more so you stay, but they feel like they're respected. They feel like they're wanted there.

The folks at Netflix, I'm drawing a blank. Patty McCord, their former head of HR, said, "Forget all you say about culture. Who and how and why an organization hands out its rewards tells you everything you know about the culture of it."

Supportive community versus that sort of dev versus ops, us versus them, the cutthroat fighting. Do we have a community where people are working harder and better together? Fairness and transparency, and aligned values. So this gives us the goalpost for are we creating the right conditions, and are our people in a situation where they're going to be able to thrive?

Okay, so imagine that's our scorecard. Now let's get to the actual system. I like to always say lean on lean. It's been around for decades in other industries. We're seeing it having great effect in our industry. So things like value stream mapping, systems thinking, lean waste analysis, A3, improvement kata. There's plenty of examples out there of the nuts and bolts of how to put that system in place, and my talk is not about that, so I'm not going to go into it in detail.

But I did talk a lot last year about that, so if you want to Google "DOES 15 DevOps Kaizen," it's a whole 30 minutes of that. Plus, obviously, there's plenty of talks about that over the course of these three days.

But what I do want to talk about is the design patterns. Because once you put the system in place, you need the design patterns that you can put in there that can help to remove that friction, that can help people thrive, that can level the workload, that can provide them with the fast feedback, that can smooth the friction and make life better for them so they can thrive as a team.

And what you hear over the next few days in this event is great examples of those patterns. In fact, you can go back to the videos over the years and really pull out these gems.

Courtney Kissler, when she was back in Nordstrom. Now, you heard this morning about her new work at Starbucks. But the idea of focusing on speed in order to get quality and throughput. Scott Prugh, his first DevOps Enterprise talk was all about the amazingness of reducing batch sizes, or one of his key points.

Heather and Ross, when they were together at Target, about the dojo model to uplift teams. A new one, Brandon Holcomb and Andy Cooper from Equifax, talking about from the macro level, how do we fund things as platforms, as products to remove the thrash of that project-based funding that is so destructive on organizations.

A couple more great ones, two from Ticketmaster over different events. Justin Dean runs all the global operations, talking about how do you integrate operations to the rest of the life cycle to build these kind of autonomous product teams. Another great pattern, Jody Mulkey, their CTO, talking about empowering teams. How does he empower teams as a leader? And the subtext of both of them is a concept near and dear to my heart: simplifying operations. That this works when you can simplify and standardize operations in order to drive things forward.

So this conference, these events, are great examples of things you're going to put into that system, again, with the eye towards removing that friction and clearing the way.

So, one thing I want to talk about is that notion of simplifying operations, right, and why that's so important. There's this common perception of enterprise DevOps transformations today. So let's talk about the old. We've divided things up in functional silos, right? We had our planning, business activity. We had our dev and test activity. We had our release-type activity and our operation activity. Right? And of course, we had all different names and divided differently, but that was kind of the major buckets.

So now we get into these DevOps conversations, and the pattern that people like to hold out there is this notion of cross-functional teams. Right? Well, let's start to break down those silos. Let's start to provide fast feedback. Let's start to have this smooth end-to-end system that spans all the way from development and planning all the way through to operations. And that's the pattern that people hold up.

But there's this, I call it the dirty little secret of the DevOps movement, which is we do a great job of getting especially the development and the testing and the release, maybe app ops, right, and putting them together. But those folks kind of already live in the same universe already. The bigger issue is getting operations. A lot of these transformations are stopping short of integrating the true, full enterprise operations.

And if you think about enterprise operations, it's the place where all these different product lines have to come together, multi-generations of technologies and techniques have to hold together in one cohesive place to make that enterprise. So it's a situation we see a lot a few years in now where organizations are hitting that wall and having a hard time penetrating operations.

And the thing about why that is, it's the complexity of operations itself. Right? Think about it. I need an environment, right? Or I have a problem, I need something fixed. What happens? I've got to fill out a ticket. It goes into one ticket system. It bounces around to a different labor pool, to a different labor pool, and then I get some information back, and I'm told my ticket was incorrect, so I've got to put a new ticket in. Now it's in a different system, and it bounces, it bounces, it bounces. Right? And eventually, I get something back, and it's not what I wanted, and we do the whole dance all over again.

And this is the world that a lot of folks in enterprise operations have to live in. Right? We call these the siloed labor pools. They're great subject matter experts, grouped like with like. They get these tickets kind of one at a time, have to jump in, do their best, and get out. Capacity is always a problem, and it's a very complex and challenging world to work in.

Let alone the fact that often they're the sort of aggrieved party in these relationships, and they just have to catch and accept whatever development wants to throw their way. Right? So we've basically created this world where operations have become far too complex, far too brittle, far too point to point.

So when you're thinking about these patterns, this is why I love the Ticketmaster examples. Equifax, I think they're speaking tomorrow, is a great example of this. They've really focused on solving that operational complexity problem by simplifying how they work in their operational realm, standardizing their platforms, so they're able to fully integrate their operational capabilities with that horizontal life cycle.

And really, that also enables them to create these other standard platforms and services that then they can support those cross-functional teams with and get them to move faster as well. And reducing a lot of the work that they used to have to do in those manual bounce, bounce, bounce, siloed labor pools into operational APIs. We're really enabling operations as a service.

So it's pretty exciting stuff, but really it's of the idea of how do we remove that friction? How do we make it easy for people to work in these environments so they can be more productive, the business wins, and the people win. Right?

So I want to talk about an example of that. This is Jody Mulkey, their CTO at Ticketmaster. He tells a great story, which is quite remarkable. When you think about Ticketmaster, their response is what matters. Right? The fans are a very public-facing organization. If the Yankees can't print playoff tickets or the Euro 2000 and whatever the next Euro soccer cup is, sorry for the European folks out there, I don't know when that is. But if you can't register for tickets, it's not TechCrunch news, it's CNN news. Right? It's a major deal, and people love to take Ticketmaster to task.

So, in this same notion of how do we simplify operations so we can fully integrate it, so we can empower people, they went after this problem of their MTTR. It was taking too long to respond to incidents. Right? And the average MTTR before they put this new system into place was 47 minutes. Right? So you imagine when people can't buy tickets, when the store is closed, I think it's a 20-something billion a year operation, that's painful. Right? Painful in the bottom line, painful in the press.

After this transformation, which is less than a couple of years old, their average MTTR is now 3.8 minutes. Right? Substantially different case. So let's talk about how they did that.

First, it was the notion of they had to simplify the platforms, standardize the moving parts, make things a bit simpler to manage. But then they have the issue of, well, currently what we have now is we have the... I'll get to that in a second.

Currently, what we have now is where, how does things work? Well, an incident happens. They have a technical operations center. What's their job? To read some books, to figure out who the person is to call. Right? So it's basically a giant escalation machine. Escalations bounced through that maze of different silos until they found the right person who could go and fix the problems.

They said, "Well, if we're going to fix this, how do we push that decision-making closer to the edge? How do we empower those people who take the calls to fix the problems themselves?" So they went to this support-at-the-edge model, and let me give you a walkthrough of how they went about doing that.

First they said, well, who knows the best about whether these things are happy and whether or not these systems are going to be performing well? Well, the people who wrote them. Whether it's developers writing applications or the systems engineering folks who put together the platforms, they're the ones that know best if this thing is healthy.

So they said, well, let's get them to write the procedures. Let's get them to use the same SDLC processes they're using to create their products to create the procedures to which people are going to operate those products. They also brought operations way up early in the life cycle to help them review those procedures, to say, if you're going to put something into production, it is your job to write the procedures that we're going to run, but we're going to come and do code reviews and make sure that those procedures that you are creating are correct.

And then those procedures then follow the same SDLC process. So they're exercising them in development, exercising them in testing and all different environments, up until where they're deployed into production just like their applications are.

And what that actually let them do, well, it let them do a few things. Number one, it made sure the procedures, it offloaded all that work. So the work of having to keep up with what are the best ways to care and feed these applications, let's get the developers to do that for us.

Now, by having those automated procedures, operations now has a standard set of procedures to use. Developers, well, now we can give them some visibility into what's going on because they know the procedures, and also let's give them some self-service. Let them do some things as well. Again, level out that work.

And the best part was, now let's get the technical operations center, who used to be technical, and get them being technical again. Let's turn them back into operators. Let's give them the procedures that they can push the buttons. The runbook no longer says who to escalate to, it says what buttons to push. You're empowered to go and make change itself. And the whole time, operations and security is in control. They get to have the final say over what goes on in their environments.

So by doing this, think about all the little things that they're able to do here. They're able to remove that friction. They're able to level the work. They're able to empower people. They're able to give people rewards that, hey, in the TOC, I'm not just the person that watches screens and calls somebody, I'm an operator. I get to save Ticketmaster when there's a problem. So compliance people are happier. So you're moving that friction all the way around.

Now, this is not a magic bullet to say, oh, you do something like this once, and suddenly everybody wants to work at your company. But you start to do these things, and it really adds up. And we're talking about 90% reduction in mean time to repair, 50% reduction in escalations, which is huge. No longer people are going to be waking up in the middle of the night for things that someone else can solve. And 55% reduction in overall support costs. So dramatic improvement in how things are working.

And if you look at what they've been doing over the last few years, it's been one win after another in these small ways. And by doing that, it's making it a better place to work. It used to be the kind of place where five-plus years ago, it was a big company. It's where you went as a lifer. You could ride your time out in the comfort of a big friendly company with nice benefits.

Now it's gotten a reputation as a place you want to work, a place that's going places and wants to do things because people enjoy working there. They feel empowered. They feel like things are happening because they've been able to take these kinds of wins and add them up one after another and another and plug them into their improvement system to continue to figure out how to get better.

It's a remarkable kind of transformation, and it's a great story. And it's also one of the cool things about the DevOps movement and how they talk about these things, and we can learn from them and then put them into our improvement systems and try these patterns out for ourselves.

So recap, because I know I covered a lot of ground there. The key mindset here, remember we said, think about like a farmer, not a hunter. That's the growth mindset. So step one, grow your talent. Step two, retain your talent. Step three, happy talent attracts more talent. It seems so simple, but obviously the devil's in the details.

The goal of our system, we call it the inverse Maslach. John and I just made that up, so sorry. But leveled work, empowered people, sufficient rewards, supportive community, fairness and transparency, aligned values. That's our scorecard to know, are we treating our people right, and do we feel like we're giving them the conditions in which they can flourish?

And we've got to put that improvement system into place. I lean heavily on those lean techniques. I was kind of joking when I said go Google my talk last year, but you're more than welcome to. There's plenty of things out there. The DevOps Handbook, that's a great example. Also Lean Enterprise and Gene's original bestseller, Visible Ops, all these things that hearken back to these lean techniques that you can use to build your own improvement system in your organization.

Focus on removing the friction. That's where these design patterns come from. As you see each of these talks over the next few days, look for these different patterns you can do. In the podcast John and I do, we're all about trying to get behind these things and find out people's thought process and why they put them into place and why we talk about sharing being so important in the DevOps movement.

And lastly, go all the way with Ops. Let's avoid that problem where we stop short of bringing enterprise operations into this DevOps excitement, into this end-to-end life cycle that we want to enable. And I think that's the biggest challenge that we have out in front of us. Something I'd like to see over the next few DOES summits here is talking more about how do we bring operations in.

It's a hard thing. Enterprise operations is very complex. There's a lot of reality that can't be escaped. And we have to do the hard work of rolling up our sleeves and going in and simplifying it and streamlining it, integrating it into the rest of the organization, and enabling people to do these new design patterns.

And lastly, let's talk, especially if you want to talk about simplifying ops. That's something that's very near and dear to my heart. I'm Damon Edwards at simplifyops.com. If you follow me on Twitter, I'll have a hope of catching up with the number of followers John Willis has, so I'd really appreciate that. And also after this, I'm going to go ahead and post the slides there so you don't have to take notes during all of that.

And so that's it. That's my talk. I think I have a few extra minutes. Gene, are you back there?

There it is.

Thanks, buddy. Thank you, Damon.