Lossy Organizations

Most engineering teams don’t announce problems as failures. They announce them as progress.

Dashboards are green. Tickets move. Releases ship. From the outside, the system looks healthy. Yet experienced leaders often feel a quiet unease. Nothing is obviously broken, but keeping things moving takes more effort than it should. Conversations drag on. The same engineers are consulted repeatedly to sanity-check decisions that have already passed formal review.

The dashboards aren’t wrong; they’re faithfully reporting a compressed version of reality.

This isn’t a failure of effort. It’s a failure of compression.

The Green Dashboard Paradox

I saw this clearly early in my career while leading mobile engineering teams for a large enterprise platform.

The platform team was shipping updates. My mobile teams were integrating them. According to the metrics, we were aligned. But the delivery velocity was asymmetric.

Every “clean” platform release triggered days of forensic work for my mobile engineers. They had to dig into implementation details that should have been contractual but were implicit. We compensated for compressed handoffs by translating assumptions into working code.

Because we were good at it, the system never forced those assumptions to be explicit. We were subsidizing the platform’s velocity with our own cognitive load.

This is Lossy Compression.

Capability is Redistributed, Not Lost

As organizations grow, they must compress reality.

Complex work travels across teams, time zones, and layers. To make this possible, high-resolution reality is translated into artifacts that are easier to transmit: tickets, APIs, status updates, and release gates.

This compression makes scale possible by reducing cognitive load and allowing people who aren’t in the details to stay oriented. But compression always involves trade-offs. Fidelity is exchanged for efficiency. Nuance is flattened into categories.

In engineering, Lossy Compression preserves the signal but discards the detail. In organizations, that “discarded detail” usually consists of uncertainty, ambiguity, and dependency.

When that detail doesn’t survive the compression into a ticket or an API spec, it doesn’t disappear. It relocates.

It relocates into the minds of your most experienced engineers. They become the “error correction” layer for the organization. The system keeps moving, not because the process is solid, but because specific humans are quietly filling the gaps left by the abstraction.

Why We Don’t Start With “Hard Interfaces”

If the solution is obvious—strict contracts, hard interfaces, explicit boundaries—why do so few teams start there?

Because in the beginning, compression feels like agility.

When a team is small, high-bandwidth conversation is cheaper than documentation. “Just go talk to Cindy” is faster than writing a machine-readable YAML spec. We mistake shared context for system design. We value the speed of the handshake over the friction of the contract.

And for a long time, this works.

The trap springs when the organization scales but the compression ratio stays the same. The “agile” reliance on conversation becomes a tax on your best people. What looked like a streamlined process was actually just a set of human buffers absorbing complexity for everyone else.

You are one resignation away from discovering what your system actually depends on.

Forcing Decompression

In that mobile role, the fix wasn’t better communication. It was refusing to let compression continue hiding the dependency.

We introduced integration contracts—YAML specifications that defined API boundaries, authentication models, and behavioral expectations before any code shipped.

• If the contract didn’t specify it, the platform couldn’t assume mobile would handle it.

• If mobile needed it, the contract had to guarantee it.

This introduced friction. Conversations took longer. Negotiation replaced assumption. We forced decompression at the interface.

The result wasn’t just smoother handoffs; it was durable velocity. When experienced engineers moved to other teams, new hires inherited contracts, not tribal knowledge. The system didn’t slow down because someone left; it kept moving because the critical detail was captured in the interface, not the person.

The Leadership Choice

The work of leadership isn’t preventing compression. You can’t. Without abstraction, scale collapses under its own weight.

The work is deciding where to allow compression and where to force decompression.

Look for asymmetric effort at your interfaces.

• One team sends a “clean” request; the receiving team spends days clarifying.

• Product defines requirements; engineering runs repeated sanity checks.

• A platform ships a feature; downstream teams dig into undocumented code.

When the same translation keeps happening, that’s not collaboration—it’s compensation.

Capability isn’t lost through failure. It’s redistributed into the invisible effort of your best people. The only way to get it back is to stop subsidizing the ambiguity and force the system to carry its own weight.

If your system works only because your best people compensate for it, your system doesn’t actually work.