Knowledge Transfer

Not as a lecture nobody remembers a week later. I work on your real code and your real problems. That can be mentoring over several weeks, where I accompany individual developers. It can be a workshop on a specific subject, such as clean architecture, testability, or the stack you work with. And it can be a live coding session where we solve a real problem together. Your team watches how I think, not only what I type.

Standard training covers standard cases. Your team doesn't have standard problems, otherwise you wouldn't need me. Because I work on your actual system, what people learn tends to stick, since it has somewhere to be applied immediately.

Mentoring and workshops work through people, and people change jobs. So knowledge transfer also has to cover what stays behind when someone leaves.

I document in the code and right next to the code, rather than in a wiki nobody maintains a year later. The most valuable part is the reasoning. Why this library was chosen and not another one, why an interface is cut the way it is. The what is in the code anyway. The why is what your team will be missing in three years when a decision needs reopening.

For that I use architecture decision records: short, dated notes on every load-bearing decision. They cost ten minutes to write and save days later on.

For teams with good developers who lack experience in one particular area. For companies that want to move away from depending on individual external providers. And for anyone who senses that their knowledge sits in too few heads and understands how risky that becomes when one of them leaves.