The Reorg Happened. Half the System Knowledge Left with the Old Teams.

The reorg made structural sense. Teams organized around technical layers — platform, services, frontend — were restructured around product areas. Engineers who used to sit together, share context, and develop collective understanding of their systems were distributed across product teams. The codebase didn't change. The org chart changed. Six months later, the platform knowledge that used to exist as a shared resource across eight engineers was scattered across four teams and was effectively inaccessible to any of them.

This is the institutional memory cost of organizational restructuring that nobody puts in the reorg planning document. The motivation for the reorg was correct. The side effect — the dispersal of the informal knowledge networks that held cross-team system understanding together — was invisible until engineers started asking questions that used to have obvious answers and finding that nobody knew anymore.

What a team carries that isn't in its members' heads individually

Engineering teams develop collective knowledge that isn't contained in any individual's memory. The team knows, collectively, that the auth service has a quirky behavior under load, that a specific configuration combination causes issues, that a certain part of the codebase requires careful handling. This knowledge is distributed — Alice knows part of it, Bob knows another part, the combination of people who've worked together is the knowledge source. No single person holds it all.

When the team disperses, this distributed knowledge doesn't transfer intact. Alice takes her portion to Team A. Bob takes his portion to Team B. The combination that produced the collective understanding no longer exists. The engineers on their new teams don't know what they don't know — the gaps created by the reorg are invisible until they produce an incident.

What a reorg does to institutional knowledge:

  Before reorg: Platform team (8 engineers)
  -> 8 engineers who know each other's services
  -> Shared context about cross-service interactions
  -> Clear escalation paths within the team
  -> Collective understanding of platform constraints

  After reorg: 8 engineers distributed across 4 product teams
  -> Each new team has 2 platform engineers surrounded by product engineers
  -> Platform context is now scattered across 4 Slack channels
  -> Cross-service questions require cross-team coordination
  -> The collective knowledge never reassembles
  -> New engineers joining product teams have no path to platform context

  The codebase is unchanged. The knowledge network is destroyed.

The six-month lag

Reorg knowledge loss doesn't manifest immediately. In the first weeks after restructuring, engineers are still in contact with their former teammates, Slack channels still have the old context, and the informal networks still function. The knowledge gap appears gradually as the new team structures develop their own context and the bridges to the old knowledge fade.

By six months post-reorg, teams are operating primarily within their new team boundaries. The engineer who used to know who to ask for platform questions now works in a product team context. The institutional knowledge that made cross-platform questions answerable has dispersed into the organization without a clear recovery path.

What survives organizational change

The artifact that survives every reorg is the codebase. The commit history is intact. The service ownership (updated CODEOWNERS) reflects the new structure. The behavioral context encoded in the code is unchanged. This is the institutional memory that doesn't depend on any team structure to remain accessible.

What survives an organizational restructuring:
  Survives:
  -> The codebase (unchanged)
  -> Commit history and PRs (unchanged)
  -> CODEOWNERS (typically updated for new team structure)
  -> Jira ticket history (unchanged)

  Doesn't survive:
  -> Informal knowledge networks ("ask Alice in platform")
  -> Team-level context about cross-service interactions
  -> Unwritten conventions understood within the old team
  -> The person you'd call for a specific service question
  -> Collective understanding that was distributed across team memory

Kognita makes the codebase queryable across whatever organizational structure exists today. Engineers in the new product team structure can ask questions about platform services they didn't inherit and get answers from the codebase — regardless of which team currently owns the context that used to be held collectively by the platform team. The org changes. The codebase knowledge remains accessible.

Final take

Reorgs are organizational decisions that produce technical side effects. The informal knowledge networks that let teams answer cross-system questions quickly don't survive restructuring intact. The codebase does. Teams that can query the codebase directly are less dependent on the informal networks that reorgs destroy — which means the knowledge loss from restructuring is smaller and the recovery faster.

The org chart changed. The codebase didn't. The knowledge network that knew the codebase scattered. Teams that can query the codebase directly don't need the knowledge network to reconstruct — the answers are still there.