[smileysteve]

The title holds for much more specific and thinner stacks, along with support, QA, and sales - especially even simple web apps.

Onboarding is important Training is important Retaining is important

Maybe your system is 100% documented, conventional (looking at you Rails, Angular), debt free, tested, instrumented - but more than likely it's not.

But if you get down to staff who can't teach a a system, including product teams that don't respect feature overload, value, or internal feature training. If you prioritize new features over team development and training (aka a team that doesn't know the system), you're likely to get muddy with existing features both technically and use facing.

[plam503711]

I agree. If it's already hard for simpler stacks, you can imagine how hard it is for more critical or complex ones. And it's even worse if you inherited some of it (ie collecting technical debt that's not yours, which is the case here as some part of the stack are the result of a fork).

Sometimes it's even a catch-22 situation, where the technical/generic knowledge is already hard to find, but you absolutely need it to train more junior people. Luckily we found such experimented people, but then you also need to use their expertise to actually fix stuff and not just mentor juniors. A very very delicate balance to find, especially in a timed market.

[mystified5016]

My boss is about to learn this lesson the hard and painful way. Retention has fallen to the point where I am the only person who groks the full stack. I'm making an attempt to document what I can, but they're going to be fucked when I leave. I would feel bad about it, but CEO has tried to fuck me over many times-- for no apparent reason.