Similar thing happened to a friend who joined a large defense contractor. They had stacks of new computers sitting in a storeroom but the workforce was partially unionized and only union electricians were allowed to plug in new computers. Totally crazy, but he had to wait a couple weeks until they got around to it.
Like CI, onboarding is a process we get better at by doing. If I work some place that hires consistently, I’ll make sure to sit with a new engineer at least once a year to 18 months and observe them going through the documented process. Save them when they get stuck, and rephrase that part of the documentation.
I’ll also prompt them to make changes as well, for one very particular reason: when you encounter a jargon term for the first time maybe the first half dozen times, you still have Beginner’s mind. You can still explain it to someone below you on the ladder. Senior staff can get trapped in circular definitions and unspoken assumptions.
Generally speaking, I find that the people who hate ramping up new engineers have made a mess that they don’t like to think about, and onboarding makes them look at it.
When I’m onboarding people, fixing bugs in the docs is the first task they complete. It helps everybody, and it keeps them from having to jump into fixing bugs in code they don’t understand at all yet for just a little while longer, while they build their 10,000 foot view.