Knowledge Loss & Operational Continuity Failures

Engineering knowledge loss is obvious — the robot stops working. Operational knowledge loss is invisible until it is catastrophic: the senior who knew the sponsor contacts, the grant logins, and the budget all graduates, and the new team rebuilds the business side from zero every single year. Hall of Fame teams are defined as much by continuity as by any single season.

Failure 1 — Tribal knowledge. Critical information (sponsor contacts, account logins, vendor relationships, registration steps) lives only in one person's memory or personal email. Fix: A team-owned, access-controlled knowledge base (shared drive or wiki) with: sponsor CRM, grant tracker, budget, vendor list, a season-operations playbook, and a credentials policy (use a shared password manager or institutional accounts — never a graduating student's personal Gmail as the team's primary account).

Failure 2 — No succession plan. Leadership roles turn over with no overlap and no documented responsibilities. Fix: Define each business role (treasurer, sponsor lead, grant lead, logistics lead) with a one-page charter. Pair each senior lead with a junior apprentice mid-season so the role transfers with overlap, not a cold handoff. Hall of Fame programs like Team 1311 (Kell Robotics) and Team 1816 (The Green Machine) institutionalize leadership development rather than relying on individuals.

Failure 3 — Undocumented annual cycle. Each year the team rediscovers when registration opens, when grant deadlines fall, when to start sponsor renewals. Fix: Maintain a living operations calendar: registration window, grant deadlines, sponsor-renewal season, event-travel prep, Impact Award timeline. Update it each year with what you learned.

Failure 4 — Single points of failure on accounts. The bank account, the FIRST Dashboard, the email, the website domain all tied to one person. Fix: Multiple authorized contacts on the FIRST Dashboard and the bank account; domain and key services under a team/institutional account with documented recovery.

Debug workflow — run a 'bus test': For each critical business function, ask 'if this person disappeared today, could a teammate continue?' Every 'no' is a continuity risk. Document until every answer is 'yes.'

Continuity is unglamorous, but it is the difference between a team that gets stronger every year and one that resets to rookie-level operations whenever a key student leaves. The artifacts you built in the Worked Examples module are exactly the documents that make continuity possible — but only if they are team-owned, shared, and handed down.