Leave Things Better Than When You Found Them

Published: 2015-02-22
Last Updated: 2015-02-22 00:12:27 UTC
by Russell Eubanks (Version: 1)
5 comment(s)

Whether at the end of a project or at the end of your time with an organization, there are some low impact and high reward actions you can take to ensure that you leave things better than when you found them. Although it is not without risk for us as security professionals, if you have the opportunity it is ideal to spend time training your successor before you leave. Through a few intentional actions you can leave a legacy that can serve to inspire others to not only sustain but to actually improve operations.

This topic is particularly close to me now because I have recently started a new position. I had the opportunity to share my experience with others and found it to be rewarding and also a little uncomfortable for me and for the person who was assuming my duties. I found myself personally and professionally vested in the success of the program while recognizing that it was time for me to let go. There are of course certain circumstances that will prevent this sharing from happening. Sometimes policies will dictate that when someone resigns, the team members are escorted from the premises right away.

Even in you are not making your next career move, maybe you are transitioning from a project and can use this time to help others. The following are some suggestions on what you can provide to your successor:

  • Operational guides
  • Original installation media
  • Configuration checklists
  • Installation guides along with clear documentation of any deviations from the vendor instructions
  • Lessons learned of things that must be done along with those that must *never* be done
  • Key contacts to support sustaining the project such as administrators, change control tickets and project documentation

Even if you are not on the way out, I recommend that you "begin with the end in mind" today. Start by setting a monthly reminder on your work calendar to update and maintain your project or program documentation. You may very well recognize that the person this helps the most is you!

Use the comments section to share what are you doing to leave things better than when you found them.

Russell Eubanks
@russelleubanks
Securityeverafter gmail com

Keywords: Lessons Learned
5 comment(s)

Comments

Well said. I've been on the receiving end of the alternative. And you're right, I often find my own documentation useful.
I am in this situation right now! I am leaving the company and have very little time to train my replacement who has way less experience then me overall, and almost none in security. My documentation, checklists, training videos and some hands on training should help him a lot.
Tri0x,

Thanks for you comment and good luck in your next role!

Think about your replacement on Day 1 - they sit down with a cup of coffee and wonder what to do first. What things do you just "know" are normal and what others are abnormal and require investigation.

Russell
well said..
This is the sort of thing we try to do for anything we take "production" at my current job. Then we leave links referring to these docs in our asset tracking tool (OpenLDAP with a custom schema). That way when someone else is on-call and gets a page about your server, they can go into nagios, click on the red folder icon and not only see details about the server (how to get a remote console or remotely power cycle it, serial numbers, support info, etc), but also what apps it serves, build notes and care and feeding notes for those apps, emergency contact info, which backup server backs it up, etc. In theory... and hopefully... anything 'n everything the on-call might need to know.

It's not always 100% up to date. As you say, it's a good idea to try to update docs like this at least once a month. But even somewhat dated docs are better than none. :-)

Diary Archives