The Best Consultancies Make Themselves Less Necessary

I’m preparing for a talk with Equal Experts, and it’s got me thinking about consultancy.

I’ve worked for consultancies, alongside them, and inside companies while consultancies have come in to assess them.

Some experiences have been brilliant.

Others have made me uncomfortable.

And the more I’ve seen, the more I think the difference between a good consultancy and a bad one often has little to do with technical ability.

It comes down to culture, honesty, empathy and transparency.

But above all, it comes down to incentives.

Every consultancy has to make money. Of course it does.

But how it makes that money matters.

The business model does the pulling

If more people, more billable days and longer engagements mean more revenue, there’s an obvious tension.

An assessment can become a sales pipeline.

A problem can become another engagement.

A gap in a team can become an opportunity to place somebody.

You don’t need bad people for this to happen.

Sometimes the business model does the pulling for you.

I wouldn't have done it like that

Years ago, I was part of a consultancy engagement that I still think about today.

I can’t name the consultancy or the company involved, but our mandate was clear: go in, assess the organisation, find the problems, make recommendations and create openings to bring in more of our own people.

I watched us do real damage.

We found fault with the code, the testing, the processes, the architecture and then the people.

But we had something they didn’t.

Hindsight.

We hadn’t lived through their deadlines, changing requirements, budget constraints, people leaving or the compromises that had got them there.

It’s easy to arrive afterwards and say:

“I wouldn’t have done it like that.”

Of course you wouldn’t.

You already know how the story ends.

That’s why Norm Kerth’s Prime Directive has stuck with me: start from the belief that people did the best they could with the information, skills, resources and circumstances they had at the time.

You can still call out bad decisions.

You start with curiosity rather than judgement.

He wasn't full stack

One example from that engagement has always stayed with me.

There was a backend engineer who was good at what he did. He knew the system, cared about the product and delivered value.

We invented a problem: he wasn’t “full stack”.

There was no problem to solve.

The company already had people doing the frontend work. He was a backend engineer, enjoyed being one and was good at it.

He left.

That left a gap.

A gap a consultancy could fill.

I've written about that engineer before, from the team's side, in good products die when people become resources.

That bothered me then.

It bothers me even more now.

Sometimes the best solution is boring

I’ve seen the same thing with technology.

A straightforward problem needs microservices, CQRS, event sourcing or whatever happens to be interesting at the time.

It looks like CV-driven development.

I love new technology. Our job as engineers is to solve problems, though, and a clever system is not the same as a solved problem.

Sometimes the best solution is boring.

The same instinct hires a scrum master for a team that’s already working, or adopts a framework nobody asked for. I’ve seen what that did to one team, and I’ve written about why you should understand the problem before you change the process.

A consultancy that finds problems which don’t exist is doing the same thing, with a bill attached.

They don't land and expand

I’ve also seen consultancy done properly.

Consultants who listen before telling, who understand why something exists before trying to replace it, and who share what they know so the existing team gets stronger.

They don’t create dependency.

That is what I like about Equal Experts.

One of their values is to put customer success ahead of their own short-term interests. They also explain what that means in practice.

They say they don’t “land and expand”.

If they’re no longer the right solution, they should leave. When they run out of ways to add value, they aim to leave the customer in a better place than they found them.

That is a different incentive.

Their engineering principles struck a chord with me too: understand the context, choose the right tool for the job and avoid over-engineering.

That is good consultancy.

Come in. Understand. Help. Share what you know. Leave people stronger than you found them.

And know when to leave.

Same idea, different subject

It’s also why I’m pleased to be doing this talk with Equal Experts.

It’s called: Magic vs Science: Making AI Coding Agents Prove Their Work

The talk is about moving past AI coding tricks and witchcraft, and using engineering practices to make generated code prove itself: testing, feedback, maintainability and observability.

Equal Experts’ own engineering principles talk about fast feedback, well-tested code and proactive monitoring.

Different subject, same idea.

Good engineering shouldn’t rely on magic.

It should demonstrate its value.