The solution to a communication problem is sometimes less communication.
Before the standardised shipping container, loading a cargo ship took days. Every crate was a different size. Longshoremen packed them by hand like a three-dimensional jigsaw puzzle. Theft was rampant -- individual crates were easy to open, hard to track. Then in 1956, Malcom McLean put 58 aluminium containers on a converted oil tanker. The interface was the container dimensions: 8 feet wide, 8.5 feet tall, either 20 or 40 feet long. Any port with a container crane can handle any container from any ship from any country. The crane operator neither knows nor cares what's inside.
Global trade didn't grow because countries understood each other better. It grew because they agreed on a box size.
Before USB, every peripheral had its own connector, its own driver, its own protocol. A printer talked differently from a scanner talked differently from a keyboard. USB defined one interface: a data protocol, a power delivery spec, and a device class system. The connectors have actually changed eight times -- Type A, B, Mini, Micro, C -- which is a nice illustration of what happens when part of your interface isn't stable: adapters everywhere, user frustration, a drawer full of cables. But backward compatibility held. The language gained words, but existing ones kept their meaning. A USB 1.0 device still works in a USB 3.0 port.
The same thing happened decades earlier with pallets. A standard pallet can be moved by any standard forklift. Trucks and shipping containers are sized to fit an exact grid of them. Products have standard palletisation patterns -- how many units per layer, how many layers, how to wrap them -- so a warehouse worker receiving a shipment already knows what they're getting without opening anything. The pallet is the interface between the factory floor and the supply chain. Neither side designs for the other. They both design for the pallet.
Money, same principle. A farmer and a software engineer have no understanding of each other's work. The farmer doesn't know what an API is. The engineer doesn't know when to plant barley. But the farmer can sell barley for EUR 180 per tonne and the engineer can buy bread for EUR 2 a loaf. Money lets you trade a good without caring what goods the seller wants. Before the metric system, every country -- sometimes every city -- had its own weights and measures. A pound in London wasn't a pound in Paris. Merchants kept reference weights from the countries they traded with and maintained conversion tables for every transaction. The metric system didn't make anyone smarter about each other's goods. It gave everyone the same units. One shared language for "how much stuff" and "how much money" -- and the translation problem disappeared.
None of these breakthroughs required mutual understanding. They required a shared interface. Narrow enough to learn in an afternoon. Stable enough to build on for decades.
Where it gets interesting: organisations
Most companies don't see this pattern because they're too busy trying to improve "communication" when what they actually need is a better interface.
The usual answer, when two groups can't coordinate, is "better communication." Write better tickets. Have more meetings. Make engineers explain their work to non-engineers. Make data scientists learn infrastructure. This advice isn't wrong exactly, but it doesn't scale. You can't teach thirty data scientists Kubernetes, and you can't teach three data engineers the statistical nuances of thirty different models. The knowledge gap isn't a bug to fix. It's a structural feature of specialisation.
Consider the north-star metric. At Bolt, GMV -- gross merchandise value, the total transaction volume flowing through the platform -- was the shared number every team used to justify their work. Product teams derived conversion rates from it. Engineering teams derived uptime targets from it. Finance derived revenue projections. Marketing derived campaign ROI.
These teams had almost nothing in common technically. A product manager evaluating a checkout flow change and a platform engineer evaluating a database migration live in different intellectual universes. Different tools, different methods, different vocabularies. And yet when the database migration was proposed, the engineer could say "this reduces p99 latency by 200ms on checkout, which our A/B data shows increases completed orders by X." The product manager didn't need to understand database internals. The engineer didn't need to understand conversion funnels. GMV was the shared interface. Both sides translated their domain expertise into a common unit, and the comparison became arithmetic.
That's what an interface does at the organisational level. It creates a translation layer where each side can express their work in terms the other side can evaluate, without either side needing to learn the other's domain.
It works for settling arguments, but it's even more powerful for planning. When tasks from different domains compete for the same scarce resource -- an engineer's time, a budget line, a sprint slot -- the north-star metric lets you compare apples and oranges. A frontend polish task worth EUR 5K of projected GMV, a data pipeline rewrite worth EUR 200K, and a model retraining expansion worth EUR 50K are suddenly commensurable. The 5K task drops itself. No argument needed. No meeting needed. The interface did the work.
The team-level version
At Bolt, a data scientist named -- let's say Nymphadora -- wanted to retrain her pricing model across 47 cities, deploy it with a gradual traffic rollout, and run replay tests against live traffic before going fully live. She described all of this in a config file: a Python function returning a dict. Schedule, instance types, rollout percentages, rollback thresholds. She opened a PR, got it reviewed by another data scientist, and merged it. That was Thursday. By Friday morning, the pipeline was live in production.
Nymphadora didn't know how Airflow DAGs are generated, how SageMaker endpoints handle traffic splitting, how Docker containers are built and pushed to ECR, or why the base image was 4GB and kept growing. She didn't need to. The config was the interface between her world and mine.
And I didn't know why she'd chosen XGBoost over a neural net for this particular problem, what features she'd engineered, or whether 47 cities was the right scope. I didn't need to either. The same config file was the interface from my side.
Neither of us understood the other's work. We didn't need to. We agreed on a contract -- a config format -- and both sides could move independently as long as the contract held. She could change her model architecture without telling me. I could rewrite the execution engine without telling her. In fact I did, twice, and she never noticed.
What makes this work
Not every shared interface works this well. The pipeline config had a few dozen fields. GMV is one number. A shipping container has two standard sizes. The narrowness is what makes them learnable and stable -- and stability is what makes them worth building on. A wide interface is an implementation detail pretending to be an interface. It couples the parties together instead of freeing them.
The config format didn't change significantly over four and a half years, even as the implementation behind it was rewritten twice. HTTP 1.1 was published in 1997 and is still in use. Shipping container dimensions haven't changed since the 1960s. The best interfaces are boring. They get defined once and then nobody thinks about them, which is exactly when they're doing the most work.
Good defaults matter too. A data scientist who just wanted "train this model weekly and deploy it" could write a config with a dozen or so lines. The replay testing, the gradual rollout, the rollback thresholds -- all present, all defaulted, all overridable. HTTP has default ports. USB has default power delivery. Currency has default denominations -- the average person has no idea what a basis point is, and the average forex trader goes entire weeks forgetting that five-euro notes exist. Same interface, completely different scales of use.
The default path should work. The expert path should exist but not be required. That's the line between an interface that gets adopted and one that gets routed around.
The mistake everyone makes
The instinct, when two teams can't communicate effectively, is to improve communication. More standups. More documentation. "Engineers need to be better at explaining their work." "Product needs to learn more about the technology."
This is treating the symptom. The disease is a missing or broken interface.
You don't need your data scientists to understand Kubernetes. You need a config format that hides Kubernetes behind a few meaningful fields. You don't need your CEO to understand database internals. You need a metric that translates database performance into business outcomes. You don't need the crane operator to understand Cantonese. You need a standardised box.
A rough interface that exists beats a perfect spec that's still in planning. Pieter Hintjens described building a grand bridge over seven years -- designed to perfection, demolished because it was in the wrong place. Someone else threw a rope across a gorge. People started using it, a footwalk was added, then a market grew up around it, and eventually it became a suspension bridge. Throw the rope. Let it carry weight. The bridge emerges from usage.
Everyone has the bravery to demand more communication to solve a communication problem. But do you have the bravery to demand less communication?
The next time two teams can't coordinate, don't add a standup. Remove a dependency. Define an interface that makes the standup unnecessary.
Better communication has diminishing returns. Better interfaces have compounding ones. The pipeline config I built at Bolt was used by 30+ data scientists across hundreds of projects for years. The total communication cost it replaced -- tickets filed, meetings held, context transferred, misunderstandings debugged -- is incalculable. And it kept working after I left, because the interface was stable even though the implementation was, charitably, held together with string.
The farmer and the software engineer will never understand each other's work. They don't need to. They share a price, a currency, a standard box. And that's enough.
Establish a common language. Talk less.