Everyone has the context now

Every company runs on context. Who decided what, and why. What's blocked. Which customer is about to leave. Which project is quietly on fire. The people doing the work know all of this. Almost everyone else gets a summary.

I used to think this was a communication problem, and that better communicators would fix it. I now think it's structural. It's what happens when information has to travel through people, and until recently there was no other way for it to travel.^[1]

Consider how a decision reaches the top of a company. Say sales closes a new customer, Acme, who want to be live in a week. Sales is pleased, because there are three more just like them in the pipeline. They tell product. Product, sensibly, plans for the customer with a deadline: they write a ticket for Acme, and the other three can be scheduled once they're closer. By the time an engineer picks up the ticket, a day has gone, and it says nothing about the other three.

The engineer notices something. Deployments take a week each, mostly by hand, so Acme will just make it. But two weeks spent on internal tooling would turn every deployment into a one-day job. The catch is that Acme would go live a week late. It's a trade-off, and the kind leadership should make. So the engineer raises it in standup. Their manager mentions it at the weekly eng sync, without the numbers. It reaches the VP at the next exec meeting, a week after the customer first asked, which is the day Acme was due.

Each step adds two things: delay and loss. Delay because every layer waits for its meeting. Loss because every layer decides what's worth mentioning. By the time the VP hears about it, a week has gone, and what arrives is no longer the real question.

The real question was: can we ask Acme to wait a week, so the three customers queued behind them are all live a week sooner, and every customer after that takes a day instead of a week? What reaches the VP is: engineering wants to make a customer late so they can work on internal tooling. Put that way, the answer is obvious. Ship Acme.

Nobody in the chain ever had the whole picture. Sales knew about the queue. The engineer knew about the tooling. Put those two facts side by side and the decision makes itself, but they were never in the same room. Nobody hid anything. Everyone behaved reasonably. The system just works that way.

Fig. A · How a decision reaches the VPSummariesSourceReplay

VP knows on day 0Call needed by day 2

1. Sales

   deal closed

   day 0

   “Acme signed! They want to be live in a week, and we've got three more just like them in the pipeline.”

   Acme in 1 wk3 more queued
2. Product

   ticket

   day 1

   “Deploy Acme. Due in one week.”

   Acme in 1 wk3 more queued
3. Engineer

   picks it up

   day 1

   “Acme's a week of manual deployment, so we just make it. Or we spend two weeks on deploy tooling and every deployment after this takes a day, but Acme slips a week. Someone needs to decide by Wednesday.”

   Acme in 1 wk3 more queuedtooling: 2 wks1 wk → 1 daydecide by Wed
4. Eng manager

   weekly eng sync

   day 3

   “Team wants to build deploy tooling before Acme. Acme would slip a week.”

   Acme in 1 wk3 more queuedtooling: 2 wks1 wk → 1 daydecide by Wed
5. VP

   exec meeting

   day 7

   “Eng want to pause a customer deployment to work on internal tooling.”

   Acme in 1 wk3 more queuedtooling: 2 wks1 wk → 1 daydecide by Wed

The question the VP answers

Should eng make a customer late to work on internal tooling?

→ No. Ship Acme first. Tooling deferred. Next month, the same trade-off.

The worst part is that it doesn't happen once. Next month there's another customer, the same trade-off, and the same answer, because the tooling still hasn't been built. Deployments still take a week. The trade-offs pile up, the investment never gets made, and everyone involved believes, correctly by what they could see, that they put the customer first.

The same thing happens in reverse. Leadership makes a decision, and the reasoning gets stripped off a bit more at each layer. By the time it reaches the person doing the work, it's just "priorities changed." So they guess what was meant, and usually they guess slightly wrong. Bercan Kilic described this well: two degrees of misalignment at the top becomes thirty by the time it reaches the people doing the work.^[2] The uncomfortable part is that good managers make it worse. A passive manager who is slightly off course does little damage. An energetic one takes the whole team further in the wrong direction.

Why we did it this way

It's tempting to blame hierarchy, but hierarchy wasn't a mistake. It was the best available answer to a real constraint: no one person can hold the context of a few hundred people. So we split it up. Each manager holds the context for their team and passes a summary to the layer above.^[3]

That works, more or less, in the way a game of telephone more or less works. The message arrives. It's just not quite the message that was sent.

Companies have spent decades trying to patch this. Standups, status reports, OKR check-ins, all-hands meetings, dashboards that stay accurate for about a week after someone builds them. Each is an attempt to move context faster. None of them change the underlying constraint, because each one still depends on someone reading something and writing it down again. Hire consultants to fix it and they'll usually recommend another layer of reporting, which is like fixing a game of telephone by adding another person.

The constraint was never really about org design. It was about bandwidth. A human can only read so much.

What changed

That constraint is now gone, or at least going.

AI, deployed properly, can read the source material directly: the Slack threads, the tickets, the pull requests, the docs, the call notes. Not someone's summary of them. All of it, continuously. And it can answer questions about it, for anyone, at any level.

This matters in two ways, and I think people tend to notice only one of them.

The one people notice is visibility for leaders. If you run a company, you can now see what's actually happening instead of the curated version from three layers down. A project drifting shows up in week one instead of week six. You notice two teams quietly building the same thing. You see the customer whose support tickets have been getting a little colder every week for a month.

What this lets you do is pull things in early. Most problems in a company are cheap if you catch them early and expensive if you don't. Re-scoping a project in its first week costs a conversation. Re-scoping it in its third month costs a quarter. Getting two engineers into a room before they've written overlapping code is a calendar invite; afterwards it's a negotiation. Calling an unhappy customer before their renewal is a favour; calling them after is an apology. Leaders were always capable of acting early. They just didn't know early.^[4]

The one people miss is that everyone else gets full context too. This isn't just a better dashboard for the CEO. An engineer can ask why a decision was made six months ago and read the actual discussion, instead of relying on whoever has been around longest. A new hire can get up to speed in days instead of months. Sales can see what engineering is actually shipping, not what the roadmap said in March.

And when people have the reasoning behind a decision, they stop guessing. That's what fixes the drift. The two degrees never become thirty, because the person doing the work doesn't have to infer what leadership meant. They can just look.

I suspect the second effect will turn out to matter more than the first. Visibility lets leaders correct things faster. Context means fewer things need correcting.

The catch

"Deployed properly" is doing a lot of work in that sentence. A chatbot with no access to anything is a very articulate stranger. Pasting your strategy doc into a chat window is not what I mean.

It has to be connected to where the work actually happens, not to the summaries of it. If it only reads the weekly updates, you've just automated the lossy layer. It has to respect permissions, because full context doesn't mean everyone reads the HR channel. And it only works if things get written down in the first place. Companies that make their important decisions in hallways and private messages will get much less out of this, which may be the most useful thing it teaches them.^[5]

The biggest risk is treating it as surveillance. If visibility turns into asking someone why they only pushed three commits on Tuesday, people will quickly learn to stop writing things where it can see them, and you'll be back where you started with worse morale. The point is to help people sooner, not to watch them harder.^[6]

What's left

If context no longer has to travel through people, a lot of what managers spend their time on goes away.^[7] That sounds alarming, but I think it's mostly the part of the job nobody liked: acting as a human relay, writing status updates, sitting in meetings whose only purpose is to find out what's going on. What's left is the part that always needed a person. Judgement. Unblocking people. Deciding what matters.

For most of history, companies scaled by adding layers to move context around, and accepted the delay and the drift as the price of being large. That trade is no longer necessary. The companies that notice first will be faster than their competitors in a way that's hard to copy, because it isn't a feature. It's how they work.

Everyone can have the context now. The interesting question is what companies do once they do.

Notes