Communication Should Take the Shortest Path

Inc. ran a piece on an email Elon Musk sent to Tesla employees about how the company should communicate. One line from it stuck with me: “We obviously cannot compete with the big car companies in size, so we must do so with intelligence and agility.” Replace “car companies” with your biggest competitor and the same is true for most software teams. I believe a smaller organization can’t win on headcount. It has to win on how fast information moves and how fast decisions get made.

You can’t out-hire them

A larger company has more engineers than you do. It has more testers and more managers. If the plan is to ship more by having more people, the larger company wins that race every time.

What a small team can control is how long work sits still. Very little of the time it takes to ship a feature is spent typing. Most of it is spent waiting: for an answer from another team, for a decision, for someone to review a pull request, for a ticket to make its way through somebody’s backlog. A big company can absorb that waiting by running a hundred projects at once. A small company can’t afford to.

That waiting is where intelligence and agility actually show up. A team that gets its answers in minutes instead of days can keep pace with a much bigger one.

Count the hops

Consider a common situation. An engineer on the web team needs a new field on an endpoint owned by the billing team. There are two ways that question can travel.

The long way goes up the org chart and back down. The engineer asks their lead. The lead brings it up with their manager. That manager mentions it to the billing team’s manager, who files a ticket, which lands in the billing team’s backlog, where an engineer eventually picks it up and has follow-up questions. Those questions travel back along the same route. Every hop adds a delay, whether that’s waiting for the next one-on-one, the next standup, or the next sprint planning. Every hop also loses detail. By the time the request reaches the person who can do the work, it has been through a game of telephone.

The short way: the web engineer messages the billing engineer who wrote the endpoint, and they talk for ten minutes. Maybe the field already exists under a different name. Maybe it’s a one-line change. Maybe it’s hard, and now both of them know why.

That’s the heart of the email, at least as Inc. reported it. Information should travel by the shortest path needed to get the job done, even when that path skips the chain of command entirely. And a manager who keeps people from talking directly to other teams is a problem to be fixed.

Handoffs are hops too

The org chart is one place hops hide. The process is another. A feature that goes from product manager to designer to developer to tester to operations has four handoffs, and each one is a queue. Work waits in every queue, and every written handoff (a spec, a ticket, a test plan) carries less than the person who wrote it knows.

A small team can remove a lot of those hops. Put the people who need to talk to each other on the same team. Have the developer and the tester work a story together from the start. Let the team that writes the code deploy it and watch it in production. When a ticket says “see attached spec,” walk over and ask the person who wrote the spec what they meant.

Conway’s law follows

Melvin Conway observed that the systems an organization builds end up mirroring how that organization communicates. It usually gets cited as a warning about architecture, and it follows directly from everything above.

If the web team and the billing team can only talk through their managers, the interface between their services will look like it. It will be formal and slow to change, so engineers will work around it. Data gets cached on the wrong side of the boundary. Logic gets duplicated because rebuilding it was easier than asking for it. An adapter layer appears to translate between two teams that never sat down together. Each of those is the communication structure showing up in the code.

When the engineers who own both sides of an interface talk directly, the interface gets designed by the people who use it. Changing it is cheap because the conversation is cheap. If you want clean boundaries between your services, start by making it easy for the teams behind them to talk.

What this asks of everyone

None of this requires a reorg. It mostly requires permission and a couple of habits.

For engineers: if you need something from another team, find the person who knows and ask them. You don’t need your manager to make the introduction. Afterward, tell your lead what you decided so they aren’t surprised later.

For managers: your job is to make sure those conversations happen and that the right people are in them. If you find yourself relaying messages between two engineers, introduce them and step out of the way. When someone on your team goes straight to another team with a question, the system is working.

Direct conversations still need a paper trail. When two engineers agree to change an interface, write it down somewhere both teams can find it: the pull request, the ticket, the team’s chat room. Talking directly and keeping a record of what you decided go together just fine.

You will never have as many people as the biggest company in your market. You can make sure that when one of your engineers has a question, the answer is one conversation away.