Is knowledge transfer in engineering teams a challenge?

In Enterspeed we recently expanded our team, so right now the topic of onboarding and knowledge sharing is pretty hot around here. As many will know, one of the biggest challenges, when new engineers join a team, is making sure that they quickly understand the history, architecture, and reasoning behind existing decisions. And when it comes down to it, effective knowledge transfer isn’t about a sleek onboard checklist and long documents – it’s the result of people working closely together.

Process vs. humans ;)

As so many other teams, we sometimes struggle to keep documentation current. But instead of relying on standalone documents that can quickly become obsolete, we strive to integrate documentation directly into our workflows. This means embedding it into decision documents, well-commented PRs, tooling, and unit tests. Basically, we leave a trace while doing our daily work.

While much of our team’s architectural and technical decision history might be described in a decision document somewhere, we feel confident that the value of knowledge sharing depends on how frequently and effectively that history is used. Often, critical knowledge resides in the minds of engineers rather than in static documents.

For instance, code reviews serve as a crucial moment for sharing and verifying historical context. However, they depend on engineers being open about what they do (and don’t) understand. The loss of historical context is inevitable to some degree, and that's why it's essential to foster an environment where engineers feel comfortable asking questions.

The reality of knowledge transfer

In our experience, knowledge transfer is an organic outcome of collaboration. It isn’t about relying solely on documentation or specialised tools. It’s about creating an environment where new and seasoned engineers actively work together. Without this genuine collaboration, even the best documentation will fall short. But that isn't an excuse for not creating documentation and we can absolutely still improve.

What to improve?

One of the learnings we made during the last weeks of onboarding, is that our decisions document archive is difficult to review in retrospect. As a new engineer you want to know what documents are open and what the decision exactly was. We want to add a bit more structure to our documents to allow for better retrospective review. But still, because a decision was made 6 months ago, the actual implementation may have drifted in a slightly new direction, so we don't want to over-do it either. The important overview for a new team member is to know what decisions are historical, which discussions are ongoing, and what is for the future.

Summing up

Effective knowledge transfer is not about achieving flawless documentation or relying solely on automated processes – it’s about fostering a culture of collaboration. By embedding documentation into everyday workflows, maintaining open communication, and using tools to enhance rather than replace human interaction, teams can ensure knowledge remains accessible. Ultimately, the most valuable aspect of onboarding and knowledge retention is the relationships and shared understanding built among team members.