How can I prepare for getting hit by a bus?

Question

As a member of small teams, I had significant responsibility. Whether driving progress by organizing meetings or maintaining/creating/understanding a large percentage of specific technical information, I often had such responsibilities. Sometimes I was the only person working on technical aspects of the project.

This happened on a variety of types of work. Sometimes it was programming projects as a sole coder with several non-technical people, sometimes it was analyzing or compiling technical information, and sometimes preparing technical data and presentations. Sometimes I was project lead and effectively the go-between person for all those involved.

I was really good at my responsibilities doing this and continued to get them assigned to me. I developed a niche skill-set and was enjoying work. Life was great.

Then... I got hit by a bus. Such a tragedy! It was too early to be taken from this world...

As I later floated through the hallways of my old workplace I found I had not done a good job preparing my team for my untimely departure.

No one else on the team was familiar with the tools I was using like I was. No one else understood even at a superficial level the technical information. I wanted to reach out and answer those questions - such simple questions! But alas. My disembodied spirit was doomed to float voiceless.

I was left wondering... what could I have done? What did I miss? How could I have changed things for these poor souls?

---

In seriousness, the above is a huge problem working in engineering. When you work on cross-functional teams it's hard to keep the rest informed about the details of what you are doing. It is easy to be a "black box" of magic for the team. Worse, you often develop/possess specific skill-sets which are not easily documented (and may involve hours upon hours of training or learning systems).

My question is:

• How should I function on a team as the sole technical contributor to avoid problems arising from my sudden departure (not necessarily only as a software developer)?

Note: I should add this is not implying anything about my future plans... but a way to make an otherwise normal question potentially more entertaining. You might get hit by a bus, have a sudden family emergency, or more realistically take a new job/promotion, get called onto a different and more urgent project, take a week vacation and not work (crazy concept), etc.

Answer 1

If you’re working as a contractor, I would say that this is 100% on your employer. Tell them that accomplishing the goals they have set for you means that other things that you think should be considered goals aren’t being done; ask them if they want to adjust your goals. They may well tell you to carry on as-is, since your time is expensive and they want the best short-term value for money.

If you’re working as an employee, you may have more leeway to plan for succession (or possibly there is an expectation that you are doing it already). Still, bring it up with your team lead or manager, as they need to know about the problem and how you are, and think you should be, spending your time.

Some things to that would help in planning for succession:

• Everyday processes should be documented to some extent, but it’s likely that other people in your team follow the same processes and could teach them to a newcomer. If you don’t all use similar processes, that is a current problem that should be resolved; get together, debate which way is best, come to some standard (consensual or forced from above), and use the standard, congratulations that standard can go in your documentation for the newcomer.
• Important things that are communicated via email, meetings, or casual conversations need to make it into a shared resource, anything from a folder of documents on a shared drive to a wiki. There’s this strange belief (at least where I’ve worked) that if something is sent via email to all members of a team, then forevermore that team will know the thing; this doesn’t take into consideration that team makeup changes and that any training (if it even happens) will never transfer all knowledge, only a subset of frequently used knowledge.
• (Possibly software-specific) Document clearly counterintuitive processes or design decisions, it is important to identify that the process is recognised to be counterintuitive and why it is so, regardless. For instance, if your client asked you to do something that seems “incorrect” (“I’m not a domain expert, but are you sure you want to do that?”), and you explained why you thought it was incorrect and they confirmed it was what they wanted (even better if they explained why), then the reasons why you thought it was incorrect and the explanation of why it was correct should be documented. That the software functions to specifications isn’t going to be enough for a replacement, they will have the same question as you did.
• For any problem that you encounter that takes a lot of time/research to resolve, document the problem, the symptoms, the shortened path to the solution (i.e.: knowing what you know now, what was the quickest path from identifying symptoms to a solution), and the solution. Symptoms are really important to your replacement, because they will hit them before they fully grasp the problem.
• The previous point is even more important with regards to legacy systems, like libraries or platforms, where new versions are being released but not used in your product. Problems you encounter in your version (or even worse, in interactions between several legacy systems) may be solved in future versions and so the very existence of the flaw will fade from public knowledge, until it is almost impossible to find information about it.

Answer 2

Documentation.

Reasonably frequent code commits.

Documentation.

Document your ideas, your designs and your code. Any gotchas you're aware of.

Documentation.

Document your bug fixes explaining what the problem was and how you've fixed it, and why.

And did I mention documentation?

If you work in an environment where policy is lax (so junior devs can simply not bother to submit documentation changes — relevant documentation updates should be mandated alongside every branch merge), peer review is missing (so junior/senior devs are caught out during spates of understandable laziness), and/or documentation is stored separately from code (so it can easily be lost), then it is also important to consider whether the environment can be changed so that these problems are made not so. Otherwise, all your effort writing documentation may be for naught.

That said, I wouldn't always go so far as to call it a personal responsibility: ultimately, if the teams are improperly managed and/or organised, then that is not your responsibility; in the case that you move on to a new job, I would just hand over my completed documentation and think "well, if you can't use and maintain this properly, then that's your fault… now good luck".

That line of thinking doesn't really hold in the "hit by a bus" case, though, where you may be in the process of instigating such policies but haven't quite got it done yet. For this scenario, I would simply suggest that you encourage management (and your senior devs) to begin taking this stuff seriously as soon as possible.

Answer 3

Do NOTHING differently. Work as though you are NOT going to be "hit by a bus" tomorrow.

The "hit-by-a-bus" problem is an organizational problem and not something that needs to be explicitly addressed in your own work-objectives.

Your co-workers and management should be thinking about it, but I think it is too much to expect individual contributors to work as though they might literally be gone tomorrow. If management is oblivious to the potential problems here, it means they're totally out of touch or maybe you're not as indispensable as you thought.

At best, if you're generous, you might want to remind key people and leads about having back-up in case of emergency. But in an era where corporations throw careers "under the bus" at a whim for the sake of short-term profit, how much should you really care?

Diligent engineering practices resolve many of the issues of the "hit by a bus" dilemma. Going above and beyond that to the point of being ready for immediate and permanent disappearence will create a lot of overhead for the individual contributor. It sounds like the environment described by the OP could benefit by simply better practices and staffing, there is no need for him to work as though he might vaporize at any minute.

Answer 4

Vacation makes a good "training" to prepare for stuff like that. It also helps to measure how well you are prepared. Get back to work after 2-3 weeks and count days and effort spent on cleaning your "backlog" - this could make a decent approximation to "hit-by-bus scenario".

This also makes a useful tool if you want to improve. Analyze backlog items you have to resolve and ask yourself, what could be made so that this could be done by someone else. At one of the past jobs, this helped me to drop "vacation backlog" efforts from about three weeks to two days in less than a year.

• ^{Oh my I seem to be the only one having this information, I need to document it to make available for the whole team.
  Dammit no one can fix this bug but me, I need to find and train a backup guy...}

The thing worth keeping in mind is that generally this is considered a responsibility of your management, so anything you do beyond required is at will. Ask yourself how much do you want to fight bus factor and proceed accordingly.

---

I for one want to be replaceable...

• ...so that other guy checking my stuff from repository doesn't have to get back to me trying to understand unmaintainable code
• ...so that other guy looking at my records in issue tracker doesn't need my help to figure what I was thinking about while working on it
• ...so that other guy reading my wiki pages doesn't need me to explain stuff documented there
• ...so that I can enjoy looking how stuff I made grows and flourishes, living its own life

...so that I can focus on doing new stuff without being distracted by worries about what left behind.

Answer 5

Ask your team. Ask your manager. Present the issue to them in exactly the way you have to us.

Give them options. Documentation for a future developer. Documentation for them. Paying off technical debt. Anything you can think of. Give them time estimates. Give them the choice. Let them weigh it up against your normal day-to-day work.

Hey, they might even decide that it's a risk worth taking. But, really, it's up to them to decide.

And, if they've decided to take the chance then your immortal spirit should stop feeling guilty about it.

Answer 6

I wanted to reach out and answer those questions...

The hardest lesson I ever learned was to not answer those questions. But to ask the right question to lead them, unsuspecting, in to finding the answer for themselves.

An answer given is different than a lesson learned!

Explanation

There are basically two different scenarios that create the single point of failure that the OP is addressing.

Business

This can be a conscious decision or a result of poor planning, process, or growth of the business. It can also be the result of inaction or failure to recognize and address the growing knowledge gap.

Regardless of the how, the business creates the situation where they have a super dependency upon a single individual or a small group of individuals that form the core of their knowledgebase. Many companies address this by using mentoring programs, cross training, and both formal and informal knowledge sharing.

From my experience the ones most successful at this also foster a teaching approach. By that I mean that you are rarely given an 'answer' to a question, but rather a discussion and pointed questions from the expert(s) that lead you down a path of learning and expanding your knowledge about the product, process, technology in play.

This also offers fresh insight and perspective to the expert in that the discussion. The teaching can indeed go both ways.

Employee

Generally speaking you have two different types of employees that end up in this position. What I call 'The Go To' and 'The Protector'.

'The Go To' is that employee that most managers love. He\she is the one that you can assign just about any task or project and not have to worry about it. These are the people that carve out their niche in the company and become the go to person and more than likely the one that has the answers.

'The Protector' is that employee who's made a decision to protect their turf. They feel that by guarding their knowledge they are assuring their position, importance, and future in the company.

Both inadvertently create single points of failure. 'The Go To' by always providing the quick answer and the 'The Protector' by not sharing any or all of the information.

So in a nutshell all of the documentation in the world won't resolve the underlying problem of a single point of failure. Yes it's important and should be part of every BCP and disaster preparedness plan. But documentation isn't really knowledge sharing in the sense that someone should be able to step in and perform your job tasks without having to wade through a 200 page document before hand.

Don't answer the question; empower them so that they can answer it for themselves.

Answer 7

Here is what we do where I work:

a) We use a wiki for documentation. Not Microsoft Word files, or text files. A wiki that is searchable, fully change tracked, etc. (I would recommend Confluence, but Confluence v4 is such a dog that I suggest you look elsewhere)

• Any repetitive or delegate-able processes should be documented.
• Checklists of "here is how we do _____" should be written
• Checklists are very important to building teams, as they allow processes to be done by anyone who can follow the list...

b) Version control, obviously

c) Case/issue tracking system, obviously

d) Commenting your work. This is the most nuanced thing, and it is so hard to teach, but as a contractor/independent, you may be able to grok this: Comments should explain your thought process and the why of what you are doing. Links to documentation, Stack Overflow, etc. are appropriate. Paragraphs and pages of comments are appropriate. Explaining the things you tried and did NOT do are appropriate. One of the biggest problems of code is that the thought and sweat that goes into making something work one way (as opposed to a different way) is lost. There is a book, something like 'beautiful code' or such, that has a chunk on the comment blocks in a unit in one of the big open VCS systems (Subversion or Git, I think). It is beautiful because it tells the story. Here is what this code does. Here is how it works. Here is how it is structured. (I confess that this block, as I recall, may not go big into the "why" question.)

A corollary to this is: How many people go back and edit code just to add comments? We all should... a lot. But in practice almost no one does.

Answer 8

Netflix has a system they call ChaosMonkey. It essentially 'breaks' or emulates breaking certain systems at random.

Employees can be thought of as systems and a way to emulate the breaking of an employee is to give that employee unannounced, unscheduled time off. The ChaosMonkey told you to go watch a movie without telling your coworkers. For the short term, the effect on them is the same as if you had been hit by a bus.

This tests the robustness of their systems and allows them to spot new flaws in their systems that might have otherwise gone unnoticed.

This could aid in knowledge transfer in a round and about way as a more robust system is likely to break less and will have fewer large bugs that need attention allowing the people in question to be able to focus more on how the system works and why it does what it does rather than just chasing down annoying issues that eat up valuable knowledge exchange time.

Since writing this answer, I have become aware of https://www.fdic.gov/news/news/financial/1995/fil9552.html. Basically the FDIC is recommending that banks impose mandatory, paid vactions of at least 2 consecutive weeks on key bank employees. Employee well being is a secondary consideration. The primary consideration is that this will force the banks to appoint someone else to take care of the vacating employee's responsibilities. If the vacating employee is embezzling the scheme will fall apart under the replacement's watch. This also means that the bank will not be vulnerable to a bus attack.

Answer 9

I'd start with

1. Standardization

   My last position before my current used to run a wild west type methodology. Everybody used the tools they wanted, what they were familiar with. What mattered was getting the projects delivered in good working condition and on time. It made for horrific code maintenance where one project would be developed with GWT as the presentation layer and JUnit solely for all kinds of unit testing and another developer stuck with raw JSPs while yet another brought JSF into the mix. Everyone was shackled to their projects and going on vacation was unthinkable for many and sounded the death knell for code reviews and optimization.

   I proposed we standardized on a number of industry standard technologies and tools that ensured that we all slept in the same direction of the bed (SoapUI for ws-testing, JSF for the web tier and with moderate success, Spring for back end processing and a couple of other stuff). And we all lived happily ever after. Discourage any individuality when it comes to tools of the trade that will create a files with a proprietary extension (or at least try to mitigate it); I

   If anyone has a favourite tool they trust their lives with, let them bring it before the court for evaluation and possibly team-wide adoption. You should've taken it upon yourself to set the standards with your tools. The benefits are obvious here, everybody used the same stuff with acceptable levels of comfort so with a decent design doc, anyone can pickup anybody else's bit and move on.

2. Regular and compulsory code/project reviews

   This is another feature from my last gig. We all met once a week with our manager in a group session and discussed the status of each other's projects and raised concerns and challenges. We all, at a very high level had an idea of what the next guy was working on and sometimes would chip in advice and a couple of lines of code to help out. There was no total isolation

3. Team Spirit

   I know it seems kind of trite and possibly a no-brainer, but healthy team spirit (and possibly a little competition) fosters information sharing. The downside to cubicle environment (especially team members in cubicles far apart) is that team members are often too far removed from each other's work lives that it's too easy to have a comms breakdown. There's better communication and information sharing when team mates are situated close to each other, preferrably in an open office environment with little in the way of walls or dividers. Discussions and mind-rubbing will happen and flow more freely, with them aim of fostering information sharing.

4. Obviously Document. It's an old song. I won't sing it again

Answer 10

Planning for this is part of a Business Continuity Planning while this is about planning for bigger disasters than just you getting hit by a bus, but the process puts in place the pieces to recover from small incidences like a key player being poached, to bigger problems like a disaster that takes out buildings, and the people who staff them.

Wiki-How has a so-so write up on how to create a BCP and while I would not recommend actually using this method for your business, it provides a good insight into the processes and thinking required for creating one. Generally BCP's are done in phased approaches handling the greatest risks, and preparing for more likely scenerios first and addressing lower risk concerns after. But each company generally builds there BCP according to their own needs so the exact process varies.

The process generally involves:

• Identify areas of risk
• document the processes involved
• determine appropriate responses to various scenerios
• Enact plans to deal with the scenerios

Answer 11

Our every-day rules against people taking knowledge to the grave:

• If someone writes a script/routine, then someone else has to be the first to use that in production.
• If someone deploys new systems, then no one will use or support those until they can look up all necessary access credentials by themselves, alone, at night, without asking someone else.
• There is also "configuration as code" and automated testing for software. It allows your successor to reverse-engineer your work.

In effect, "things that are not yet listed/tested don't exist for us". Only things that are listed are reliable.

We call it "arcane knowledge" (only stored in someone's head), and everybody refuses to act on it.

Obviously that does not work between techie and non-techie topics. But we don't expect techies to be able to take over financial calculations from the accounting department either. So even our accounting department might take "knowledge to the grave", if only 1 accountant ever did those calculations.

Because there is a limit. If the team is too small, then there will always be someone who is going to be hit by a bus.

Answer 12

What would I do if I gave two weeks notice?

I made a quick outline and began video recording my screen and voice. It included:

1. Where do I keep everything.
2. Examples of current requests and where I'm at in the process.
3. Demonstrations of how to do some of the more unique or complex tasks just in case a less technical person has to manage things for a short-term.
4. How to find things in the database I built on day one to manage all the little things (When you first start a job, you really find out what you don't know.).

My goal as always to leave a job better off than I found it. I try not to let management set my standards. Their job is to be concerned with end results, my job is to know how to do my job better than they do. I'm not just an extra set of hands.

Answer 13

The points below should be in your work description handed to you and established by the owners of the company. Its their responsibility to have this in place. You may however be the only one that has the knowledge to inform them that this is needed.

• Work within well established standards established for your field or organization.
• Document what you do.
• Document in great detail if you deviate from well established standards and why you did so
• Document how to document for your organization.
• If you are at the top of a system administration chain and hold the root/super user accounts; create an account that has the highest possible security clearance. Generate a long random password for it. Print it on paper. Sign it. Seal it in an envelope and hand it to the board of directors not the CEO. Because a CEO can part with the company on bad terms and still have that password. Tell them to store it safely, off-site and it's use(It can give you super user status on the network in case of your absence or other reasons that may apply).