Iyfjky

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.

Related question on Freelancing: How can we prepare for Ã¢Â€Âœgetting hit by a busÃ¢Â€Â? — Sep 4 '14 at 9:25
Imagine being a ghost and spending your time back at work, checking on how everyoneÃ¢Â€Â™s managing meetings now. — Sep 4 '14 at 10:41
related: If I did a good job delegating all my work to a team I built, and there is no work left, am I redundant? — Apr 1 '15 at 19:53
An important point to remember is every single employee will get hit by the bus eventually. Every employee will quit, retire, or die. Corporations know this: they take out life insurance policies on every employee, to hopefully allow easier recovery. A smart company will assume every employee will leave at some point and plan appropriately (documenting, cross-training, mentoring, etc) — Sep 22 '15 at 20:40

Matt 1,26487 · Accepted Answer · 2013-01-24 03:48:21Z

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.

Great answer. I feel to add that, in order to avoid such situations, I was advised to add very very clear "final consignment" condition to freelancing contracts: "the code will be supplied and a VM with the toolchain used to compile final version will be provided. Code will be accepted as-is after your revision and anyway no later then xxx/xx/xx, code compatibility is to be intended only for OS xxxx, version xxxx. No further maintenance nor patching will be provided after xxxx. All UX/functional will not be changed after xxxx/xx/xx" — Oct 30 '17 at 14:29
Not sure I agree with "If you donÃ¢Â€Â™t all use similar processes, that is a current problem" conformity for the sake of conformity is usually a red flag for me, it assume's everyone works best in the same way. E.g. we all use git version control however there is no prescription on what client you use to access it by design. Some people like command line, some like a visual client — Feb 26 at 22:56

score 185 · Answer 2 · 2014-09-02 21:13:48Z

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.

One thing it's important to remember, too, is that commenting your code is not a sufficient form of documentation. It's an absolute necessity for any maintainable system, but it doesn't tell QA how to test it, and it doesn't tell support how to use it. You need to provide quality documentation for both technical and end-user perspectives. — Jan 24 '13 at 14:16
@enderland: In precisely the same way. When you have documentation to leave for the next person, the next person can largely pick up where you left off. The only issue then becomes one of experience and skill, to which the only solution is the new guy training up and spending time with the project, but he will have no shortage of reference material and there should be no "gaps in knowledge" if you've documented your work (including proper test documentation, as Polynomial quite rightly identifies). It's self-explanatory, even, IMO. — Jan 24 '13 at 19:23
@tvanfosson: That's why you keep documentation in version control, and fail code review when the documentation is not updated. And, yes, when you look at the documentation of course you check the "last modified" date and ensure that everything matches up, instead of just blindly taking it as god's word. Anyway, design and architecture documentation, being the most important, does not go out of date until you refactor everything. — Jan 30 '13 at 21:39
@David: I keep all my documentation up-to-date, because I'm a decent software developer. You should too. I don't understand why everybody keeps arguing against documentation using laziness as an excuse. If I can manipulate management in order to find time to keep my 1,000 pages of technical documentation for various projects entirely up to date, then I'm sure so can you. You might also consider revising your code check-in policies: no check-in should be accepted unless its tests and documentation source are updated in the same revision. (How do you "lose" documentation?!) — Sep 2 '14 at 20:42

score 122 · Answer 3 · 2013-01-24 17:12:55Z

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.

If you were really indispensable management would hire someone to walk beside you and take the hit for you. The only way to totally solve the hit by a bus problem is to make yourself unneeded and that is not in your best interest. — Jan 24 '13 at 2:14
@emory: Unneeded is not necessarily unwanted. You can put yourself in a position where you're not needed but you are the best choice and you are already doing the job, which is VERY much in your interests. Those who are utterly indispensable end up never being able to take a holiday, never getting a weekend off, working all night long and, if they have any pride at all, end up never being able to leave for a better job. — Jan 24 '13 at 2:34
@pdr is right, keeping yourself indispensable in your current role is a great way to stop yourself getting promoted — Jan 24 '13 at 8:50
@emory that's a poor example, both are non-technical roles. The nature of being promoted in engineering usually means becoming less technical. If the OP stays as the fountain of all technical knowledge instead of cataloguing and sharing it he opens the door to having people recruited in for non-technical roles above him. — Jan 24 '13 at 17:46
I disagree with this answer categorically. If you realize that, if you were hit by a truck tomorrow, your team could not function, then your team's "truck number", by definition, is 1 - you. This is a bad state of affairs, and it will inevitably affect you, because in any situation short of actually being hit by a truck in which you become personally unavailable in the office, your team will still try to get ahold of you by any means they can, even when you're in the hospital, on vacation, or working at your new job. — Jan 25 '13 at 1:02

Communityâ™¦ 1 · Answer 4 · 2017-04-13 12:48:42Z

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...}

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.

... so that its possible to get a promotion. If you are the only one who can do something your chances of being promoted is slimmer, as they need to you keep doing what you are already doing. If you aren't replaceable, you aren't promotable! — Sep 4 '13 at 8:50

score 16 · Answer 5 · 2013-01-24 00:02:15Z

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.

I see the problem of the OP constantly in my work. And I always try to do what you suggest. But what if the answer is always "it's great, we should do it, but we don't have time"? — Jan 24 '13 at 8:04
@dema80 All you can really do is explain the problem, propose a solution or solutions, and let the team lead or manager decide. In the end, they are paid to manage your time and are often privy to more information than you are (e.g.: we're getting out of that product in 2 months, so reducing the bus factor is likely a very low value task; we haven't told employees because some layoffs will be associated with this change in strategy). — Jan 24 '13 at 11:28
If your company is not thinking about their future then realize that they are not thinking about your future either. So if you are willing to accept that your company does not want to plan for their future then you are not planning for your future with the company either. — Jan 24 '13 at 15:23

score 13 · Answer 6 · 2013-01-25 15:19:39Z

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. Heshe 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.

The difference is that "The Protector" is someone who the company will want to get rid of. It's not a safe position. — Jan 10 at 22:52

Peter Mortensen 45547 · Answer 7 · 2016-11-04 17:21:27Z

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.

This is good but written nearly 100% from a software perspective... not necessarily as applicable for an engineer — Jan 24 '13 at 15:41
@enderland It applies to working in CAD, Word, Excel.... or most any tool.... Yes it is written from a coder perspective, but it applies across the board, imo — Jan 24 '13 at 17:13
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 - this observation is priceless and should be said out loud each morning while eating breakfast by every developer — Jan 11 '15 at 5:22

score 9 · Answer 8 · 2013-01-24 16:18:36Z

I'd start with

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.

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

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.

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

I agree with this answer overall, but I strongly disagree with 3rd point, which makes the (unfortunately) far too common mistake of confusing communication and team spirit with open space - open space does not foster good communication - regular reviews and pair programming does — Jan 11 '15 at 5:17

score 8 · Answer 9 · 2018-01-10 17:00:02Z

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.

@RhysW you have made some really good edits - normally though it's best if you are going to add so much content to add a separate answer - we are currently discussing this in chat here — Jan 25 '13 at 16:07

IDrinkandIKnowThings 43.9k1398188 · Answer 10 · 2013-01-24 14:50:09Z

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

user8365 · Answer 11 · 2013-01-25 16:11:30Z

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:

Where do I keep everything.

Examples of current requests and where I'm at in the process.

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.

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.

David K 20.8k1075110 · Answer 12 · 2018-02-26 19:21:23Z

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.

Not part of the answer: We (should) never document in text. We only document in systems that provide a useful output by themselves. Their documentation is a side-effect. (The way a launch checklist summarizes the most important parts of a plane. Or the way reception keys are a reliable way of listing the people who are still inside the building.) — Dec 16 '13 at 15:45

IDrinkandIKnowThings 43.9k1398188 · Answer 13 · 2014-02-21 17:50:17Z

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).

Why hand it to the board of directors not the CEO? Individual members of the board can part with the company and still have that password. Why not just accept that just as no individual is indispensable, no organization is indispensable. We will all - individuals and organizations - die someday. — Jan 24 '13 at 13:03
So the board of directors can attain super user status but what if none of them have technical skills. This does not really solve the bus problem. — Jan 24 '13 at 13:06
@emory - Actually they can give the envelope to someone who can get take over for your responsibilities. — Jan 24 '13 at 15:34
@Chad but enderland wrote "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 take that to mean that the board does not really have anyone they can hand over the keys to. — Jan 25 '13 at 13:15

Matt 1,26487 · Accepted Answer · 2013-01-24 03:48:21Z

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.

Great answer. I feel to add that, in order to avoid such situations, I was advised to add very very clear "final consignment" condition to freelancing contracts: "the code will be supplied and a VM with the toolchain used to compile final version will be provided. Code will be accepted as-is after your revision and anyway no later then xxx/xx/xx, code compatibility is to be intended only for OS xxxx, version xxxx. No further maintenance nor patching will be provided after xxxx. All UX/functional will not be changed after xxxx/xx/xx" — Oct 30 '17 at 14:29
Not sure I agree with "If you donÃ¢Â€Â™t all use similar processes, that is a current problem" conformity for the sake of conformity is usually a red flag for me, it assume's everyone works best in the same way. E.g. we all use git version control however there is no prescription on what client you use to access it by design. Some people like command line, some like a visual client — Feb 26 at 22:56

score 185 · Answer 15 · 2014-09-02 21:13:48Z

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.

One thing it's important to remember, too, is that commenting your code is not a sufficient form of documentation. It's an absolute necessity for any maintainable system, but it doesn't tell QA how to test it, and it doesn't tell support how to use it. You need to provide quality documentation for both technical and end-user perspectives. — Jan 24 '13 at 14:16
@enderland: In precisely the same way. When you have documentation to leave for the next person, the next person can largely pick up where you left off. The only issue then becomes one of experience and skill, to which the only solution is the new guy training up and spending time with the project, but he will have no shortage of reference material and there should be no "gaps in knowledge" if you've documented your work (including proper test documentation, as Polynomial quite rightly identifies). It's self-explanatory, even, IMO. — Jan 24 '13 at 19:23
@tvanfosson: That's why you keep documentation in version control, and fail code review when the documentation is not updated. And, yes, when you look at the documentation of course you check the "last modified" date and ensure that everything matches up, instead of just blindly taking it as god's word. Anyway, design and architecture documentation, being the most important, does not go out of date until you refactor everything. — Jan 30 '13 at 21:39
@David: I keep all my documentation up-to-date, because I'm a decent software developer. You should too. I don't understand why everybody keeps arguing against documentation using laziness as an excuse. If I can manipulate management in order to find time to keep my 1,000 pages of technical documentation for various projects entirely up to date, then I'm sure so can you. You might also consider revising your code check-in policies: no check-in should be accepted unless its tests and documentation source are updated in the same revision. (How do you "lose" documentation?!) — Sep 2 '14 at 20:42

score 122 · Answer 16 · 2013-01-24 17:12:55Z

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.

If you were really indispensable management would hire someone to walk beside you and take the hit for you. The only way to totally solve the hit by a bus problem is to make yourself unneeded and that is not in your best interest. — Jan 24 '13 at 2:14
@emory: Unneeded is not necessarily unwanted. You can put yourself in a position where you're not needed but you are the best choice and you are already doing the job, which is VERY much in your interests. Those who are utterly indispensable end up never being able to take a holiday, never getting a weekend off, working all night long and, if they have any pride at all, end up never being able to leave for a better job. — Jan 24 '13 at 2:34
@pdr is right, keeping yourself indispensable in your current role is a great way to stop yourself getting promoted — Jan 24 '13 at 8:50
@emory that's a poor example, both are non-technical roles. The nature of being promoted in engineering usually means becoming less technical. If the OP stays as the fountain of all technical knowledge instead of cataloguing and sharing it he opens the door to having people recruited in for non-technical roles above him. — Jan 24 '13 at 17:46
I disagree with this answer categorically. If you realize that, if you were hit by a truck tomorrow, your team could not function, then your team's "truck number", by definition, is 1 - you. This is a bad state of affairs, and it will inevitably affect you, because in any situation short of actually being hit by a truck in which you become personally unavailable in the office, your team will still try to get ahold of you by any means they can, even when you're in the hospital, on vacation, or working at your new job. — Jan 25 '13 at 1:02

Communityâ™¦ 1 · Answer 17 · 2017-04-13 12:48:42Z

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...}

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.

... so that its possible to get a promotion. If you are the only one who can do something your chances of being promoted is slimmer, as they need to you keep doing what you are already doing. If you aren't replaceable, you aren't promotable! — Sep 4 '13 at 8:50

score 16 · Answer 18 · 2013-01-24 00:02:15Z

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.

I see the problem of the OP constantly in my work. And I always try to do what you suggest. But what if the answer is always "it's great, we should do it, but we don't have time"? — Jan 24 '13 at 8:04
@dema80 All you can really do is explain the problem, propose a solution or solutions, and let the team lead or manager decide. In the end, they are paid to manage your time and are often privy to more information than you are (e.g.: we're getting out of that product in 2 months, so reducing the bus factor is likely a very low value task; we haven't told employees because some layoffs will be associated with this change in strategy). — Jan 24 '13 at 11:28
If your company is not thinking about their future then realize that they are not thinking about your future either. So if you are willing to accept that your company does not want to plan for their future then you are not planning for your future with the company either. — Jan 24 '13 at 15:23

score 13 · Answer 19 · 2013-01-25 15:19:39Z

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. Heshe 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.

The difference is that "The Protector" is someone who the company will want to get rid of. It's not a safe position. — Jan 10 at 22:52

Peter Mortensen 45547 · Answer 20 · 2016-11-04 17:21:27Z

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.

This is good but written nearly 100% from a software perspective... not necessarily as applicable for an engineer — Jan 24 '13 at 15:41
@enderland It applies to working in CAD, Word, Excel.... or most any tool.... Yes it is written from a coder perspective, but it applies across the board, imo — Jan 24 '13 at 17:13
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 - this observation is priceless and should be said out loud each morning while eating breakfast by every developer — Jan 11 '15 at 5:22

score 9 · Answer 21 · 2013-01-24 16:18:36Z

I'd start with

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.

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

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.

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

I agree with this answer overall, but I strongly disagree with 3rd point, which makes the (unfortunately) far too common mistake of confusing communication and team spirit with open space - open space does not foster good communication - regular reviews and pair programming does — Jan 11 '15 at 5:17

score 8 · Answer 22 · 2018-01-10 17:00:02Z

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.

@RhysW you have made some really good edits - normally though it's best if you are going to add so much content to add a separate answer - we are currently discussing this in chat here — Jan 25 '13 at 16:07

IDrinkandIKnowThings 43.9k1398188 · Answer 23 · 2013-01-24 14:50:09Z

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

user8365 · Answer 24 · 2013-01-25 16:11:30Z

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:

Where do I keep everything.

Examples of current requests and where I'm at in the process.

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.

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.

David K 20.8k1075110 · Answer 25 · 2018-02-26 19:21:23Z

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.

Not part of the answer: We (should) never document in text. We only document in systems that provide a useful output by themselves. Their documentation is a side-effect. (The way a launch checklist summarizes the most important parts of a plane. Or the way reception keys are a reliable way of listing the people who are still inside the building.) — Dec 16 '13 at 15:45

IDrinkandIKnowThings 43.9k1398188 · Answer 26 · 2014-02-21 17:50:17Z

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).

Why hand it to the board of directors not the CEO? Individual members of the board can part with the company and still have that password. Why not just accept that just as no individual is indispensable, no organization is indispensable. We will all - individuals and organizations - die someday. — Jan 24 '13 at 13:03
So the board of directors can attain super user status but what if none of them have technical skills. This does not really solve the bus problem. — Jan 24 '13 at 13:06
@emory - Actually they can give the envelope to someone who can get take over for your responsibilities. — Jan 24 '13 at 15:34
@Chad but enderland wrote "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 take that to mean that the board does not really have anyone they can hand over the keys to. — Jan 25 '13 at 13:15

Search This Blog

Iyfjky

How can I prepare for getting hit by a bus?

13 Answers
13

protected by Communityâ™¦ Jan 27 '13 at 15:21

13 Answers
13

13 Answers
13

protected by Communityâ™¦ Jan 27 '13 at 15:21

Comments

Post a Comment

Popular posts from this blog

Long meetings (6-7 hours a day): Being â€œbabysatâ€ by supervisor

Is the Concept of Multiple Fantasy Races Scientifically Flawed? [closed]

Confectionery

Category

Random preview

How can I prepare for getting hit by a bus?

13 Answers 13

protected by Communityâ™¦ Jan 27 '13 at 15:21

13 Answers 13

13 Answers 13

protected by Communityâ™¦ Jan 27 '13 at 15:21

Comments

Post a Comment

Popular posts from this blog

Long meetings (6-7 hours a day): Being â€œbabysatâ€ by supervisor

Is the Concept of Multiple Fantasy Races Scientifically Flawed? [closed]

Confectionery

13 Answers
13

13 Answers
13

13 Answers
13

Long meetings (6-7 hours a day): Being â€œbabysatâ€ by supervisor