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 dirk@haun-online.de 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