The Contours of an AI Team

A note from Titus. Karl was my Executive Director of AI and Data Science at Avidity, and he is now Chief AI Officer in the Vigilance Division at Alloy Therapeutics. I asked him to lay out how you actually staff a team to do this work. The AI Product Partner is one of the seats on that team, and the engineering seats around it are what this new series is about. This is its opening piece.

So you’ve decided you want to get going with AI and need a team to do so. The first thing worth settling is what you want that team to do, because there are two different jobs hiding inside the question and they call for different investments.

The first job is getting tools into people’s hands. Rolling licenses out across the company, standardizing on a common set of tools, and making sure people know how to log in is worthwhile work, and IT can usually manage it without much outside help. What it buys you is some personal productivity and learning, the same organization operating a bit faster.

The second job is changing how the company works, and that’s a bigger and slower bet. It 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. Most biotechs end up needing both, tools rolled out broadly for baseline speed, and a small team going deep on the handful of workflows where the transformation happens. The team is for that second job.

The right size for that team tends to land at four ICs with a leader. Go smaller and you’re looking for too many different skillsets in one person. Go larger and you lose the ability to sit in a room and think through a problem together.

Those five seats are the whole of it, so here they are before the detail:

• AI enablement, getting no-code AI tools into people’s hands one team at a time.
• A forward deployed engineer, embedding in a function to build the bespoke thing it needs.
• A platform engineer, owning the hub that lets everything else scale.
• A system engineer, building the deep machinery underneath.
• A team lead, choosing which workflows are worth it and winning the room to do them.

Each one exists because the job it does cannot be borrowed from the seat beside it. The rest of this piece is what each is, and why.

The new shape of the roles

What makes a group that small viable is that the roles themselves have changed. If you’re picturing the software team you’d have assembled five years ago, it would have included a PM, a scrum master, a few junior developers supporting a couple of senior ones. Much of that structure existed to move information between people and prioritize the work because writing code was expensive. AI allows you to remove the purely connective and the junior roles.

What you want in the roles is overlap in the middle and spikes at the edges. Everyone should understand enough of the adjacent roles to cover a gap, review someone else’s thinking, or carry a project one step further than their own seat strictly requires. But overlap alone produces a team of generalists who can each do a little of everything and none of it well. Each seat needs a spike, a depth that nobody else on the team has, running from someone who understands the business and can teach people to use no-code tools, to someone capable of architecting a backend. The overlap is what makes the team resilient. The spikes are what make it worth having.

The four seats

AI enablement. This seat is the AI Product Partner, the role Titus has already written up, so I will not relitigate it here. This person works hand in hand with individual teams to figure out where no-code and low-code AI tools solve a problem worth solving. Their value isn’t to scale the process, they work one person or one team at a time, but they have the fastest path to impact. This is the person who becomes the office’s favorite coworker in about three weeks.

Much of the job is training, and the good version of it looks less like a lunch-and-learn than like an apprenticeship. Sitting with someone while they work through a problem they care about teaches far more than a slide deck on prompting, which is why the work is slow and why it sticks. The trap is letting all of it stay one to one. Every session should leave something behind, a short guide, a worked example, a template someone else can pick up, so the second person with the same question can be handed an answer rather than an hour on the calendar.

The other underrated part of this seat is broadcasting. Because they are the only person circulating through every department, they are the only one positioned to tell finance that clinical ops solved this exact problem last month. Left alone, companies build the same thing three times and nobody notices. A running internal record of what has been built and who to ask about it is worth more than it sounds, and this is the person who keeps it.

Forward deployed engineer. Palantir made this model famous, an engineer who embeds directly with a business team and builds something bespoke for the workflow in front of them. Compared to AI enablement, the FDE can take on harder problems and has more tooling flexibility, at the cost of some speed, which makes this the seat you reach for when a problem is worth that tradeoff.

What separates this seat from a normal engineer is that the hard part is not the code. The FDE spends a meaningful share of their time sitting with the regulatory team or clinical ops, watching how the work happens, and figuring out which of the twelve steps in a process are load-bearing and which exist because someone set it up that way in 2019. The people doing the work often cannot tell you this, not because they are being difficult, but because nobody has asked them to examine it in years.

This is also where the failure mode lives. An engineer who takes the request at face value builds a faster version of a broken process, which is the most common way these projects produce something impressive that nobody uses. The FDE has to be willing to come back and say the thing you asked for is not the thing you need, and have enough credibility with that team to be believed. Hire for the willingness to sit in someone else’s workflow for two weeks before writing anything.

Platform engineer. Somebody has to own the platform itself, the hub, the internal app store, the thing that lets everything else scale. Part translator and part glue, this is also who the team leans on when demand spikes. They keep an overhead view across every application being built, which lets them spot the capabilities that need to exist before anyone else notices the pattern. If three or four applications all need to schedule activity, the platform engineer catches that overlap and hands it to the system engineer to build once instead of four times. They think in reusable components, and in how fast and how consistently the team ships code.

The other half of this seat is judgment about when to build something permanent. Not every capability that shows up twice deserves to become part of the platform, and a person who promotes everything ends up maintaining a sprawling library that nobody uses. The platform engineer has to sit with a request and decide whether it is a passing need or a pattern, which requires enough distance from any single project to see the whole portfolio, and enough contact with the business to know which departments are about to need the same thing.

They also set the standard for how the team works. Because the FDE and the enablement seat are moving fast and building things that will outlive their original use case, somebody has to decide what good looks like, which tools everyone builds with, how things get documented, and what has to be true before something gets deployed. That sounds like bureaucracy, and done badly it becomes exactly that. Done well it is the difference between a team where any member can pick up someone else’s project and one where every application has precisely one person who understands it.

System engineer. This is the deep technical seat, the person who builds the machinery everything else runs on. Databases that hold your data, the connections between systems that let one tool talk to another, the rules governing who is permitted to see what, and the capacity to handle a hundred people using something at once rather than one person testing it.

The most important habit in this seat is building components that are abstracted. An abstracted component is a piece of machinery built once, general enough that many different applications can plug into it without knowing how it works inside. A light socket is abstracted. You screw in whatever bulb you want and the wiring behind the wall never changes. The alternative is a system engineer who builds a scheduling function for the regulatory team’s application, then a second for clinical ops, then a third for the lab. Three times the work to maintain, three places for something to break, and no leverage from any of it.

The second habit is writing adaptable code. Whatever model your applications are built around today will be surpassed within a year or two, and your team will want to swap it out. If a vendor’s specific setup is hardcoded into a dozen places across your applications, that swap becomes a rewrite and a budget conversation. If everything routes through one layer designed to be changed, it becomes an afternoon of work. The system engineer is the person whose choices determine which of those two situations you’re in, usually eighteen months before anyone notices it mattered.

Team lead. The four seats above are tactical. They are heads-down on the problem in front of them, which is where you want them, but it means nobody in that group is looking up. The team lead is the person who does.

Their first job is strategy, deciding which workflows are worth the team’s attention and which are not. A four-person team can take on maybe a handful of meaningful projects a year, so choosing the wrong ones is expensive in a way that’s hard to see until the year is over. That means saying no frequently, including to executives with a pet project.

Their second job is organizational alignment. This team touches every function in the company, and every function has its own priorities, its own budget, and its own reasons to be skeptical. Somebody senior enough to sit with the head of R&D or the CFO has to build the case for why a team is embedding in their department, secure the sponsorship to make it stick, and handle the political friction that comes with changing how people work.

Their third job is planning and roadmapping. Where the tactical team is thinking in weeks, the lead is thinking in quarters, sequencing work so the platform pieces exist before the applications that need them, forecasting when the team will run out of capacity, and making the case for the next hire before the shortage becomes a crisis. You can technically get away with one of the four carrying this part-time if they’re senior enough, but the strategic work is the first thing to get dropped when a deadline gets tight, and it’s the part with the longest lag between neglecting it and feeling the consequences.

Handoffs and collaboration

The way these seats connect matters as much as the seats themselves. Think of it as a filter, where every request enters at the same place and only the ones that need deeper resources travel further down.

Every request goes to AI enablement first. A large share of what comes in is training, or an individual workflow, or something one team wants that doesn’t need to work anywhere else. Those get handled on the spot with low-code and no-code tools like Claude Cowork or OpenAI’s Codex, and they never travel further than the first seat.

What survives that filter is the more complex work, or a workflow spanning several teams that needs something purpose-built. Those go to the forward deployed engineer. If the request is close to something the team has built before, the FDE assembles it from existing pieces and the chain ends there, which is the outcome you want most of the time. Duplicating a known pattern is cheap and fast.

Only when there’s new surface area, a capability the platform doesn’t have yet, does it reach the platform engineer. Their call is which structural elements the new thing should be built from, what can be reused, and what needs to be constructed from scratch. Whatever falls into that last category gets handed to the system engineer.

The reason to run it this way is resource scarcity. Deep engineering talent is the hardest thing on this list to hire, the most expensive to keep, and the easiest to waste. A system engineer spending their week on a request that a no-code tool could have handled is the most costly mistake a team this size can make repeatedly. The filter exists so that by the time work reaches the bottom, three people who understand the business problem have already agreed it belongs there.

Why the small team wins

This works better on paper than it probably should, for a few reasons. The overlap in skills builds in some redundancy even at four or five people, someone gets sick, someone leaves, and the team keeps functioning. Having all four in a room on one hard problem also means the group can take on complications that would otherwise need a much larger team. But the biggest reason is probably visibility, the whole team carries full context on the problem from day one.

Compare that to how most enterprise AI projects stall out, where the customer-facing person hands off to a prototyping team, who hands off again to a production team, and something gets lost at every step along the way. This model skips that gap, not because the handoffs disappear, but because they happen between four people who were in the same room from the start.

Where to go from here

Assume this works and you need more capacity. The instinct is to scale the team evenly, adding an engineer for every enablement hire, but that gets the ratio backwards. Growth should be weighted heavily toward the top of the funnel, roughly two or three additions at the enablement and forward deployed layers for every one at the platform and system layers.

The logic follows from how the work is built. If your system engineer has been abstracting components properly, each piece they finish serves many applications rather than one. A scheduling capability built once gets used by the regulatory application, the clinical ops workflow, and the two things nobody has thought of yet. The deep engineering work compounds, so a single person at that layer can support a growing number of applications above them without a proportional increase in their own workload.

The people building workflows and training teams don’t get that leverage. Their work is inherently one at a time, which means they hit their ceiling first. When your team is struggling to keep up, the constraint is almost never that you’re short a database engineer. It’s that the queue of departments waiting for someone to sit with them has stretched to three months.

As you build this team, remember that the hardest part of AI transformation won’t be the technology, it will be the change management. Which means the job doesn’t end at the offer letter. Think hard about what these five people will need from you once they’re in the building, because a team with the right skills and no organizational cover will spend its first year proving it deserves to exist.

Best,
-Karl