What makes a good technical consultant

When I list "technical consultancy" as a service, you might often assume it means we turn up, write a report full of jargon, and leave. That's not what I do, and frankly that's not what anyone should pay for. So what should you expect? Good technical consultancy is about giving a business the knowledge it needs to make informed decisions about technology, without having to become technical experts themselves.

The situations where clients come to me for consultancy rather than development fall into a few patterns. They're about to commission a significant web project and want an independent view on the approach before committing. They have an existing site that's underperforming and want to understand why before spending money on fixes. They've been pitched a solution by another agency and want a second opinion. Or they're hiring developers and need help evaluating candidates or structuring a technical team.

What good looks like.

I think the most important quality in a technical consultant is the ability to explain complex things simply without being condescending. If a client asks "should I use headless?" and the answer involves twenty minutes on server-side rendering, API gateways, and content delivery networks without ever connecting it to a business outcome, the consultant has failed. The answer should be: "here's what headless means for your specific situation, here's what it would cost compared to the alternative, here's what it would enable that you can't do now, and here's our recommendation."

Good consultants also say "I don't know" when they don't know. The technology space is vast, and no one person is an expert in everything. When a client asks us about a platform I don't have deep experience with, we say so, and either research it properly or refer them to someone who does. The alternative, bluffing, is how businesses end up with the wrong technology for their needs.

Independence matters

You should know: a consultant who also sells development services has an obvious conflict of interest. I do both, and I'm upfront about that. When I provide consultancy, I'm clear about where our recommendations might lead to us winning development work, and I make sure the client knows they're free to take our recommendations to any developer they choose. The consultancy deliverable stands on its own, it's not a sales pitch disguised as advice.

In practice, and you'll find this yourself, this means I sometimes recommend a client stick with their current platform, or use a technology I don't specialise in, or hire an in-house developer instead of outsourcing. Those recommendations might not lead to revenue for me, but they build trust, and trust is what brings clients back.

What you should get

A good technical consultancy engagement produces: a clear understanding of the current state (what you have, how it works, what's good and bad about it), a recommendation with rationale (what I'd suggest and why, including alternatives we considered and rejected), a realistic plan (timeline, cost range, risks, dependencies), and plain-English documentation that non-technical stakeholders can use to make decisions.

What it shouldn't produce: a 60-page report that nobody reads, jargon intended to make the consultant look clever, or a recommendation that conveniently requires buying more services from the consultant.

If you're facing a technical decision and want an honest, practical perspective, I'd welcome the conversation, get in touch.