I'd argue that missing on mise en place is symptom of a team leadership failure, as well. Allowing excessive tribal knowledge vs. repeatable process (docs, dev

I'd argue that missing on mise en place is symptom of a team leadership failure, as well. Allowing excessive tribal knowledge vs. repeatable process (docs, dev tools, tests, well organized code, etc.) is an organizational risk. There's the efficiency loss side, but also the possibility that an incapacitated team member becomes a critical business loss – the team becomes unable to meet goals or worst case, to ship at all. Not empowering new team members to efficiently onboard is just one facet of this. With new hires, there are also the power issues that result, particularly blaming new hires for poor onboarding performance. I "fondly" recall one early job in my career starting with the promoted-from-the-ranks dev lead filling a whiteboard with boxes and acronyms... an overwhelming brain-dump to a newcomer that took hours of time spread over days. By the time I'd sorted out what we really did, months later, I could explain the whole thing to a new hire in fifteen minutes. One easily understood diagram, pointers to the two actually-important directories in our codebase, and some context – and they would be off to the races. Funny enough, I met a number of other people at that gig that thought of their work as "irreducible". One was, to use the recent meme, a "10x engineer" for whom the company maintained a rotating roster[1] of tech writers to follow around everywhere and try in vain to record what the heck they were doing. [1] "rotating" as in "hired, then fled screaming"