For many years I believed I could change the system from the inside. Become the manager, fix the processes, deploy DevOps, train the team, mentor the engineer, and speed up delivery. But of course, that doesn’t scale without buy-in from everyone and it definitely doesn’t move quickly. As a manager you have responsibilities, and you are still governed by the very processes you’re trying to change.
So, I finally started to understand my best fit for the world of software delivery. And it’s coming full circle, back to where I belong. Anyone who knows me will tell you that I like to jump on new things, learn them, implement them and then move on.
Now, for that personality type, you would think that consultancy is the perfect fit. However, I’ve come to realise that traditional ‘consulting’ is not optimised for speed and efficiency – it’s optimised for hourly billing.
There is no incentive for the consultant or the intermediary or company through which they work to make it a shorter engagement. More consultants, more hours, more complexity, more money. The client loses both ways. Additionally, I lose interest in that arrangement. I don’t want to be locked into a long-term contract with my clients. I want to deliver value when they need it, I want to move on.
So that’s lose-lose.
Additionally, the top speed that anyone can ever work is always governed by the speed of the process. Technical problems get solved very quickly, but they don’t always get delivered into production quickly. This is often because not enough attention is paid ahead of time to the delivery process i.e. compliance, security, release management, and change management. Additionally, if your scripting and automation are weak, you’ll get breakage in CI/CD before you even get to the regulatory hoops you need to jump through.
So I’ve been trying to work out how to do all these things.
- Speed-up technical delivery
- Solve procedural delivery problems systematically
- Deliver this for a fixed-price
But, that’s not quite enough. You see, I’ve always loved fixing broken things – reusing something which already has a massive sunk cost.
Sunk cost though is not sexy. Everyone wants something new. But by the time you’ve built the new thing, it’s already legacy. So how do you know when to abandon and re-write, and when to stick with a platform that’s already working?
It’s the same with your legacy codebase or your legacy application. By focusing on the legacy software you also fix two big problems in your team, namely:
- Staff attrition because fewer people want to support legacy than want to do new stuff. Doing new stuff helps people move on, it doesn’t help your core mission.
- Legacy becoming a huge support headache through a lack of knowledge and expertise.
What if you could make legacy a destination rather than something to be avoided? What if you could make legacy sexy?
So that’s it. My particular focus, is on legacy systems and making them, not only more supportable and maintainable but also something that you and your engineers will be proud to work on for many years to come.
This means making legacy systems a destination rather than saying “no we need to rewrite this in microservices or in lambdas” let’s just take a look at what you’ve got. Let’s improve our technology and our processes around that technology to take away distractions from the core service that we’re offering.
So, since June 2022 I’ve been working on a statement about what I offer and so far this is what I’ve come up with:
I fix your technical and procedural software delivery and make your legacy systems a destination for the best engineers.
So, this is my offering. It won’t be for everyone. But it might be for you.
If you have any questions then please feel free to check out my resources and my daily newsletter where I explore all of these subjects in more detail. And who knows, perhaps we’ll get to work together someday?
Thanks for reading!