The pitch from a consultancy is compelling. Expertise on demand. Faster delivery. Flexible headcount you can scale back when the project ends. In principle, there’s nothing wrong with any of that.
In practice, I’ve rarely seen it work as advertised. I’ve been on both sides – working at a consultancy and hiring contractors and consulting teams into my own organizations – and the same problems surface repeatedly. That doesn’t make outside help always wrong. But it does mean you need to go in with clear eyes.
If you can’t define the problem, you can’t hire someone to solve it Link to heading
This is the deepest issue, and it tends to go unspoken.
Organizations that know precisely what they need, can articulate it clearly, and have the internal expertise to evaluate whether it’s been delivered well – those organizations rarely struggle with consultancies. They know how to scope the work, they can push back when something’s off, and they can take ownership of what’s been built when the engagement ends.
The organizations that struggle are the ones hiring outside expertise precisely because they don’t have that internal knowledge. And here’s the uncomfortable implication: if you didn’t have the skills to build the thing in the first place, you’re unlikely to be well-positioned to own, maintain, and evolve it once the consultants have left. Software is never really done. Requirements change, systems age, new things are needed. The question of who’s driving that work after the engagement ends matters as much as the initial build.
A good consultant will recognize this and try to guide the client – drawing on their experience to shape what’s actually needed. That works when the consultant genuinely has relevant experience. In my own time working in consultancy, I saw frequently that they often didn’t. Which meant the client was effectively paying for the consultant to learn the domain. That’s not what consultancy is supposed to be.
The business model problem Link to heading
Consultancies make money by selling their people’s time. The longer the engagement, the more people on the account, the better the margin. This isn’t cynicism – it’s just how the model works.
The problem is that it creates a misalignment of incentives. A short, focused engagement that solves your problem cleanly is a good outcome for you. It’s a less good outcome for the consultancy. This doesn’t mean consultancies are bad actors, but it does mean their interests aren’t naturally aligned with yours, and you should structure the engagement accordingly.
The sales process reflects this too. I’ve watched consultancies promise capabilities they didn’t have to win a deal, citing experience that didn’t really exist, occasionally wheeling out a reference customer they had a tight relationship with to speak to the account. The assumption is: get the foot in the door, then figure out delivery. Sometimes they do figure it out. Often they don’t – and by the time that’s apparent, you’re already committed.
What you’re often actually paying for Link to heading
Even when the consultancy is acting in good faith, there are structural issues worth understanding.
The people who sold you the engagement are rarely the people who deliver it. Senior consultants with genuine expertise win the work; junior consultants – sometimes grads – end up on the project, often at a discounted rate that makes the economics look better to you but quietly represents the consultancy’s workforce development program running at your expense.
I want to be clear: I’m not against developing junior engineers. I believe in it. But if you’re paying a consultancy for expertise, the arrangement should be transparent. If they want to put a grad on your project, fine – but they should carry that cost, not pass it to you. What you end up with instead is paying for a resource while simultaneously diverting your own engineers’ time to train them. The consultancy has, in effect, sold you the privilege of training their staff.
The contractor inside the team problem Link to heading
Bringing contractors into an existing development team is a different scenario, but it has its own failure modes.
Every development team carries tribal knowledge – patterns, decisions, deployment approaches, unwritten context that accumulates slowly over months and years. New employees absorb it gradually, with the benefit of time and a clear onboarding path. Contractors arrive quickly and are expected to contribute quickly. That tension rarely resolves cleanly.
What I’ve seen happen: either the team ends up spending significant time bringing the contractor up to speed – slowing delivery in the short term, which often negates the reason for hiring them – or the contractor is pointed at something and left to get on with it, and delivers something that works in isolation but doesn’t fit the patterns or conventions the rest of the codebase follows. Both outcomes have a cost that doesn’t show up in the contract.
How to protect yourself Link to heading
If you’re going ahead with a consultancy engagement, the structure of the arrangement is your main protection.
Write a detailed Statement of Work before anything starts. Not a loose scope document – a specific description of what will be delivered, how you’ll know it’s done, and what happens if it isn’t. Vague requirements are the primary mechanism by which costs expand and expectations diverge.
Push for a fixed-price engagement. Time-and-materials contracts benefit the consultancy. Fixed price forces both sides to get serious about scope upfront and protects you from open-ended cost accumulation. Make sure the SoW is rigorous before agreeing to it, because fixed price without a clear definition of done is just a different kind of risk.
Define milestones with clear acceptance criteria. Don’t wait until the end to find out whether you’re getting what you expected. Payment tied to milestone delivery gives you leverage and gives the consultancy clear targets.
Know who’s actually working on your account. Ask specifically. If they propose individuals, ask about their relevant experience – not the consultancy’s experience, the individual’s. If people rotate off your account, understand why and what approval you have over replacements.
If the engagement needs a project manager, be explicit about it. If the PM is being supplied by the consultancy, the SoW should specify that they’re dedicated to your project. A PM spread across multiple accounts is a PM whose attention is split by definition.
Don’t take references at face value. The references a consultancy offers are the ones they’re confident about. Try to find independent contacts – people who’ve worked with them in roles similar to yours, through your own network.
For contractors joining a team, treat the first few weeks as a structured onboarding period with explicit time budgeted for knowledge transfer. It’s a cost, but it’s a known cost. The alternative – throwing them in and hoping – has a hidden cost that’s usually higher.
When it can actually work Link to heading
I’m skeptical of consultancies and contractors, but I’m not categorically against them.
Contractors are genuinely useful for managing workforce risk. When business conditions change and headcount needs to come down, contractors go first. That’s the deal, and it’s understood by everyone. In volatile conditions, a team that’s partly contractor-staffed gives you flexibility that a fully FTE team doesn’t.
If you’re building something greenfield with an inexperienced internal team, experienced contractors with directly relevant skills can accelerate the early stages meaningfully. The caveat is real: your engineers learn more from figuring things out themselves, and that learning has long-term value. The tradeoff between speed and capability development is worth naming explicitly before you make the call.
For very specific, genuinely bounded expertise – a security audit, a specific architectural review, a technology migration where someone has done exactly this before – a consultancy can be the right answer. The key word is specific. The narrower and better-defined the scope, the better the chance the engagement goes well.
The common thread in the cases where this works: the client knows what they need, can evaluate whether they’re getting it, and can own the outcome when it’s done. That’s worth checking honestly before you sign anything.