Two engines. One craft. Why Consulting and Tech Factory live in the same house.

The gap we kept seeing.

In our years inside larger firms and on the client side, the same pattern came up again and again. A strategy team delivered an elegant target operating model. A systems integrator built something against an interpretation of that model. By the time the two artefacts met in the production environment, the original logic of the transformation had quietly been negotiated away, and nobody in the room could quite say when the negotiation had happened.

The reverse failure was just as common. A capable engineering team shipped a working platform, with clean code and a respectable release cadence, but the business outcome the platform was supposed to enable did not arrive. The team had been left to make a hundred micro-decisions that were really business decisions, on the assumption that someone upstream had ruled on them. Nobody had.

When we sat down to build B One, the founding question was simple. If those two failures are the most expensive ones in enterprise transformation, what kind of firm sits where the failures happen rather than on one side of them. The answer we converged on is a house with two engines, each of them serious on its own terms, and an operating discipline that lets them share files without losing the integrity of either.

How the two engines connect.

The Consulting engine carries the pillars our clients tend to engage us on first: strategy and vision, transformation and organisation, performance and value, AI-augmented enterprise. The Tech Factory engine carries the build pillars: data and AI engineering, agents and automation, modern applications, platform and reliability work. Each has its own leadership, its own rituals, its own delivery rhythm.

When a file lives in only one engine, that is where it stays. A consulting engagement around an organisational redesign runs as a consulting engagement, with the team, the methods and the artefacts that work for that kind of question. A Tech Factory build runs as a build, with the team, the architecture reviews and the operability standards that decide whether the platform survives its first year.

When a file calls for both, the connection is structured rather than improvised. A Consulting partner sits on the operating model and the business choices that shape the target. A Tech Factory partner sits on what the platform must be capable of, how it will be observed, what the cost of running it looks like at steady state. They share a working rhythm, exchange evidence in both directions, and arrive at the steering committee with one view rather than two competing ones. The way we typically organise the work in those cases is to write a single decision log that both sides own, so that the trade-offs land in one place rather than scattering across two separate slide decks.

What stays separate. What bridges.

A common question we get from clients evaluating the model is whether the two engines are really separate, or whether one is a thin wrapper around the other. The honest answer is that the separation runs deeper than it looks from the outside, and the bridges are narrower and more deliberate than people assume.

Separate commercial models.

Consulting is contracted as advisory work, on fixed-scope or retainer terms, with the deliverables and the access patterns that make sense for that kind of engagement. Tech Factory is contracted as delivery work, with acceptance criteria, build phases and a path to operations. The two contracts coexist when both engines are involved; they are not bundled into a single ambiguous instrument. We have found that this clarity protects the client more than it protects us, because it forces each side of the work to be defensible on its own terms.

Separate delivery rituals.

A consulting team that runs steering committees on a two-week cadence and a Tech Factory squad that runs sprint reviews every Friday do not need to share a single ceremony. They need to share evidence. The rituals on each side stay native to the work, and the bridges are the artefacts that move between them: a target-state document the build team can implement against, an architecture decision record the consulting team can read, a clear capture of which choices were made for business reasons and which for technical ones.

A shared operator pool.

What bridges the engines is the people we hire. The expert consultants in Consulting tend to have engineering backgrounds. The expert engineers in Tech Factory tend to have stood in front of an executive committee at some point in their careers. Neither side is a stranger to the other side's work. That overlap, more than any process, is what lets the engines talk to each other when a file needs both.

A shared evaluation discipline.

Across both engines, what we treat as evidence has the same shape. A claim about an operating model should be testable against how the work actually flows. A claim about a platform should be testable against how the operators actually use it. The vocabulary is consistent; the rigour is consistent. A Consulting recommendation that cannot be cashed in Tech Factory work, or a Tech Factory release that cannot be defended to the operating committee, gets surfaced before it becomes a problem.

A shared design language.

The deliverables look like they come from the same firm. The way we frame a decision, the way we draw an architecture, the way we structure a runbook, share a visual and editorial discipline that holds across files. That is not cosmetic. When a client team reads a Tech Factory architecture document and a Consulting target operating model side by side, the cognitive cost of moving between them is one of the things that decides whether the transformation lands.

The operating discipline that keeps both engines coherent.

A house with two engines can drift in two directions. One engine quietly absorbs the other, and the firm becomes a strategy boutique that also writes code, or a software house that also gives advice. We watch for both, and the discipline that keeps the engines in balance has a few simple components.

Every file is staffed by an expert partner on at least one side, and that partner stays on the work end to end. There is no rotation that removes the person who shaped the recommendation from the room where the work is built, and no rotation that removes the engineer who built the platform from the room where the next version is decided. Continuity is the cheapest insurance against the two-engine failures we set out to avoid.

Both engines run on the same anti-pyramid discipline. The work is done by the people whose names are on the file, not by a junior team translating an expert view. That is true on the strategy side and on the build side, and it is one of the reasons our team sizes look modest by larger-firm standards and our partner-to-engagement ratio looks heavy.

Joint files have a single owner, even when two engines are involved. One partner carries the conversation with the executive sponsor, sits on every steering committee, and is accountable for the way the two sides connect. The other engine's partner is not invisible; they are on the file and visible to the client, but the operating model has one face on the client side rather than two competing voices.

The most useful question to ask of a transformation is whether the people who designed it would recognise it in production. In a house with two engines under one roof, the answer can be yes.

One craft, two muscles.

We sometimes describe B One as a consulting firm that builds, and sometimes as a software house that advises. Both descriptions are true and both are insufficient. The cleaner framing is that there is one craft, the craft of moving an enterprise from one state to a better one, and that craft has two muscles. The strategic muscle that decides what should change and how. The engineering muscle that makes the change live and last. A firm that has one without the other will, in our experience, run into the same predictable failure on a long enough timeline.

For clients evaluating the model, the practical implication is that you can engage one engine without committing to the other, and you can engage both without paying the integration cost that would normally come with running two firms in parallel. The published cases in our work pages, ranging from innovation governance platforms in the energy sector to a multi-market CRM rollout, a consumer brand launch built for Southeast Asia and a hospitality SaaS, all sit somewhere on that spectrum. Some are predominantly consulting files. Some are predominantly Tech Factory files. The ones that draw on both look different from either one taken alone.

If you are weighing a transformation where the strategy side and the build side will eventually meet, the conversation we tend to find most useful starts with a simple question. Which decisions, on this file, will fail if they are made on only one side of that line. That question is usually enough to surface where the two engines should sit and where they should stay out of each other's way.