"The alternative to good design is always bad design. There is no such thing as no design."
- Adam Judge, author of design books
Companies also waste time and money with poor onboarding processes.
The same way bad design is the alternative to good design, the alternative to good onboarding is bad onboarding.
Bad onboarding processes happen not as a result of poor planning, but often because the process is neglected altogether.
The problem is, again, a matter of subjective perspective. The existing project members are already onboarded, and especially the most senior ones have seen the project emerge from the beginning. They know all the details and intricacies inside and out. Additionally they have been immersed for a long time in everyday details and problems. I…
"The alternative to good design is always bad design. There is no such thing as no design."
- Adam Judge, author of design books
Companies also waste time and money with poor onboarding processes.
The same way bad design is the alternative to good design, the alternative to good onboarding is bad onboarding.
Bad onboarding processes happen not as a result of poor planning, but often because the process is neglected altogether.
The problem is, again, a matter of subjective perspective. The existing project members are already onboarded, and especially the most senior ones have seen the project emerge from the beginning. They know all the details and intricacies inside and out. Additionally they have been immersed for a long time in everyday details and problems. Inevitably, they lose the perspective of the newcomer, of the one that stands before the system for the first time, and tries to figure out how everything fits together.
It is not due to bad intentions, it is because they now are in a different position. Drastically different position from a newcomer.
Bad Onboarding
If "onboarding" as such is not considered as a necessary process, then it happens by accident. Newcomers are given some minimal details to get started and are asked to figure the rest out. Learning-by-doing. Or "learning-on-the-job". "Do tell if you get stuck" and "if something is missing from the (outdated and/or poorly written) documentation feel free to improve on it".
Potential problems I see with these requests:
- Newcomers don’t know what they don’t know. Often they do not know if something is not working because something is not working, or they did something wrong. Additionally, if a clear plan is missing, they don’t know if they now know "enough".
- Newcomers often want to cause a good impression and prefer to solve their challenges on their own before asking for help (because the seniors are so important and seem to have better things to do).
- Newcomers might lack the insight and/or expertise to complete the documentation in a meaningful way.
The result is an "onboarding" process that is erratic, accidental, full of traps and frustrations, and take longer than need to be.
What would a good onboarding process look like?
Good Onboarding
A good onboarding process, in my view, consists of a clear roadmap and is a mixture of good documentation and automation. My motto here goes: automation where you can, documentation where you must.
First, the roadmap: it consists of a clear, finite, non open-ended, easy to understand, non-overwhelming list of things to do.
The "things to achieve" consist of things to read or "do".
The things to "do" can either be done automatically (preferred) or manually. If they are to be done manually, see point "reading".
The things to "read" either give you insight about key aspects of the project (setup, architecture, codebase, etc.) or how to achieve things to "do" which could not be automated.
But how to achieve "good onboarding" if everyone is so busy?
Achieving Good Onboarding
First, it needs to be recognized as something necessary. Something that, if done right, will save the company real money (by having the newcomer produce results earlier instead of still struggling longer than necessary).
Second, in my view it is a process that need to be "owned" by somebody in the team. It cannot be left to chance or the goodwill of the "group".
Natural candidate for this is of course the project manager, but it can be delegated to a senior developer or technical lead.
At each important feature development or architectural change (latest in a sprint-review) it needs to be discussed if there was an onboarding-relevant change. Then the onboarding documents and processes need to be revisited accordingly.
Final words
If done iteratively, if owned, and if kept in check, this approach should minimize (ideally eliminate, but "minimize" is a good-enough outcome) onboarding friction.
Newcomers to the project would feel empowered, welcomed and cared-for, and the momentum gained during the onboarding process would carry to the first feature developments.