kasperhermansen-blog/content/posts/2024-03-09-the-problem-with-consultant-model.md

---
type: blog-post
title: The Problem with the consultant model
description: This post explores the limitations of traditional consultancy in software development, advocating for integrated, long-term solutions over repetitive, short-term fixes. It highlights the need for strategic leadership and collaborative approaches to avoid complexity and enhance efficiency.
draft: false
date: 2024-03-10
updates:
  - time: 2024-03-10
    description: first iteration
tags:
  - "#blog"
---

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.