braindump - how to leave your knowledge when leaving your job
TRANSCRIPT
As you can probably guess, the motivation for this talk was that I was thinking about leaving my job. But how could I make sure that all the knowledge I accumulated while doing it was
still available to the company after I left?
Braindump How to leave your Knowledge
when leaving your Job
Dirk Haun @dirkhaun ACCU 2015
Let me start with a few assumptions. First of all, I assume this is not what you have in mind when you think about leaving. I’m
assuming you want to leave on friendly terms, not burn bridges.
Assuming this is not what you have in mind
After all, this is the ACCU. Our motto is “Professionalism in Programming”. And in my opinion, that professionalism should
extent to all aspects of your job. Including leaving that job.
Professionalism
Speaking of leaving: For the purpose of this talk, it doesn’t matter whether you think about (hypothetically, of course)
leaving the company entirely or moving to a different position within the same company.
leaving
My first takeaway point would be this: Some loss of knowledge is inevitable. It is simply impossible to transfer the entire
knowledge you’ve accumulated over months or years within the short amount of time that’s left until you leave.
some loss
is inevitable
Having said that: It’s your job to minimise that loss of knowledge; that goes with the professionalism angle.
your job:
minimise loss
The first thing that comes to mind when you think about preserving knowledge is documents. Having to write lots of documentation may sound tedious. Hopefully, though, you
have some documentation already and it’s “only” a matter of updating it now.
Documentation
So you have to identify the knowledge that’s only kept in your head …
… and transfer it to someone else’s head; possibly via a document. There are other ways, as we will see shortly.
How do you do that? Watch yourself in your daily routine. At each step, ask yourself if someone else could do the same thing if you were not there. Document everything they would
need to know (and that’s not already documented).
watch yourself
The kind of documentation we’re dealing with can be divided into two chunks: On the one hand, there are the Big Things, like the architecture of the system. These things tend not to change so often, so it’s worth documenting them since the
document will be relevant for a long(ish) time.
big things
And then there are the smaller things, which also tend to change more often. Keep those closer to where they are used. For source code, comments would be an obvious place. Even though comments are notorious for being out of sync with the
code, they at least have a better chance of being updated than a document that sits somewhere else entirely. Also see if you can keep notes in your tools, e.g. the description fields for
jobs in Jenkins.
small things
Also check the documentation that new employees of your company get (if you have such a thing - if not, now would be a good time to start it). See what needs to be updated and what
you can add to it.
That will still leave you with a lot of snippets that don’t really fit anywhere else. I’d suggest to simply collect those in a huge document. Call it an “FAQ”, even though the contents are
probably more like infrequently asked questions. Whatever you call it, the document will be searchable and easy to add to.
FAQ
There is another way to store information, which I actually consider superior to documents and that is to store knowledge
in people.
People >>
Documents
Find your successor (or whoever will be doing your job temporarily after you left) and teach them.
teach your successor
Yes, people tend to forget things. But if they have actually done the things, they will be able to reconstruct that
knowledge. Which is also why “learning by doing” works. So don’t just show people what you do - let them do it.
I hear and I forget. I see and I remember. I do and I understand.
(probably not by Confucius)
Another factor you will have to deal with is time. Depending on your contract and how much vacation you have left, there may
actually only be a really short period of time between your announcement to leave and your last day at work.
Time
Due to the short amount of time, don’t wait for others to come to you. I’ve seen this happen more than once: “We need to
arrange a handover!” But then, nothing happens and on your last day, panic breaks out. So be proactive and start the
activities described in this presentation early.
don’t wait for them
to come to you
Then, one or two weeks before your last day, remind the people your are working with that you are about to leave. Show
them the documentation you’ve written and ask them if they need anything else from you.
remind people that you are leaving
The purpose of all this is, of course, to make your last day(s) at work less stressful.
less stress
for you!
Also, check if you have any files on your PC that may still be of value and that you haven’t handed over. Don’t expect that
people will be able to get to those files after you left; company policy and privacy laws will sometimes require the deletion of
all data on a former employee’s PC.
check the files
on your PC
A minor point: Please make sure to unsubscribe from all newsletters and mailing lists that you subscribed to with the company email address. Those handling those lists will be
grateful not having to deal with the bounces. unsubscribe
So you did everything you could and the final day came and you left. You may think that that was that, but there’s one more
thing you could do …
Consider visiting your former colleagues after two or three months and check if they ran into any problems. If they had
had a serious problem, they would have contacted you. What often happens, however, is that they run into a minor problem
and work around it somehow. So when paying them a visit, offer to look into these sorts of things. It’s just a gesture of
good will, to keep the good relations alive.
checking back
Summary
Some loss of knowledge is inevitable. Don’t sweat it.
some loss
is inevitable
If in doubt, store knowledge in people instead of documents.
People >>
Documents
The guiding principle for everything you do should be the concept of professionalism.
Professionalism
Thank you!Dirk Haun @dirkhaun [email protected] www.TheMobilePresenter.com
Image credits, in order of appearance: A CT scan of my brain by Dirk Haun, Jamestown Bridge Demolition by Nemosdad, iStockphoto #1550442, Businessman Adjusting Tie by jackethead, iStockphoto #13969032, Swing Doors in Revolving Door, New Bucktown Walgreens by Daniel X. O’Neil, Flickr, CC BY, Puzzle2 by Willi Heidelbach, Flickr, CC BY, Stack of Papers by phrawr, Flickr, CC BY, Young Man With Eyeglasses by Ridofranz, iStockphoto #35042864, KW 4: Blickwinkel #fotoprojekt2014 by Dirk Haun, Flickr, CC BY, City Light employee Mr. McKeen, 1937 by Seattle Municipal Archives, Flickr, CC BY, Tiny books by Kelly Taylor, Flickr, CC BY-SA, The Start and Finish Line of the "Inishowen 100" scenic Drive by Andrew Hurley, Flickr, CC BY-SA, Question Box by Raymond Bryson, Flickr, CC BY, Rain Helping Roman by djromanj, Flickr, CC BY, Plate and chopsticks by akiyoko, iStockphoto #25674490, Cronometro by MrTossum, openclipart.org, El tiempo pasa by Jorge, Flickr, CC BY-SA, Transparent glass doors leading to office by ER_Creative, iStockphoto #27792785, Slacking while working by Alle, Flickr, CC BY-SA, Thank you for sharing by F Delventhal, Flickr, CC BY, EMAIL Keys by OmirOnia, freeimages.com, London January 6 2014 063 Parliament Visitor Pass by David Holt, Flickr, CC BY-SA
Presentation by Dirk Haun, www.TheMobilePresenter.com released under a Creative Commons Attribution 4.0 International licence