Throughout my career, I’ve built engineering toolchains to help software development teams deliver higher quality software, more quickly, with less fuss. I’ve also worked hard to improve feature throughput with pragmatic application of (Agile) project management.
Many of the engineering leaders I’ve worked with have realised the importance of tooling, but few have the luxury of someone dedicated to implement it. Being a software geek looking for an automation angle, I was always looking to optimize the development experience for those I worked with. So I stepped up. The happy accident of that meant that teams could focus on delivering more features and worry less about building, packaging and deploying the software. The boring stuff that ensures insight, quality and repeatability – the cornerstones of resilience.
After many years of building bespoke automations using scripts, they invented a word for all of this – DevOps. Off the back of the movement came a ton of products which help us now every day. The merging of Development work with Operations work which meant that faster feedback and faster fixing of failing or incorrect software. Nowadays there is a sea of automation and tooling options for all engineers to use off-the-shelf, but this doesn’t always mean that we go faster or deliver more value.
Why?
Because we have too much choice in our toolchains, too many ways of doing things differently and it’s very hard to see what’s going on. Sometimes we even have multiple implementations of the same tool within our enterprise. How many engineering leaders end up building their own bespoke observability platforms? Too many.
Wanting to give engineers the freedom to play and experiment is wonderful, but how can you combine that with a vision, oversight and ensure quality and speed at the same time?
That, my friends, takes work. Break it out. Make it a work-stream. Treat it as a product in its own right.
It’s vital, so treat it with respect.