Published on 6 November 2014 by

If you’ve been in IT for any length of time, you know why people resist change. It’s risky, for one thing — so many different things depend on each other, and most organizations have enough technical debt that you can’t be sure what will happen when you change something. It’s uncomfortable, too; we’re often deeply invested in the status quo, even when we don’t really like it.

Yet we’re all drawn to talks, books, articles and events that we think will help us make positive change in our organizations. At Puppet Labs, we’re privileged to meet customers and community members who are true change agents of IT ops. They have some great stories to share about introducing innovations in Ops that help their companies adapt quickly to customer needs, business goals and market shifts, and compete more effectively.

These innovators have shown us a few things about what it takes to spark positive change in IT operations:

  • An understanding of why the organization does things the way it does now
  • A clear idea of why change is needed, and what it would improve in the business and in the lives of ops team members
  • Commitment to continuous improvement
  • Willingness to take risks and ask tough questions about the status quo
  • Deep interest in trying out tools, both new and traditional
  • Willingness to lead, and to lead by example

Ask questions and listen

Sam Eaton, director of engineering operations at Yelp, has launched quite a few changes in his career. It’s critical, he says, to understand the patterns your organization has in place before proposing change. You can’t really know whether a change you think obviously beneficial will actually make things worse, unless you make the effort to learn about why the infrastructure was set up as it was. That effort is also critical to earning people’s trust, so they’ll buy in and help implement change.

“Get to know the people who are doing the practices as they exist now,” Sam said. “Spend some time with them. It helps if you’ve done what they do, so you should take the on-call rotation, take the alerts, and walk a mile in the other person’s shoes before you speak up about what needs to be changed.”

That’s a common practice at Yelp. People hired in as managers are often expected to work for a period as individual contributors, to get hands-on experience. Once a person has done that, “you can ask the tough questions,” Sam said, because everyone knows you’ve actually done the work.

When you start asking questions, you might find there are perfectly valid reasons for a current process. Perhaps even more important, when people explain why, and how conditions were when they started doing things that way, “people will probably point out the problems themselves,” Sam said. You’ll get a more accurate picture, and you’re also making it easier for people to acknowledge the need for change, “because they aren’t defending the choices they made back then.”

Because change makes people uncomfortable, and carries actual risk to operations, “you should be concentrating on evolution, not revolution,” Sam said. Make sure you present change as both experimental and incremental. “Here’s something we can try, and see if it improves things in a certain direction, and then we can continue to iterate,” is a much less threatening approach than signaling a change will be permanent, regardless of how it turns out.

Another way to control risk and make people more comfortable with new ideas is to set a time limit. Agree that the group will look at the new process three months from now, or six months. Even better, make it a standard practice to revisit changes after a given time period, Sam advises. “You’re giving the message that this change is an increment, and there will be more increments to come.”

If you start by making small, iterative changes, you can make the case for bigger change more easily. “Sometimes the most convincing thing is to demonstrate value first, and evangelize later,” Sam said. Small improvements show people that there’s real benefit to be gained from change.

You can make your case much better if you’re humble, and admit the possibility of failure. It’s more realistic, anyway, than pretending all is guaranteed to go well. When a change doesn’t improve things, “you need to say, ‘Looks like I was wrong about this. Maybe we should go back and try fixing something else,’” Sam said. This tells people that change itself isn’t wrong — it was just one experiment that didn’t turn out as well as expected.

IT operations teams are charged with keeping things stable and predictable, while at the same time being asked to speed the rate of technology change. Sam’s tips, drawn from years of experience, honor Ops people's rational hesitation to change too much too quickly, or to change for change’s sake.

We’ll be telling stories of change agents in IT ops over the next few months — we’d like to hear yours.

Do you have a story about making positive change in your IT operations team? We’d love to hear it. Email [email protected], and tell us what you did. We may publish your story in a future blog post!

Learn more

Share via:
Posted in:
Tagged:
The content of this field is kept private and will not be shown publicly.

Restricted HTML

  • Allowed HTML tags: <a href hreflang> <em> <strong> <cite> <blockquote cite> <code> <ul type> <ol start type> <li> <dl> <dt> <dd> <h2 id> <h3 id> <h4 id> <h5 id> <h6 id>
  • Lines and paragraphs break automatically.
  • Web page addresses and email addresses turn into links automatically.