Unlocking Potential Through the Transition from Management Consulting to Asset-Based Consulting (ABC)

“There is surely nothing quite so useless as doing with great efficiency what should not be done at all.”
Peter Drucker

Having been both a client of management technology consultancies and someone who's tried to build one myself, I've watched this industry change quite dramatically over the past eight years. What I've seen has been... well, let's say it's given me some rather strong opinions about where things are heading.

What Management Technology Consulting Actually Is

The textbook definition would tell you it's about providing strategic advice, tech solutions, and operational improvements to help clients perform better. Consultancies supposedly help businesses navigate digital transformation, make better decisions, and grow by combining management expertise with technical know-how.

In theory, they work closely with clients to spot new opportunities, improve existing processes, and implement new technologies. The goal is meant to be sustainable competitive advantage.

That's the brochure version, anyway.

A Different Approach: Asset-Based Consulting (ABC)

Some consultancies – the ones that seem to have retained their integrity – are moving towards what they're calling Asset-Based Consulting, or ABC. I'm not entirely convinced by the terminology, but the concept appears more promising.

Rather than just throwing people at problems, ABC firms focus on building reusable intellectual property. Instead of starting from scratch with every client, they develop tools, frameworks, and methodologies that can be adapted and applied across multiple situations.

The shift in thinking is quite significant. Traditional consulting asks: "How many consultants can we deploy?" ABC asks: "What knowledge assets can we create that solve this type of problem repeatedly?"

This might include developing proprietary software tools, creating diagnostic frameworks, or building methodologies that can be licensed or adapted for different clients. The emphasis shifts from maximising billable hours to creating genuinely valuable intellectual property.

What appeals to me about this model is that it aligns incentives better. If you're building assets that need to work across multiple clients, you're forced to think more rigorously about what actually works rather than what just gets you through the current engagement.

Whether this represents a genuine evolution or just clever rebranding remains to be seen. But it does seem like a more sustainable approach than the current race to the bottom that characterises much of the industry.

The challenge, of course, is that building real intellectual property takes time and investment upfront, which doesn't suit the quarterly profit mentality that drives many consulting firms. But for those willing to play a longer game, it might just be a way back to providing genuine value rather than just warm bodies.

“The overarching aim is to steadfastly deliver client value while growing the organisation's intellectual property. (IP).“

Assets aren’t just kit in a rack. They can be very tangible — a pricing engine, an internal API gateway, deployment scripts, a data catalogue — and just as often intangible: hard-won expertise, trusted client relationships, playbooks, design patterns, or a way of working that consistently gets results.

Asset-Based Consulting (ABC) leans into long-term, knowledge-led outcomes. The aim is to help clients grow around what they truly need (which may not match the loudest want), and to do so in exchange for shared domain insight. Pricing tends to reflect that stance. Rather than pure time-and-materials, ABC mixes models — subscriptions to reusable assets, licensing, outcome-based fees, retainers — so value isn’t tied solely to hours on a timesheet. Time-and-materials still has its place for discovery or spikes, but it stops being the only lever.

A typical ABC practice, in my experience, looks something like this:

• It leans on a firm’s genuine strengths — the things you’d put your name to — and builds partnerships around them.
• Growth is SAS: Sustainable, Amiable, and Sufficient. Profit matters, obviously, but it’s treated as a constraint to respect, not the point of the exercise.
• Hidden resources are surfaced and put to work: a half-finished toolkit becomes a productised accelerator; a set of war-room notes becomes a formal runbook.
• Structure is flatter and more decentralised. That can unlock collaboration, provided stewardship and clear ownership are in place.
• The organisation behaves like a living system with an iterative operating system: explore, experiment, reflect, adjust. People come first; complexity is acknowledged rather than hand-waved away.
• Continuous hypothesis testing — RFCs, spikes, A/Bs — tightens the learning loop and creates step-changes in value for both the firm and its clients.
• Delivery blends uncommon consulting moves (e.g., service blueprints, domain storytelling) with internal knowledge to ship the right thing quickly.
• A healthy scepticism questions received wisdom. Curiosity isn’t decoration; it drives the work.
• First-principles thinking is applied where it counts, so solutions aren’t just variations on last year’s slide deck.

Common advantages of an ABC approach may include:

• Better use of people and knowledge. Juniors can contribute sooner through documented assets — think Terraform modules, linting rules, or a domain glossary — rather than shadowing indefinitely.
• Value and risk shift in your favour by leveraging existing assets and competencies without watering down quality.
• Modern product practices (design thinking, product management, lean) bring agility, customisation, and a clearer line of sight from problem to outcome.
• Multidisciplinary teams create real artefacts: test harnesses, data pipelines, reference architectures. That makes responding to market shifts faster and less theatrical.
• Decentralised, accountable systems lift productivity because teams can improve and capitalise on the assets they steward.
• Solutions are aligned with the client’s current and future goals; you build capability with them, not just deliver to them.
• Integration cycles shrink. Fewer weeks lost to discovery thrash; more time spent plugging in well-defined components.
• An entrepreneurial culture moves plans from slide to shipped. Not always tidy, but undeniably quicker.
• Safe-to-try experiments with new tech or approaches uncover opportunities early and turn promising ideas into working solutions.
• Defects aren’t buried; they’re mined. Post-incident reviews feed back into the asset base so the same fire isn’t fought twice.
• The focus is on value streams, not whack-a-mole problem lists.
• Complexity is handled by slicing it sensibly and naming the system you’re in. Sounds obvious; rarely is.
• People are invested in. Skills compounds are treated as assets too, with time set aside for training, pairing, and proper mentorship.

I’ve seen a small internal library save weeks on every future project; that’s the quiet magic of ABC. It’s less about theatre, more about compounding what already works — and being honest enough to change it when the evidence suggests you should.

The power of assets

I’ll come back to nature in future pieces — murmurations, mycelial networks, that sort of thing — because they hint at how local rules can create surprisingly capable systems. For now, a few practical patterns I keep reaching for when shaping assets in an Asset‑Based Consulting context.

Resilient by design
Assets should earn their keep in production, not just in a demo. That usually means they fail gracefully, recover quickly, and don’t make a bad day worse.

• Fault tolerance that’s boring on purpose: circuit breakers, idempotency keys, retries with jitter, bulkheads, back‑pressure.
• Recovery paths that are automated where sensible: auto‑rollback/canary releases (e.g., Argo Rollouts), health probes and horizontal pod autoscaling in Kubernetes, runbook‑driven auto‑remediation for well‑understood incidents.
• SLOs and fast feedback: burn‑rate alerts in Prometheus, traces via OpenTelemetry, dashboards that show user impact rather than server vanity metrics.

I’m not claiming self‑healing solves everything. It usually buys you time and reduces blast radius; it doesn’t replace root‑cause analysis.

Multipurpose, not kitchen‑sink
Good assets pull their weight across teams and use cases without turning into a bloated platform.

• Decompose into small, composable pieces (libraries, templates, services) with clear contracts and versioning.
• Golden paths and unified interfaces: a standard CI/CD pipeline template, a common auth module, a reference data access layer.
• Cost pragmatism: use open‑source where it fits (PostgreSQL over yet another proprietary licence), retire overlapping tools, and document how to use the thing in 15 minutes, not a week.

Microservices can help with scale and team autonomy, but they’re not a moral victory. If a well‑structured modular monolith serves you better, take the easier path.

Decentralised and distributed by default (with eyes open)
Spreading capability to the edge often improves experience and resilience — and, yes, adds operational trade‑offs.

• Security that travels with the service: mTLS in the mesh (Istio/Linkerd/Envoy), short‑lived tokens, policy as code (OPA/Rego).
• Data where it’s needed: geo‑partitioned stores (e.g., CockroachDB), edge caches (Cloudflare/CloudFront), local‑first sync for intermittently connected clients. Sometimes CQRS/event streams make sense; sometimes a read replica is enough.
• Governance that’s federated but coherent: clear ownership, paved roads, and a small control plane so teams don’t reinvent access patterns and secrets management.

The aim isn’t maximal distribution; it’s the minimum decentralisation that meaningfully improves latency, reliability, or autonomy.

Decoupled yet cooperative
Independent units that play nicely together tend to age better.

• Service mesh features for the boring but vital bits: traffic splitting, authN/Z between services, retries/timeouts configured consistently.
• Observability at the edges: propagate trace IDs, log with context, expose useful health and readiness signals.
• Failure as a first‑class case: graceful degradation (serve cached results, fall back to approximate answers) so a single service going sideways doesn’t take the house down.

First principles as the habit, not the banner
When the default answer is “because that’s what we used last time”, it’s time to pause.

• Strip the problem to essentials: what must be true for this to work, and what can we safely ignore for now?
• Start from constraints and outcomes, then choose patterns and tech. Sometimes that leads you back to familiar tools; sometimes it doesn’t.
• Keep assumptions testable: small spikes, throwaway prototypes, and written decisions with explicit reversal criteria.

None of this is especially glamorous, but it compounds. A resilient core service here, a well‑documented API there, a handful of reusable Terraform modules — before long you have an asset base that shortens delivery, lowers risk, and, crucially, keeps working when the world gets noisy. That, to me, is the real power of assets.

Why it makes commercial sense

Moving to an asset‑based model — building and owning reusable knowledge assets rather than only billing for time — tends to pay off commercially. Not overnight, and not without some discipline, but the upside is hard to ignore.

Recruitment and retention first. The people you most want to keep often get restless if their week is a string of one‑off PowerPoints and slightly tweaked deliverables. Give them space to build assets — a configurable pricing toolkit, a set of reusable data pipelines, a domain “field guide” clients actually use — and they’re more likely to stick around. Product companies will still tempt with higher salaries and share schemes, of course. Even so, ABC is likely to hold on to exceptional engineers and consultants when there’s visible ownership, a roadmap, and time ring‑fenced to work on something that lasts.

Cash flow tends to look healthier too. Assets can be licensed on annual terms, bundled with support, or used to shorten delivery times on projects. That usually smooths revenue and improves margins because the second, third, and tenth client don’t pay for the same ground work. It does require upfront investment and a tolerance for delayed payback, which is worth saying out loud.

On intellectual property, the effect is compounding. Each client engagement teaches you something specific — regulatory wrinkles in insurance, quirks in hospital data, edge cases in payments. Capture that as patterns, test suites, and reference datasets (with proper permissions), and ABC’s library grows. One caution: nail the contracts. What you learn from a project isn’t always yours to package, and getting IP assignments and licensing clear avoids awkward conversations later.

Assets also make selling easier. A live demo beats a slide. A benchmark, a sandbox environment, or a short trial on the client’s data tends to open doors and keep them open. It gives your best people a stage to show their craft, and clients can actually see why they’re specialists rather than just reading it on a CV.

Brand follows delivery. A visible portfolio of assets, case studies with measured outcomes, and a cadence of updates make ABC look like a place serious people want to work with — and work for. That often supports a higher rate card, although market conditions still set the ceiling.

Culturally, an asset focus nudges the organisation towards making things that endure. That sounds grand; in practice it means product management habits inside a consultancy: versioning, documentation, deprecation, usage analytics, and a backlog that isn’t just “nice ideas”. Do that, and ABC is likely to create more value per person and find pockets of the market where it sets the pace rather than chases it.

Epilogue

"The ecstasy of deciphering the unsolved."

It’s a simple line, but it captures what ABC is about. The pull isn’t just “doing projects”; it’s the buzz you get from stripping a problem back to first principles and asking, quietly but persistently, “What’s actually true here?”

That curiosity is more than a mood. For an ABC team, it’s where the satisfaction comes from. You put the usual assumptions to one side, take a beginner’s look, and—every so often—something clicks. A clunky monthly spreadsheet ritual becomes an automated check. A vague “process gap” turns into a small rules engine with tests. A tangled permissions model is redrawn so it’s obvious who can do what. None of this sounds flashy, which may be the point: the solutions that stick often look plain once you’ve found them.

It would be easy to romanticise this as constant breakthrough. It isn’t. First‑principles thinking doesn’t mean reinventing the wheel, and not every experiment pays back. Some ideas look neat in a demo and then wilt under a client’s data, or under procurement. Still, the habit of trying—of running small spikes, keeping score, and being willing to bin work that doesn’t carry its weight—appears to sharpen judgement over time.

That itch to decode the hard bits shapes the culture. People read outside their lane, share half‑finished prototypes, and are oddly cheerful about being wrong on Tuesday if it gets them to right by Friday. It’s a quiet kind of ambition: push the edge a little, learn out loud, and package what works so the next team starts further ahead.

And that’s where the Assets come from. We bottle the useful parts—checklists, reference models, APIs, data fixtures—and maintain them like products. Clients get tools that actually change how their organisation runs; the company gets compounding value because the tenth deployment is faster than the first. It may not sound grand, but it’s usually how new space opens up: less noise, fewer moving parts, and—every now and then—a corner of the market where we’re not just competing on day rates.

References

1. The Creative Consulting Company, by HBR
2. Consulting on the Cusp of Disruption, by HBR
3. Asset-Based Consulting Will Gradually Change The Consulting Revenue Model, By Forrester
4. Asset-Based Consulting. Why Leading Consulting Firms Are Adopting It. By 9 Lenses