Operating consultancy for defence tech

Operating consultancy for defence tech exists to hold a dual mandate: build for a warfighter who needs the thing to work in conditions nobody can fully simulate, and build a company that needs revenue, runway, and a cap table that survives to the next round. Mission and market do not optimise for the same thing, and the operating system has to hold both without either one silently starving the other.

Most operating advice imported from consumer tech or enterprise SaaS assumes one customer, one buying motion, one cadence you tune the whole company around. Defence tech does not get that luxury. Get the shape wrong and the cost is not abstract.

That is the failure the rest of this piece is written to prevent. None of it resolves into one tidy process, and that is the point.

Two customers who never agree on "done"

A programme office measures success in mission assurance: does the capability perform under the worst conditions, is it auditable, does it survive an after-action review. A venture board measures success in ARR, logo count, and time to the next raise. Both are legitimate. Neither will wait for the other.

The instinct is to force one cadence across the company so everyone is on the same calendar. It reads as tidy on a whiteboard and it fails in practice, because the two customers are not solving for the same variable. The fix is structural, not heroic: stand up two cadences, not one. A programme cadence tracks the customer's world of test windows, accreditation gates, and contract milestones. A product cadence tracks the team's world, the weekly build-measure-learn loop that keeps the commercial product improving in the gaps the programme cadence leaves open. The two share a roadmap but not a calendar.

This is why the same company can look glacial on one workstream and fast on another. That is two clocks running on purpose, not a team that has lost the plot.

Both columns share the same roadmap. They do not share a stand-up, a review, or a burndown chart, and trying to merge them is what breaks teams.

Compliance is the lane you drive in

Founders coming from commercial SaaS treat ITAR, CMMC, or a clearance requirement as friction to be minimised. That framing is wrong and it is expensive. Compliance in defence tech is the lane the venture is permitted to drive in. Nobody let you into the market without it. Building outside the lane does not get you to market faster. It gets you disqualified before the contract is even scored.

That changes what good operations means. A commercial ops leader optimises for removing steps. A defence tech ops leader optimises for making the required steps repeatable and boring, so they stop being the bottleneck. Build the audit trail, the classification handling, and the export-control review into the default workflow once, properly, and they become a moat rather than a tax.

A carpenter does not argue with the wood. They read it first. The grain here runs classified, slow, and procedural on the mission side. Fighting that grain wastes motion. Reading it, and building the operating system to run with it, is the actual job. If that framing is new, the grain metaphor for reading your organisation is the longer version.

The procurement clock does not run on venture time

This is the mismatch nobody warns founders about early enough. A Series A term sheet assumes a growth curve measured in quarters. A defence procurement cycle, especially anything routed through a formal acquisition process, is measured in years. Even the fast-track pathways designed to compress it still run on a different clock than an investor update.

Founders who do not plan for this burn cash waiting for a contract that was always going to land eighteen months later than the pitch deck implied. The ones who survive treat the procurement clock as a known constant, not a variable to be wished away, and they stand up a commercial or dual-use revenue line that keeps the lights on while the primary contract grinds through the system.

Reading that timeline correctly is not pessimism. It is the difference between a runway plan that survives contact with reality and one built on hope. The same discipline of forecasting off what is actually there, not what you wish were there, is what separates strategy from operating reality.

There is a second-order trap inside this. The demo worked. The rollout didn't. A capability that dazzles at a test event still has to survive integration, accreditation, and sustainment, and each of those is its own stall point. The same forces that make AI pilots stall at production apply here with the volume turned up, because in defence the consequences of a workflow that quietly degrades are not a paused programme, they are a fielded system nobody is maintaining.

Hire the translator, not just the operator

The single highest-value hire in a defence tech operating team is someone who has actually sat inside the customer organisation. A former programme manager. A former contracting officer. Someone who has been on the other side of the requirements document. Not for the network, though that helps. For the translation.

Translation is most of the work. Engineering teams write in capability language. Programme offices evaluate in requirements language. Investors think in market language. A translator who has lived in the customer's world can take a technical capability and phrase it as a line item against an actual requirement, catch the compliance gap before it becomes a stop-work order, and tell the product team which "nice to have" is really a "will not be scored" in disguise.

Without that person, every proposal, every demo, every review becomes a guessing game about what the customer actually meant. With that person, the guessing stops, because someone in the room has already been the customer. This is a specific case of a general rule: hire for the shape of the work, not the shine of the CV. The longer argument is in hiring for the grain.

Before you make the hire, run the candidate and the role through a filter, because the wrong version of this person is expensive and slow to unwind.

What operating consultancy for defence tech actually builds

None of this collapses into a single tidy process, and pretending otherwise is the mistake. Operating consultancy for defence tech is not selling founders a way to make the dual mandate disappear. It is building the scaffolding that lets both mandates run at once: two cadences that share a roadmap, a compliance function treated as infrastructure rather than overhead, a realistic model of procurement time sitting next to the commercial growth model, and at least one person in the building who has genuinely been on the customer's side of the table.

Built well, the results are not soft. On one defence tech engagement, the operating system we stood up moved real numbers.

Those numbers came from the same discipline every sector version of this work rests on: read the organisation at workflow level, redesign the workflows, ship the systems that hold the new shape, and train the people who own it after we leave. The sector changes the constraints, not the method. The tooling is deliberately unglamorous, self-hostable workflow automation on n8n at roughly £20 per builder seat per month, SOC 2 and ISO 27001 in the stack, so the classification and audit story holds up under scrutiny rather than being a slide.

Get that scaffolding right and the dual mandate stops being a contradiction you manage around. It becomes the actual shape of the business. The fastest way to find out whether your operating system can hold both is to put one real process through it end to end, which is exactly what the Grain Audit is for. This piece sits inside a wider set of sector operating lenses; the constraints differ by sector, the operating discipline does not.