A small team whose job is not the tools. It is how the company works.
Rolling out licenses buys you a faster version of the same company. Rebuilding the handful of workflows where the transformation actually happens takes a dedicated team. This is that team.
Two jobs, and only one of them needs this team
The decision to build an AI team hides two different jobs. The first is getting tools into people's hands: licenses rolled out, a common set standardized, everyone able to log in. That is real work, IT can usually run it, and it buys you the same organization operating a bit faster. The second job is changing how the company actually works, which means picking apart specific workflows, rebuilding them around what these systems can do, and getting people to adopt the result. No license purchase gets you there. This team is for the second job.
The shape that makes four people enough
Five years ago this team would have carried a project manager, a scrum master, and a stack of junior developers under a couple of senior ones. Much of that existed to move information between people and prioritize work, because writing code was expensive. AI removes the purely connective and the junior roles, and what is left is small: four ICs and a lead.
What you want across those seats is overlap in the middle and spikes at the edges. Everyone understands enough of the adjacent seats to cover a gap or review a teammate's thinking. But overlap alone makes a team of generalists who each do a little of everything and none of it well, so each seat also holds a spike, a depth nobody else has. The overlap is what makes the team resilient. The spikes are what make it worth having.
Four ICs, each with a spike. One lead, looking up.
Everyone overlaps enough to cover a gap. Each seat carries a depth no one else on the team has.
- 1
AI enablement
One team at a time, with no-code and low-code tools. The fastest path to impact, and the office's favorite coworker in three weeks. The trap is staying one to one, so every session should leave a template behind. This seat is the AI Product Partner.
- 2
Forward deployed engineer
Embeds with a function and builds something bespoke. The hard part is not the code, it is finding which of the twelve steps are load-bearing and which only survive from 2019. The failure mode is a faster version of a broken process.
- 3
Platform engineer
Owns the hub, the internal app store, the thing that lets everything scale. Spots the pattern across projects and decides what becomes permanent, and sets the standard for how the team builds.
- 4
System engineer
The deep machinery: databases, connections, permissions, scale. Builds abstracted components used many times over, and code adaptable enough to swap the model in an afternoon instead of a rewrite.
- 5
The team lead
The only one looking up. Chooses which workflows are worth it (and says no a lot), wins the organizational sponsorship, and sequences the work in quarters so the platform exists before the applications that need it.
An engineer who takes the request at face value builds a faster version of a broken process. It is the most common way these projects produce something impressive that nobody uses.
So the work starts in the workflow, not the code, and the seat has to be willing to say the thing you asked for is not the thing you need.
The handoff is a filter
The seats connect as a filter. Every request enters at AI enablement, and most stop there, solved on the spot with no-code tools. What survives, the complex or multi-team work, goes to the forward deployed engineer, who assembles it from existing pieces when he can. Only genuinely new surface area reaches the platform engineer, and only what has to be built from scratch reaches the system engineer. The reason to run it this way is scarcity: deep engineering talent is the hardest thing here to hire and the easiest to waste, so by the time work reaches the bottom, three people who understand the business problem have already agreed it belongs there.
How it scales
When you need more capacity, the instinct is to grow evenly, an engineer for every enabler. That is backwards. Weight the growth toward the top of the funnel, two or three additions at the enablement and forward-deployed layers for every one below. Abstracted components mean a single deep-engineering seat serves a growing pile of applications without a matching increase in its own load, so it compounds. Enablement does not, it happens one team at a time and hits its ceiling first. When the team is underwater, the constraint is almost never a missing database engineer. It is that the queue of departments waiting for someone to sit with them has stretched to three months.
Staff the second job.
Decide which job you are funding. If it is baseline speed, IT can roll out the licenses. If it is changing how the company works, name the handful of workflows that matter and put a team of four on them, with a lead senior enough to say no.
Weight your first hires to the top, where impact lands first. The deep seats compound later, on the way to an AI-native biotech.