Organizational Latency

I've been thinking about how much time people spend waiting at work. Waiting for access, for another team's availability, for someone to explain how something is supposed to be done. As AI gets better at doing the work itself, I think this waiting will become a much larger part of what determines a company's output.

At Anthos Capital, I worked on a research team of three quants. My manager had been a managing director at Citadel. It was an incredible experience, and I'm still grateful for what he taught me. Working around someone with that level of ability gives you a better sense of how much more you're capable of learning.

At RepRally, my cofounder was especially good at finding engineers. At our height, recruiters around New York knew us as a place to poach them. He deserves much of the credit for that. Once you have enough good people, their peers want to work with them.

The people who stood out could take a problem all the way through. They had a particular expertise, but they could work outside it. They'd figure out what they needed to learn and keep going. You could give them responsibility for something without having to connect every step for them.

I've since spent time inside a larger technology company, which has made me think more about what happens to that ability as a company grows.

There are good reasons to divide responsibilities. Analytics needs consistent definitions. Someone needs to maintain the systems everyone uses. You can't have people changing things without understanding who else depends on them.

But those boundaries also create dependencies. You may understand a problem and be capable of solving it, yet still have to get several other teams to prioritize their part. They have work to do. Your request joins a queue, and part of your job becomes making the case for moving it up.

At that point, your own capability has less to do with how quickly you can finish. You're waiting on other people.

That's what I mean by organizational latency.

I've been using AI since the early models became available, testing different platforms and trying to understand what I could actually trust them to do. For a long time, I had to move the work between steps myself. A model might help with the analysis or write part of the code, but I was still carrying the process.

With models like Astra and Fable, I've begun to delegate whole workflows. They can work across tools and applications. In my own use, this is the first time I've seriously reconsidered how much of the execution requires me.

The limits matter. Some work is easier to define and check than other work, and a completed task can still be wrong. I need enough understanding to judge the result. But where an agent can reliably carry a workflow through, a job built around manually completing that workflow has to change.

The person starts managing the system doing the work. They decide what to give it, supply what it needs to know, and check what comes back. If the process repeats, they should be improving it so the same problem doesn't need to be solved again.

I think this makes systems builders much more important. A capable person can extend their work through agents, provided they understand the process well enough to supervise it. Giving them a narrow role and requiring every adjacent task to pass through another department wastes much of that ability.

Consider a team trying to improve customer onboarding. It needs to understand where customers struggle, change the relevant parts of the process, and see whether the changes helped. That can involve analytics, engineering, and operations. I would give that team more ability to do the work itself, within rules the specialists have agreed on.

This is where documentation becomes essential.

A lot of learning how to work at a company means finding out who knows what. Which data can you trust? Why does a particular process exist? Who can decide whether it changes? The answers may be scattered across documents and conversations, or known only to someone who's been there long enough.

An agent needs those answers too. If I have to find and explain them every time, I'm still required at each step.

Useful documentation gives people and agents a way to work through unfamiliar parts of the business. It needs to explain the actual rules, identify the reliable information, and make clear what they can do on their own. Straightforward Markdown files can already carry instructions for agents. The work is in making those instructions accurate and keeping them that way.

Writing down how to request permission won't help much if every task still needs permission. The company has to decide what people and their agents are allowed to complete independently. Some actions will need review. Others can proceed once defined checks pass.

I think a meaningful amount of management can be replaced this way. If someone's recurring job is explaining the same procedure, routing requests, or passing along decisions that have already been made, I'd want to understand why that still requires a person.

That work can be necessary in the company as it exists. It can also be a sign that the company hasn't built a better way to operate.

I'd organize more of the business around small teams responsible for a result they can carry through. Shared specialists would maintain the systems and standards those teams depend on. An analytics team, for example, would still be responsible for reliable data and consistent definitions. Part of its success would be whether other teams could answer routine questions correctly without asking it to do the analysis for them.

Engineers are a good place to look for people who can build this. Pair someone who knows how to construct and test systems with someone who understands the business problem, and you have a useful starting point. The engineer needs the domain expert's judgment. The domain expert needs a way to make that judgment useful beyond the work they can personally complete.

I'd apply the same expectation to managers. Before hiring or promoting someone to oversee this work, I'd want to see a system they've built and used. Can they explain where it fails? Can someone else run it? Their previous title wouldn't answer those questions.

There will still be difficult personnel decisions and disagreements about priorities. Managing people takes skill. But I think hiring a layer of managers who can't understand or build the systems doing the work would be a serious mistake. They'd need other people to interpret the work for them, recreating the dependencies the company should be trying to remove.

The talent consequences concern me too. The people I've most enjoyed working with wanted room to use their ability. If a company consistently makes them wait for work they could do themselves, some will leave. Losing those people may then make the organization more dependent on managers and process. You can keep recruiting strong candidates while missing why the strongest ones don't stay.

A company can give every employee access to AI and still require their work to pass through the same approvals and departmental queues. If execution gets faster while those dependencies stay in place, it may simply have more work waiting.

Companies starting now have a significant advantage here. They can build around people who understand the work and can construct systems to carry it through. They can make documenting that understanding part of the job from the beginning, so the next person doesn't have to ask the same questions or depend on the same people.

An established company has to reconsider decisions that were reasonable when it made them. Some roles will need to change substantially. Others may no longer be necessary. That's much harder than introducing a new tool, especially when the people responsible for redesigning the organization have built their careers around managing it as it exists.