How does your engineering team preserve context when senior engineers leave?

I've been thinking about this problem lately and wanted to hear how other engineering teams deal with it.

As our systems grow, it feels like engineering knowledge gets scattered everywhere—GitHub PRs, Jira tickets, Slack threads, docs, dashboards, runbooks, and people's heads.

Some situations I've seen:

  • A senior engineer leaves, and suddenly nobody knows why a service was designed a certain way.
  • A production incident happens, and engineers spend more time searching Slack, GitHub, Jira, and Grafana than actually fixing the issue.
  • Someone asks, "If we change this service, what else could break?" and nobody is completely sure.
  • New engineers spend weeks asking teammates where information lives instead of building features.
  • Six months later, nobody remembers why a particular architectural decision was made.

I'm curious how larger engineering organizations handle this.

  • How do you preserve engineering context over time?
  • What tools or processes have actually worked well?
  • What's still frustrating about your current setup?
  • Are there any problems you've just accepted because there isn't a good solution?
  • If you could magically fix one pain point around engineering knowledge or context, what would it be?

I'm especially interested in hearing from teams with 50+ engineers or companies running lots of services.

Would love to learn how this works at your company.

Posted Jul 11, 2026, 2:25 PM UTC

016
Loading comments…