Match AI programme ambition to working-team capability
AI programme designs that look right on paper depend on the working team's technical confidence to execute; calibrate the design to the team you have, not the team the design assumes.
A common failure mode in AI advisory work is recommending the right programme design for the wrong team. The standard structures — committee, delivery cell, knowledge-manager role, governance review cadence — each presuppose a working group capable of operating them. Programme designs are usually evaluated on their internal logic; the team that will run them is treated as a fixed input. It isn’t.
Two engagements at comparable mid-tier firms make the dependency visible. Same advisor, broadly similar programme design, materially different outcomes. The first ran a roughly ten-member cross-functional committee with mixed seniority and uneven technical confidence; rich discussion, little delivery, eventual pivot to a small cell (A mid-tier firm’s pivot from AI committee to delivery cell). The second ran a five-member senior and technically-confident committee; informal platform consensus in approximately thirty-six hours of hands-on access, executive sign-off on track within weeks. The programme design was not the load-bearing variable. The team’s technical confidence — its ability to engage substantively with platform features, skill-building and architecture decisions — was.
The heuristic is to read the team before committing to a programme design.
Assess working-team technical confidence honestly. Can members hold a substantive conversation about feature differences between platforms? Can they build a small skill on first attempt? Will they engage with architectural questions about knowledge bases and connectors, or do those conversations bounce off?
Calibrate the design to what the team can run. A team that can deliver doesn’t need a deliberative committee to plan delivery — it can be the delivery cell from the start, sidestepping the dynamic Separate deliberation from delivery in AI initiatives addresses after the fact. A team that can’t yet deliver needs a different programme: more advisor-led delivery, smaller initial scope, more time on building working-team capability before scaling ambition.
Don’t assume capability will arrive on the schedule the design needs. Technical confidence grows through doing, not through training events. A team that lacks it at the design stage will not reliably acquire it during execution. This is the working-team counterpart to Leadership team AI fluency must be collective, not individual — neither layer’s fluency is a given, and a design that assumes either is fragile.
The same calibration-to-actual-people rule operates at interaction scope as well as at programme scope. A single onboarding encounter can fail in the same way a programme design can — by assuming a user the encounter does not have. See AI onboarding teaches both the person and the AI for the interaction-scope form.
This is not an argument against ambition. It is an argument against programme designs whose preconditions go unexamined.