How to Prevent Turnover in DevOps Teams
Turnover is all too common in software engineering. The Bureau of Labor Statistics 2021 report found that the average software developer turnover is 57.3%. It’s a market for programmers, and these desirable people could hop off for a higher salary, better work-life balance, different team dynamics, or maybe even a company with a better ESG footprint. However, constant changes in a development team can stifle progress when there is pressure to meet new digital requirements and deliver new features quickly.
The shortage of IT professionals can hamper innovation across the board. But attrition can be particularly problematic in the DevOps space, as the practice relies on collaboration between teams and a shared understanding of operational standards. A knowledge gap here can affect ongoing platform maintenance.
I recently sat down with Nathan Sutter, Global VP of Engineering at CoderPad, to examine the top causes of attrition in engineering and to look for concrete ways to prevent it in DevOps teams. In short, he advocated reducing context switching, giving both engineering and product teams a seat around one table, and not underestimating the flexibility of your teammates.
Reduce context switching
Engineers like ownership and pride in what they create – take that away and it can lead to burnout and even retirement. The more you switch context, Sutter describes, the less you focus on building a core project and the less committed you feel to the code or architecture you’re building. “Engineers like to build cool stuff, ship it, and use it,” he said.
Context switches can occur for several reasons. First, it can simply result from poor planning, in which case engineering time is wasted. Second, a context switch can occur due to legitimate emergencies such as incident response or necessary troubleshooting. Additionally, companies traditionally devolve operational concerns to a production team, increasing the number of applications a developer oversees and reducing their role in ongoing maintenance.
Instead, Sutter is a proponent of allowing developers to own everything about an application end-to-end. Essentially, the DevOps or infrastructure team builds the framework and the application teams are responsible for the rest, e.g. B. Writing Terraform configurations, Docker containerization, monitoring and alerting, and readiness support. In other words, you operate what you build and own the component throughout its lifecycle. This practice has already been adopted by full-cycle developers at Netflix.
Especially in DevOps, readiness cycles can be challenging when you have so many things to own. “When you have 25 apps to look after, something always goes wrong,” says Sutter. “It’s an “exhausting, thankless and appalling way of working.” This imbalance can impact work-life balance and reduce your time to focus on updating core infrastructure.
Don’t separate engineering and product teams
Another setback that could manifest itself in revenue has to do with inefficiencies caused by siled teams. Suppose a product team spends months sketching a complex software design in a black box. In this case, they will most likely encounter many problems once the schematics are finally sent to the engineering teams. Without prior collaboration between the two groups, companies can increase time to market for new features and face frustration between teams.
Instead, Sutter believes product and engineering teams should balance each other and collaborate more closely in the product design phase. While product teams can identify “where the puck is going” and market trends, engineering teams figure out how to engineer those designs and build a long-term scalable work flow. Of course, the other side is also true – engineers can overdo their hand and plan the smallest details too far into the future, Sutter described. This underscores the need for ongoing collaboration where both sides at the table have a voice.
Don’t underestimate the flexibility
While software engineers like to have a sense of ownership, let’s not discourage flexibility—people get bored of working on the same thing for years. There’s also the sunk cost fallacy to consider, which states that we tend to value things more because we’ve put more time and effort into them. Therefore, providing flexibility to pan when it makes sense can increase overall satisfaction and output.
Accordingly, flexible management is also crucial to accommodate pivots when they are necessary. For example, when a project is in full swing but an engineer identifies a new, more elegant solution, team leaders should be open to detecting and responding to changes. But to make that kind of relationship happen, trust and openness have to go both ways, Sutter said. When engineers can’t articulate their ideas or are afraid to tell their boss they’re wrong, those important conversations can’t happen.
A flexible structure is also necessary to attract talent that prefers a more modern work-life balance. As large tech companies with multimillion-dollar commercial leases now want employees to return to physical offices, small to medium-sized businesses now have an unprecedented upper hand to attract and retain talent when they leverage flexible remote hybrid working options, added Sutter.
What matters most?
According to the EDB Open Source Talent Survey, the majority of developers working on open source projects are open to changing jobs in 2022. Job satisfaction is a challenge to rack your brains and every engineer can come from a variety of backgrounds reasons to be motivated.
But after building and leading many software engineering teams over the years, Sutter saw an interesting shift in attitudes about what matters most to software engineers in their day-to-day work. Before COVID, software developers were definitely interested in higher compensation, he said. After that, it built something to be proud of, team camaraderie, the value of a brand name and a positive work-life balance. Post-COVID, compensation and other benefits are still just as valid. Still, hybrid flexibility is often a table game — some are even willing to take a pay cut to get these benefits. This underlines the great importance of flexibility when leading modern software engineering teams.
Executives and technical directors have a lot to do when it comes to attracting and retaining top talent. Interestingly, however, many obstacles are not so much technical problems as human and organizational problems. As we mentioned earlier, reducing context switching and increasing ownership of individual products could increase satisfaction. One of the tenets of DevOps is also the de-siloing of teams to improve collaboration. Reducing effort could also go a long way towards increasing happiness. Regardless of your chosen strategy, it’s always good to “show openness and understanding to listen to people when they’re not happy,” Sutter said.