Comment by an-allen | Hacker News Reader

Comment by an-allen | Hacker News Reader

Real Story Here. A colleague and I developed a training course on the Foundations of DevOps. We started the course off with a discussion about risk in Software Delivery and IT in general. Attendees would often surface the "Key-Person Risk" or the "Hit by a Bus Risk" to which we would use as a teachable moment for pair programming, cross pollination, and measuring and improving the time it takes for new joins to become productive with the systems and or code base. We would illustrate that one of the ways we mitigated the Key Person Risk with the course was to always deliver it in pairs.

My colleague was tragically struck by a car and killed about three months ago. The course suffered an immense blow to the knowledge capital it had - but due to the fact that we had planned to mitigate against key-person risk by pairing - the course was able to survive and retain a fair bit of the legacy my colleague left behind.

I just share this to say that the getting "hit by a bus" scenario is something that, much like this post, we throw around in jest and treat in a laissez-faire fashion. The fact is that it is a tragic, unimaginable, event that does in fact occur from time to time and something I will take seriously for the rest of my life.

I'm very sorry for your loss.

I've heard "wins the lottery" as a less morbid metaphor for the same concept: one of your employees stops working in a low-probability event. Of course the higher-probability event is leaving their job (but somehow it's less polite to just say that); you usually get two weeks to hurriedly start documenting things, and with the current state of employee/employer relations you might easily get less. Or they might have several days of vacation saved up.

I don’t like when people use “wins the lottery” because it leads to distracting tangents. A person that wins a lottery could do anything. How much did they win? Maybe they’ll still keep working? Maybe they’ll go off to start their own company and take a bunch of key employees with them? Maybe they’ll be broke in a year and come back to their job? Maybe they don’t leave right away? These are just distractions you don’t need when illustrating a point.

By contrast, a person being struck by a bus and killed has a definite finality to it. There is no going back. There is no hope of extracting knowledge from the once living individual. There is not even time to prepare. Their existence and their output has ceased and everyone alive must now live in this new reality.

The great thing about hypotheticals is you can just say "wins the lottery, leaves the job, and never comes back" and it's implied in the scenario that you shouldn't read too much into it.

A lot wordier than "hit by a bus" though.

Some people wouldn't dare speak to their former employers, let alone help them, if they won the lottery. Death or not, winning the lottery can be just as effective in getting rid of someone.

I agree, and the "don't want to talk about morbid stuff" shows an overall immaturity in thinking about risk and controls. People die, people get sick, people leave for other jobs or roles, people steal. The institution has to be able to survive.

That's not to say folks should be callous about it. But failing to think about things like this is also unfair and stressful to employees who are not dead.

Hm. I guess if you read it as a euphemism for getting a better job offer elsewhere, winning a medium-sized lottery prize is more accurate: you can, in theory, contact a former employee, buy them drinks in exchange for getting their advice on a thorny problem, counteroffer them either now or in a year, etc. (And with a larger prize it's not impossible they'll use the winnings to start their own company or maybe even split the winnings with a coworker they're friends with.

Winning a lottery prize large enough to never talk to anyone again, and getting hit by a vehicle, are both very low-probability events. Employees (especially good employees, and perhaps in groups) leaving is a much more pressing risk.

I think it's pretty clear what's meant by it, and "hit by a bus" has very similar problems if taken too seriously. Were they hurt? Are they out for a few days, just shaken, decide to change their approach to life etc.

> How much did they win? Maybe they’ll still keep working? Maybe they’ll go off to start their own company and take a bunch of key employees with them? Maybe they’ll be broke in a year and come back to their job? Maybe they don’t leave right away?

Well exactly. You don't know, and now you've given yourself four scenarios to think through:

1. Employee remains.

2. Employee leaves forever, maybe with others.

3. Employee leaves for a while but would come back.

4. Employee leaves, but with some time to plan.

1 should not be a difficult thing to plan for, and 2-4 all ask the same major question of "what if they leave". There's perhaps a slight benefit of not having to say "well assuming you are dead..." - I know I've had some time this year where I was trying not to focus on a death.

The key point is the risk. If your answer to "what if X wins the lottery" is "well as long as they don't want to leave..." then you're already setting yourself up to answer the question it's intended to propose - what if they are no longer working for the company?

the problem with 'wins the lottery' as a metaphor to me is basically that one is calling the winner a jerk..

if I suddenly could retire without a care in the world, I probably wouldn't mind dropping in for a day or two every now and again for knowledge transfer, even if I didn't like the company overall, to help my teammates..

At my job we say "hit by the lottery bus" to make it clear that we're using a euphemism for "what if this person quits".

I am the same way, but we are not the norm. In fact, most people don't even want to provide the occasional consulting once they leave the team (but stay at the company), let alone the company. There's also the problem of where to draw the line. Is a quick question ok? What about a bunch of questions? What about asking for a training session? What if the question requires diving back in to the source code to answer? Everybody has a different opinion and tolerance threshold.

I’m happy to provide consulting if you’re happy to actually pay me for my time. Otherwise I’ve got hobbies. I’ve had one job total where the company asked me questions and they stopped the instant I mentioned cash after 7 hours of chatting. I asked because it was actually taking measurable time to answer things. It’s up to them if they want to trade 60 hours of someone relearning a thing instead of an hour of me contracting. Not sour grapes actual numbers from a thing an employee mentioned at a party they did (gdpr) that I had 3 simple solutions to in minutes.

Yep. In every company I've been in here in the UK, I have pretty much never heard of an ex employee returning to explain their work, fix a bug, do training, etc. And well, the more people leave a company, the less likely they are to come back to help at all, cause of a 'toxic' atmosphere or sub par working conditions.

I think pride plays its part here. People want to prove that they could indeed cope without the person. I think there is also the point where people think, "we are going to have to learn this stuff one day, it may as well be now".

In some key-person areas long notice periods (3months, for instance) are the norm. However this is never going to be the most productive 3 months of anyone's life! Serving 3 months notice becomes very dull by the end...

I will never do consulting again for a former employee unless I get paid upfront. A previous employer "adjusted" an incredibly reasonable bill. Then two months later their nginx server goes down and he calls me in a panic. I required them to deliver the check before I even took a look at it. Out of spite I charged him a near egregious amount because of that. On the plus side the office manager had a grin on her face, she forced the owner to pay the full amount of the previous bill. She thought it was incredibly underhanded.

As far as I can tell, "hits by a bus" is actually the euphemism. The highest probability way to lose an employee is just the employee quitting to work somewhere else. But you can't say that because it implies that your current workplace is suboptimal. Whereas "hits by a bus" is out of the control of your employer, so safe to say...

It's hit by a bus because an employee leaving, or dieing of a prolonged illness leaves you time to plan for a departure or possibly ways to retrieve information from them after they are gone. Immediate unexpected death is a worst case, and "hit by a bus" neatly sidesteps a lot of questions such as whether there was someone with them, whether the other party in the accident was hurt, etc which can derail the point.

Perhaps its "hit by a bus" because assuming that an employee will give you a solid 2 weeks of documentation on leaving and will be able & willing to answer questions after they leave is very much not a safe assumption.

Devs stay in one place like 15 months

Occassionally a 2 year stint just so some Gen X-er that reviews their resume’ doesnt consider them too noncommittal

No need to mince words about people leaving

I don't know if this is the norm outside of SV. I typically stay four years at a position and almost every interview I've had, people will comment about how short of a tenure that is.

It's definitely not unusual for developers to stay in roles for a decade or more. Especially very good ones.

Its not the norm outside VC-backed tech land

There is just a lot of stuff to build and a salary that needs to increase 30% every other year

I see all the comments about needing huge pay bumps every 2-3 years and then I also see things about how you can’t get a job in sv over 40. I wonder if it’s related

Food for thought but probably not

I'm not so sure the 30% pay increase with every job hop is necessarily the norm either. Maybe at first when you're moving up from entry-level to senior. But in some markets, you hit the regional salary cap after four of those and you're stuck with 2-4% annual raises -- even with in-demand skill sets.

If I posted the job offers I've received for having experience with Spark/Hadoop, building / productionizing machine learning models (since 2011 even), an AWS certificate, and 15 years worth of other worthwhile skills, people here wouldn't believe me because they are so low. Definitely well below the startng salary of someone at Google. Yet I've had three, all of which were basically identical.

Mind providing a source for this? I read this all the time but it doesn't match my experience here in Germany.

1.5 to 3 years doesn’t seem to be too far off the mark.

https://insights.dice.com/2016/07/08/how-long-do-tech-pros-s...

Thanks for the backup

Maybe some people stop wasting their lives tallying the years instead of tallying those 000s

In b4 “but I like my manager and team”

Hmm, data compiled from "Public Profiles". I wonder where they got "Public Profiles", listing people's profession and length of tenure. Could it be places like LinkedIn or Dice, and could it be that such places overrepresent engineers inclined to switch jobs?

Personally, I'd be disinclined to interview a candidate with >= 3 jobs on the resumé, none of which lasted longer than 2 years. Taking into account the time spent for them to get up to speed, and the time their successors would have to spend taking over their code, it seems unlikely that their tenure would make much of a positive impact.

Furthermore, a key driver of experience in software engineers is maintaining their own code over multiple product cycles. Job hoppers not only don't acquire that experience, but may actively fall into a habit of bailing as soon as they get sick of their own code.

Well,two points.

- Salary compression especially early on in your career is real. Most companies don’t do market adjustments after you are hired and only adjust salaries by a predetermined very low amount. The only way to get market salaries is by frequent job changes.

- If you have a job and people are willing to hire a job hopper, why not leave? At some point it will be a negative but when that time comes, just stay at a job until you get a better one. Also, if you do change jobs make sure it’s for the right reasons. For me, it’s technology, environment, and money in that order.

Covers only the SF region (with a questionable data gathering methodology).

Same for me. I've been at SAP for nearly 7 years now, and I know only a handful colleagues who left the company. Some people moved to different teams though, so that may count as well, but retention is still way way way higher than 1.5 or 2 years.

Hmm. Been at the same company over five years because there were drastic changes/new things every six months. Luckily they were able to do a few promotions and stuff... :)

Seeing it as a euphemism is, itself, morbid.

“Guys, I have some bad news. Brian, our star programmer, is leaving to work for a competitor.”

‘Oh no! We depended on him so much!’

“Hah! I’m just messing with you. He was hit by a bus and died.”

‘Phew! I was worried I had a job that didn’t pay competitively!’

Flight risk is another term one could use.

A lottery number and a bus number are slightly different values. A lottery number you can still find the person and they may be enticed to help.

http://wiki.c2.com/?LotteryNumber vs http://wiki.c2.com/?TruckNumber

In the "wins the lottery" and "left for a new job" cases there is at least the possibility of knowledge transfer. I was brought in on a situation where the primary IT lead suffered a stroke, rendering him unable to communicate for weeks. We had to reverse engineer everything, crack passwords, rebuild servers, etc. This is, unfortunately, my go to example of the need to mitigate risk of a central point of failure.

That's really tough. Sorry to hear about that. It's all abstract until it actually happens and then suddenly all those lessons bear fruit. You of course hope you'll never need them, but just in case you (or those that take over from you) do you will be very happy (insofar as the situation allows) that you were prepared.

It is an interesting phenomenon that I hear several times per year 'but what are the chances of this actually happening?'. The chances in any particular case are pretty good. But with 43 companies we looked at in 2018 and 100+ over the last years there are multiple such instances that I can refer to so even if the chances are not super high they probably are a lot higher than you think they are!

Actuarially, just go with 1 per 1000 employees for bigger companies. Go 1 in 3000 as a lower boundary, but as high as 1/500 or less for companies with older or lower skilled employees.

I do agree with other commenters that your procedures should keep you safe in case of regular churn (say 1 in 3 to 1 in 10) or even non-regular churn (say due to a toxic team-lead and a whole team quitting).

Ideally procedures should be in place that treats all these events quite equally and favor robust practices.

Upper management tend to travel quite a lot and tends to be under high levels of stress. So turnover there, due to buses, disease, burn-out or other mishap is substantially higher than in the population at large. And of course they can simply stop showing up one day for reasons all their own as well. In all of those cases it might as well have been a bus.

We had a colleague pass away abruptly a month-ish ago. So much disappeared with him. And I kept finding myself typing out, "oh ____ would know that" before reality caught up with me.

It started to get really frustrating and upsetting. I'm not exactly a "pair programming" zealot but I definitely find value in overlap of responsibilities.

Reply on news.ycombinator.com