A good technical consultancy delivers in weeks what a hire needs months to cover. A badly hired one burns the same budget and returns the problem untouched. The five patterns below show up before the consultant's first day, and none of them gets fixed by paying more.
Mistake 1: hiring a consultant to dodge a decision
"Let's bring in a consultant to recommend what to do." The sentence shows up when the team is split, the CTO holds no position, or a stakeholder is pushing. The consultant writes the recommendation, and the split team stays split at execution time.
Consulting pays off when the CTO already has a technical position and wants to test it against an outside view, when execution capacity is missing, or when someone has to structure the implementation process. Marty Cagan separates these roles in Empowered (Wiley, 2020): direction and limits come from leadership, and execution stays with the internal team.
Mistake 2: open scope
"We want to improve the architecture" is an aspiration. Consulting scope is a sentence with a number and a date: refactor the API layer to carry 10x current volume, define the monolith migration strategy, raise the team's technical level in three months.
An open scope leaves the consultant without a definition of done and leaves you without a criterion to bill against. The project runs without an end, and both sides walk away frustrated.
Mistake 3: using the consultant as a development resource
A senior technical consultant spending days on JIRA tickets applies expensive capacity to the wrong place. Will Larson explains in Staff Engineer (O'Reilly, 2021) that the value of this profile sits in the decisions he makes, the patterns he sets and the people he develops.
If the math is development hours, hire a senior engineer through an agency or a contractor. If the math is high-level technical judgment, the profile changes and the contract changes with it.
Mistake 4: leaving the knowledge with the consultant
Consulting without knowledge transfer builds dependency. The consultant leaves knowing more about the system than the internal team, and the company keeps parts only he understands.
Structure the engagement so the team learns along the way: code review with explanation, open architecture sessions, documentation as a deliverable. Tom Demarco and Timothy Lister show in Peopleware (Dorset House, 1999) how much capacity walks out when someone who holds the system's knowledge leaves.
Mistake 5: paying by the hour
One hour with the right architect can be worth more than two sprints of development. A contract measured on the clock shifts the consultant's incentive toward time invested.
A good contract defines deliverables, measurable success criteria and payment by scope. W. Edwards Deming listed management by the numbers among the obstacles to remove in Out of the Crisis (1986); billing consulting by hours worked repeats the mistake.
What to settle before signing
Four things on paper: the specific problem, the deadline, the success criterion, and an internal contact with authority to decide. With those four, the consultant works with focus and you bill against outcomes. Without them, the contract becomes a bet.
Write down, before the proposal meeting, what has to differ in the system, the team and the operation when the project ends. Three lines change the conversation with any consultancy.
