One of the most common—and frankly, most damaging—mistakes I see organizations make when they set out to “do DevOps” or pursue engineering excellence is this: they outsource the whole thing to a vendor. It’s a pattern I’ve seen repeated across industries and continents, and it almost always leads to the same set of problems.
Let’s be clear: outsourcing your DevOps transformation is the least likely way to achieve a positive, sustainable outcome for your business. Why? Because you’re not just buying a set of tools or a shiny new pipeline. You’re buying a black box—one that your own engineers don’t understand, can’t maintain, and will inevitably become dependent on. This is the very definition of vendor lock-in, and it’s a trap that’s both expensive and difficult to escape.
Here’s what typically happens:
- The vendor builds something bespoke, tailored to their own way of working.
- Your engineers inherit a system they don’t understand.
- Every time you need a change, you’re back at the vendor’s door—paying for every tweak, every upgrade, every fix.
- Over time, you fall behind. You’re stuck on old versions, unable to move forward without another costly engagement.
This is exactly how organizations end up with legacy systems that are impossible to modernize. It’s how you get stuck on .NET 3.5, or find yourself still using TFVC or Subversion when the rest of the world has moved on to distributed source control like Git.
So, what’s the alternative? Partnership, not outsourcing.
You need someone who will come in and work alongside your people—not to do the work for them, but to help them do it themselves. This is the approach I take with every organization I work with. I’m not there to rack up billable hours making changes in your system. In fact, I often don’t even have credentials to your environment. My job is to help your engineers:
- Rebuild their workflows for a modern engineering context
- Refactor and break down legacy systems into manageable pieces
- Understand the theory and philosophy behind modern practices
- Tackle real-world problems as they arise, together
Let me give you a concrete example. I’m currently working with a customer who’s still on TFVC and SDN, with codebases scattered across .NET 3 and 3.5. The challenge isn’t just technical—it’s about mindset, workflow, and incremental progress. How do you even begin to upgrade? Where do you start? What’s the smallest, safest piece you can bite off and deliver value?
Moving from a server-based source control system like TFVC to a distributed system like Git isn’t just a migration. It’s a fundamental shift in how you manage code, branching, releases, and even what you put in your repository. Every decision has downstream implications for your product, your process, and your people.
This is why you need a partner who can:
- Teach: Explain not just the “how” but the “why” behind each change
- Mentor: Guide your teams through the inevitable bumps in the road
- Coach: Help your people build confidence and competence
- Transform: Enable your organization to own its engineering excellence
My background is in software engineering, not just coaching and training. I’m a Microsoft MVP in DevOps and GitHub, and I’ve spent years as a DevOps consultant, building pipelines, modernizing practices, and—most importantly—helping teams build the capability to do it themselves.
If you want to achieve true engineering excellence, you need to do it on your terms, at your pace, with expert guidance—not by handing the keys to a vendor. Let’s work together to build the skills, the mindset, and the practices that will set your organization up for long-term success.
Ready to move beyond vendor lock-in and start your journey to engineering excellence? Let’s talk.
