ExpertsFMEuropean Defense Sovereignty Starts in the Factory: Stark’s Uwe Horstmann and Johannes Schaback
Training Data · October 28, 2026
5 Selected Lessons:
framework · 2 heuristic · 1 reasoning_pattern · 1 case · 1
Organizing like a venture fund of internal startups
Source
Training Data — European Defense Sovereignty Starts in the Factory: Stark’s Uwe Horstmann and Johannes Schaback (October 28, 2026) · at 13:06 ▸
When this applies
when a company must move fast on multiple distinct product lines while still sharing core technology across them
The takeaway
Separate the organization into autonomous, customer-facing product teams plus a shared platform layer that compounds reusable capabilities across them.
Why it works
Giving each program autonomy to act like its own startup maximizes speed and focus, while a shared platform layer (capability teams) captures reusable technology so autonomy doesn't fragment core capability.
One level up
Speed and reuse can coexist by cleanly separating 'build for a specific customer' work from 'build shared infrastructure' work.
Where it stops holding
This stops working when the shared platform layer becomes a bottleneck that product teams must wait on, reintroducing the coordination costs autonomy was meant to avoid.
Detail
procedure:
- Organize into cross-functional 'programs' that serve specific external customers autonomously (e.g., maritime, aerial, electronic warfare)
- Build a separate 'capability teams' platform layer for reusable technology (navigation, object classification, comms)
- Let engineers choose to work on a platform capability (benefits whole family of systems) or a frontline program (serves one customer)
rationale: Mirrors a venture fund's portfolio model — autonomous bets with shared infrastructure.
In their words
So, the way how we organized the company is by building programs that can act and build very autonomously. And so, as Uvi said earlier, we're organizing the company almost and it almost like a venture fund where we're building small startups in a startup.
Shift-left on manufacturability to avoid 'manufacturing debt'
Source
Training Data — European Defense Sovereignty Starts in the Factory: Stark’s Uwe Horstmann and Johannes Schaback (October 28, 2026) · at 29:39 ▸
When this applies
when a hardware or physical product must move quickly from prototype demo to real production volume
The takeaway
When racing to a demo, simultaneously design for production reality (sourceable components, scalable processes), or you will pay a larger cost later to retrofit manufacturability.
Why it works
Optimizing purely for time-to-market produces a demoable but unmanufacturable product (like a Formula One car), creating a 'debt' that must be repaid later at higher cost; building manufacturability considerations (component choice, supply availability) into the design from the start avoids this debt.
One level up
Speed metrics that ignore downstream constraints create deferred costs that compound — optimize for the full lifecycle, not just the next milestone.
Where it stops holding
This stops working when the product will genuinely never need to scale beyond a handful of units, making manufacturability investment wasted effort.
Detail
procedure:
- Set two explicit goals when starting a program: time-to-market and production readiness
- Choose top-quartile but procurable-in-volume components over 'best available' components
- Factor supply chain resilience into component decisions at the earliest stage, not after a design is locked
benchmarks: {"analogy":"Formula One car built once vs. a washing machine built at scale"}
rationale: Avoids accruing a 'debt' of unmanufacturable design choices that must be fixed later.
In their words
We shift left on manufacturability. That's extremely important because otherwise you accrue a debt that you have to fix later on.
Why structural (not charismatic) change is more durable
Source
Training Data — European Defense Sovereignty Starts in the Factory: Stark’s Uwe Horstmann and Johannes Schaback (October 28, 2026) · at 9:51 ▸
When this applies
when evaluating whether an institutional change driven by crisis will outlast the crisis that caused it
The takeaway
Judge the durability of an institutional change by whether it was adopted because of a compelling story or because of an unavoidable structural reality.
Why it works
Changes driven by a single charismatic leader's narrative tend to fade with that leader, whereas changes adopted out of structural necessity ('we have to') persist because the underlying conditions that forced them remain true.
One level up
Reforms rooted in necessity outlast reforms rooted in persuasion.
Where it stops holding
This stops working when the structural condition itself reverses (e.g., the external threat recedes and institutions revert to old habits regardless of the earlier reasoning).
Detail
approach: Distinguish narrative-driven change from necessity-driven change when forecasting durability.
signals:
- Change adopted without a singular charismatic champion
- Change tied to an undeniable external reality (e.g., war)
- Multiple structural elements changing together (talent, capital, process)
rationale: Necessity-based change doesn't depend on continued persuasion or leadership continuity.
In their words
Changes like that in Europe, they don't happen because there is like a charismatic leader who says, you know, we need to change. This is the way. Follow me. Here's a great narrative. That's not how Europe works. Europe works based on, well, I guess we kind of have to do it now. It's reality kicking in.
Design for the user, not just the buyer
Source
Training Data — European Defense Sovereignty Starts in the Factory: Stark’s Uwe Horstmann and Johannes Schaback (October 28, 2026) · at 2:13 ▸ · at 4:14 ▸
When this applies
when the decision-maker who approves a purchase is not the person who actually uses the product day-to-day
The takeaway
When the purchaser and the user differ, prioritize the user's operational feedback as the primary design input, even above the purchaser's stated requirements.
Why it works
Buyers approve based on specs and budget; users reveal usability failures invisible in a spec sheet (e.g., mental load, materials, ergonomics), so treating the user as the real customer surfaces requirements the buyer never would have asked for.
One level up
True product-market fit requires identifying who actually experiences the product's failure modes, not who signs the check.
Where it stops holding
This stops working when the end-user has no real influence over renewal or future procurement, so their satisfaction never feeds back into the buying decision.
Detail
rule: Treat the hands-on user as the primary customer for product iteration, even when a separate official is the actual budget-approving buyer.
threshold: Willingness to rebuild and return with an improved version within days when users say a prototype is bad ('a bit less shit tomorrow').
rationale: Iterating visibly on user feedback builds trust and and surfaces real-world failure modes a spec sheet can't.
In their words
The customer for us, yes, it's the buyer, but it's also the user. And those are not the same people in the military situation.
The Virtus turnaround — four-week crisis response
Source
Training Data — European Defense Sovereignty Starts in the Factory: Stark’s Uwe Horstmann and Johannes Schaback (October 28, 2026) · at 16:00 ▸
When this applies
when a public failure of a not-yet-ready product threatens company credibility and a high-stakes follow-up test is imminent
The takeaway
In a credibility-threatening crisis, co-locate your best people, create tight iterative feedback loops between field data and engineering fixes, and set an unambiguous bar for 'done' before standing down.
Why it works
Concentrating the best engineers in one physical location, running continuous shifts with real-time data collection and iteration loops (flight test → data → model retrain → repeat), and setting a strict non-negotiable success bar (three consecutive perfect hits) compressed what might have taken months into under four weeks.
One level up
Visible failure under time pressure can be a forcing function that accelerates engineering excellence beyond what calm conditions would produce.
Where it stops holding
This stops working when the underlying technical gap is too large to close with intensified effort alone, or when there's no real-time data pipeline connecting field testing to engineering fixes.
Detail
situation: Stark's Virtus system, with an untested major hardware/software upgrade, failed a high-visibility Bundeswehr experiment amid negative media coverage.
decision: Declared an all-hands crisis, set up a makeshift base near the shooting range, ran three round-the-clock shifts combining flight testing, software retraining, hardware repair, and simulation improvement, with a strict bar of three consecutive perfect hits before standing down.
outcome: Achieved perfect hit accuracy in under four weeks, and the system has hit consistently ever since.
lesson: A forced, resource-unconstrained sprint with tight field-to-engineering feedback loops can resolve what looks like a fundamental capability gap.
In their words
But there was this moment because we wouldn't hit, we said that we will have, we'll only leave this place if we had three consecutive spot-on strikes