How Business Leaders Can Put the “Dev” Back in DevOps

The trouble with troubleshooting? When it’s the No. 1 activity on which tech professionals spend their time, there’s little of it left for development and innovation. As business and technology leaders, we must ensure developers, web product managers (WPMs), and DevOps teams have time to proactively add features and automation to improve the speed and safety of releases—and ultimately the bottom line. Lack of time dedicated to development and innovation has tangible consequences—it can even make or break a business. SolarWinds Cloud Confessions: The Trouble with Troubleshooting revealed a tug-of-war that developers, WPMs, and DevOps teams are currently fighting: trying to innovate and expand the principles of DevOps within their organization while spending the majority of their day troubleshooting issues. When tech professionals spend hours resolving application and infrastructure problems—instead of developing, testing, and automating application and infrastructure components—the team inevitably loses grasp on the fundamental philosophy and business value of DevOps. This negatively impacts both development and innovation, as well as the tech professional’s morale. As business and technology leaders, we must recognize that this juxtaposition is prohibiting tech professionals from applying their knowledge, insight, and skillsets to transform our organizations. We must provide better solutions to help them get back to doing what they love. Here are a few tips for our business and technology leaders to help developers, WPMs, and DevOps teams “get back to it”:

• Prioritize Business Drivers –In your team’s day-to-day activities, work to prioritize business drivers over troubleshooting alone. Do this by taking a step back and becoming more proactive about how you approach handling DevOps. Carefully adopt capabilities like observability and find better, automated ways to monitor staging/developing environments. Think about how to push the boundaries behind automation to find better (and more) ways to automate.
• Educate and Distribute Knowledge – Document and institutionalize all the knowledge across your organization, specifically for the teams that are touching the code and rolling out updates across the DevOps chain. After adopting the DevOps philosophy, educate and train people in your organization. It’s a business leader’s job to implement/leverage resources and tools to train individuals in the organization in the DevOps philosophy and update internal processes accordingly.
• Look at People, Process, and Tools – Help yourself help others. Look at your teams and how they can improve. Look at processes and figure out what you can do better tomorrow than you did today. The “right” tools can help facilitate this; look at tools and ensure they will support key parts of the DevOps philosophy, including proactive work, automation, and spreading knowledge across the board. After considering this, set goals and expectations for what you can improve and how you can practice what you preach regarding DevOps integration.
• Measure Time Spent Troubleshooting – Measure time spent troubleshooting quarter after quarter, to help inform strategy and course correct if the time is not decreasing.

The Cost of Troubleshooting Not only does the lack of time doing development and innovation come with a price tag of missing business goals and losing opportunities, but nearly half of the SolarWinds survey respondents said if they can’t move away from troubleshooting into areas of work they love—e.g., creating meaningful products and services and making a difference in their organization—they will look for new jobs. You run the risk of losing valuable employees if you don’t address the troubleshooting issue internally. From SolarWinds Cloud Confessions: The Trouble with Troubleshooting, it’s clear: business and technology leaders have a job to do. We must set developers, WPMs and DevOps teams up for success—to help drive our business forward, empower them to do what they love most, and put the “Dev” back into DevOps.