Reduce Dependency by Increasing Capability
Most consulting relationships are built, whether anyone admits it out loud or not, to be renewed. Being needed again next quarter is obviously valuable to the person being paid for it, and much less obviously valuable to the person doing the paying. That incentive quietly shapes what gets explained, what gets handed over, and what stays inside a system only the consultant knows how to operate.
Halo's fourth core principle takes the opposite position on purpose: reduce dependency by increasing capability. The goal isn't to be indispensable. It's to leave a business more capable than it was found. Not because dependency is unprofitable in the short term, it usually isn't, but because a business that understands itself better is the actual outcome a founder is paying for, whether or not that's what gets sold to them.
The reasoning behind it is stated plainly in how Halo thinks about the work itself: expertise should create clarity, not dependency. A good consultant shouldn't become indispensable, they should leave the business understanding itself better than it did before. The best outcome isn't that a client needs Halo forever. The best outcome is that, after working together, they need Halo less than they did when they first met.
That's easy to state and harder to build, because most of what makes a consultant useful in the moment, the dashboard only they know how to read, the report only they know how to produce, the account only they can navigate confidently, is also what makes a client dependent on them staying. Reducing that dependency on purpose means giving some of that away, deliberately, before it's asked for.
A regional placement and in-home care provider Halo worked with shows what that looks like in practice. Shortly after the client opened a second market, the relationship with the agency had narrowed to "launch campaigns, react to issues," and underperformance in the new market looked, from the outside, like ordinary growing pains. It wasn't. Tracking parameters were passing placeholder values, form-to-CRM data was inconsistent, and scripts were interfering with attribution badly enough that the real question wasn't whether the campaign was working, it was whether the numbers describing it could be trusted at all.
Fixing the tracking was the obvious part of the fix. The less obvious decision was what came after it. Rather than simply handing back cleaner numbers and continuing to be the only party able to interpret them, the account introduced a Traffic Light reporting system, built specifically so the client could read performance without living inside the ads account themselves. That's a small design choice with a large implication. It moved a piece of capability from the agency's side of the relationship to the client's, on purpose. Full story on From Reacting to Leading.
The account's own framing shifted as a result, from "is the channel working" to "this is a systems problem, now being solved," and the relationship moved from campaign execution toward account leadership. That shift is only possible once a client has enough of their own visibility to ask the second question at all. A client who can only ever ask "is it working" is a client who still needs someone else in the room to answer.
Most businesses don't consciously choose ongoing dependency on an external partner. It accumulates by default, because handing over a capability takes more effort in the short term than simply continuing to provide it yourself. Every unexplained dashboard, every "just ask us and we'll pull the number," every report built to be read by the consultant rather than by the client, is a small decision that keeps the client one step further from being able to answer their own question. None of those decisions look wrong in isolation. Added together, they're the difference between a business that's had work done to it and a business that's actually more capable than it was before.
This is also why "we will not create dependency" sits among Halo's non-negotiables, not because it's a difficult idea to agree with in principle, but because the version of the work that creates dependency is often genuinely easier to deliver, and looks identical from the outside to the version that doesn't.
A few honest questions worth asking about your own consulting or agency relationships, from either side of the table:
- If the person managing your account left tomorrow, could you still answer your own basic performance question, or would you be starting from zero?
- Is your reporting built to be read by you, or built to be explained by whoever sends it? Those are two different designs with two different intentions behind them.
- When did an external partner last hand you something that made you need them less, rather than something that made the relationship stickier?
- If a consultant's business model quietly depends on you staying dependent, it's worth asking directly what capability they're actually planning to leave behind.
The best outcome isn't that a client needs Halo forever. It's that, after working together, they need Halo less than they did when they first met.
Reducing dependency isn't a line in a pitch, it's a design decision made repeatedly across an engagement: what gets explained versus handed over, what gets built to be read internally versus externally, what capability moves from one side of the table to the other before the engagement ends. It's the same discipline behind why systems amplify capability, they don't replace it: a business is genuinely more capable once its own people, not just its tools or its consultant, can act on what's in front of them.
What people ask about dependency and capability.
Isn't it in a consultant's interest to keep the client dependent on them?
Often, yes, in the short term, which is exactly why Halo treats reducing dependency as a deliberate principle rather than something that happens by accident. Left unmanaged, the incentive runs the other way: it's genuinely easier to stay the only person who can operate the reporting than to hand that capability over.
How do I know if my business has become dependent on an agency or consultant?
Ask a simple question: if that person or agency left tomorrow, could your own team still answer your basic performance question? If the honest answer is no, or "we'd have to ask them," that's dependency, whether or not the relationship otherwise feels healthy.
Does reducing dependency mean Halo works itself out of a client relationship?
Not necessarily. A business can be significantly more capable and still choose to keep working with Halo, on different, more strategic questions, rather than staying reliant on Halo for the basics. The goal is that the client is capable, not that the relationship has to end.
What does "increasing capability" actually look like in practice?
In one real Halo engagement, it looked like introducing a reporting layer designed so the client could read their own account's performance without needing the agency to interpret it for them, a specific, deliberate handover of a capability the agency had previously held alone.
If your own reporting or agency relationship feels like something only someone else knows how to operate, a Commercial Diagnostic is a 90-minute session built to find out how dependent the business actually is, and what it would take to change that. For a business that already suspects the gap runs deeper than one relationship, a Commercial Audit goes further. More on the thinking behind this is on About, or get in touch directly.