Startup Mindset

In 2009, I started a company. Four and a half years later, I sold it. In between, my team and I built cloud hosting infrastructure for enterprise clients, raised seed and Series A funding, hired people, grew the business, and navigated an acquisition. Revenue per full-time employee (FTE) exceeded $2 million per year. I was, simultaneously, the chief executive and the chief technologist.

A few years after that, I was accountable for the architecture, delivery, and maintenance of a platform serving 250,000 people, leading 250 architects and engineers across 50-plus subsystems for the Ministry of Defence (MOD) as part of the ATLAS Consortium.

Both experiences taught me a great deal. But the most useful thing founding a startup taught me was something I did not fully appreciate until I was sitting on the other side of the table: what accountability actually feels like when it is real.

Process Is Not a Product

In a startup, there is no governance layer between a decision and its consequence. If you ship something broken, your clients leave. If you burn through your runway, your people do not get paid. If you miss a commitment to an investor, you do not get the next call. There is no board to escalate to, no programme director to absorb the blast, no commercial framework to hide behind. You deliver, or you cease to exist.

Most large defence programmes are structured in exactly the opposite way. Process is the product. The artefact of delivery is the document, the gate review, and the compliance sign-off. The people who produce these things are often talented, hard-working, and genuinely motivated. But the system around them rewards activity rather than outcome, and that changes behaviour in ways that compound over time.

This is not a criticism of individuals. It is an observation about what incentive structures do.

What the Startup Teaches You That the Programme Cannot

The most important thing a startup teaches you is the difference between accountability as a word and accountability as a lived experience.

Every mature organisation has accountability frameworks. Responsible, Accountable, Consulted, Informed (RACI) matrices, governance boards, and named owners on risk registers. These are useful tools. But they are not the same as actually being accountable, in the sense of knowing, viscerally, that if this goes wrong, it is your problem and no one else is coming to fix it.

That feeling changes how you make decisions. You move faster because delay is costly, and you can feel the cost. You ask different questions because you are asking them for yourself rather than for a review audience. You surface problems earlier, because hiding them only makes them worse, and there is no one to absorb them on your behalf.

The startup also teaches you something about decision speed that is hard to replicate at scale. A decision that needed to be made got made that day. Not because we were reckless, but because the cost of delay was visible and immediate. In large programme environments, decisions that need making often sit in queues, waiting for the right meeting, the right attendee list, the right format. By the time they are resolved, the context has changed, and the decision needs to be remade.

The Wrong Lesson and the Right One

The obvious takeaway here is that defence should run more like a startup. That is the wrong lesson, and it is not a useful one.

Defence programmes operate at scale, in a security- and regulatory-constrained environment, and with a set of stakeholder obligations that make a direct comparison misleading. A startup that fails loses money and disappoints investors. A defence programme that fails can have consequences of a different order entirely. The structures that look like overhead in a commercial context are often there for legitimate reasons.

The right lesson is narrower and more useful: the best delivery teams inside large programmes find a way to preserve the things that make startups effective, even within a complex, multi-supplier, heavily governed environment. Real ownership. Short decision chains. Genuine consequence for outcome. They do not achieve this through culture workshops or agile transformations. They do it through structural design.

What Accountability Architecture Looks Like in Practice

There is a simple test worth applying to any programme or workstream. Can you name, without hesitation, the single person accountable for this outcome? Not the workstream lead, not the programme director, not the ‘accountable’ column on the RACI. The actual person who, if this does not deliver, has a problem.

If you cannot name that person, you have an accountability gap.

The second question is harder. Does that person have the authority that matches their accountability? Can they make the decisions they need to make, at the pace they need to make them, without routing everything upward? Accountability without authority is just liability with a job title.

The third question is about consequence. Is there anything meaningful attached to the outcome? Not a performance review in six months, but something that creates a felt incentive to move, decide, and own the result today.

These are not questions about culture. They are questions about how the programme is designed.

The Stakes Always Need to Feel Real

The company I founded ran on a simple principle. If it does not work, we do not eat. That is not the right principle for a defence programme, and I would not suggest it is. But the best programmes I have seen find their own version of it: a genuine, shared sense that the outcome matters, that the people responsible feel that weight, and that the structures around them are designed to support accountability rather than distribute it into nothing.

That is not a startup. It is a well-designed programme. The difference is smaller than most people think.