Startups and Corporates Through My Lens

Startups want enterprise scale. Enterprises want startup speed. Both are understandable, and both become incomplete when copied without context. The startup looks at the enterprise and sees distribution, capital, customers, process, staying power. The enterprise looks at the startup and sees speed, courage, simplicity, ownership, energy. So both try to copy each other.

Startups hire enterprise leaders. Enterprises launch innovation labs. Startups build governance. Enterprises preach agility. Startups introduce layers. Enterprises remove layers — then quietly add them back again.

The gap is not cosmetic. It is structural. After experiencing both sides of that line, the variable I keep returning to is the same one almost every “agility versus stability” conversation talks around: the cost of being wrong.

• In the startup, being wrong is often permissive in the moment. Small bets fail in ways the organisation can absorb, until the misses accumulate and quietly consume runway.
• In the corporate, being wrong is more often concentrated and consequential. Once a material failure surfaces, it tends to compound slowly, publicly, and at scale.

The Cost of Being Wrong

The clearest way to see the asymmetry is in money, but not only in the per-incident way most people compare it.

The corporate side accrues cost from breaches, fines, and outage hours. IBM’s 2024 Cost of a Data Breach Report puts the global average breach at USD 4.88 million, with financial services consistently second only to healthcare on per-incident cost. ITIC’s 2024 Hourly Cost of Downtime survey adds the operating view: a single hour of unplanned outage exceeds USD 300,000 for over 90% of mid-size and large enterprises, and 41% put the cost between USD 1 million and over USD 5 million [1] [2].

The startup side accrues cost differently — almost entirely as runway burn. In CB Insights’ analysis of VC-backed startup shutdowns since 2023, “ran out of capital” tops the list at 70%, while “poor product-market fit” shows up in 43% of identified failure patterns [3].

So both sides can be hurt financially, but the blast radius is different. In a corporate system, the scale of impact is larger and recovery is harder. In a startup, the damage is usually smaller per mistake, but each miss eats runway until there is no time left to correct it. Neither pattern is irrational; each follows the economics of the environment.

The pattern is visible when a corporate tries to move like a startup at scale. McKinsey’s digital-transformation survey found that organisations with fewer than 100 employees were 2.7× more likely to report success than organisations with more than 50,000.

That gap is not because large organisations are incompetent. It is because every decision at that scale carries more dependencies — more customers, more systems, more stakeholders, more legacy, more handovers, more invisible risks. Each dependency multiplies the cost of being wrong. The cost of being wrong is not symmetric, so the cost of caution cannot be symmetric either.

The System Tax

This asymmetry shows up in the engineering metrics people often compare too quickly.

Google Cloud’s DORA research has, for years, shown deployment frequency and lead time spread across orders of magnitude: elite teams shipping multiple times per day, low-performing teams less than monthly [6]. That is the strongest evidence for why decision velocity matters: shorter loops create more chances to learn before the market, the product, or the runway moves on. The common reading is a maturity scale: elite is good, low is bad.

An enterprise running tiered change approval, separation-of-duties at release, regulatory pre-notification for material changes, and rollback rehearsal for critical releases is not always a low-performing team that needs to “level up.” It may be a team operating with deliberate friction because the cost of an unwound change is not symmetric with the cost of the change itself.

That friction can be compressed. Daily deployments are achievable in regulated contexts, and many teams have built them. But the work to get there is not the same work as moving fast in a small, low-dependency product. It is a different problem:

1. How do you compress a control surface without dissolving it?
2. How do you automate tiered controls without making them ceremonial?
3. How do you cut a release window from days to hours without losing the audit trail a regulator will eventually ask for?

A startup can run on high trust, low documentation, and fast decisions because the system is still small enough for people to carry context in their heads. As it grows, that context has to move from people into systems: architecture, process, documentation, controls, metrics, operating rhythm, decision rights. Without that migration, speed becomes chaos. This is the system tax.

Startups often underestimate it. Enterprises often overpay it. Either way, it does not disappear when you modernize. It gets paid more efficiently.

The Regulatory Substrate

From the outside, corporate regulation can look like a vague headwind: something slow, bureaucratic, and mostly legal. Inside a regulated enterprise, it is much more concrete. It is a set of obligations with named owners, deadlines, evidence trails, and consequences when those promises fail.

My examples naturally lean toward banking because that is where much of my experience sits, but the pattern is broader: manufacturing, aviation, healthcare, energy, public infrastructure, and financial services all operate with different forms of enforceable constraint.

1. Operational resilience. The organisation must know which operations are critical, how much disruption they can tolerate, and how recovery will be proven when failure happens. In banking, BCBS Principles for Operational Resilience (2021) is one reference point [7].
2. ICT risk management and incident reporting. Major ICT incidents must be reported to regulators inside hard time windows and standardised formats. The EU’s Digital Operational Resilience Act is one prominent expression of that pattern in financial services [8].
3. Third-party and concentration controls. Every critical service must be mapped down to its underlying dependencies — including cloud and other third parties — and tested against severe-but-plausible scenarios.
4. Audit-grade change management. Every release must produce an evidence chain that an internal or external auditor can reproduce a year later.

These are not abstract guidelines.

A startup ships features. A regulated or safety-critical enterprise ships features inside an enforceable promise about how those features fail. That is not a vague constraint; it is a contract with named counterparties and named consequences.

The Organization Layer

Why does the corporate decision so often look slow?

Not because anyone is incompetent. Because the decision has to aggregate signals from risk, legal, compliance, audit, technology, business — and sometimes sustainability — while the cost of skipping those signals may be paid years later, often by people who were not in the original meeting.

But there is a second pattern, specific to scale: structure can become a substitute for judgment. A meeting becomes alignment. A committee becomes ownership. A process becomes progress. A dashboard becomes understanding. None of those are inherently wrong — each was useful when it was first introduced — but in aggregate they create something corrosive: too many places where decisions can be delayed without anyone being clearly wrong.

That is why many enterprises do not move slowly because people lack ambition. They move slowly because the organisation has accumulated more places to defer than to decide.

McKinsey’s survey of more than 1,200 managers shows how expensive decision work becomes once an organisation is large enough: slow decisions do not just cost time; they consume management capacity, coordination energy, and opportunity.

At scale, the decision itself becomes a system. It has participants, dependencies, incentives, evidence, ownership, and execution risk. If that system is badly designed, speed disappears into coordination. If it is over-corrected, integrity becomes ceremony.

So the split between the two sides comes down to which optimization the organisation has internalised. Fast feedback loops matter, and scale turns internal coordination into real operating work.

• Startups tend to optimize for decision velocity because the cost of waiting can be fatal: a quarter of missed market is a quarter of evaporating runway.
• Large corporates tend to optimize for decision integrity because the cost of a bad decision compounds across customers, partners, auditors, regulators, and the operating promises the company has already made.

The risk on each side is similar: confusing the optimization for the goal. A startup that mistakes velocity for quality eventually runs out of room to correct. A corporate that mistakes integrity for caution can become unable to react to a market shift it saw two years before its competitors.

The People Asymmetry

In startups, a small number of people carry massive ambiguity. In enterprises, many people carry small pieces of a much larger machine. Both are hard.

Startup mode can burn people through intensity. Enterprise mode can drain people through friction. One suffers from chaos. The other suffers from coordination cost.

When I was operating closer to the startup side, I did not have to think deeply enough about things like:

• design for an operational tolerance someone else committed to in writing,
• justify a release through an evidence chain auditable a year later,
• partition a system so a third-party dependency can fail without taking the organisation with it,
• or carry an on-call rotation where the SLA is regulatory rather than commercial.

Conversely, when I spend too long inside the enterprise register, it is easy to forget what startup mode forces people to practice:

• ship a half-formed feature, watch it interact with reality, and rewrite it the same week,
• treat the absence of structure as a tool rather than a deficiency,
• cut a feature surface area with no consensus and no precedent,
• or operate in a market where a missed quarter is existential.

Across a decade, many people will only see one or two operating environments deeply. The interesting hires are the ones who have done both. The rarer hires are the ones who can articulate which register they are in at any given moment, and switch deliberately.

What Both Sides Romanticize

Both sides romanticize what they have never had to operate.

Startups romanticize enterprise scale but underestimate the discipline required to survive it: governance complexity, operational resilience, scalability under sustained load, compliance obligations, recovery planning, the long tail of maintainability. They are not wrong to defer most of this in year one — they would die otherwise — but they sometimes mistake deferring a problem for solving it.

Enterprises romanticize startup speed but underestimate the clarity, ownership, and risk appetite required to move that way. They are not wrong to insist on controls — they would face a regulator otherwise — but they sometimes mistake control for caution, and ship caution when control was sufficient.

A startup cannot simply add process and become mature. An enterprise cannot simply add agile and become fast. Both are trying to import visible behaviours without importing the underlying operating model — which is why the imitation almost always reads as theatre.

The best operators eventually realise speed and control are not opposites. They are two sides of the same engineering problem, and the harder side is whichever one you have not built before.

The Converged Ideal

Through my lens, the ideal state is not one where startups become corporates, or corporates become startups. It is a convergence of operating strengths: startups learning discipline before scale punishes them, and enterprises learning speed without dissolving the controls that keep them trustworthy.

The interesting work — the work that may distinguish the next decade of engineering leadership from the last — is building production systems where:

1. experimentation is genuinely possible,
2. guardrails are explicit rather than tribal,
3. accountability is distributed but traceable,
4. and learning cycles stay fast without sacrificing resilience.

That balance is harder than any strategy deck makes it look, and it gets much harder when the system is already in production, serving millions of customers, under regulatory oversight, and still expected to innovate continuously.

That is the convergence I hope to see: not cultural imitation, but operating-model maturity. The best startups will learn operational discipline before scale forces it painfully. The best enterprises will learn to reduce unnecessary coordination cost without destroying the controls underneath.

Moving fast is different when very little breaks outside the company. Moving responsibly at scale is different when every change carries customers, regulators, partners, and public trust with it.