It’s commonplace to read about how DevOps is transforming modern software development. The practice has achieved mainstream status and businesses of all shapes and sizes are adopting DevOps tools and principles to optimize their software delivery.
Transitioning your organization to DevOps involves an overhaul in processes, technology, roles, culture, and even mindsets so teams can effectively work together toward a common goal – but someone has to lead the effort.
Your management style has a direct influence on how teams respond to these significant changes, so if you truly strive to streamline all dimensions of your organization with DevOps, you must upgrade the way you manage your DevOps team.
Prioritize company culture
In a survey conducted by Quali, the most common barrier to total DevOps adoption amongst respondents was the culture.
The notion that everyone should collaborate toward a common goal and that everyone is responsible for the project’s success is an unfamiliar mindset for most organizations. The problem is that corporate culture runs deep and is usually left in the backseat while DevOps tools and processes are prioritized.
This is where the importance of leadership steps in. You’re in charge of breaking down silos and discouraging the tradition of throwing code over the fence (then blaming someone else when something goes wrong). Instead, everyone should have an attitude of shared responsibility, mutual understanding, and empathy. This is the foundation of a successful DevOps team.
In an interview, Jason Poole, a senior software engineering manager at New Relic, shared the results of prioritizing DevOps culture,
“Rather than managing siloed teams of dev and ops engineers, I’m managing one team that is focused directly on delivering customer value,” Poole says. He adds, “Our teams are healthier because they work toward the same goals together, solve trickier problems together, and celebrate wins together.”
Foster close collaboration, but separate duties
While the DevOps model dictates that teams should cooperate and collaborate on shared tasks, there is a strong need to maintain a separation of duties to reduce the risk of fraud and failures.
This may sound contradictory, and on the surface it would seem so. DevOps calls for zero barriers between dev and ops teams, but separation of duties means there should still be a line. The fact is, combining teams does not mean combining duties. Embracing DevOps should not mean Developers also take on the role of Operator.
High-performing DevOps understand this. These teams have clearly defined roles where members focus on what they’re best at to optimize the team’s workflow around everyone’s abilities. So while assigning multiple people to complete a task means bringing everyone together, there should be a limit to the power any individual has over what gets put into production.
For example, dev teams should be allowed to see what’s going on in production so they can analyze issues and avoid bottlenecks, but they just can’t change it. This calls for more eyes on any troublesome findings and prevents any single individual from negatively impacting the environment – whether intentionally or not.
However, it can be difficult to maintain and keep track of who’s authorized to do what, in which environment, and when. Manually managing various roles, permissions, and tasks will likely slow down deployment, so make a point of automating the controls for separation of duties for safer software and reduced risk of compliance violations.
Measure results, not time
In a traditional 9 – 5 setting, an employees’ performance is measured by how many hours they spend hunched over their keyboards. With DevOps, the objective is to deliver more value to the customer in less time, so what really matters are the results and not the number of hours your team works.
Prioritizing time spent over delivered value will only leave your team feeling punished for working more efficiently. As their leader, it’s up to you to make the switch and start measuring your team’s effectiveness based on results, rather than the time commitment.
Although there is another important reason to focus solely on measuring results, and that’s the autonomy it gives developers to be responsible for their own productivity. Research shows that workers actually value autonomy over money, so when you’re not micromanaging their time, you’re instilling the trust and freedom developers crave – resulting in a much happier and more productive team.
Focus on automation
“DevOps means having a fully automated workflow to deliver software. This cannot happen without mature automation that works.”
– Eran Kinsbruner, lead software evangelist.
DevOps relies on the automation of Continuous Integration (CI), Continuous Testing (CT), and Continuous Delivery (CD) to deliver better software faster and with less risk.
Traditionally, only testing was automated and the rest of the pipeline required human intervention. But even with highly skilled workers, human intervention equals an increased chance of errors.
In DevOps, automation starts from the code generation on a developer’s machine and continues even when monitoring the live application in production. The end-game is for your entire software development lifecycle to become automated, leaving your team to focus on bigger and better tasks rather than babysitting each and every phase of the pipeline.
So, you need to find a technology that allows you to optimize, standardize, and automate your software delivery lifecycle (SDLC) to deliver the speed, reliability, and consistency expected of DevOps. For dozens of Global 2,000 companies, including Netflix, Target, and Etsy, this technology is Spinnaker.
Spinnaker not only allows teams to replace error-prone paths to production but also enables completely automated deployments across multiple cloud targets. With Armory’s Software Delivery Platform, powered by Spinnaker, enterprises can jump right into delivering value with confidence and velocity without interrupting their team’s day-to-day operations.
Having a platform that takes care of automating and optimizing your SDLC not only spares your team from a major teething stage of DevOps adoption but also frees you up to focus on fostering the more people-reliant aspects of DevOps that truly bring the practice to fruition.