Somewhere in the world right now someone is leaving a team that can’t afford to lose them.  There are heavy sighs and sad goodbyes aplenty, and somewhere in the mix are the group of people panicking.

They know that what they’re losing cannot be replaced; the knowledge that leaves with a system guru comes only through years of experience.  These folks hold second and third derivatives of the rate of change of the system somewhere in their brain: Not just how the system works, or how it’s changing, but how the change curve itself is changing, and where that change curve is probably going to go next.  The only path to that kind of knowledge is hard-won experience, not with a system but with the people who use a system.

Nevertheless, the day comes when all that accumulated value walks out the front door.  There are, however, ways to better survive a system handover.

  1. Do handovers.  It seems really simple, but whenever possible you should take the last few weeks of a person’s employment to harvest as much of their knowledge as possible.  This can put a crimp in project schedules, people can get lost down long-settled side tracks, and it can be really hard to assign a value to the activity, because the pay-off is very much long term rather than short.  It’s also a bit of a gamble, because sometimes the business shifts out from underneath the old way of doing things before you can extract value from handover docs.  But in this case the odds are that a well-honed handover process (and, by extension, a finely-tuned knowledge transfer ecology) will dramatically reduce both the cost and the risk associated with maintaining a system.
  2. Be keenly aware of the value of email, messenging, and even paper logs.  If you have documentation, you have a reference point.  You should forward a copy of anything that is particularly useful to yourself.  This eliminates all those nasty situations where a person disappears from the corporate directory and takes a swath of key useful-information email with them.
  3. Be willing to change what you don’t understand.  Every inch of your being may rebel at this, and it breaks every known best practice in our nascent practicum, but at the end of the day someone has to change the system, and a system that works but doesn’t fulfill new requirements is a system that doesn’t work.  So break the system.
  4. As much as possible, follow best practices. I know, I just said something counter to this.  But best practices are the second-best tool (just behind Knowing Stuff, just ahead of Asking) for keeping things simple.  If you’re following them, then most people can drop into a team and trust their professional instincts to help them navigate.  If you’re not, well, it’s a jungle in there.
  5. If you have enough influence, get a little budget allocation set aside for contract engagements with departed team members.  Nobody is going to get things done faster than the guy that maintained a particular system long term.
    1. As a corollary, make sure to have someone internal paired with the contractor.  This will allow someone who’s still at the organization to gain meaningful experience doing maintenance.  At minimum, ensure that someone internal does a code review with the contractor; ideally, have them sit together while the work is performed.  This has the side benefit of creating a mini-market over time where you have multiple possible options for hiring contractors who know your particular system intimately.
    2. This can be politically – not to mention personally – sensitive in some organizations, and almost every organization thinks IT is a cost centre, which means budgeting pay for the guy who left is seen as wasteful.  A good IT group makes this business case in the long term, not on a per-task basis, and tries very hard not to burn bridges.  Team dynamics and cohesion come into play here – the better everyone plays together, the fewer opportunities for strife, and the more a united front can be presented to the business. That united front is key when trying to win support for ideas that only pay off on long cycles that can’t be captured in a quarterly report.

Most important of all, be good to people.  It can be exhausting.  It can even require lying to people and treating people well when they don’t deserve it.  But in a professional environment, being good usually means being direct, honest, and focused when dealing with other people.  Any software development and support group will have more work than resources almost all of the time; getting through even the most important bits of that work is a lot easier and more enjoyable if everyone is trying to get to the same place.