Your Issue Is Not Unique

A support operation I worked with had a routing problem they could not name. Cases were piling up in the wrong agent inboxes. Senior agents were handling tickets a junior could have closed in five minutes, while a backlog of genuinely complex cases sat with people who escalated them anyway. The team described it to me in their own vocabulary: tier-1 versus tier-2, skill tags, escalation rules, the manager’s morning re-shuffle. Every solution they had tried was inside that vocabulary. New tags. Tighter rules. A different escalation matrix.

The problem was not a routing problem in their sense. It was a scheduling problem in the sense the operations research literature has used for sixty years. Incoming cases of varying complexity arriving at unpredictable intervals, agents with non-uniform service rates, a need to minimize total time-in-system without starving any class of work. The moment we stopped calling it “routing” and started calling it a queue with heterogeneous servers and priority classes, the existing answers showed up. Little’s Law for the steady-state math. Shortest-expected-processing-time for the assignment rule. A small dose of priority aging so the hardest cases did not languish. None of this was novel. All of it was solved before any of us were born. The team had been trying to invent it from scratch because they did not know it had a name.

This happens constantly. The hardest part is almost never the solving. It is recognizing that someone else already did the solving and used different words for it.

Fluency Hides the Shape

The instinct is to assume domain expertise makes you better at this. It does the opposite, in the part that matters.

When you are deep in a domain you have a precise vocabulary for everything in it. Tier-1 cases. Reseller margin. SLA breach. Onboarding cohort. That vocabulary earns its keep most of the time. It lets you speak quickly with your team, capture nuance, signal experience. But it also welds your problem to its specific framing. The words you reach for first are the ones that describe what makes your situation yours, not the ones that describe what makes it like everyone else’s.

The shape of a problem lives under its vocabulary. A queue is a queue whether the items are cases, packets, patients, or planes. A feedback loop is a feedback loop whether you are calibrating a thermostat, a forecasting model, or a sales-quota target. Domain expertise is what makes the surface differences feel important. It is also what hides the structural sameness underneath.

I think this is why the people who solve these problems fastest are often not the most experienced people in the room. They are the ones who have moved between enough domains to have stopped trusting their first vocabulary. They translate before they search.

Borrowing From Other Fields

Once you start looking for it, cross-field borrowing becomes a tactic you can practice deliberately. A few of the trades I have watched pay off in operational settings.

Anything that involves items arriving, waiting, and being served is a queueing problem. Support tickets, code review backlogs, approvals waiting on a manager, customers in an onboarding pipeline. The queueing literature gives you arrival rates, service-time distributions, utilization ceilings, the cost of running near capacity. It also tells you, with math, why the “we need to push the team harder” instinct fails past about 80% utilization.

Distributing work across workers with different capacities is a load-balancing problem. The web infrastructure world has spent twenty years refining strategies for it. Round-robin, least-connections, weighted random, consistent hashing. The vocabulary translates almost directly onto sales-territory assignment, case routing, or shift scheduling. You do not need to reinvent the wheel; you need to know the wheel has a name.

If you are adjusting a system based on its output and trying to land on a target without overshooting, you are in control theory. Pricing experiments. Hiring against a headcount plan. Promotional spend against a CAC target. The PID controller has been the workhorse of industrial automation for nearly a century. Most of the lessons it teaches about lag, oscillation, and integral windup transfer cleanly to any business loop where you are tuning an input to chase an output.

Game design has a literature on motivation and progression that is more rigorous than most corporate “engagement strategy” work. Ecology has models of carrying capacity and predator-prey dynamics that map onto market saturation and competitive response. Epidemiology has decades of work on diffusion through networks that applies to feature adoption, internal tool rollouts, and how policy changes spread through a sales org.

The point is not to become an expert in any of these. The point is to know they exist, so that when your problem starts to smell like one of them, you know where to look.

Natural Language Finally Closes the Gap

The reason cross-field borrowing was a niche skill for so long is that the search infrastructure penalized it heavily. To find the queueing-theory answer to your support problem, you had to already suspect it was a queueing problem. Then you typed queueing-theory keywords into a search engine and parsed academic papers written for an audience you were not part of. The vocabulary gap was the gap. If you did not know the words, you could not find the answer that used them.

This is the part AI changes most concretely. You can describe the shape of your problem in your own words, with all the messy operational context attached. Then you ask whether anyone in any field has worked on something structurally similar. The model has read enough of the corpus to recognize the pattern under your vocabulary and name it back to you. Often it will offer two or three candidate framings, each from a different field, and you can pick the one that fits.

That capability is genuinely new. Old search demanded the answer’s address up front. The new mode lets you describe the building from the outside until someone tells you where to find it.

Used well, it collapses the abstraction step from a skill that took years of cross-domain reading to one that takes a careful paragraph.

The Trap Hidden in That Capability

The same capability is also the most dangerous part.

If you describe your problem in narrow, domain-specific language, AI will happily produce a narrow, domain-specific answer for you. It will not push back. It will not say “this is a queueing problem and there is a fifty-year literature on it.” It will give you a plausible, bespoke-looking response tailored to the framing you handed it. That response will often be good enough to ship. It will rarely be as good as the known general solution would have been. You will not know what you missed, because you never asked the question that would have surfaced it.

The risk gets worse the more competent the model is. A weaker tool produces obvious garbage when you ask the wrong question. A stronger one produces polished answers that hide their narrowness. You read the output, it sounds right, and you move on. The fact that an entire field already solved this never enters the conversation, because nothing in your prompt invited it to.

The defense is abstraction first, query second. Before you ask the model how to solve your specific problem, ask it what general class of problem this is. Ask whether any other field has worked on something with the same structure. Ask for the names of the patterns it resembles. Then go look at those patterns and decide whether the general solution fits before you commission a custom one.

This is the same move good engineers used to make at the library, and good consultants used to make by calling someone in an adjacent industry. The tool is faster now. The discipline is identical.

Four Teams Built the Same Two Things

I watched this play out at an offsite. The brief was open: take a week, find a way to fold AI into how your team works day to day, present what you built on Friday. Small teams, no shared plan, little coordination by design. The point was to see what people reached for when you handed them room.

By Friday there were not six different projects. There were two, built four times.

Half the teams had built a dashboard of some kind. The commercial team called theirs a reporting tool, the partnerships team called theirs a pipeline view, but under both labels sat one need: reach the data faster so the next move with a customer or partner is informed instead of guessed. Nobody used the same words. Everybody built the same thing.

The other half had built capture. Engineers had noticed that the most valuable output of a hard week was not the code, it was the reasoning: the back-and-forth with the model that took them from a vague symptom to a root cause. They built ways to save that thread, hand it off, and let the next person see how the conclusion was reached instead of inheriting only the conclusion. Different teams, different tools, one shape: make the path to an answer visible to whoever needs it next.

Nobody set out to converge. The convergence is the evidence. When four independent teams land on two problems, those were never four teams’ problems. They were two shapes the whole organization carried, wearing four sets of local vocabulary.

The part that matters for this piece: the sameness was invisible until Friday. Each team spent the week certain its problem was its own. It took standing them next to each other for the shared shape to surface. The presentations did the abstraction no single team had done alone.

The Dashboard Should Be a Query

Look closer at what those teams built and a second lesson shows up. Most of it was not an AI solution at all. A dashboard that pulls numbers and arranges them on a screen is deterministic. It is a SQL query and a render. There is no judgment in it that needs a model at runtime, no ambiguity for a language model to resolve. The intelligence was spent on the way in, not on every run.

What the model did was help each team find the exact dashboard they needed, in an afternoon instead of a sprint. That counts, and it is the discovery half of the work. The output was a one-off HTML file that proved the shape. The shape was right. The artifact was a prototype.

The mistake is to confuse the two and ship the prototype. A file generated inside a chat is not a system. It does not run on a schedule, it does not flex when the team’s question shifts next month, and if a model stays in the loop at runtime it burns tens of thousands of tokens to produce a table a query would return for a fraction of a cent.

The next challenge, the one the offsite did not have time to reach, is conversion. Take the spec the prototype encodes and graduate it into something deterministic that runs cheaply, predictably, and with the flexibility the team needs. Deciding which parts keep the model and which parts become plain code is an architecture decision, the same one the previous arc was about. The model found the requirement. Architecture decides the runtime.

The Throughline

In the previous piece I argued that the upstream skill is describing problems at the right level. This piece is about what makes the right level reachable. The right level is almost always the abstract one, the one where someone else’s solution already lives. Getting there means stripping your own vocabulary off the problem long enough to see its shape.

That is half of the loop. The other half is the mirror image, and it shows up in the next piece. When you solve something, describe it at the abstract level too, so that the next person whose problem rhymes with yours can find it. Abstraction is how you reach the work others have already done. Sharing is how you put your work where others can reach it. The arc only closes if both halves are happening.

Most of the things you are trying to figure out have been figured out. Maybe not in your industry, maybe not in your vocabulary, maybe not on the first page of your search results. But somewhere, by someone, often a long time ago. Your job is to describe the problem well enough that you can find them.

If you want help teaching your team to recognize when their problem is a known pattern in disguise, reach out at hello@escapecommand.com.