feat: add blog contents

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

@@ -0,0 +1,126 @@
+---
+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.