|
Automate yourself out of a job. Sounds like terrible career advice. If you automate everything you do, why would they still need you? I used to work with a team that thought like this. Mostly sysadmins that had been doing similar things for 20+ years. Every month they had a manual patching process with a few bash scripts as the extent of their automation. Some ticketing system that told them which runbook to follow. Or worse a ticket for a problem that was handled with tribal knowledge. They viewed it as job security, as long as things kept breaking their job was safe. It's actually the riskiest thing you can do right now. Here's why. AI has made writing code dramatically faster. Developers are shipping more features, more services and more changes than ever before. But all of that code still has to be tested, deployed and monitored before it reaches users. Shipping code is the bottleneck now and it's driving massive demand for DevOps engineers. Here's how I think about the work a DevOps engineer does. It falls into three buckets.
The first two have a name in the industry, toil. Toil is work that's manual, repetitive and never-ending. The more technical debt you accumulate the more time you waste repeating the same task. A lot of engineers spend most of their week on toil. That's the job that can be replaced. Your goal should be to automate away as much of the toil as you can. This gives two benefits. Your team or customers relying on you to do the work now get a more consistent and faster result because they're not waiting on you. You can go on vacation. Just kidding… removing the toil from your day frees up time to work on higher leverage activities. Document the questions you're consistently asked by team members. Build an automated process for applying patches. Set up alerts for your Kubernetes pods that are repeatedly crashing, before they crash. I'll give you a small example from my own work. I worked at a company provisioning a ton of infrastructure on Azure for a period. Every time I created Azure resources inside our network, I had to send an email to IT requesting they add DNS records for my new resource to our internal DNS. I argued for months that we should allow our Terraform code to add the DNS records, but they were worried of giving up control. This meant I could provision infrastructure and sometimes not test it for 24 hours while I waited for some random guy in IT to spend 3 minutes typing in a few records… Toil. Finally after enough times of me bugging them and a handful of typos in DNS, we automated it. Now every Terraform module that requires DNS changes just applies them. Did I make anyone useless? No. I got a faster deployment process with no typos and IT no longer was annoyed by my daily requests for the same work. So don't be afraid of automating yourself out of a job. Because making everyone around you move faster is valuable. But keeping tribal knowledge as your source of job security is a sure fire way to end up lacking skills in a time where automation is king. Mischa P.S. I'm running a free live workshop on Tuesday Oct 20 at 5PM CEST: The DevOps Roadmap. Live Q&A at the end, and you get the replay if you register. Save your seat here. |