The Problem with the consultant model
@kjuulh2024-03-10
I recently talked about Developer Experience in a few places and got a ton of messages afterward – way more than usual. People were really resonating with one particular point, so let's dive into it.
Here's what I heard from a consultant: “..., I’m stuck doing the same old stuff again and again, even within the same client.” And from regular employees: “What you showed was cool, but we’re just redoing the same things over and over.”
So, what was my talk about? I shared how we set up shared infrastructure at my company. This means devs can just focus on the cool stuff, their business logic, while we handle the boring bits like platform runtime and pipelines.
The main thing I picked up from the feedback: whether you’re a consultant or a dev, you’re probably tired of setting up the same infrastructure every single time. And it's tough to step back and think about a shared approach to fix this.
Handy but Fleeting
Consultants are like a quick fix for companies that can afford them. They fill a gap and then they’re out. It's easier than committing to a permanent hire, but it's pricier in the short run. It's a bit like choosing cloud services – convenient but can get expensive, especially if you get too hooked on them.
The trouble with consultants is they don’t really become part of the team. They pop in, do their thing, and pop out. This means whatever they build can get lost in translation when they leave, since they take their know-how with them. Even with the best handover, it’s not the same as having them truly embedded in the team.
Bespoke, boutique, everywhere
Here’s the deal with the current setup: consultants come in with their cloud expertise, set things up for the team, and then bounce. This isn’t bad in itself, but it becomes a problem when every team ends up with their own custom setup. It’s great at first, but later, the team struggles because they don’t really know the ins and outs of what's been built.
Every team doing its own thing means no one’s thinking about how much easier life could be with a shared system that everyone uses.
Oil and Water
Consultancy firms aren’t really into the whole 'one-size-fits-all' solution thing, and businesses usually want quick fixes, not big-picture solutions. This leaves consultants and devs kinda stuck – they want to create better, easier solutions but can't always make it happen.
- Consultants typically swoop in, fix a specific problem, and then peace out.
- Devs, on the other hand, are too busy delivering business value to really dive deep and evolve these solutions.
This often ends up piling on complexity for companies without really unlocking the full benefits these solutions could offer.
From what I've seen, getting a consultancy to solve a problem is usually not a great long-term move. I’ve mostly seen success when they’re brought in for extra hands or for training, not as a standalone squad handling features.
Delayed Gratification
The key? Be patient for that metaphorical cookie. It takes mature leadership willing to tackle the big issues instead of just patching up small ones here and there.
Companies should be willing to use consultants, but they need to be integrated into the teams maintaining the solutions. I’m not a fan of outsourcing the whole implementation to a consultancy, though. That can lead to a messy situation where the company becomes too dependent on the consultancy. If you’re a dev or leader and you see this starting to happen, shout it out to the higher-ups. Otherwise, you're looking at a huge pile of technical debt and a knowledge gap that's a nightmare to cross.
Making it Work
I've seen a few places actually nail this, although it wasn’t without its challenges. The common thread? They brought in a domain expert backed 100% by management.
Tackling a problem that every team has their own approach to can cause a lot of tension. Management needs to fully trust the domain expert to handle things smoothly. If not, it just undermines the whole effort.
This puts a lot of pressure on the new team and the domain expert. They’ve got to deliver something solid, which is a whole other story, but it's definitely possible and worth the effort.
The Payoff
If you get these shared problems sorted, it can massively speed up development. I’ve been at places where setting up a production environment was a months-long ordeal. At my current company? It's a 5-minute job, with next to no long term maintenance requirements.
Compare months of work for, say, three developers to a quick setup by two devs. That's a huge saving. Sure, you might think it’s nuts that setting up for production could take that long, but it's a different ball game at traditional companies with their own data centers and rules compared to just using AWS on the side.
Wrapping Up
I was struck by the feedback from consultants – they were just as keen to improve and evolve their solutions as the devs. They’re tired of the endless cycle of temporary fixes.
In my view, the current consultancy model isn’t cutting it. The best results I’ve seen are when consultants are part of the team, not just passing visitors. The goals of the consultants and the company are often too different, which is why it often ends in frustration.
Hopefully, this post gives you something to think about. I’m already seeing some companies tackling this issue head-on. Others should take note – unless they want to keep dealing with the same old problems.