13 ms·
I’d love to see a checklist but the other side of the table. When a developer is going to leave and you have two weeks. What’s the checklist for handoff on a gr
by social_quotient 4y ago
I’d love to see a checklist but the other side of the table. When a developer is going to leave and you have two weeks. What’s the checklist for handoff on a granular prioritized level. Do you start from front end and work backwards or from db model and go forward?
The use case is I run an agency and we tend to get hired when an internal resource is leaving and we need to take over a big fat codebase we have never seen. The guy running is is leaving in 2 weeks. Where do we start… a checklist like this could be awesome
- plorkyeran 4y agoI know you can't do much about it from the side coming in to replace someone, but waiting until someone is on the way out is fundamentally a flawed way to do it. As an employer you need to be focused on seamless onboarding _before_ the people who know how to do things have decided to leave. "Knowledge transfer" is just new-hire onboarding done by someone who no longer has a stake in seeing it succeed.
- _l0wh 4y agoI'm not sure how the agency is structured - but what I can vouch for (and seen work) is continuous communication amongst coworkers in the form of tech talks and documentation. That way, knowledge is distributed within the team and a situation like this is avoided upfront. I'm reminded of the Bus Factor concept: https://en.wikipedia.org/wiki/Bus_factor https://en.wikipedia.org/wiki/Bus_factor
- ukoki 4y agoMost companies I've worked in had an onboarding checklist or guide for new devs. You should also have an offboarding checklist. Whenever you add something the onboarding checklist, add it to the offboarding checklist as well ("grant Jira access to project X" => "revoke Jira access to project X" etc)