Ask HN: Is there any guideline for 'Handover Process' when you quit a job? | Hacker News Reader

Ask HN: Is there any guideline for 'Handover Process' when you quit a job?

5 pointsdesaiguddu6 comments

I am quitting my current job! I have been working with current organization with 2 Years and been in to almost every projects related with Mobile. My team has grown to 5 people now, but I am waving goodbye to my current organization. I wanted to give my team, technical head and management enough confidence to work as easily without me.

What are the things I need to consider ? I have made a list of things to do , but still I wanted to know from you guys!

View on HN

"I wanted to give my team, technical head and management enough confidence to work as easily without me"

Why?

I can guarantee that the minute you walk out of the door, they will tear up anything that you wanted them to do. Whoever will replace you will want to do it their way, not yours, and that's all there is to it. Management are notoriously eager to stamp their authority when someone leaves, for good reasons as well as bad. No need to be overly romantic about any legacies!

Friendship and networks on the other are valuable so work on those as your priority.

Here are the quick Bullet Points, I have planned for my Exit. That will give my Team a good support. I wanted to make sure, I don't miss out any thing.

A.) Hand Over of Current / Live Projects

B.) Hand Over of Old / Finished Projects

C.) Transfer of Important Research and Knowledge update

D.) Important Enquiry and Well documented Enquiries / Probable Clients

E.) Design Resources and Development Resources / PDFs and eBooks, Important Blogs

F.) Important Application on iPhone and iPad

G.) Important Success Stories of Companies in Mobile

H.) Interesting Business Model and Strategies by Mobile Companies

I.) Internet Advertising, Mobile Advertising and Other Revenue stream for Mobile Apps

J.) Client Communication and Client Trust Building measures

K.) Enquiry Client Communication and Handling Enquiry, Sales Team

L.) Documentation , Code Review, SVN and Git Protocols

M.) Client Stories for each Existing and Old Clients, Blunders made with Client / How to avoid blunder Clients

N.) App Store ( Deployment, Distribution) - TestFlight, App Store Distribution, App Store Marketing , Enterprise Distribution

O.) One to One - Understanding the individual Team Member Potential and Interests

P.) Internal Projects and Products

Q.) Code Review Sessions

That list is very long with some very nebulous items in it. Just ASK THEM what actionable things you can do in 2 weeks (or however long the notice period is) to make the transition as smooth as possible. Anything more than that and you're wasting your time.

This has been my experience - every organisation I've left has got by irritatingly well without me. The ones without solid metrics to measure success just fudge the metrics anyway; the ones with solid metrics notice quickly what they need to replace.

Transfer what you intended to do. Explain the TODOs in your code, optimizations that you had in mind, but didn't get the time, explain the code for handling special cases if they are not too obvious... when people refactor old code they often overlook the tiny edge cases unless it is too obvious or they had been bitten by it.

Thanks, I have started that exercise with Codebase. My involvement was more than managing Codebase. I was involved in outsourcing Customer requirement gathering and Customer building measures as well.

Reply on news.ycombinator.com