Pair SAs with implementation resources in strike teams¶
Strategy Overview¶
Pair the Solution Architect on an engagement with an implementation resource, as a standing strike team from the first day of the engagement rather than as a team stood up once design is finished. Where the work warrants it, the pair extends to more than one.
The SA leads the client conversation, sets direction and makes the calls. The implementation resource sits alongside from the start, close enough to the context that it never has to be re-explained, and free to begin work the moment direction is set. When the SA walks out of a client meeting, someone is already ready to act on what was decided.
The purpose is concurrency. Today an SA fills their utilization by carrying several engagements at once, because early-phase work is stop-and-go by nature. Pairing keeps an engagement moving while the SA's attention is on another one.
Where the SA is also the Engagement Lead, this extends their reach without diluting ownership. Direction, decisions and client communication stay with the SA.
Motivating Factors¶
Stop-and-go early work forces concurrency, and concurrency has become the bottleneck. Early design, evaluation, transition and assessment efforts are typically sold as a small block of pre-approved hours, and they involve a great deal of waiting: on client meetings, on feedback, on dependencies outside our control. Because of that rhythm it is close to a necessity that SAs are put onto multiple concurrent engagements simply to fill utilization. With projects getting smaller, and with SAs increasingly staying aligned to ongoing development work, this has become a growing problem. The SA cannot move fast enough to serve all of their concurrent engagements, and we become the delay rather than the client.
Engineers are starved while SAs are stretched, and delivery teams are shrinking anyway. Fewer engagements now proceed to implementation as a distinct follow-up phase. That leaves engineers short of work at the same time that architects are spread too thin. A model that lets implementation resources engage sooner, during the smaller engagements rather than after them, makes better use of the team we already have, without needing to replace all of them with SAs.
Team size is moving in the same direction independently. Given the speed and capability of AI, it is natural that project teams get smaller: one to three delivery resources becomes typical, and a project carrying more than three becomes rare. For many engagements the entire delivery team will be an SA plus one implementation resource, or perhaps two. Which means the strike team is not an extra structure layered on top of a project team. Increasingly, it is the project team.
This only works because the work now arrives differently. In a traditional project, where solution design is the first step, pairing makes little sense. There is nothing for an implementation resource to do during that phase. That is no longer the typical shape of what comes in. Clients increasingly arrive having effectively completed most of the solution design themselves with AI tools, and they bring artifacts with them: UI screens, partial source code, partially deployed applications. Once access and an initial review are out of the way, there is real technical work available immediately. We are seeing more engagements where we are only a step away from development, and this staffing model addresses that reality directly.
Clients are buying two things, and only one of them requires the SA personally. When this works, we are selling two things at once: the SA's experience and their ability to build confidence in every real-time conversation, and our ability to set an outcome, a cost and a delivery expectation and then actually meet it. In most cases the client does not care who did the work. They care about who they invest their knowledge into and take advice from. If we can pair an implementation resource with the SA, then someone is ready to do work the moment the meeting ends, while the SA turns to the next engagement.
Solution Approach¶
The pair is assigned at the start, not after design completes. That is the whole mechanism. The implementation resource is present through the early conversations, so the context arrives as it is created rather than being handed over later in a document. The SA sets direction; the implementation resource carries it out.
The value is in a handoff that never happens. Today work waits for the SA to have time. Under a strike team, work waits only for direction, and direction takes minutes of SA capacity rather than hours. The same person is still deciding what happens. They are simply no longer the only person able to make it happen.
The pairing scales with the engagement. On a small assessment the implementation resource may be engaged a few hours a week. On a larger effort the pair may extend to include more than one. The principle holds at any size: the SA's scarce time goes to judgment and client contact, and the implementation side absorbs everything that follows from it.
There is a limit, and it needs respecting. This works by leveraging the SA further, not by removing them from the work. Shift too much off the SA and we solve engineer utilization by creating SA bench, which is the same problem pointed in the other direction. The pairing has to be sized to what an SA can practically direct and review, not to what looks efficient on paper.
Tactical Changes¶
| Structure | Process | People |
|---|---|---|
| Minimal | Moderate | Moderate |
Structure Changes: Minimal¶
- No change to the organization, to roles, or to reporting lines
- Our implementation resources already work under the direct guidance and oversight of our SAs, so the working relationship is familiar and nothing will feel different day to day
- The only structural element is the pairing itself, which is an engagement assignment rather than a reporting change
Process Changes: Moderate¶
- We have to sell it differently up front. How we present the engagement, and who is named on it, changes at the proposal stage and needs to be thought through rather than improvised
- Work orders have to be written for a pair, rather than for a single named resource against a block of pre-approved hours
- Estimating has to account for two people engaged concurrently in a phase that was previously staffed with one
- Care is needed not to over-leverage. Shifting too much work off the SA risks creating SA bench instead of engineer bench. The pairing should extend what an SA can carry, not replace what they do
People Changes: Moderate¶
No reporting or organizational change. The shift is in what the role requires, not in where it sits. But the requirement itself is a real change and is worth stating plainly.
- Engineering expectations change materially. Our engineers have historically been able to live in a single technology stack, .NET or Node, and often to specialize further into front-end or back-end work. We have been telling the team for some time that full-stack capability is now a requirement and that the ability to work across multiple stacks is critical. Saying it does not make it so. Not every engineer has become a multi-language, full-stack developer able to operate inside modern delivery windows
- The engineers who thrive here will be a particular kind. Those with the aptitude to learn quickly, who use their AI tools effectively to cover and fill knowledge gaps so they can move across layers and languages, and who can keep pace with how fast technology and AI capability is evolving in order to implement it effectively
- Some people may not be viable in this model. Engineers who cannot adapt, or cannot operate at this pace, may not have a place in a Next Gen SOLTECH. The expectations of a delivery resource are materially different from what has been successful here in the past, and as that becomes more real over the next year it could lead to some forced turnover
- This is a potential change rather than a planned one. It is noted here because pairing an engineer directly with an SA, from day one, on partially built applications across unfamiliar stacks, is precisely the situation that surfaces whether someone can work this way