The podcast that this series draws on carries the title "FDE: The $1M/Year AI Job Explained". In it, Vasuman Moza describes the rare person who combines consulting-grade communication with deep software engineering as worth up to a million dollars a year. That figure is the episode's headline and the guest's own claim. It is not a salary benchmark: independently reported figures sit well below it, and compensation varies by market, company, equity, seniority and commercial impact.
The more useful question is what makes the work valuable in the first place. Forward deployed delivery needs someone, or some team, to:
- discover real work and organisational constraints;
- translate between executives, practitioners and engineers;
- make architecture and product trade-offs;
- build production software;
- design evaluation and evidence;
- lead adoption and operate the service;
- turn field learning into reusable product capability.
Very few people are equally strong at all seven. An organisation that bets its delivery on finding one who is has a hiring plan, not a delivery model.
Sandveld Foods and Ironbark Digital are fictional, and their systems and figures are illustrative. Ironbark's forward deployed lead at Sandveld was a strong former solution architect, and for the first two months of the engagement almost everything ran through that one person: the operating map, the integration decisions, the conversations with the AP manager, the evaluation thresholds and most of the CFO updates. It worked, until the lead took a week of leave during the shadow period and three decisions waited for their return.
The forward deployed pod
The answer is a team with a clear lead, not a lone hero.
| Role | Core responsibility |
|---|---|
| Forward deployed lead | Owns the client outcome, the operating map, decisions and delivery coherence |
| Product or business owner | Owns priority, adoption, policy and realised value |
| AI or software engineer | Builds orchestration, services, interfaces and tests |
| Solution or integration architect | Owns system boundaries, non-functional requirements, integration and transition architecture |
| Domain expert | Defines real decision quality, exceptions and acceptable practice |
| Data or knowledge engineer | Prepares governed data, retrieval, provenance and quality |
| Security or risk specialist | Defines identity, data, action and assurance controls |
| Evaluation or quality engineer | Builds datasets, tests, release thresholds and production monitoring |
| Service or operations owner | Owns support, incidents, capacity, recovery and change |
Small engagements combine roles; one person can hold several. High-risk work still needs independent challenge and a named approval authority, which means the person building the evaluation should not be the only person deciding whether it passed.
Ironbark's fix at Sandveld was modest. It brought in an evaluation engineer from week five, who took over the golden set and the release thresholds from Part 4. The lead started writing decisions down in the design record from Part 3 rather than carrying them, so that the AI engineer and the integration architect could act on them without asking. Sandveld's senior AP clerk was formally named as domain expert, with time set aside for it, rather than being consulted when someone remembered. None of this made the lead less important. It made the lead's judgement available when the lead was not in the room.
A hub-and-spoke practice
One pod can deliver one engagement. A practice that runs several needs a structure that stops each pod rebuilding the same plumbing.
- A central platform hub provides approved model access, identity patterns, tool gateways, observability, evaluation services, deployment templates, security controls and reusable connectors.
- Forward deployed pods work with business units or clients, adapt the platform, and own outcomes.
- A product feedback mechanism decides which local solutions become shared platform features and which stay client-specific.
- An assurance and design authority reviews high-risk architectures, material exceptions, and changes to approved patterns.
Without the hub, every pod rebuilds plumbing and margins fall. Without the pods, the platform drifts away from real work.
Ironbark runs three pods off one platform team. The feedback mechanism is a fortnightly review where pod leads bring field needs and the platform team decides what to absorb. Sandveld's fresh-produce weight tolerance went through it: a rule a single clerk had carried in their head became, after discovery, a configurable tolerance setting in Ironbark's product, available to the next client with a perishable supply chain. The evidence layer the hub provides, traces, cost receipts and evaluation results, is the same one described in The Agent Evidence Layer, and it is what lets a pod explain its results to a client without building reporting from scratch each time.
The same structure works inside a large organisation with no external provider at all. Replace "client" with "business unit", and the platform hub is an internal AI platform team. The agentic AI operating model covers that version in more detail.
Measure the team, not the hours
Measuring forward deployed engineers on billable time, prototype count or coding speed rewards exactly the behaviour that sank Sandveld's first AI purchase. A balanced scorecard looks more like this:
- time from discovery to the first measured value;
- the share of deployments that reach stable production;
- adoption and task completion;
- quality and human correction rates;
- cost per successful outcome;
- incident and recovery measures;
- client-specific code reduced through reusable assets;
- platform improvements that originated in field evidence;
- handover, and the client team's capability to run the service.
The last item is the one most often missing. A forward deployed team that leaves behind a client unable to operate what was built has created a dependency, not a capability.
Career pathways
Several backgrounds lead into forward deployed work. Each brings a strength and a gap.
| Starting background | Existing strength | Capability to build |
|---|---|---|
| Software engineer | Code, systems and debugging | Discovery, business value and executive communication |
| Solution architect | End-to-end design and stakeholder alignment | Deeper coding, evaluation and production ownership |
| Business analyst | Process discovery and requirements | Software architecture, APIs, data and delivery |
| Data or ML engineer | Models, data and experimentation | Workflow integration, product judgement and adoption |
| Consultant | Problem framing, change and communication | Production engineering and technical depth |
| Product manager | Outcome, prioritisation and users | Hands-on system design and delivery evidence |
The target is not shallow competence in everything. It is a strong primary discipline plus enough range to lead the whole problem and work well with specialists. Ironbark's Sandveld lead came from the second row and spent the engagement closing the gap in the third column, mostly by pairing with the evaluation engineer.
The South African opportunity
South Africa is a good place to do forward deployed AI work, and not despite its complications. Many organisations here run modern cloud services alongside established enterprise platforms, legacy systems, manual processes and uneven data maturity, often in the same workflow. That is precisely the gap forward deployment exists to close.
Local practitioners need to understand:
- POPIA and contractual data obligations;
- local and cross-border processing decisions;
- public-sector procurement and governance, where relevant;
- the controls that come with banking, insurance, healthcare and telecommunications;
- cloud regional availability and service constraints;
- cost sensitivity in rand, and exposure to services priced in dollars;
- mobile, WhatsApp and low-bandwidth channels;
- organisational change and support capacity;
- South African languages and local context in evaluation data.
These are not obstacles around the "real" technology. They are part of whether the solution works. Sandveld's invoices arriving as phone photos via WhatsApp, its month-end ERP lock and its growers' handwritten weights were not edge cases to engineer around. They were the work.
The short version
The headline is not the job. A million-dollar figure is the podcast's claim, not a market benchmark.
Build a pod, not a hero. A clear lead, named roles, and decisions written down.
Hub and spoke scales. Pods own outcomes; the hub stops them rebuilding plumbing; feedback turns field learning into product.
Measure outcomes and handover. Not hours, prototypes or coding speed.
Hire for a strong core plus range. Several backgrounds work; each has a known gap to close.
Previous: Part 6, sell the discovery, not the fantasy. Next: Part 8, build the capability in 90 days. All parts are on the series page.
How CloudNala can help
We help organisations and providers build forward deployed capability that does not depend on one person: designing the pod and its decision rights, setting up the platform hub and the feedback loop that turns field learning into reusable assets, defining team measures based on outcomes and handover, and planning development paths for architects, engineers and analysts moving into the role.
Work with CloudNala
CloudNala helps organisations move from technology ambition to practical execution across cloud, AI, data, platform engineering and digital services.
Whether you are exploring AI, modernising your cloud environment, building a public-sector digital service, or turning an idea into a working MVP, we can help you shape the roadmap and deliver the next step.
Book an AI Opportunity Sprint or write to us at consult@cloudnala.co.za