Author: Penny Lane
There is a particular point in consultancy delivery when the commercial success of winning the work becomes an engineering problem.
The proposal has been approved. The statement of work is signed. The client is ready to begin. The programme team has been assembled, but one workstream depends on platform knowledge or engineering capacity that is not available internally.
Perhaps the engagement requires deeper experience with Adobe Experience Manager, Adobe Experience Platform or Adobe Journey Optimizer. Perhaps the delivery team needs Salesforce Commerce Cloud, Marketing Cloud or CRM expertise. In financial services, the gap might involve Backbase, Mambu, Temenos T24 or Avaloq.
The issue is not that the consultancy made the wrong commitment. It is that the delivery reality has become more specific than the original staffing plan.
That gap needs to be covered quickly, without weakening the client relationship, creating a permanent bench, or moving a valuable work package to another delivery partner.
This is where staff augmentation can be useful: not as a replacement for consultancy ownership, but as a way to add the senior engineering depth required inside the engagement.
The gap appears after the sale
Consultancies rarely know every delivery detail at the point a proposal is submitted. Discovery may have identified the broad platform landscape, but the engineering shape often becomes clearer only after mobilisation.
A technical workstream may turn out to need:
- A senior engineer to lead a complex integration
- Platform-specific knowledge for a critical implementation
- Additional capacity during a build or migration phase
- Someone who can stabilise a team that is carrying too much delivery responsibility
- Experience with a platform the wider consultancy uses less frequently
The timing matters. Once the work is won, the question is no longer whether the capability would be useful. The question is how to introduce it without disrupting the programme.
Permanent hiring is unlikely to solve an immediate mobilisation problem. Building a bench of every specialist a consultancy might need is expensive operationally and difficult to justify. Subcontracting the whole work package may solve the skills issue, but it can also introduce another layer between the consultancy, the client and the people doing the work.
The more precise answer is often to add one or more senior engineers directly into the existing delivery team.
Augmentation is not subcontracting
The distinction between augmentation and subcontracting is important, particularly when the consultancy has won the work and remains accountable for the outcome.
With subcontracting, a separate provider is typically given responsibility for a defined deliverable, work package or service. It may manage its own team, methods and delivery decisions. The consultancy coordinates the relationship, but part of the delivery is effectively handed elsewhere.
With staff augmentation, the external engineer joins the consultancy’s delivery structure. The consultancy continues to own:
- The client relationship
- Programme and engagement management
- Architecture and delivery direction
- Priorities, quality standards and ways of working
- Communication with client stakeholders
- Accountability for the wider outcome
The augmented engineer contributes inside that structure. They use the team’s tools, attend the relevant ceremonies, work through the existing backlog and take direction from the consultancy’s technical or delivery leadership.
That means the consultancy does not need to explain a new delivery model to the client every time a specialist joins. The specialist becomes part of the team already responsible for the engagement.
The provider supplies capability. The consultancy retains ownership.
That is the commercial and operational difference.
The right question is not “Who can take this over?”
When a consultancy finds a capability gap, the instinct can be to look for another organisation to absorb the work. That may be appropriate when the work requires a separate delivery team or a distinct area of accountability.
But if the programme already has the right direction, client context and delivery leadership, handing over a workstream may create more coordination than it removes.
A better question is often:
Which senior capability is missing from the team, and how can it be added without changing who is accountable?
This keeps the intervention proportionate.
The consultancy might need one platform specialist for a critical build phase rather than an entire external squad. It might need a senior engineer who can make progress on a blocked integration while also helping less experienced team members understand the underlying decisions.
That is particularly relevant across large experience, commerce and financial-services programmes. The technical landscape may span several platforms, but the immediate gap is usually narrower: a specific workstream, a specific phase or a specific decision that needs deeper engineering judgement.
What a good two-week brief looks like
A short mobilisation window is possible when the brief is clear. It does not need to be a perfect technical specification, but it does need enough context for the right person to be identified quickly.
A useful two-week brief should cover five areas.
1. The engagement context
Start with the client environment and the consultancy’s role within it.
Explain:
- What the programme is intended to achieve
- Which phase the work is in
- Who owns the client relationship
- How the delivery team is structured
- Which parts of the work are already in motion
This helps distinguish a genuine engineering requirement from a broader programme-management problem.
2. The capability gap
Describe what the team cannot currently cover.
Be specific about the platform, technical responsibility and level of seniority required. “Adobe experience” or “banking platform knowledge” is too broad on its own. The brief should clarify whether the person needs to design, build, troubleshoot, review, lead or coach.
For example, the gap may involve:
- AEM component and integration delivery
- AEP data and event implementation
- AJO journey orchestration
- Salesforce Commerce Cloud engineering
- Marketing Cloud configuration and development
- CRM integration and customisation
- Backbase digital banking delivery
- Mambu, Temenos T24 or Avaloq engineering within a regulated environment
The point is not to list every possible technology. It is to identify the depth needed for the work in front of the team.
3. The first two weeks
A good brief explains what success should look like during the first fortnight.
That might include:
- Joining the relevant ceremonies
- Reviewing the existing backlog and technical documentation
- Confirming the immediate delivery risks
- Picking up a defined set of tickets
- Producing or reviewing a technical design
- Identifying dependencies and decision points
- Pairing with an internal engineer
- Establishing a practical plan for the next delivery increment
This makes the first two weeks a working period rather than an extended orientation exercise.
4. The team environment
Senior engineers add value faster when they understand how the team operates.
Include the tools, repositories, delivery methods, working hours, documentation standards and definition of done. Explain how technical decisions are made and who has final approval.
The best brief also describes the human context. Is the team experienced but stretched? Is it newly formed? Is the client highly involved in day-to-day decisions? Is the work moving through a formal governance process?
These details affect fit as much as the platform itself.
5. The handover expectation
The person joining should know that the objective is not simply to become indispensable.
Set out what needs to remain with the consultancy’s internal team. This could include documentation, pairing, design rationale, reusable patterns, runbooks or a clear record of unresolved decisions.
A specialist should make the work more manageable over time, not create a new dependency that is difficult to remove.
Integration is the test of a good engagement
The first sign of poor augmentation is often visible in the team’s calendar.
The external specialist is invited to a separate meeting, given a separate backlog and asked to report through a separate channel. Before long, there are two versions of the work: the consultancy’s delivery plan and the specialist’s technical activity.
That is not integration. It is parallel delivery.
A well-integrated engineer should be visible in the existing flow of work. They should contribute to planning, refinement, design discussions, code reviews and retrospectives where relevant. Their work should be traceable through the same tools and standards as everyone else’s.
This does not mean treating every person identically from the first day. A senior specialist may need early access to architects, security teams or client subject-matter experts to understand the landscape. But the direction should quickly move towards shared ownership of the team’s priorities.
The consultancy remains responsible for making that integration possible. Access, context and clear decision rights are not administrative details; they determine whether the additional capacity becomes productive.
Leave the internal team stronger
The most useful measure of augmentation is not how much work the specialist completes alone. It is what the wider team can do more confidently after working with them.
That can happen through:
- Pairing on complex technical tasks
- Explaining platform decisions in plain language
- Documenting patterns that the team can reuse
- Reviewing work constructively
- Making hidden dependencies visible
- Sharing practical troubleshooting methods
- Creating a clearer ownership model for the remaining work
This is especially important when the specialist joins for a defined phase. The consultancy should know what knowledge needs to transfer before the person arrives, not as an afterthought when the engagement is nearing completion.
Good augmentation delivers the immediate work and increases the team’s ability to carry the next stage.
A delivery lever, not a substitute for planning
Staff augmentation does not remove the need for proper discovery, estimation or technical leadership. It works best when the consultancy already understands the engagement and can describe the gap honestly.
Used well, it gives delivery partners a practical way to respond when the work sold is more specialised than the available team. It protects the consultancy’s relationship with the client while bringing the right senior depth into the programme at the point it is needed.
Finative’s technical services cover six platform specialisms for consultancies, agencies and delivery partners. The emphasis is on senior engineers who join the existing engagement, work within its delivery model and contribute without creating another layer around the client work.
For consultancies reviewing a newly won engagement, the first step is usually straightforward: compare the sold scope with the team that is actually available, identify the capability gap, and decide whether it can be covered by adding the right person rather than moving the work elsewhere.
Talk through the delivery requirement or explore the wider platform specialisms.
+44 20 4620 4946