Onboarding New Engineers

Ask any engineer what their first three months at a new job actually involved and the honest answer is rarely "reading documentation." It's asking a teammate why a service behaves a certain way, getting a half-remembered answer, and slowly building a mental map of the parts of the system that don't work the way the code alone suggests they should. That process has a name in most engineering orgs: ramp-up time. It's expensive, it's slow, and it depends entirely on which teammates happen to be around and willing to answer questions that day.

The knowledge a new engineer is reconstructing during that period is exactly the tribal knowledge a contract is built to capture, not what the code does, which they can read for themselves, but why it does it, what would break if they changed it, and what got tried before and didn't work. None of that is visible from the implementation alone, and none of it shows up reliably in a wiki that hasn't been updated since the person who wrote it moved teams.

A capability with a contract gives a new engineer something closer to a conversation with whoever built it, minus the wait for that person to have time. They can read the non-goals and immediately know what not to touch. They can read the history and understand why the retry policy looks unusual instead of assuming it's a bug worth fixing. cdad graph shows them how the capability connects to the rest of the system, so their first change doesn't quietly break something three services away that nobody mentioned in their onboarding doc.

This doesn't eliminate the need for a real onboarding process, pairing sessions, or a manager checking in during week two. What it does is take the highest-risk, least-documented parts of the system, the ones a new hire is most likely to break by accident, and make them legible before the new hire ever has to guess.