The efficiency vs. flexibility framework for engineering organizations

Daniel wanted to introduce Kafka.

He was one of the best engineers on my team — sharp, curious, always looking for the right tool for the job. And technically, he was right. A central event bus would have solved the problem he was looking at elegantly. I agreed with his reasoning.

But I said no.

Not because the idea was bad. Because Kafka would have required a central team to maintain it. Only one engineer on the team knew how to do it. It would have tightly coupled several teams that were otherwise independent. The operational cost was enormous relative to the benefit.

Daniel pushed back, and he had every right to. His argument was sound. My "no" felt arbitrary to him — like I was blocking good engineering for no reason.

That moment forced me to articulate something I had been doing intuitively but had never made explicit. I was making trade-offs between efficiency and flexibility every day, but I had no framework for communicating them. Every "no" felt like politics because I could not point to a principle — only to a gut feeling.

The framework

Efficiency and flexibility are inversely related.

The more optimized a system is for a known outcome, the less it can adapt when that outcome changes.

A factory assembly line is incredibly efficient, and completely useless the moment you need to build a different product. A small generalist team is slower per unit of output, but it can change direction overnight.

You cannot maximize both. This is not a failure of leadership. It is a property of systems.

The framework is simple: for every major decision in your engineering organization, decide deliberately whether you are optimizing for efficiency or flexibility. Write it down. Explain the constraint. Make the trade-off visible.

That is it. No scoring matrix, no spreadsheet. Just a clear, explicit answer to the question: where are we flexible, where are we efficient, and why?

Why this matters

Most engineering organizations never make these decisions explicitly. Instead, engineers discover constraints by accident.

A new engineer joins. They want to use a new library. Nobody says no, so they use it. Six months later, they go on vacation and nobody can maintain what they built. Now there is an implicit rule: don't use obscure libraries. But nobody wrote it down. Nobody communicated it. The next engineer discovers the same constraint by crashing into it.

Multiply this by every decision an engineering org has to make — languages, infrastructure, deployment pipelines, monitoring, documentation — and you get engineers spending their energy playing archaeologist. They are not building. They are excavating: figuring out what is actually allowed by proposing things and seeing what gets rejected.

This is a maze with invisible walls. It breeds resentment, kills autonomy, and makes every decision feel political.

The fix is not to eliminate flexibility or to lock everything down. The fix is to be explicit. When an engineer knows the constraints upfront, they can work independently within them. When the constraints are invisible, every decision requires permission — and that is the opposite of autonomy.

This is what happened with Daniel. His Kafka proposal was technically excellent. But it crossed a constraint he did not know existed: any new infrastructure that requires cross-team coordination or a dedicated maintenance team needs organizational approval, not just a technical argument. An engineer can pick any library they want for their service. They cannot introduce a system that three other teams now depend on without the organization agreeing to the operational cost.

Daniel did not agree with the decision, but he understood the reasoning (over the years). And that is the difference between a "no" that feels political and a "no" that feels like a trade-off.

Organizations naturally drift toward efficiency as they grow. Not because leaders are control freaks, but because efficiency is measurable. You can count story points, track velocity, build dashboards. These numbers are comforting. Flexibility is invisible to most organizational metrics — you cannot dashboard "the team adapted quickly when the market shifted" — so it gets deprioritized in favor of what shows up on a chart.

In a previous post, I argued that AI is automating the execution side of engineering — the part that takes a clear input and produces a predictable output. That is the efficiency side. What AI cannot do is the flexibility side: figuring out what to build, adapting when requirements change, making judgment calls with incomplete information.

Organizations that over-indexed on efficiency are going to find they optimized for the part of the work that a machine now does for free. The ones that invested in flexibility — that learned to set explicit constraints and then trusted their people to operate within them — will be the ones that can respond to what comes next.

An example: programming languages

At one company, I told engineers they could choose whatever language they wanted. Total flexibility; or so it seemed.

But I added two constraints: you must be able to hire for it, and someone else on other team must be able to take over if you leave or go on vacation.

That sounds like freedom, and it is. Freedom within explicitly stated efficiency constraints. It rules out the engineer who wants to rewrite a service in Haskell because it is intellectually interesting. Not because Haskell is bad, but because I cannot staff a team around it.

Without those explicit constraints, someone would have built something in an obscure stack, left the company, and I would have discovered the constraint through disaster instead of through design.

This is the whole framework in miniature. Give flexibility where creativity and ownership matter. Keep efficiency where consistency and coordination matter. Be explicit about both. And when a sharp engineer comes to you with a technically sound proposal that you need to turn down, point to the trade-off and explain the reasoning.

Engineers respect trade-offs. It is what they do for a living.