The Plan Assumed the Team. The Team Was One Person.

content/blog/2026-05-04-plan-assumed-the-team-was-one-person.md

@@ -0,0 +1,62 @@
+---
+title: "The Plan Assumed the Team. The Team Was One Person."
+date: 2026-05-04
+pillar: "Post-Launch Reality"
+tags: []
+linkedin_copy: |
+  Every project plan I review assumes a team. Every critical workstream I audit is actually held together by one person.
+
+  Not one team. One person. The one who knows the integration mapping. The one who remembers why the field transform changed in sprint three. The one the vendor support team actually responds to.
+
+  The plan says "team." The execution says "person."
+
+  Here is what this looks like in practice. A content migration has forty items queued. That person takes a week off. Nobody else knows the transformation logic, the edge cases, or the client-specific naming conventions. The work does not slow down. It stops. And the recovery, when they return, costs more than the original work.
+
+  The instinct is to say "we need better documentation." That instinct is wrong. Documentation captures what was decided. It does not capture the reasoning behind the decision, the rejected alternatives, or the context that shaped the tradeoff. The person who holds all of that answers a question in thirty seconds. A new person reconstructs it in two hours from docs alone.
+
+  The actual fix is distributing ownership before the absence forces you to. Not as a Friday-before-PTO brain dump. During the build itself. Rotate a second person in. Let them hit the questions organically while the primary owner is still available.
+
+  This costs a small amount of velocity now. It prevents a large amount of chaos later.
+
+  I have started asking one question in every project review: "For each critical workstream, who is the second person who can answer questions?" If the answer is silence, the project has a single point of failure wearing a human costume.
+
+  Full post: {{url}}
+---
+
+Every project plan I have ever reviewed assumes a team. Boxes on an org chart. Names in a RACI. Rows in a capacity sheet.
+
+But when you look at who actually holds the context for a critical workstream, it is almost always one person. One person who knows the integration mapping. One person who has the relationship with the vendor's support team. One person who remembers why that field mapping was changed in sprint three.
+
+The plan says "team." The reality says "person."
+
+This is not a staffing complaint. It is a structural observation about how mid-market commerce projects concentrate knowledge without noticing they have done it.
+
+Here is what happens. A content migration has forty work items queued for handoff. The person who prepared them takes a week of PTO. Nobody else knows the transformation logic, the edge cases already handled, or the client-specific naming conventions baked into the templates. The work stalls. Not because the tasks are hard. Because nobody else can answer the questions that come up when someone new picks them up.
+
+The recovery, when the person returns, costs more than the original work would have. Rework. Re-review. Context re-transfer that was never transferred in the first place.
+
+I have seen this pattern on content migrations, integration builds, QA certification passes, and marketplace submission workflows. The shape is always the same. The project plan models the work as though knowledge is distributed. The execution concentrates it in whoever touched it first.
+
+The instinct is to say "we need better documentation." That instinct is wrong. Or rather, it is insufficient.
+
+Documentation captures what was decided. It does not capture the reasoning that led to the decision, the alternatives that were rejected, or the client-specific context that shaped the tradeoff. The person who holds all of that in their head can answer a question in thirty seconds that would take a new person two hours to reconstruct from docs alone.
+
+The actual fix is simpler and harder than documentation. It is distributing ownership before the absence forces you to.
+
+This means two things in practice.
+
+First, no critical workstream should have fewer than two people who can answer questions about it. Not two people assigned to it. Two people who have enough context to unblock someone else. This is a different bar. It requires intentional pairing, not just Slack channel membership.
+
+Second, the distribution has to happen during the build, not as a pre-PTO knowledge dump. The Friday-before-vacation brain dump is the most common version of this, and it is the least effective. A person summarizing their own context under time pressure will miss the things they consider obvious. Those obvious things are exactly what the replacement will not know.
+
+The better pattern: rotate a second person into the workstream early. Have them do a few of the tasks. Let them hit the questions organically and get answers while the primary owner is still in the room. This costs a small amount of velocity in the short term. It buys a large amount of resilience over the life of the project.
+
+Most mid-market merchants and their implementation partners skip this step. Not because they disagree with it. Because the project is already running hot on timeline, and pulling someone off their primary assignment to shadow a workstream feels like a luxury.
+
+It is not a luxury. It is risk management. And the cost of not doing it shows up in the exact moment you can least afford it: when the one person is unavailable and the deadline has not moved.
+
+I have started asking a specific question in project reviews: "For each critical workstream, who is the second person who can answer questions?" If the answer is silence, or "well, it is all in the docs," the project has a single point of failure wearing a human costume.
+
+The fix is cheap. The failure is expensive. The reason it keeps happening is that the failure is invisible until the person is gone, and by then it is too late to prevent.
+
+Plan for the absence before the absence plans for you.