There is a difference between consulting for the person who buys the engagement and consulting for the person who has to run the program after it ends. Most consulting firms optimize for the buyer; we optimize for the operator. The buyer is usually an executive sponsor: a C-suite leader or SVP who approved the budget and expects deliverables. The operator is usually one or two levels down: a VP who owns the P&L, the program, or the capability the engagement is supposed to build. The operator will sit in the chair on day one after we leave and try to make everything work. These two audiences have different needs. The buyer needs confidence the investment is justified; the operator needs structure they can use. The engagement process is what the client is buying, and the operator is the one who lives with it.
The Operator Can Run It Independently
Consulting for the operator changes how the work gets designed and what the engagement produces. Design decisions start with a question: will the operator be able to run this independently after the engagement ends? A roadmap that requires our proprietary tool to update fails that test, and so does a governance model that depends on our facilitation to function. Designing for the operator means every artifact and process has to work in our absence. That constraint eliminates frameworks that require specialized training and deliverables optimized for the final readout rather than ongoing use. Methodologies fail after handoff when they’re not built with the operator in mind. What it produces is practical infrastructure: templates the team can fill in themselves and facilitation guides they can follow without external support.
Working Executive and Operational Problems
The operator’s problems span multiple levels. Some are executive-level: budget approval is stalled, the steering committee has conflicting priorities, two SVPs have an unresolved scope dispute. Others are operational: a workstream lead cannot get testing resources committed, a dependency was never formalized, a critical milestone has three different dates in three different documents. Consulting for the operator means working across both levels. At the executive level, the consulting team removes blockers the operator cannot resolve from their position. At the operational level, the team surfaces constraints that are invisible from above. A VP running a cross-functional program needs both: someone who can clarify a decision in the steering committee and someone who can identify a sequencing conflict in a workstream planning session. The problems that derail programs are rarely confined to one level. A resource conflict that looks like a scheduling issue is often the downstream effect of an executive decision that was never made explicit.
The Client’s Team Builds the Deliverables
The traditional consulting model produces deliverables that the firm builds and the client receives: the firm’s analysis and the firm’s recommendations. The client reviews and approves. The intellectual foundation belongs to the consulting team. When we leave, the operator executes a plan they did not build. They understand it at the summary level from the readout; they do not understand it at the structural level because they were not in the room when dependencies were mapped, constraints surfaced, and sequencing decisions made. Co-creation makes the client’s team the primary builders. We design sessions and provide structure. The client’s team defines scope, maps dependencies, identifies risks, and sequences milestones. The output is the same: a roadmap and a governance model: but the knowledge of how those artifacts were built and why specific decisions were made lives in the client’s team. This is slower than having the consulting team build everything in a back room and present a polished deliverable, but the real measure is whether the operator can maintain and extend the work after the engagement ends. What stays after you leave is the measure of whether the answer held.
