The email arrives on a Tuesday: your most experienced engineer has accepted a new job. Everyone is happy for him, and at the same time the department feels the ground shift. Twelve years of projects, customer preferences and design decisions are about to walk out the door, and most of it is written down nowhere.
The reflex is a thick handover document in the final week. That document gets written, saved and never opened again. Knowledge retention when an engineer is leaving works differently: you choose sharply what is worth securing, capture it where the successor will naturally run into it, in the models, folders and templates themselves, and hand over live projects in person. You do not need a separate system for that, although tooling like Thundercad helps metadata play that role.
Below is a playbook for the notice period, week by week. It was written with a departing senior at a machine builder in mind, but works just as well at a sheet metal shop or a special machinery firm.
The archive that exists nowhere
What actually leaves? Not the models and drawings; those stay neatly on the server. What leaves is the layer around them: why the frame is welded rather than bolted, why one particular customer wants every revision checked twice, which supplier can deliver custom work when it really matters, and which assembly you should never casually update because something elsewhere will topple.
That layer splits into three kinds of knowledge, and the order doubles as the priority for securing it:
- Warning knowledge: where the bodies are buried. Models that break when reused, constructions dimensioned right on the edge, agreements never formally recorded anywhere.
- Customer knowledge: preferences, sensitivities and unspoken agreements per customer. Often more important to the relationship than the engineering itself.
- Why knowledge: the reasons behind design decisions. Without them a successor "improves" something back into a solution that was already rejected years ago.
Prioritise: ten working days, so choose
A notice period of a month or two sounds generous, but there are still projects that need finishing. Realistically count on ten working days of actual securing time at most, often less. Capturing everything is off the table; it is about the knowledge that is expensive to reinvent and likely to be needed soon.
Do not build the priority list by asking "what do you know", because the answer is an encyclopedia. Ask closed, concrete questions:
- Which three projects should your successor never revise without help, and why not?
- Which customers always call about the same thing, and what is the right answer?
- Which models or assemblies would you personally never reuse as a starting point?
- What do you do differently from the rest of the team, and does it matter?
Capture it in the systems, not in a document
The handover document has a fundamental flaw: it sits apart from the work. The successor revising a machine four months from now will not think to dig a document out of a folder first. Knowledge has to surface at the moment it is needed, and that only happens when it lives in the systems themselves:
- In the metadata of models and drawings. A remarks or notes field on the file is the best home for warnings: whoever opens the model sees the data card, and with it the warning. With the iProperty Panel from Thundercad you set up such a data card per document type, so the field is always there and never has to be reinvented per file.
- In templates. Customer-specific demands on title blocks, projection or delivery belong in a template per customer, not in one person's memory.
- In the project structure. Mark one reference project per customer or product family as the starting point, and say so explicitly in its description. That keeps the successor from copying the wrong project.
- In the customer records. Preferences and sensitivities per customer belong in the system where customer information lives, short and factual, not a novel.
The great advantage of knowledge in metadata: it can be searched. Whoever searches by properties instead of by folder memory also finds the warning a departed colleague once left behind. How to make that shift is described in Finding work by properties instead of folder memory.
One category deserves its own inventory: home-grown automation. Every iLogic rule or macro with the leaver as its only author belongs at minimum on a list stating what it does and where it runs. Why such home-built automation is fragile and when a ready-made toolbox is the better choice is covered in iLogic or a ready-made toolbox? When to choose what; here it suffices to put it on the inventory and appoint a new caretaker.
Knowledge that lives in metadata and templates simply stays put when the engineer leaves. With a fixed data card per document type you capture it the moment it appears, not in the final week.
Try 30 days freeHand over live projects in person
For running projects no document is ever enough; the handover only succeeds once the successor has actually done the work while the leaver was still around. So deliberately reverse the roles: the successor executes, the leaver watches and fills in the gaps. The other way round, watching over the leaver's shoulder, feels productive but does not stick.
- Appoint one successor per running project. "The team takes over" means nobody takes over.
- Have the successor carry out the next change or revision personally, from model to release, with the leaver as a backstop.
- Spend one hour per project walking through the main assembly together: browser structure, critical dimensions, the places you must not touch. In the model itself, not in a slide deck.
- Attend the next customer meeting together and announce the handover there. A warmly introduced contact saves the successor months of feeling their way.
After each session, have the successor write the three most important insights into the project metadata or project file themselves. What you formulate yourself, you remember; what you merely hear, evaporates.
The playbook week by week
Summarised, the notice period looks like this, assuming six weeks. If the period is shorter, scale down proportionally and cut the capturing first, never the in-person handover.
| Period | Focus | Concrete result |
|---|---|---|
| Week 1 | Take stock and prioritise | Top-ten list, inventory of scripts and templates, successors appointed |
| Weeks 2 and 3 | Capture in the systems | Warnings in metadata, templates updated, reference projects marked |
| Weeks 4 and 5 | Hand over in person | Successors have executed a change themselves, customer contacts done together |
| Final week | Questions only | No new tasks for the leaver; loose ends and access wrapped up |
Keeping the final week deliberately empty is the least intuitive part and at the same time the most important one. Whoever keeps production work on the leaver's desk until the last day buys one extra week of capacity and pays for it with months of searching afterwards.
Frequently asked questions
What if the notice period is only a few weeks?
Then prioritise ruthlessly: warning knowledge and the in-person handover of the biggest running project only. One afternoon walking through the critical assemblies together, writing the warnings straight into the metadata, beats any attempt to document everything.
Is an exit interview not enough?
An exit interview is about the organisation and ends up in a report engineering never sees. Knowledge retention belongs in the working environment itself: in models, templates and project files, recorded by the people who have to carry on with them. The interview is a fine way to close things off, not a safeguard.
How do I keep the next departure from becoming a crisis again?
By making capturing part of normal work: a remarks field on the data card, reference projects kept current, and agreements recorded in the customer data instead of in heads. If you want to see how such a fixed data card per document type works, try Thundercad 30 days free.