Prefer to watch? Watch the video on YouTube.

Why do large engineering organisations struggle so much to deliver software? It isn’t the engineers. It isn’t the technology. It’s the structure.

Picture the scene. You’re an engineering lead. You’ve got a clear roadmap, a motivated team, and a feature your customers are screaming for. You could probably build it in six weeks. But you can’t start — because you need a new data pipeline from the data team, and you’re 14th on their backlog. You need a Kubernetes namespace from the platform team, and they’re mid-migration. And security need to review your architecture before you write a single line of code — their next review slot is five weeks away.

Welcome to enterprise software delivery, where the org chart is the bottleneck and nobody can figure out why everything takes so long.

The one idea that underpins everything

Before the three problems, one idea. Conway’s Law, first stated by Melvin Conway in 1967:

Any organisation that designs a system will produce a design whose structure is a copy of the organisation’s communication structure.

In plain English: the software you build mirrors your org chart. Siloed organisation → siloed systems. Teams that can’t communicate easily → services that don’t integrate easily.

This isn’t just theory. If you’ve worked in a large organisation, you’ve seen it. You can literally look at the architecture diagram and point at the org chart that produced it. Which is why organisational design isn’t just an HR topic — it’s an engineering topic. How you structure your teams directly determines how effectively you can deliver software.

With that in mind, three big problems.

Problem 1 — capabilities vs value streams

Most enterprises organise around capabilities: vertical teams aligned to technical functions. A data team. An infrastructure team. A governance team. A security team. A QA team. Each serves the entire organisation as a shared service.

On paper it makes sense. It avoids duplication. It creates centres of expertise. It looks clean on an org chart, and a CFO loves it because it’s efficient on headcount.

In practice, it’s a delivery disaster.

You’re building a new product feature. You need work from the data team — a new event pipeline. You need infrastructure provisioned. You need a security review. Each of those teams has their own backlog, priorities, leadership, and capacity constraints. You don’t control any of it. You raise a ticket, make your case, and wait. And you’re not the only team waiting — every product team is competing for time from the same shared capability teams.

Your six-week feature takes six months. Not because the work is hard, but because you spent most of it blocked.

Compare that to how startups work. A startup has a small cross-functional team aligned to a value stream — they own a slice of the product end-to-end. Their own front-end engineer, their own back-end engineer, someone who can handle the data work, someone who can manage infrastructure. Self-sufficient. Set their own priorities. Ship.

The painful irony: large organisations adopt the capability model specifically to be more efficient, and it makes them dramatically slower. You’ve centralised expertise, but you’ve also centralised bottlenecks.

And there’s a cultural side-effect nobody talks about. When you depend on other teams and can’t influence their priorities, people game the system. They inflate the urgency of requests. They escalate to leadership. They try to build things themselves to avoid the dependency — creating a whole new set of problems.

Which brings us to problem two.

Problem 2 — adversarial organisations

Capability verticals produce fuzzy boundaries. Fuzzy boundaries breed conflict.

An example. Your company has a platform engineering team providing self-service access to cloud infrastructure — compute, storage, networking. They’ve been doing it for years. They’ve built tooling and abstractions. They have a roadmap. Then the company decides AI is a strategic priority and spins up a new AI platform team, whose job is to democratise access to LLMs, GPU compute, ML pipelines.

Makes sense from a strategy perspective. But now you have two teams whose scope overlaps. The AI team needs infrastructure — do they use the existing platform team’s tooling, or build their own? Who owns the GPU clusters? Who decides which LLM provider to standardise on? Who controls the spend?

What starts as a reasonable organisational decision turns into a turf war. Both teams feel ownership. Neither wants to be dependent on the other. Leadership hasn’t clearly delineated where one team’s responsibility ends and the other’s begins — partly because with emerging technology, nobody’s sure yet.

This pattern plays out everywhere. The mobile team and the front-end team arguing over who owns the design system. The data engineering team and the analytics team both building transformation pipelines. The DevOps team and the SRE team with near-identical mandates and completely different tooling.

The result is duplicated effort, political tension, and engineers spending their energy navigating internal politics rather than building software. In the worst cases, teams actively block each other — refusing to support integrations, withholding access, competing for the same headcount budget.

None of this happens because the people are bad. It happens because the structure creates misaligned incentives. When teams are measured on their own output rather than overall delivery, they optimise for their own domain. They protect their scope because their funding and headcount depend on it.

Startups don’t have this problem. Not because startup people are better, but because there’s one team, one mission, and no ambiguity about who owns what.

Problem 3 — the outsourcing trap

This one might be the most frustrating, because the logic behind it sounds so reasonable and falls apart so completely in practice.

Large organisations love outsourcing. From a pure balance-sheet perspective it makes sense — fewer full-time employees, lower fixed costs, workforce flexibility, scale up when there’s work, scale down when there isn’t. If you’re an accountant, it’s beautiful. If you’re actually trying to deliver software, it’s a nightmare.

The company maintains a thin veneer of full-time employees to hold institutional knowledge and manage vendors. When a new initiative kicks off, they engage a consultancy or staffing firm to bring in contract engineers. The project finishes, contractors leave, you scale back down. Elastic workforce, neat on a spreadsheet.

Now the reality.

First, procurement. Before a single contractor writes a line of code, you’re dealing with legal reviews, contract negotiations, vendor onboarding, background checks. In a large enterprise, that process alone can take weeks — sometimes months.

Then hardware. Provision and ship a laptop. If you’re lucky there’s stock. If not, there’s a lead time. I’ve seen people wait three or four weeks for a machine.

Then access. Internal systems, VPNs, code repositories, cloud environments, CI/CD pipelines. Each one requires an access request, often with separate approval chains. Some require additional security clearance. Another week or two.

We’re now potentially two months in, and your contractor hasn’t written a line of code.

Now the real clock starts. They need to learn your domain, your architecture, your codebase, your conventions, your internal tooling, your deployment process, the weird quirks of your legacy systems that aren’t documented anywhere. Depending on complexity, ramp-up is anywhere from a few weeks to several months.

And then, just when they’re finally productive — genuinely contributing, understanding the context — their contract ends. They leave, and everything they learned walks out with them. The next contractor starts from zero. You’re paying for the same ramp-up cost over and over again. You never build compounding knowledge.

It’s like filling a bathtub with the plug out.

The companies that do this aren’t stupid. They’re optimising for the wrong metric — minimising headcount cost when they should be optimising for delivery throughput and knowledge retention. Both of those require stability. People who stick around long enough to build deep context, who feel ownership over the product, who care about the long-term quality of the codebase because they know they’ll be maintaining it next year.

How to fix it — think like a startup at scale

Three patterns that individually slow you down and together grind delivery to a halt. What do you do about it?

You can’t restructure a thousand-person engineering org overnight. And you can’t pretend you’re a startup when you have regulatory requirements, legacy systems, and a board to report to. But you can apply startup principles deliberately and strategically.

1. Align teams to value streams, not technical capabilities. The single highest-leverage change a large organisation can make. Instead of a data team, an infrastructure team, and a front-end team that all serve everybody — create cross-functional teams that own a product or customer outcome end-to-end. Each team should be able to take a feature from idea to production without raising a ticket with another team. This is essentially the model in Team Topologies by Matthew Skelton and Manuel Pais — streamlined teams supported by enabling teams and a thin platform layer. If you haven’t read it, it should be required reading for anyone designing an engineering organisation.

You’ll hear pushback — “but we’ll duplicate effort.” Yes. You might have two teams that each have someone who knows Terraform. The cost of that duplication is dramatically lower than the cost of the coordination overhead, blocked backlogs, and six-month feature delivery cycles you’re living with now. Optimise for flow, not for resource efficiency.

2. Draw clear boundaries and make them explicit. Every team should have a clearly documented scope: what they own, what they don’t, and where the interfaces are. Obvious in principle, and most large organisations still don’t do it. They assume people will figure it out. They won’t — they’ll fight about it instead. When two teams have overlapping scope, leadership needs to make a call and communicate it clearly. That’s not micromanagement; it’s the bare minimum of organisational clarity.

3. Invest in your platform as a product, not a mandate. If you need shared capabilities at scale — and you probably do, for things like CI/CD, observability, cloud infrastructure — treat your platform as an internal product. The platform team’s customers are the engineering teams. That means self-service, well-documented, genuinely useful. If teams are trying to route around your platform, that’s feedback, not insubordination. The best internal platforms I’ve seen operate with the same discipline as an external SaaS product. Roadmaps, adoption metrics, developer satisfaction — and friction treated as a bug.

4. Stop treating people as interchangeable resources. Build stable, long-lived teams. Invest in their domain knowledge. Accept that onboarding takes time and continuity is value. If you must use contractors, embed them in existing teams for meaningful durations — not 12-week rotations — and pair them with permanent staff who maintain continuity. The goal is compounding knowledge. Every month a stable team works together, they get faster, understand the codebase better, anticipate problems, build shortcuts. Every time you churn the team, you reset that clock.

5. Measure what matters. If you measure teams on utilisation and output — tickets closed, story points delivered — you’ll get teams that optimise for looking busy. If you measure teams on outcomes — time to deliver a customer-facing feature, deployment frequency, lead time for changes — you’ll get teams that optimise for actually shipping. The metrics you choose encode your values. Choose ones that reward flow, not activity.

Watch the full video

The 13-minute version is on YouTube — Why are large organisations bad at delivering software?. If you’ve lived through any of these patterns and found ways to work around them, drop it in the comments.

More posts and videos like this at Insightful Pause on YouTube — same premise, look before leaping.