Why DevOps Productivity Tools Kill Your Productivity

DevOps is great. But if you’re like a lot of people, you may have noticed your DevOps productivity decay over time.

You’ve witnessed how your DevOps culture created pathways to automation, helped speed release by breaking down silos, empowered developers to take responsibility for QA and established a mindset of continuous improvement—not to mention left-shifting security.

But you may also be pondering why aren’t your developers more productive?

Here is one thought: Dev tools competing for developers’ attention has become a zero-sum game. The second you introduce a tool to seemingly make your team more productive, it also comes with a learning curve, not to mention that it diverts attention from those tools.

If there’s one thing we’ve learned looking back on the last 15 years, it’s that DevOps is a journey, not a destination.

Going forward, creating a sustainable and efficient DevOps climate will take more than shiny new tools. DevOps needs to take a long, hard (metaphorical) look in the mirror to rethink the way we view our tools, prioritizing simplicity above all.

The Chaos Of Context Switching

Peeking inside the mind of a typical DevOps engineer, you may notice chaos, mostly stemming from attempting to context-switch effectively.

Context switching is a concept from computer science—because computers are very good at it. It’s Computer Science 101: When a CPU needs to switch tasks, it saves the state, whatever it’s working on. Then, it works on a different task. Afterward, it retrieves the saved state and resumes the previous task. There’s no time lost and no inefficiency—the CPU simply picks up where it left off.

But while computers are great at context switching, study after study has proven that humans are not. Or, as the title of one Harvard Business Review article put it, “You can’t multitask, so stop trying.”

In an interview with Fast Company magazine, researcher Gloria Mark, who studies task switching, said that once a person’s work is interrupted, “it takes an average of 23 minutes and 15 seconds to get back to the task.” That’s a problem that both kills productivity and also cranks up stress across your organization.

Leading Distractors For Your Team

So what’s distracting your teams? Ironically, the very tools that are supposed to make them productive.

Harvard Business Review also points out that our brains are hard-wired to crave access to information, as much information as possible. Today’s DevOps tools give us plenty of that—possibly even too much.

Take an example: Slack is great for helping teams work more productively. Slack also hurls notifications at users that demand instant engagement—regardless of what they’re doing. As a result, the productivity benefits of some tools cancel each other out by the distraction they create, paralleling the alert fatigue seen on security teams.

Think of any IT, security, compliance or production incident. Typically, this pulls all of your cloud ops team members into a “war room” operating mode where they abandon all lower-priority ops work. The ripple effect spreads outward. Developers needing compute resources, salespeople wanting SFDC access, new users waiting to be onboarded and external suppliers requiring system access are all put on hold, bringing the organization to its knees.

Also, every minute your cloud operator is focused on repetitive work like access requests, user onboarding or resource provisioning is time they could be spending on innovation.

The Band-Aid Solutions

Ironically, many organizations try to solve these problems by adding dev tools to keep developers on task. What these have in common is they force developers to change their workflow, which creates pushback.

For example, service catalog solutions let development teams put toolchains in place with automated provisioning and the promise of self-serve resource access. Internal developer platforms (IDPs) offer another approach, focused more on the operations side of DevOps and providing templates for configurations and permissions that promise to get teams up to speed quickly.

Both approaches are promising since they open the door to automating self-service actions; however, both demand that your teams change the way they work. Not surprisingly, “Let’s add another tool to reduce our tools” is a tough sell.

The Journey Toward More Sustainable DevOps

So how can we make both DevOps and developers more productive without simply throwing more tools at them?

The ultimate goal should be empowering a culture of self-service that minimizes reliance on DevOps and SREs. Eventually, much will be codified, solving 80% of the backlog while leaving only 20% for operator intervention. However, the ultimate goal is to introduce a tool that doesn’t look or act like a tool, functioning in the background and taking a load off your teams rather than handing them more work.

Will we ever arrive at zero? Probably not. A human in the loop (HITL) will still be essential to oversee the system, but 80% is effective. And edging your organization closer to that ideal is key.

To start moving in the right direction, it’s essential to implement a few concepts, such as easy searchability and usability of resources and workflows that any organizational user can leverage, as well as uniform access controls, ideally triggered through natural language so there’s less learning curve. It’s also important to establish clearly defined and easily accessible workflows.

These measures will help your DevOps team deal with distractions and avoid the chaos of context switching. And as you choose tools going forward, ask yourself: Are your DevOps processes working for you, or are you working for them? If tools are getting in the way, what you need isn’t more tools.

Wherever possible, elect tools that act as a force multiplier, not a distraction. Choose tools that fit naturally into your developers’ workflows. (Hint: That’s also a great way to get them excited about new tools.)

Ultimately, we need to work toward a culture of self-service that prioritizes protecting your most sacred resources: DevOps and developers. Any tools that don’t prioritize this are not serving your aims. Eliminating end-user frustration will put you well on the way toward an efficient, sustainable DevOps culture that breaks away of the zero-sum game.

This article was originally published in Forbes.