It is no secret that it is difficult to recruit and retain IT talent. Millennial disloyalty, boredom, stressful workplaces, and the ubiquitous advice that job-switching leads to higher salaries are some of the many reasons employee tenure is reaching all-time lows across multiple industries. Low employee retention in the enterprise always means expense and disruption.
Turnover among cloud engineers and in DevOps teams is especially painful. According to a recent survey of IT executives, 43% of polled companies report being understaffed in IT. Furthermore, 41% of large firms pursued cloud expertise in 2015, greater than the number that pursued security, network, or data analytics expertise. Replacing lost cloud engineers can take months and delay projects making it particularly challenging for companies beginning DevOps transformations or establishing small, efficient pockets of cloud-based teams.
Volumes have been written on how to retain tech talent. Improving working conditions and higher pay might help, but what enterprises really need is an insurance policy against turnover. They need to create conditions such that when a cloud engineer leaves, projects stay on track.
To create those conditions, you need to create a team of cloud engineers that is protected from turnover: an outsourced cloud team. To be clear, this would absolutely not be to the exclusion of creating an internal cloud team. But as more enterprises undergo cloud transformations, many are realizing that a combination of internal DevOps teams plus an external team is a highly effective strategy.
Your internal DevOps team should be laser focused on product delivery. Their goal should be cloud-enabling your applications, creating automated deployment and testing pipelines, and making sense out of the complexity of your existing monoliths. They should be building new applications that deliver immediate business value.
To achieve these product transformations most efficiently, your internal team should have pre-configured cloud computing resources on hand. These cloud resources should “just work.” Your (expensive, valuable, but easily bored) DevOps engineers should not be responsible for spinning up cloud instances and manually configuring cloud networks, installing anti-virus, and managing backups.
Despite the marketing speak, no cloud platform automatically supports your applications out of the box. Cloud platforms like AWS and Google abstract away your physical interaction with machines, but someone still needs to maintain the services your applications run on top of, set up Auto Scaling, establish security groups, etc. and monitor your environment 24x7x365. And most importantly, someone needs to templatize your cloud resources so that your DevOps team has a library of cloud resources to support new projects. Outsource this. Make your cloud a stable, repeatable, secure foundation for your internal DevOps team to use. Focus your DevOps engineers on what matters to your business.
Why not build this technical cloud platform knowledge in-house? Because outsourced engineers do not quit. For several long-term clients, Logicworks is the highest tenure engineering team. For some clients, we have seen multiple executive teams and nearly 80% turnover over the course of our engagement. We frequently train new staff and when issues arise in their applications, we offer historical context. When a new engineer makes an error, we let them know that 18-months ago their ex-colleague tried the same thing — and here is why it did not work.
This is the kind of continuity that is extremely valuable for a rapidly growing team. For a company in the middle of a DevOps transformation that is relying heavily on the experience of a very small group of highly skilled engineers, this is crucial.
As you create your 2016 budget, it is worth considering whether or not you have an insurance policy for your cloud transformations. The outsource/in-house debate has never truly been a strict dichotomy; in cloud projects, both are necessary to create efficient, fully-functional, and stable teams. You cannot control who quits, but you can control what remains behind.