The Work No Longer Needs to Travel to the Expert

For years, one of the most useful things I could do in a customer conversation was connect a pain point to a capability the customer did not yet know they had. The feature itself was rarely the interesting part. The interesting part was understanding the work well enough to see how the feature could shorten a process, remove a handoff or make an irritating task disappear. Looking back, that was an expertise queue: too much useful cognition lived in a few people, so the work had to travel toward us.

I learned this in an enterprise software company long before generative AI entered normal business vocabulary. I had spent time earlier in my career working inside the kind of business many of our customers operated. Later, I developed unusually deep knowledge of the software itself. Put those two things together and I could often recognize a customer’s operational problem, translate it into the system and propose something that felt like a solution rather than a product demonstration.

That was good for the customer. It was useful for sales. It was useful for the company. But it also exposed an operating-model problem that I did not have the language for at the time: the work had to travel to the person who carried the right combination of knowledge.

Large or unusual opportunities pulled specialists into the conversation. International work created another layer because the organization was still relatively regional and some customers needed more than product knowledge; they needed someone who could navigate different expectations and ways of working. The larger and stranger the problem became, the more likely it was that the work would find its way toward a small number of people who could connect the dots.

This is not a story about a badly managed company. It is a story about how knowledge work has traditionally scaled.

Why the expertise queue made sense

Organizations have always had ways to distribute knowledge. We document processes. We create training. We build centres of excellence. We pair junior and senior people. We introduce peer review. We hire specialists and ask them to teach everyone else. We create escalation paths so that difficult problems eventually reach someone who has seen something similar before.

Those mechanisms work. There is even experimental evidence that deliberately creating opportunities for colleagues to exchange techniques can improve performance after the intervention ends. Research on workplace knowledge flows, for example, found durable gains when workers were given structured opportunities to learn from high-performing peers.

But the mechanisms have an unavoidable characteristic: they are largely serialized. Someone has to know something before someone else can receive it. The expert has to become available. The review has to happen. The training has to be scheduled. The documentation has to be written, found and interpreted. The question has to reach the right person.

That serialization is what turns scarce knowledge into an expertise queue. It is not only the cost of the expert’s time. It is waiting, routing, context reconstruction and the repeated effort required to bring the expert into enough of the problem to make their judgment useful.

I saw the same problem in software development from a different angle. I was not the developer carrying the scarce technical knowledge, but I knew which people did. We made repeated efforts to distribute that knowledge more broadly. What eventually gained real traction was not another appeal to document more. It was changing the development process so that knowledge transfer became part of the work itself through stronger review practices.

That experience was fundamental in changing how I think about AI. The opportunity is not simply to create a faster expert; it is to attack the serialization of cognition.

The goal is not to make everyone an expert. It is to stop making routine cognition wait for one.

AI expertise should become a learning system, not another knowledge base

If I imagine that earlier software business with today’s technology, I would not start by giving everyone a chatbot and declaring expertise democratized. I would start with what happened after a successful customer engagement.

In the old model, I learned something. Perhaps a customer described a process in a way I had not heard before. Perhaps I discovered an unexpected combination of features. Perhaps I found a better way to explain the solution to a particular kind of stakeholder. Some of that knowledge might make it into documentation or a colleague’s memory. Much of it remained attached to the people involved.

Now imagine that every successful resolution enriches a shared knowledge graph. The system does not merely store the answer. It retains the relationship between the customer’s problem, relevant context, the product capabilities considered, the solution that worked, the trade-offs that mattered and the way the engagement unfolded.

A probabilistic system can then do something a static knowledge base struggles with: join a new problem to a pattern that is similar without requiring the wording to be identical. It can retrieve prior resolutions, suggest plausible paths and adapt the presentation to the person using it. A salesperson may need a way to explore the problem without overcommitting technically. A customer-success person may need a diagnostic path. A product specialist may want the edge cases and underlying evidence.

This is where AI expertise becomes useful in a more precise sense. The system does not need to become the expert. It can make more of the expert’s reusable cognition available without forcing every familiar problem back into the same expertise queue.

This is closely related to what I call Cognitive Leverage: AI gives human judgment more reach, context and speed. But there is an organizational implication beyond making one person more capable. If reusable cognitive operations can be available at the point of need, the workflow no longer has to route every familiar problem through the same scarce human nodes.

Recent field evidence makes that possibility harder to dismiss as theory. In an experiment involving 776 professionals working on product-innovation challenges, individuals using AI matched the performance of teams without AI, while AI users also produced more balanced solutions across functional backgrounds. The researchers describe AI as changing how expertise sharing manifests inside teams. That does not prove that every expertise queue should disappear, but it does show that some benefits previously obtained through cross-functional collaboration can move closer to the individual doing the work. The field experiment is available through the NBER.

The important distinction is cognition versus judgment

This is where the argument can easily go wrong.

If AI can retrieve product knowledge, connect patterns and generate plausible solutions, it is tempting to say that expertise has become abundant. I do not think that is precise enough. Some cognitive operations are becoming dramatically easier to distribute. Expertise itself is more complicated.

My value in those earlier customer conversations did not come only from remembering where a feature sat in a menu. It came from recognizing the relationship between a business problem and a possible intervention. It came from experience of the customer’s world. Sometimes it came from understanding that a technically correct answer would be a terrible way to approach the people in the room. In international engagements, cultural fluency mattered too.

AI can make more of the ingredients available. It can expose patterns that would otherwise remain trapped in previous engagements. It can make deep product knowledge accessible without waiting for the person who memorized it. It can pressure-test a proposed solution against more cases than one human can recall. What it does not automatically inherit is responsibility for the consequences, trust with the people affected, or the judgment required when the pattern does not quite fit.

That boundary is increasingly visible in research as well. A 2026 randomized field experiment with practicing patent lawyers found that AI assistance improved benchmark drafting performance, but the longer-term effects on professional judgment differed by experience. Senior lawyers showed gains on a later unassisted judgment task; junior lawyers did not show the same average improvement. The authors’ interpretation is important: foundational expertise may be a prerequisite for extracting durable skill from AI-assisted practice. That result is a useful warning against confusing access to cognitive output with possession of expertise.

This is also why I resist framing AI expertise as a universal replacement for specialists. The more interesting design question is which cognitive operations are repeatable enough to distribute and which moments still deserve scarce human judgment.

Vertical scaling reduces the expertise queue without removing the expert

Years later, in professional services, I encountered the same mechanism from the other side.

I was asked to rethink an intervention after earlier attempts had failed. This time I had an AI system around me that could work with the collateral from those failures. It could retain more of the problem world than I could comfortably keep active at once. I could bring my own experience with operating models and transformation methods into the work, while the system helped me explore a wider solution space and avoid obstacles that had already been discovered.

I think of this as vertical scaling. My pattern recognition remained the key element. The AI did not suddenly become accountable for the engagement or build the relationships required to make the intervention work. But my effective cognitive reach became larger. I could tap into things that my own working memory, available time and immediate network of specialists would have made slower to reach.

More importantly, a failure no longer had to remain a one-off failure. It could enrich the context for the next decision. A successful intervention could become reusable evidence for the wider team. The system had the potential to learn across attempts instead of requiring each person to reconstruct the history manually.

This is different from horizontal scaling, where the obvious answer to more work is more people. It is also different from simple automation, where the objective is to remove the human from a task. Vertical scaling asks how much more territory one capable person can cover when reusable cognition, organizational memory and machine-supported exploration are available around them.

That distinction fits another pattern emerging from research. Studies of AI in customer support found especially large gains among less experienced workers when systems could draw on patterns from successful prior conversations and surface them in real time. In one large deployment summarized by the NBER, average productivity rose while the strongest gains accrued to less experienced or lower-performing workers. The mechanism matters: useful behavior from experienced agents became available closer to the moment another worker needed it. The NBER’s review describes this as knowledge from skilled agents being passed through the system to novices.

Where the expertise queue still hides in everyday work

Once you start looking for the pattern, expertise queues appear everywhere.

A salesperson waits for a solution architect. A product team waits for a researcher to synthesize what customers are saying. A consultant waits for the colleague who worked on the comparable engagement. A developer waits for the person who understands a particular part of the codebase. A manager becomes the routing layer because they know who knows what.

Some of those waits are valuable. The specialist may carry judgment that genuinely changes the answer. The manager may hold authority that should not be delegated. The review may protect customers from a consequential mistake.

But some waits exist because organizational memory is fragmented and cognition is difficult to access. That is a different problem. It is an expertise queue created by the architecture of knowledge rather than by the inherent difficulty of the decision.

It is related to the Interface Tax: capability can exist and still be expensive to use because people have to cross tools, contexts and boundaries to reach it. An expertise queue adds a human version of the same friction. The answer exists somewhere in the organization, but accessing it requires finding the right person, explaining the context, waiting for capacity and translating the answer back into the work.

This is why merely placing an AI assistant beside the old workflow is not enough. A large cross-industry field experiment found that generative AI changed activities workers could alter independently, such as email and document work, but did not produce comparable changes in coordination-heavy activities such as meetings. That is a useful constraint. Individual cognitive leverage can arrive before the organization redesigns the workflow around it. The experiment covered 7.137 knowledge workers across 66 firms.

I have argued elsewhere that the old workflow is too small for AI. Expertise queues are one concrete reason why. If the system can now make prior cases, organizational knowledge and routine analysis available at the point of need, preserving every old handoff means preserving the economics of scarce cognition after part of that scarcity has changed.

Redesign the escalation, not the expert

The practical starting point is not a reorganization. It is an escalation path.

The first two categories are obvious candidates to move closer to the work. The latter two should make us much more cautious. This is the operating-model boundary that turns AI expertise from a chatbot feature into a workflow redesign question.

Then change the learning loop. If the AI-supported worker resolves a problem successfully, the resolution should improve what the system can offer next time. If the recommendation fails, that failure should become context too. The objective is not a magical corporate brain that always knows the answer. It is an operating environment in which the organization gets less dependent on manually rediscovering what it has already learned.

Finally, redesign the expert’s role around exceptions. Instead of answering the hundredth familiar question, the specialist should spend more time on the question that does not fit the existing pattern, on improving the system’s knowledge, and on the situations where trust and judgment make human involvement valuable.

That is how an expertise queue becomes smaller without pretending that expertise itself has disappeared.

Cheap cognition does not make human interaction cheap

There is one part of my earlier work that I would not want to automate away even if the system became technically capable of doing much more.

Human interaction itself mattered. Customers trusted a solution partly because someone understood the problem they were trying to solve. Colleagues became involved because they would eventually have to live with the consequences. A technically elegant recommendation that fails to create trust, ownership or commitment is not necessarily a good intervention.

That is why the distinction between cognition and judgment matters so much. AI can make analysis, retrieval, synthesis and pattern matching cheaper. It can make organizational memory more accessible. It can reduce the number of familiar questions that have to queue behind a scarce specialist. None of that makes accountability, trust or meaningful stakeholder involvement free.

The operating-model opportunity is therefore not to flatten expertise until everyone is interchangeable. It is almost the opposite. Make routine cognition widely available so that genuinely scarce human capabilities become easier to see.

In the old model, I was useful because I could stay a step ahead in connecting client pain to system knowledge. Today, much more of that system knowledge can become continuously reusable and immediately accessible. The question is what I should do with the capacity that returns.

I would spend less of it being the human API to information the organization already possesses.

I would spend more of it recognizing the problem that does not fit, earning trust with the people affected, and deciding what should happen next.

That seems like a much better use of an expert… and a much better reason to redesign the expertise queue.