Nobody tells you the senior architect handed off the work. You find out when something breaks.
That's not an exaggeration — it's a fairly consistent pattern in how large VCF consulting engagements actually run. The pre-sales process puts a senior engineer in front of you. That person is often genuinely expert, answers every technical question correctly, and gives you a high degree of confidence that the firm knows what it's doing. Then the project kicks off, and a different name shows up on the calendar invite. Sometimes there's an introduction email. Sometimes there isn't.
This isn't about bad faith or deliberate misdirection. It's just the math of how volume consulting businesses have to operate — and it has real, predictable consequences for the quality of what gets deployed in your environment.
Why the Handoff Happens
Large systems integrators grow revenue through leverage. The senior engineers who close deals can't also be the engineers who execute all the work — there aren't enough hours, and the billing model doesn't support it. So those organizations build a delivery pyramid: a small number of senior architects at the top, a much larger group of mid-level engineers doing most of the execution, and in some shops, junior staff handling configuration tasks under supervision.
The pitch-to-delivery handoff is typically managed through a project kickoff and a design package. The senior architect who scoped and sold the work produces a design document — high-level design, low-level design, configuration specifications — and that package becomes the primary instrument that guides what the delivery team builds. In theory, a good design document captures enough detail that any competent engineer can execute against it faithfully. In practice, VCF environments don't work that way.
A design document captures intent. It doesn't capture the judgment calls that surface when the environment doesn't behave exactly as expected during deployment.
VCF is an integrated stack. When you're doing a bring-up with SDDC Manager, standing up NSX-T, configuring vLCM image baselines, and wiring up vSAN — all in a specific sequence, against a specific hardware profile, in a specific network topology — the number of variables that can produce an unexpected result is high. An experienced engineer who has done this many times knows what those results mean and how to respond. An engineer who has done it a handful of times makes judgment calls. Those judgment calls compound.
Where It Shows Up in the Environment
The most consistent place I see the effects of a junior-led deployment is in the as-built documentation. The as-built is supposed to be a record of exactly what was deployed — configuration values, design decisions made during implementation, deviations from the original design and why. On engagements where the delivery was done by senior engineers who owned the work end-to-end, the as-built tends to be accurate and complete. On engagements where there was a significant handoff, the as-built tends to reflect what the design said rather than what was actually deployed.
That gap matters because the as-built is your primary reference document the moment anything needs to change. When you're planning a VCF patch cycle and need to validate that vLCM image baselines are configured correctly, you go to the as-built. When an NSX-T issue surfaces and you need to understand the segment topology and what DFW policy is applied where, you go to the as-built. If that document doesn't reflect reality, every subsequent operation that depends on it starts from a position of uncertainty.
vLCM Image Baselines
This is one of the more technically specific places where junior execution creates downstream problems. vLCM image-based lifecycle management is how VCF manages ESXi host firmware and software currency in an integrated way. Getting the initial image composition right — the correct base ESXi image, the right hardware vendor add-ons, the appropriate firmware components — requires both platform knowledge and familiarity with the specific hardware in the environment.
When it's done wrong, you typically don't find out immediately. The environment runs. Hosts are in the cluster. Workloads are deployed. Then the first patch cycle comes around, and SDDC Manager surfaces remediation failures because the vLCM image doesn't match the installed hardware components, or because a vendor add-on was included that conflicts with the firmware version on the host. Tracing that back to the original baseline configuration and correcting it is a careful, time-consuming process — and it's entirely avoidable if the initial build was done by someone who understood what they were configuring and why.
NSX-T Segment Topology
NSX-T segment topology is another area where Day 0 decisions made during deployment create constraints you don't feel until Day 180. The physical structure of how segments are organized — which transport zones they belong to, how they relate to gateway topology, how they'll be referenced in DFW policy — determines what your micro-segmentation design options look like months later when the security team asks you to implement zero-trust policy for a specific application tier.
If segments were created without a clear naming and organizational structure, if the transport zone design doesn't account for eventual policy scope, or if gateway configuration doesn't align with how traffic actually needs to flow for the workloads that will run on those segments — you're rebuilding, not building. That work falls on whoever is operating the environment, not on the team that did the original deployment and handed it off.
SDDC Manager Domain and Cluster Boundaries
SDDC Manager domain and cluster design is one of those areas that feels straightforward during deployment and reveals its complexity over time. The decision of how many workload domains to deploy, how cluster boundaries align with business units or application tiers, and how lifecycle management scope maps onto those domains affects every subsequent operational activity — patching, capacity expansion, adding workload domains, and integrating new clusters into the management plane.
A junior engineer working from a design document may implement the topology exactly as drawn but miss the reasoning behind the design decisions, which means they also miss the places where the actual hardware or network configuration necessitates a deviation. That deviation gets made in the moment, gets noted (or doesn't get noted) in the as-built, and becomes someone else's problem to reverse-engineer later.
How to Recognize It During the Engagement
By the time you're discovering misconfigurations in your as-built six months post-deployment, the engagement is long over. The signals are there during the project if you know what you're looking at.
- Status call rotation. If a different engineer is on the call each week, or if the person presenting doesn't have context from the previous week's call, the engagement is probably being staffed with whoever is available, not whoever owns the work.
- "We'll circle back on that." Once is fine — some questions genuinely require offline research. More than once on the same topic, or a pattern of deferring specific technical questions across calls, means the person on the call can't answer the question and needs to go find someone who can. That's not a scheduling issue.
- Questions you've already answered. If the delivery team is asking you to re-explain your environment — your hardware profile, your network topology, your existing domain structure — at a point in the engagement where that context should be fully established, the person doing the asking didn't get a proper handoff from whoever scoped the work.
- Documentation lag. On a well-run engagement, documentation keeps pace with deployment. If you're in week six of deployment and the as-built is still empty or contains only placeholder sections, that's a sign the documentation is being written after the fact, from memory or from the design spec rather than from what was actually deployed.
- Design deviations with no rationale. Every VCF deployment involves some number of decisions that deviate from the original design — hardware doesn't match the assumed spec, the network isn't configured exactly as expected, a vendor compatibility issue requires a workaround. What distinguishes senior execution from junior execution is whether those deviations are documented with their rationale or just implemented silently.
What Senior-Only Engagement Actually Changes
It's worth being specific about this, because "senior-only" can sound like a marketing claim rather than a delivery model distinction. The practical differences are concrete.
When the same person who scoped and designed the work is also doing the deployment, the judgment calls that inevitably come up during a VCF bring-up are made by someone who understands the full design intent. When SDDC Manager reports an unexpected validation failure during bring-up, that person knows whether the failure is a legitimate blocker, a known intermittent, or a sign that something in the configuration needs to be revisited. A junior engineer in the same situation either escalates — which delays the project and consumes senior time that wasn't budgeted — or makes a call that may or may not be correct.
When the person doing the deployment is also writing the as-built documentation, the documentation reflects what was actually deployed, including the deviations and their rationale. That document is accurate when you need it six months later.
When the person on the status call is the person doing the work, every question gets answered by someone with full context. There's no telephone game between the delivery engineer, the project manager, and the principal architect. The answer is either known or it isn't — and if it isn't, you hear that directly rather than getting a deferral that obscures the uncertainty.
Who specifically will be doing the deployment work — not who will be on the kickoff call?
What is the handoff process from the architect who designed the environment to the engineer who will deploy it, and how is design intent preserved through that handoff?
How are deviations from the approved design captured during deployment, and who has authority to approve them?
Who will be on the status calls, and will that person have direct knowledge of what was done since the last call?
What does the as-built documentation process look like — is it written concurrently with deployment or compiled at the end?
A Note on What This Isn't
This isn't an argument that large SIs are incapable of delivering quality VCF work. Some of them have senior engineers who do stay engaged through deployment, and some of them have delivery models that produce accurate, complete as-builts. The point is that the staffing model of a volume consulting business creates structural incentives that work against senior-led delivery, and those incentives are worth understanding before you sign.
It's also not an argument that boutique necessarily means better. Small shops can deliver poor quality work too — limited experience, limited staff depth, and limited capacity to handle unexpected complexity are all real risks in a small practice. The differentiator isn't firm size. It's whether the person accountable for the outcome is the person doing the work, and whether your engagement structure lets you verify that before problems surface in production.
When I say McSherry Tech operates as a senior-only practice, what that means in concrete terms is this: I scope the work, I design the environment, I deploy it, I write the as-built, and I'm on every status call. There's no handoff between the person who knows what should be done and the person doing it, because they're the same person. That's not a positioning statement — it's just how a solo boutique practice is structured, and it's the model that makes the most sense for the type of work VCF engagements require.