Managing Hardware R&D Programs You Are Not Allowed to Talk About

Bu yazı bilinçli olarak İngilizce yazılmıştır. Blogun arayüzü Türkçedir; içerik uluslararası okuyucuya yöneliktir.

Most project management literature carries a silent assumption: that you can describe your work. Case studies name the product. Retrospectives quote real numbers. Portfolio reviews put the customer on a slide. Conference talks show the actual system.

In defence and other classified engineering environments, none of that is available. You cannot name the program, the customer, the delivery date, the quantity, the performance figures, or in many cases the fact that the program exists at all.

This is not a minor inconvenience. It removes the raw material that a surprising number of standard management practices are built on. This article is about what survives that constraint, what has to be rebuilt, and (since it matters to anyone in this position) how you remain visible and hireable without ever crossing the line.

What actually breaks

Benchmarking breaks. You cannot compare your program against a similar one, because you cannot describe either of them precisely enough for the comparison to mean anything. The usual answer to "are our numbers good?" is unavailable.

External learning breaks. In commercial software, when you hit a hard problem, someone has written about it. In classified hardware work, the people who solved your exact problem are frequently not allowed to say so, and neither are you.

Cross-team learning inside the same building breaks. This one surprises people. Need-to-know compartmentalisation means the team two doors down may have solved your problem last year, and neither of you will ever find out. The organisation pays for the same lesson repeatedly.

Recruiting and retention get harder. An engineer who cannot describe their work cannot build a public portfolio. For younger engineers who measure their careers in visible output, this is a real cost, and it is one of the quieter reasons people leave the sector.

Retrospectives get shallow. A genuinely useful retrospective needs specifics. When the specifics are the classified part, teams drift toward safe generalities ("communication could be better"), and the exercise stops producing anything.

What survives unchanged

It is worth being precise about this, because the constraint is narrower than it first appears.

The classified part of a program is almost always what it is: the product, the customer, the performance, the schedule commitment.

The how is very rarely classified. Your estimation method, your risk register structure, your integration strategy, your escalation path, your definition of done, your review cadence, your qualification planning approach: these are engineering management practice, and practice is transferable.

This distinction is the whole game. A program manager who has internalised it can:

• Learn from outside the sector freely, because methods travel even when products do not
• Contribute to the professional community by writing about method
• Explain their competence in an interview without disclosing anything
• Build genuine cross-team learning internally, because process lessons cross compartment boundaries that product lessons cannot

Practices worth rebuilding deliberately

1. Run a methods-only lessons-learned register.

Keep an internal record that deliberately strips product specifics and preserves only the process lesson. Not "the X sensor failed thermal cycling" but "we scheduled thermal qualification after design freeze; we should have run a reduced-scope thermal screen before it."

This register can be circulated far more widely than any program document, and it is where organisational learning actually accumulates in a compartmented environment.

2. Make the estimation basis explicit and internal.

Since you cannot benchmark externally, your own history is the only calibration data you will ever have. Record estimates against actuals, with the reasoning, every time. After a few years this becomes an asset that no outside consultant can replicate, and in an environment without external benchmarks, it is the only defensible basis for a schedule.

3. Define done in terms of evidence, not demonstration.

In open commercial work you can show the thing. Here you often cannot, even internally, to everyone who has a stake. So "done" must be expressible as a document trail: which test, against which requirement, with which result, witnessed by whom. Qualification discipline is not just a quality requirement in this sector; it is the substitute for showing your work.

4. Budget for the compartmentalisation tax.

Access approvals, clearance processing, secure facility scheduling, courier timelines for controlled documents: these consume real weeks. Programs that treat them as administrative noise rather than scheduled work are the ones that slip for reasons that never appear in the risk register.

Put them in the plan as tasks with owners and durations. They behave exactly like long-lead procurement items, and they deserve the same treatment.

Staying visible without disclosing anything

This is the practical career question, and I think the honest answer is more encouraging than people assume.

What hiring managers actually want to know is how you think, not what you built. No one decides to hire a program manager because of a product name on a CV. They decide because the person demonstrated judgement about risk, about sequencing, about when to accept technical debt and when to refuse it.

Judgement is fully expressible without a single classified detail.

So:

• Write about method, not projects. How you structure a risk register, how you handle a qualification plan, how you decide between simulation investment and additional hardware iterations. All of this is publishable and all of it is evidence.
• Publish anything genuinely open. Academic work, open-source tooling, standards commentary, general engineering analysis. If you have a thesis or a research interest, that is unrestricted ground and it demonstrates depth directly.
• Talk about failure modes generically. "Programs of this type typically fail at the transition from laboratory validation to relevant-environment demonstration" says a great deal about your experience and discloses nothing.
• Never blur the line to seem more interesting. The temptation to hint ("a program I can't discuss" said with a certain emphasis) is real and it is a mistake. It signals poor judgement to exactly the people whose opinion matters, and in this sector, judgement about disclosure is part of the job description.

The part that is genuinely a loss

I do not want to end this too neatly, because one thing here does not have a workaround.

In open engineering communities, a hard problem gets solved once and then everyone benefits. In compartmented environments, the same problem gets solved repeatedly, in parallel, by people who will never know about each other. That is a real and permanent inefficiency, and it is the price the sector pays for the protection it needs.

The most useful thing a program manager can do about it is to push, constantly and specifically, for the method layer to circulate even when the product layer cannot. That layer is where most of the repeated cost actually sits, and it is almost always more shareable than the default assumption allows.

---

Views are my own and do not represent any employer.