Why AI Orchestration Doesn't Have a Key-User Pattern (Yet)

I have worked on enough ERP projects to know how the team usually forms itself. Before the project even starts, everyone already knows who the key users [1] will be. The finance person who lives in the ledger becomes the finance key user. The warehouse lead who runs the floor becomes the ERP key user for warehouse operations. The business gives you this team before you even ask for it. Decades of enterprise-system projects have made this pattern common knowledge. By go-live, everyone on the team already knows exactly what they own.

That does not mean building an ERP team is easy — even when everyone agrees on who the key users are, coordinating them, training them, and freeing up their time from a day job is real work. But an AI orchestration [2] team is a different kind of challenge, not just a harder version of the same one — starting with the word itself. "Orchestration" doesn't translate cleanly into most languages. The closest Polish word, "zgranie," really means something narrower, closer to "coordination." That's not just a translation problem. It's a sign that the discipline itself is still being defined, in English and everywhere else. On top of that, the roles are unfamiliar, and building this team well also means moving away from the typical hierarchical structure an ERP team can still lean on, toward something flatter and more flexible. That makes choosing the right people even harder, because you are not slotting someone into an existing box on an org chart.

I think most companies underestimate how big a problem AI orchestration actually is. It is a new discipline inside IT. In a typical manufacturing or distribution business, no existing job naturally grows into an "automation key user." Nobody's job title says "orchestration." There is no established pool of candidates, and no clear career path. What the role even needs can change again next quarter, because the platform itself keeps changing (Workato adding AI agents is just the latest example).

Good frameworks already exist for structuring a team once you have one. Workato's own onboarding methodology, OCP 3.0 [3], gives you a clean role chart: Sponsor, Platform Owner, Master Chef, Developer [4]. But none of these frameworks tell you where these people actually come from. And none of them tell you how to grow people once they are in the role.

I want to be honest about where I am writing this from. There are only a handful of people at Lightning ERP, and I don't have years of experience to draw patterns from either. What I do have is a bet: the right shape for an automation team is small and flexible, built around real work rather than a fixed hierarchy. I did not design it to match someone else's framework. I built it this way because it actually worked as we grew.

Let me borrow a real example. In August 2012, the trading firm Knight Capital Group rolled out new trading software. The rollout only reached seven of its eight servers — the eighth server kept running old test code from years before. When the market opened, that old code read the day's live trading signals as test signals. It started buying and selling millions of shares automatically, at bad prices. The engineers on duty did not fully understand the system in front of them, so their fix made things worse: they reverted the update on the other seven servers. Now all eight machines were running the broken logic at the same time. In forty-five minutes, Knight Capital lost $440 million and nearly collapsed overnight.

Nobody in the building that morning held the one role this whole article is about: someone who understood the system well enough to know what to shut off, and how. This is an old problem, really. Jacques Tati was already making comedies about it in 1958, in Mon Oncle, where nobody in the house understands the machine well enough to stop it before it breaks.

Spot, Pair, Renew

I think of building this team as three ongoing stages, not one single hiring event. The first stage is the hardest to describe as a "process" — because it is not really one.

1. Spot — take the person who's curious, not the résumé that matches.

Here is the practice, in plain terms. When someone shows genuine interest in how the automation actually works, I act on it. The signal looks like this: they ask questions beyond what they needed to know, they experiment with a recipe [5] on their own time, they want to understand why something works, not just how to use it. I do not look for a job title, a certificate, or a checklist of required skills — for this discipline, there is often no checklist to write yet.

This is harder to defend than a normal hiring process, so it is worth explaining why this is not just "going with my gut." Two things support it, and both came up independently in the training research behind this article — I was not looking for them, they simply appeared. First: material on digital-transformation talent argues that job titles are "insufficient" for judging this kind of talent, and recommends direct skills assessment instead. Second: agile team-building material makes a similar point from a different angle. It recommends recruiting for genuine interest in the mission, not for a matching CV — an idea often illustrated with the story of Shackleton, who is said to have picked his crew for a dangerous, poorly-defined expedition by looking for who truly wanted to be part of it.

The common thread: for genuinely new kinds of work, interest and follow-through predict success better than a CV written against a job spec that does not exist yet. This is really the deeper reason traditional HR sourcing struggles here: you cannot hire against a fixed list of requirements when the requirements change every few months. What you can assess reliably is curiosity and follow-through. So in practice: watch for it, don't post a job ad for it. The right person usually reveals themselves before you go looking.

One shortcut I actively avoid is age. There is a common assumption that only younger, digitally native people really understand AI. I do not agree, and neither do several people my own age that I have compared notes with. I have seen the opposite fail just as often: someone who grew up glued to a phone, comfortable with every new gadget, but with no real understanding of what AI can and cannot do, or where its risks actually are. Age is just another proxy [6] — and proxies are exactly what this section argues against.

2. Pair — put them next to someone who already knows.

Once someone is spotted, the fastest way to develop their skill is not a course. It is pairing: a new builder works on a real client project alongside a core architect or an experienced delivery partner, on a real recipe, with real consequences. This is also why I run projects as small pods [7] rather than routing work through one central queue. A pod gives a new builder a real place to learn by doing, with someone senior right next to them, accountable for the result.

I will not pretend I can give a clean number here — how long a pairing should run, or what ratio of core people to new builders is right. I do not have enough pairings behind me yet to know, and guessing would go against the whole point I am making: don't force a fixed rule onto something that does not have one yet. What I do rely on is an old, well-tested idea about how teams develop. Bruce Tuckman described four stages: forming, storming, norming, and performing [8]. In the "storming" stage, teams work through friction and disagreement before things click — and this stage has no fixed length. You know a pairing is finished the same way you know storming is over: not by the calendar, but by a real sign. The new builder can now handle a recipe alone, under real pressure, without me watching over their shoulder.

3. Renew — treat the role as a moving target, on purpose.

This is a stage that ERP teams don't need, but automation teams cannot skip. Once a finance key user learns Infor M3, the job stays largely stable for years. An automation builder's job does not. New connectors and new AI-agent capabilities appear every few months, not every few years. This means the team needs a standing habit of re-skilling built into how the work runs — not a one-time onboarding. That means regular time to retrain, and a clear way to flag when "the way we used to do this" no longer applies.

This is also where I add discipline back into a process that deliberately starts on instinct. Spotting someone for their curiosity does not mean skipping standards forever. It means the standard applies after selection, not before it. Everyone I bring in this way works toward Workato's own certification track [9] — not a badge I invented myself. Curiosity gets someone in the door. The certification is what confirms, using a recognized outside standard, that the instinct was right. It is also the same standard I hold my own core team to, as we work to close our own certification gaps.

The engine stays the same; the people inside it adapt

I want to keep two things separate, because it is easy to blur them together: how Lightning ERP is structured, and how I find the people who work inside that structure. These are not the same decision. They were not made at the same time, or for the same reason.

The structure is a small permanent core team plus a flexible network of delivery partners, organized around domains and Accelerators [10] rather than a fixed department chart. This structure was not improvised, and it did not come out of Spot, Pair, Renew. I borrowed it deliberately, from an operating pattern that leaders of real digital transformations had already proven elsewhere: small, cross-functional units with end-to-end ownership, instead of work passed through a siloed hierarchy. This is "the engine" [11], and it is built to stay constant even as everything running through it changes.

Spot, Pair, Renew is a completely different layer. It is how I find and grow the people who work inside that engine. Depending on the situation, what I adapt is the people, and how the domains and Accelerators are divided between them — not the engine itself. Encouragingly, when I later checked Workato's own onboarding methodology against the engine I had already built, it described almost the same shape back to me. That was confirmation, not the original blueprint.

In practice, adapting the people means resource balancing [12]: we look for the people we need wherever they are, matched to what a given client project actually needs, instead of sticking to one fixed location or one fixed way of dividing the work. Today, most people on a pod still cover more than one function. But that is already changing — as the team grows, roles are starting to specialize instead of everyone doing everything. Some of this sourcing runs through remote work and talent based outside Europe. I know this choice is viewed differently by different people. But it is made on the same basis as every other resourcing decision here: what the project needs, not where someone happens to sit.

Elevation, not replacement

The easy, wrong story about automation is that it takes someone's job away. The truer story is that it gives someone a second, more valuable job — but only if the company actually invests in developing them into it. That is the outcome worth building toward. It is also, honestly, the only version of this story that people will trust enough to actually take part in.

Building an automation team of your own? Lightning ERP helps manufacturers and distributors get Workato and Infor M3 automation running, and grow the people who run it.

Talk to us

Glossary

1. Key user — the person inside a company who knows one business area or system inside out, and represents it during an implementation project.

2. AI orchestration — using AI to connect and automate tasks across different software systems, so they work together without manual work.

3. OCP 3.0 — Workato's official methodology for onboarding a new customer onto its platform.

4. Sponsor / Platform Owner / Master Chef / Developer — the standard roles OCP 3.0 defines for a customer's automation team: executive sponsor, platform governance owner, senior architect ("Master Chef"), and builder.

5. Recipe — Workato's term for one automated workflow: a set of connected steps that move data or trigger actions between systems.

6. Proxy — a stand-in signal used to judge something indirectly (e.g., using age to judge AI skill, instead of testing the skill itself).

7. Pod — a small project team: typically one senior architect from the core team plus supporting builders from delivery partners.

8. Forming, storming, norming, performing — a well-known model of team development from psychologist Bruce Tuckman (1965). Teams first get to know each other (forming), then hit friction and disagreement (storming), then find a working rhythm (norming), and only then perform at their best (performing).

9. Certification track — Workato's official training and exam program that proves a person's skill level on the platform.

10. Accelerators — ready-made, reusable automation packages that can be applied quickly to new client engagements.

11. The engine (Lean Core + Flex Factory) — Lightning ERP's own operating model: a small permanent core team plus a flexible outside network of delivery partners.

12. Resource balancing — matching the right people to the right client project, regardless of where those people are located.

Author: Adam Grabowski