Architecture Thinking

Most engineering organisations don't fail because of a lack of talent, effort, or good intentions. They fail because they are designed to optimise for the wrong thing.

In many companies, success is implicitly measured by roadmap delivery. Features shipped, milestones reached, commitments honoured. Over time, the roadmap stops being a planning tool and becomes a control mechanism. Delivery becomes the goal. Value becomes an assumption.

That's how feature factories are created — not by bad teams, but by design.

When organisations optimise for output, teams naturally optimise for throughput. Product managers become backlog managers. Engineers focus on getting things "done". The question slowly shifts from "did this actually solve the problem?" to "did we ship it?".

The outcome is predictable: products that grow in surface area but become harder to evolve, harder to change, and harder to innovate.

Sustainability is a design constraint

Engineering organisations shouldn't be judged only by what they deliver, but by how sustainably they can keep delivering.

If each new roadmap takes longer to ship than the previous one, if meaningful change becomes increasingly expensive, or if innovation requires constant heroic effort, the problem isn't productivity. It's structural.

These organisations are accumulating organisational and architectural debt. They may still be delivering roadmaps, but at an ever-slower pace and on increasingly rigid systems. That's not an execution issue — it's a design failure.

The missing feedback loop (and my own mistake)

I've contributed to feature factories myself.

In leadership roles — both as an engineering manager with direct reports and as a technical leader without them — I sometimes valued feature delivery more than the impact those features actually created. The real mistake wasn't the prioritisation itself. It was failing to put proper mechanisms in place to measure and expose real impact.

When teams are shielded from outcomes, they optimise for delivery. That behaviour is entirely rational. It's what the system rewards.

Things changed when impact became visible.

During a merchant selection optimisation project at Farfetch, we shared a simple dashboard with the team showing the revenue generated by their work. Nothing fancy — just a clear, understandable business signal.

The effect was immediate. The team became deeply involved in product decisions, challenged assumptions, and discussed trade-offs very differently. Ownership didn't come from process or accountability frameworks; it emerged naturally from proximity to impact.

Ownership comes from proximity to impact

"You build it, you own it" is often misunderstood.

Ownership isn't about doing everything, being on call forever, or absorbing organisational pain. It's about tight feedback loops between decisions and consequences.

The closer teams are to customer and business impact, the stronger and healthier ownership becomes. Distance from impact creates detachment. Detachment creates feature factories.

This isn't a people problem. It's a system design problem.

Conway's Law is not optional

Conway's Law is real. Organisations inevitably build systems that mirror their communication structures and success metrics.

If you measure delivery, you get delivery-shaped systems.
If you measure outcomes, you get outcome-shaped systems.

Trying to transform a product without redesigning the organisation around it is wishful thinking. The inverse Conway manoeuvre isn't an academic concept — it's a practical necessity.

If you want outcome-driven products, you have to intentionally design outcome-driven organisations.

Closing thought

Designing engineering organisations is product work.

If teams keep delivering but products fail to evolve, the problem isn't execution. It's organisational intent encoded in structure, incentives, and feedback loops.

Most engineering organisations aren't broken. They're simply doing exactly what they were designed to do.

Most product–engineering misalignment isn't caused by poor communication.
It's structural.

In many organisations, product and engineering are optimised for different things. Product is pushed to deliver features. Engineering is pushed to deliver a roadmap. Both behaviours are rational given the incentives in place.

The problem is that neither of those things, on their own, is the goal.

Rational behaviour, bad outcomes

Product teams sit close to the business. They deal daily with stakeholders, commercial pressure, and customer demands. Wanting to ship more and better features is not a failure — it's expected.

What often gets lost is the long-term effect. Feature factories don't just create bloated products; they create systems that become harder and harder to change. This usually isn't driven by malice or neglect, but by the perception that technical work doesn't directly deliver value.

Engineering teams live with the consequences. They feel the friction of building on unstable foundations and see delivery slow down over time. Where engineering frequently falls short is in explaining — in concrete terms — how technical work is, in fact, product work.

Both sides are responding correctly to the system they're in.
And that system is the problem.

Prioritisation without data doesn't work

At some point, priorities have to be set. And without data, that process quickly turns into opinion and negotiation.

Business features should have quantified expected outcomes. Technical work should too. Development teams are an expensive, limited resource. Allocating them based on gut feel or conviction alone isn't strategy — it's guesswork.

When there's no shared decision model, product and engineering end up debating beliefs instead of making trade-offs. Alignment becomes performative. Meetings increase. Decisions slow down.

The issue isn't disagreement. It's the lack of a common language to decide.

Everything here is product work

The classic "us versus them" dynamic between product and engineering is a smell.

There is no real divide between business work and technical work. There is only product work. Some of it results in visible features. Some of it improves foundations, speed, and optionality. All of it contributes to the same outcome.

When organisations fail to treat technical investment as part of the product, they force teams into artificial conflict. Alignment doesn't break because people don't care. It breaks because incentives pull in different directions.

What actually helps (even if nothing is perfect)

I've never seen this work flawlessly.

The best setups I've seen weren't the ones with the cleanest processes or the most detailed roadmaps. They were the ones where teams were clearly aligned around contributing to the product and were genuinely empowered to make trade-offs.

Not empowered to ship features faster, but empowered to decide what was worth investing in next. That doesn't remove tension, but it changes it. The conversation shifts from "my priorities versus yours" to "what's the best decision for the product right now".

That shift doesn't come from better alignment meetings.
It comes from changing the structure.

Closing thought

Product–engineering alignment doesn't improve because people try harder to agree.
It improves when organisations design incentives and decision models that make alignment the natural outcome.

If alignment feels fragile, it's rarely a trust or communication issue.
It's almost always encoded somewhere in the system.

It's inevitable that engineering organisations end up structured in blocks.
Call them domains, departments, teams — it doesn't really matter.

Those blocks will have different goals and contexts, but they will repeatedly face the same kinds of problems. Writing similar code. Choosing similar technologies. Buying similar tools. Defining similar processes.

From the company's perspective, this means solving the same problem multiple times. At that point, there are only two coherent models to choose from.

Optimising for speed

One option is to optimise for speed.

In this model, each block is autonomous. Teams solve problems in the way that best fits their context, prioritising what is fastest or most convenient for them. Reuse is accidental rather than intentional, and coordination costs are kept low.

This increases autonomy and local speed. Teams move quickly and independently.

The trade-off is efficiency. From an organisational perspective, resources are used less effectively. Similar problems are solved repeatedly, knowledge is fragmented, and long-term leverage is limited.

Optimising for efficiency

The other option is to optimise for efficiency.

Here, common concerns are centralised. Shared or core services are introduced. Tools, technologies, and processes are selected and distributed centrally. Reuse becomes deliberate.

This reduces duplication and improves resource efficiency. The organisation gains leverage.

The cost is autonomy. Dependencies between teams increase. Local decision-making slows down. Delivery speed is reduced, at least in the short term.

There is no right answer

Neither model is inherently right or wrong.

Choosing between speed and efficiency depends on diagnosis, not ideology. At a given moment, what matters more: delivering faster, or delivering more efficiently? Early on, speed often dominates. At scale, inefficiency becomes increasingly expensive.

The mistake is not choosing one model over the other. The mistake is not being explicit.

The worst outcome is ambiguity

When the organisation doesn't make a clear choice, teams receive mixed signals.

They are told to move fast, but also to reuse. To be autonomous, but also to align. To optimise locally, but also to think globally. This creates tension that has no good resolution.

The result is the worst of both worlds: reduced autonomy without real efficiency gains, and increased coordination costs without meaningful reuse.

Closing thought

Centralisation and autonomy are not opposing values. They are levers.

What matters is being clear about which one you are pulling, why you are pulling it, and when you are willing to change direction. Without that clarity, the trade-off doesn't disappear — it just becomes a source of constant friction.

At that point, the problem isn't the structure itself.
It's the lack of a shared understanding of what the organisation is optimising for.

AI doesn't automatically make companies faster.
It amplifies whatever culture already exists.

That's why today AI can be a 10x or a 0x for engineering organisations. Most teams have access to similar tools. What changes the outcome is not the technology itself, but how the organisation is set up to absorb it.

This is not a tooling problem

One of the first barriers is organisational.

Some companies still treat AI as something optional, risky, or fundamentally incompatible with how they work. Framed as caution, it often hides a deeper cultural decision: preserving existing ways of working.

Trying to build modern software while deliberately avoiding AI is increasingly similar to trying to work without the internet. You can do it, but you are choosing to cap your own productivity.

Organisations that reject AI outright aren't protecting quality. They're protecting familiarity.

The harder resistance is personal

The second barrier is individual, and it's more uncomfortable to talk about.

For many engineers, AI is disruptive at an identity level. It challenges how we define good work, where we feel value is created, and what "flow" looks like. For some people, that triggers a real sense of loss.

In large-scale rollouts, the biggest difference I've seen isn't seniority or skill. It's how quickly people accept that shift.

Some move through it fast, or never experience it at all, and become genuinely curious about what the technology enables. Others remain stuck, often hiding behind arguments like "AI doesn't generate good enough code".

That misses the point.

The goal isn't to preserve an uninterrupted coding flow or to protect professional ego. The goal is to build good products faster. That inevitably means spending less time writing code and more time specifying intent, reviewing outputs, and orchestrating systems.

Whether we like that change or not is largely irrelevant.

Adoption is the real work

Rolling out AI tools is easy. Adoption isn't.

AI may look magical from the outside, but it has a learning curve. Without proper support, teams either underuse it or use it poorly. When that happens, organisations conclude that "AI didn't work", when in reality the rollout failed.

In practice, AI tooling needs to be treated as part of an Internal Developer Platform:

• as a product, not an announcement
• with clear ownership
• with proper enablement and training
• and with tight feedback loops between the platform and its users

When teams are given good tools, helped to learn how to use them, and listened to when things don't work, adoption tends to follow naturally.

Principles matter more than tools

The pace of innovation in this space is unlike anything we've seen before. Tools will change. Models will improve. New abstractions will keep appearing.

That makes tool-centric strategies fragile.

What scales is a strategy built on principles. One of the biggest shifts I've seen is that the main bottleneck has moved from how fast we can write code to how well we can specify what we want.

Processes, roles, and incentives need to evolve around that reality.

This doesn't mean pushing new tools to developers every week. It means building a solid foundation — cultural and organisational — that allows teams to evaluate, adopt, and replace tools deliberately when the time is right.

Closing thought

AI won't fix broken engineering organisations.
But it will expose their weaknesses very quickly.

In organisations with strong culture, clear ownership, and effective feedback loops, AI becomes a genuine force multiplier. In organisations without those foundations, it simply amplifies existing dysfunction.

The difference between 10x and 0x has very little to do with the tools themselves.