My Best Engineer Built an AI Workflow Nobody Else Uses. How Do I Fix That?

Direct answer: A great AI workflow trapped on one engineer's machine is the most common and most expensive failure in AI adoption. You fix it by making the pattern visible, lowering the effort to adopt it, and removing whatever made the person's own setup hard to copy. The goal is to turn one person's efficient pattern into the team's default, which is worth far more than any single workflow, because it is how individual wins become team capability.

Every engineering team I have looked at has at least one of these. A staff engineer, usually, who quietly figured out how to make a coding agent do something genuinely hard and reliable. A migration that used to take a week now takes an afternoon. A review workflow that catches the class of bug everyone else keeps shipping. And almost nobody else on the team is using it. The value is real and it is stuck, and the cause of the stall is structural rather than a matter of lazy or skeptical engineers. Once you can see the structure, you can fix it.

Here is the part most leaders have backwards. The reason a great workflow stays trapped is usually invisibility: nobody knows it exists, and the person best positioned to announce it has the least reason to. A pattern moves from one engineer to the team through three gates, and it dies at whichever gate is closed. The first gate is visibility: do other people even know the workflow exists. The second is legibility: can they understand what it does well enough to trust it. The third is effort: how much work is it to adopt, relative to continuing to do the task the old way. Trapped workflows are overwhelmingly stuck at the first gate, and almost every leader I talk to spends their energy on the third, building adoption tooling for a workflow the team has never heard of.

Start with visibility, because it is the cheapest to fix and the most commonly broken. The engineer who built the workflow has no reason to announce it. To them it is just how they work now. There was no launch, no message in the team channel, no ceremony, because from the inside it did not feel like an invention, it felt like Tuesday. So the workflow is invisible by default, and it will stay invisible until something surfaces it. This is exactly the kind of thing that hides from you if the only lens you have on AI usage is the aggregate bill, because in the aggregate this workflow is a rounding error. It is efficient. It barely costs anything. The expensive, flaky workflows dominate the number, and the quiet excellent one you most want to spread is the hardest to see.

Now legibility. Once people know the workflow exists, they need to trust it enough to change how they work. This is where naming the pattern helps more than engineers expect. "Marcus's migration thing" does not spread. "The two-step migration workflow that runs the codemod, then has the agent verify against the test suite" spreads, because it tells the next person what it does and why it works. Legibility is mostly a documentation and articulation problem, and it is worth the founder or the manager spending an hour to write it down properly, because that hour is what converts a personal trick into a team asset.

Then effort, the gate leaders overfocus on, and the overfocus is the expensive part. Watch what a team does when it decides to spread a workflow. It almost always builds tooling first. A shared template, an internal wrapper, a platform team ticket to productionize the pattern. That work assumes the binding constraint is how hard the workflow is to adopt, and it burns a sprint on the third gate while the first two sit untouched. With visibility and legibility handled, a proven workflow with a clear description is usually something an engineer copies in an afternoon, no tooling required. The sprint spent lowering adoption cost was spent on the barrier least likely to be the one holding the workflow back.

Underneath the three gates sits the reason any of this is worth a leader's attention, which is where a team's compounding advantage in AI actually comes from. A single excellent workflow saves one engineer's time. The same workflow adopted by thirty engineers saves thirty, and the second number is the one that shows up in how fast the whole team ships. Spread is the multiplier, and most teams pour their effort into building new workflows while the highest-return move is circulating the good ones already sitting on someone's laptop. The value trapped in existing unspread patterns is almost always larger than the value in the next pattern you have not built yet.

So the fix, concretely, is to run the three gates as a loop. Find the efficient workflows already working, which means having a way to see them that the aggregate bill does not give you. Make them legible by naming and describing what they do. Lower the adoption effort only where it is actually the binding constraint. And do this continuously, because your best engineers are building new quiet excellent patterns all the time, and every one of them starts life invisible.

Oberhahn was built to surface exactly these workflows, the efficient ones that hide in the aggregate, and show how widely each is being adopted, so the good patterns your team already has can spread on purpose instead of by luck. A live demo with sample data shows what that looks like.

Frequently Asked Questions

How do I get my team to adopt an AI workflow one engineer built?

Run three gates in order: make the workflow visible so people know it exists, make it legible by naming and documenting what it does, and lower the effort to adopt it only where that is the real barrier. Most workflows are stuck at visibility, not effort.

Why do good AI workflows stay stuck with one person?

Because the person who built it has no reason to announce it. To them it is just how they work now. It stays invisible until something deliberately surfaces it, and in an aggregate spend view an efficient workflow is a rounding error that is easy to miss.

Where does a team's compounding AI advantage come from?

From spreading the best workflows widely. One great pattern saves one engineer's time, and the same pattern adopted by thirty engineers saves thirty, which is the number that shows up in delivery speed. Most teams overinvest in building new workflows and underinvest in circulating the good ones they already have.

How do I find the efficient workflows worth spreading?

You need visibility into per-workflow usage and outcomes, not just total spend. Efficient workflows cost little and hide in the aggregate, while expensive flaky ones dominate the bill and draw all the attention.