As AI reshapes delivery, deep expertise takes years to build yet often concentrates in a few people. This article makes the case for the forever team: a model where capability is grown, circulated, and renewed across the team, so depth belongs to the team rather than any one person.

Here is something I have come to believe about building teams: as they get leaner, the cost of misreading a person rises sharply. The strongest contributor and the one labeled difficult can look alike from a distance, and telling them apart, and knowing what to do about it, is becoming one of the most valuable things a delivery lead can get right. This piece is about designing a team where that judgment, and the expertise behind it, is not concentrated in any one individual.

Why expertise, not headcount, decides if a team is staffed

In specialized delivery, expertise is not a resource you plug in and out. On products like Adobe Commerce, the depth that lets a team move fast and get complex work right is built over years of hard engagements: an investment leaders make in their people, one client problem at a time. When that investment concentrates in one or two people, it becomes both the team's greatest asset and its greatest exposure.

AI is changing what a delivery team can do. We can get more done with fewer people now, but that gain only holds if the team carries real depth. A team without deep expertise operates as if understaffed, whatever its headcount; a team that carries it will outperform a much larger one that does not. The catch is that depth is the hardest thing to staff for. Documentation captures what a person knows, but not what they can do: the judgment, the pattern recognition, the instinct for where a build will break. That layer determines outcomes, and it is the one most easily lost.

That is why I think the model of a delivery team should be a forever team: an expert team designed to renew its own capability, so depth becomes a property of the whole team rather than something a few people hold, and the team keeps performing as roles and missions shift around it.

A model built on three layers

Most delivery organizations already run parts of this. Mentoring happens, planning for who steps up gets discussed, someone keeps a mental list of who could grow into more. What a forever team adds is not a new practice but a single design: a way of seeing everything a team needs built or enabled as one connected model, so the pieces reinforce each other instead of running as separate efforts. It names where expertise needs to be built, and organizes the team to build it, in one place.

The model rests on three things: what an expert knows, what an expert can do, and how they build more of it. The first two are what a person carries; the third is how the carrying grows.

Carrying forward what an expert knows

This is the knowledge layer: architecture decisions, integration context, the reasons behind past choices, the workarounds that usually live in one person's head. Making this explicit and shared is the foundation, but on its own it produces informed people, not capable ones.

Carrying forward what an expert can do

This is the capability layer: product depth, customer-centric thinking, problem-solving instinct, speed, and attention to detail. These are built through mentoring and practice, not documents. A peer mentoring structure, where experienced practitioners actively develop others, is how this layer grows.

What the team looks like

The shape is simple, and the diagram lays out how it fits together.

A team lead at the center, and the title matters: team lead, not permanent lead. The role anchors and oversees, but it is built to be handed on. Around it, expertise flows in two directions: inward, where peer mentor leads grow the team's own capability, and outward, where a readiness bench applies that depth to leadership and cross-functional teams. Underneath runs a renewal loop that keeps producing the people who fill these roles.

Two things are worth pulling out of the diagram. First, the two roles are a matched pair defined by direction: one grows capability inside the team, the other puts it to work outside it, and both draw from the same pool the loop produces, not a separate reserve. Second, none of this is a management layer. The lead does their own deep delivery work; the mentors mentor while delivering; the bench serves while practicing. Every part of the model is carried alongside the work, as part of being a senior expert, not instead of it.

How the team keeps producing its own leaders

The renewal loop is a genuine cycle, not a one-way pipeline. A mentee becomes a mentor; a mentor becomes a ready-state next lead, the backup, ready to cover the role when needed or take it on when the lead moves forward. Whoever holds the seat, it is never permanent: whoever takes it begins growing the next ready lead behind them, and keeps mentoring rather than leaving the cycle. Everyone is already somewhere in it, usually both learning and developing someone else at once.

A word on what these stages mean. They are not a ranking of people, and being a mentee is not a signal that someone needs fixing. They are roles anyone moves through, repeatedly, as the ground shifts. When a new technology emerges, whether Adobe Commerce as a Cloud Service (ACCS), Edge Delivery Services (EDS), or whatever comes next, even the most senior expert becomes a mentee in it, not because they have fallen behind but because the field has moved. Which role a person holds at any moment reflects what the team needs to develop next, not a judgment of where they stand. In a field changing this fast, everyone is cycling through these stages continuously.

Because the loop keeps producing ready people, there is never one fragile point of dependence but several ready leads at once. That is what turns the team's depth from a fixed asset that depreciates into a renewable one: each person's growth produces the next person's.

Building capability through real work, not instruction

The fastest way to build a capability is to be placed where it is required, with a mentor supporting you through it. Someone who needs confidence with ambiguity grows by owning something ambiguous, coached in real time, rather than by being told about it. Placement turns growth into something that happens through the work itself.

Three things keep placement from becoming a stress test. First, diagnose before you place: is the gap a skill gap, a way-of-working gap, or a confidence gap? The right placement differs by type. Second, make the reason explicit, so the person knows they are placed there to grow, not because they are seen as lacking. Third, define what "grown into this" looks like, so the placement has a visible finish line rather than becoming an open-ended label.

The frustration that is often a capability gap

One pattern is worth naming on its own, because it is easy to misread. When someone brings persistent frustration to task after task, it is tempting to read it as attitude. Often it is something else: a capability gap the person is quietly compensating for. The frustration is a signal, not a shortcoming.

It rarely announces itself as a skill gap. It looks like impatience, or pushing back on process, or going quiet when a task moves outside a comfort zone. The tell is that it shows up regardless of the work, which is the clue that the task in front of them is not the real problem.

Reading it that way changes what you do about it. Instead of managing a behavior, you identify the underlying gap and place the person where it gets built, with support, not exposure alone. Some of the strongest contributors on a team are people whose early friction signaled they were operating just past their current depth, and who became excellent once that depth was deliberately built. A forever team is designed to catch that signal and act on it, rather than let it harden into a label.

The expert's role is widening

This model is not afraid of a leaner team or a faster pace. It treats both as reasons to grow, not to protect. Anyone who worked in the startup days remembers wearing many hats, and building range because of it. That instinct is worth recovering. As AI makes single-skill work more efficient, the value of being only a developer, only an architect, or only a requirements analyst compresses. What grows in its place is range: the expert who also enables, coaches, and co-develops the expertise of the people around them while still doing their own deep work.

As more of the routine technical work is handled by AI, this range is exactly what a person uniquely brings: the judgment, the coaching, the ability to grow others that a tool does not replicate. Expertise is no longer just something you apply. It is something you extend.

Why this matters now

AI is letting delivery organizations do more with fewer people, and that makes deep capability more important, not less; as teams get leaner, each person carries more of the whole. At the same time, AI is opening new roles and kinds of work that did not exist a few years ago, and the strongest practitioners are drawn toward them, as they should be. Both forces point the same way: toward teams that renew their own expertise rather than depend on a few people holding it.

That is the case for the forever team. Not as a safeguard against any one person's move, but as the operating model for how specialized delivery works when AI lets a smaller team carry the ambition of a larger one.

Underneath the structure is a mindset, and it may be the real shift the AI era asks for. In a forever team, advancing the delivery organization and growing yourself are not in tension, and neither sits above the other. They are the same motion: as you extend your expertise to others, the team gets stronger, and as the team gets stronger, you grow with it. The teams that thrive through rapid change will be the ones whose people stop treating those as a trade-off.

The experts will always change. That is not the risk to manage; it is the environment we work in now. The expertise is what has to stay. A forever team is simply a team built so it does.

FAQ

How is this different from just planning who replaces whom?

Planning for replacements names who steps in when a role opens. A forever team builds capability continuously across everyone, so readiness is a standing property of the team rather than a plan that activates only during a transition.

What if someone does not want to mentor?

Mentoring in this model is framed as advancement, not extra work, a marker of growing into someone who develops other leaders. It is carried alongside a person's delivery work, not bolted on top of it, and when it is positioned and recognized that way, it reads as a step up rather than a tax on people's time.

How do you tell a skill gap from a genuine attitude problem?

Look at the pattern. Frustration that appears across nearly every task, regardless of the work, more often points to a capability gap being compensated for than to the task itself. Targeted placement with support tends to resolve the former quickly, which also helps you tell the two apart.

Does building capability across the team slow delivery down?

In the short term, mentoring and placement take attention. Over any real horizon, a team whose depth keeps renewing delivers faster and more reliably than one that depends on a few irreplaceable people and stalls whenever the work exceeds their bandwidth.

What does the readiness bench actually do?

It points expertise outward, to leadership and cross-functional teams, where peer mentoring points it inward. Both draw on the same people the team keeps growing. The idea is that depth should not only accumulate inside a team; it should also be available to the organization around it.

Where does AI fit in a forever team?

AI is what lets a team do more with fewer people: it handles more of the volume so the team can focus on the high-judgment work. The forever team is how you make sure the team still carries the judgment the work demands, at whatever size it operates.

Actionable takeaways

Name the depth you cannot afford to lose, then start growing someone into it. You do not build this by reorganizing everyone at once. Pick the one capability that currently lives in a single set of hands, and pair someone with them on real delivery work, not a briefing, actual work where the capability is exercised.

Read chronic frustration as a signal before you read it as attitude. When someone brings friction to task after task regardless of the work, look for the skill or confidence gap underneath it, and address that rather than managing the behavior.

Treat mentoring and enabling as part of the senior role, not extra work. Expect your most experienced people to grow others and extend their expertise outward, to teammates, to the organization, and to the AI they now direct, while still doing their own deep work.