Mark Peterson

Hey everyone, my name's Mark Peterson. I'm with Nordstrom, and I'm joined here today by my good friend Ross Clanton from Target. You see our pictures there.

The talk we're going to do today is a result of a collaboration with all those individuals pictured on the slide from when we gathered last spring in Portland to talk about the most important elements of organizational design related to leading enterprise DevOps transformations.

As we were undertaking the work in Portland, we had a really good time talking about where we've had successes, but we had even more fun discussing places where we had failed and our common mistakes.

So what we're going to attempt today is a two-person Ignite. Our slides, in just a few seconds, are going to start auto-advancing on us. Thank you, Brent.

As they come through, we'd appreciate all of you go ahead and give a round of applause for each of these things that you've maybe stumbled on as you've worked through your own transformation.

So with that, let's do it.

All right. Customers don't truly know what they need. At Nordstrom, we have been very successful by letting our technology people drive our system functionality, because we all know very clearly that software engineers know style better than fashion advisors.

Ross Clanton

It's also important to remain functionally siloed. It's easy to apply labor arbitrage and get cheaper labor to do all this manual work. You achieve economies of scale, which allows you to leverage large shared-service pools, and you can keep optimizing around cost and around function and not be concerned about your customer.

Mark Peterson

Collaboration tools and physical co-location are both super expensive. I imagine that everybody in this room has some type of expensive ticketing system that's very complex. We would recommend you stick with those complicated workflows and handoffs.

Ross Clanton

Focus on local optimization. Silos allow us to optimize each function. Who cares if we suboptimize the whole system? Drive cost efficiency at the expense of effectiveness, and don't worry about externalities. Force your burden onto others in the system.

Mark Peterson

Optimizing around projects lets you always put the A team on that project. Then they can move on to the next big thing. The last thing you want is these people to do a bunch of mundane production support, and heaven forbid they get a call in the middle of the night for a system they designed.

Ross Clanton

Hire for all hyper-specialized roles. This really makes it a lot easier to apply Tayloristic management approaches. Who really actually needs T-shaped people? You don't need that much flexibility in your resources. Just line the people up, and management can tell them what tasks they need to do.

Mark Peterson

We all know that if you don't get your features and functionality funded in that first round of CapEx, you're probably never going to get another chance. So for me, this is the idea of you better go big, or you better just go home.

Ross Clanton

Make sure you create lengthy approval processes. After all, these folks definitely know more about the work you need to get done than you do, and bureaucratic approval processes keep us safe and stable. You need extra process to protect you from previous failures.

Mark Peterson

It's clear many mistakes have been made previously. Look at the speakers today. Ask around this conference. It's full of people who have had failures.

I don't think we should be here necessarily to compare scars and rehash history. I think we should be here mostly to one-up each other and do new things.

Ross Clanton

Let HR structure dictate how you collaborate. Who really needs ChatOps? The best way to collaborate with people outside of your team is through an intake request. Don't worry if you need to talk to an expert. They'll get back to you in five days, although it's possible they might decline your request on the fifth day.

Mark Peterson

Highly customized incentive programs for each individual gives people a sense of direction so that they can achieve their individual goals, which is super important. And at all costs, avoid aligning business and IT, because you don't want your technology people taking an incentive hit for bad business decisions.

Ross Clanton

Show of hands, how many of you have had that killer project, the more money you throw at it, the more you need to? How many of you have lived through that? Yeah. That always works. About 10, 20, 30 million in, you finally scrap the project. That's an awesome feedback loop.

Mark Peterson

Long hours, constant flurry of motion, shows a person with the right mindset to do any task at any time and do it over and over. We call these people heroes, and I'm here to tell you they're the future of your organization. Celebrate them.

Ross Clanton

Relying on cascading messaging to change your culture. This works really well, especially when these executives have opposing values and incentives. Don't worry. I'm sure your teams will just blindly buy into the changes. There's no need to encourage your teams to collaborate across organizational boundaries.

Mark Peterson

Repetition is the key to success. So if you fail at something, maybe you just made an error. Don't sit around doing lengthy blameless postmortems. Just get right back on that horse and try again. Just try harder.

Ross Clanton

Focus only on how long the journey is. There's really no reason to focus on short-term wins and use that as momentum to build long-term success. Just build your long-term plan and roadmap. After you actually don't get anything done, you can just redo your plan.

Mark Peterson

Oh, I love this one. Engineers are like artists, and we need to enable this creativity to let them show us their full range of skills. That is a truly empowered culture right there. True beauty happens at the command line, not through a bunch of boring, repetitive automation.

Ross Clanton

Limit risk by avoiding change agents. After all, change is actually really, really hard. If you do this, maybe the status quo will prevail. DevOps is just a fad, right? If you ignore it long enough, maybe the fad will go away.

Mark Peterson

All right. Hope you had a little bit of fun with us. Obviously, these aren't the ways that you should be doing org design and structure around DevOps.

But if you want to find out how, we have a panel discussion tomorrow at 2:15 in the exhibit hall. We've got a great group of panelists that all have expertise in, actually, org design and how to think about that in the context of DevOps.

So please come join us. It should be a lot of fun. Thank you.

Next, we'll have Jeff Gallimore up talking about automated testing. So welcome, Jeff.