Company does not understand what the “bus factor” is and continues to give me more and more responsibilities

Question

At the company I am working for, I believe is beginning to give me more and more responsibility. Trying to get me to be responsible for more and more pieces of the application and infrastructure we are building.

However, in tandem with this, they are not giving me a team to work with, to get other people to learn what I am doing. They are very resistant when I suggest that I will take initiative to teach other people what I am doing so they can learn it. In case I can’t work on it for some reason (both management and also the people I am choosing to teach are resistant).

They want me to be the person solely responsible for an uncomfortably wide and growing swath of the application.

In short, my company is intentionally decreasing my “bus factor,” and are resistant to the point of outright denying me when I suggest that this is not healthy, and that I want to raise my bus factor by coaching and mentoring others in the company. As well as hiring more people who can share my knowledge and responsibility (I am the most recent hire at the company and I have been working for almost 7 months).

I’ve explained the concept of “bus factor” to my manager (who is the CTO of the company; there is nobody above his head to go to) and to other senior people in the company. Their answer is “We need this done fast, you know how to do it. Just do it and don’t waste your time or company time teaching or coaching others.”

Does anyone have any suggestions as to how I can increase my own personal “bus factor” in this situation?

Answer 1

You have done the number one thing that you can do to help the company: call it to their attention and give them the chance to get in front of this. They have decided not to take any action, with the statement "don't waste your time" they're trying to forcefully end the discussion. You are basically left with some things that you can do to help the company by yourself:

1. Write documentation. As someone who has taken over software projects where no one in the company knows how they work, I would've come on-board much faster with better documentation. General architectural diagrams for the project and state machines for the complicated parts probably offer the biggest bang for your buck.
2. Write tests. A good testing suite will immediately inform others that their changes are breaking things. And of course, even a crappy testing suite offers some protection.

The big advantage of both of those things is that you need them whether or not you are going to be hit by a bus. Supposing one day your boss sees it your way and hires someone else to takeover the project, having good documentation and tests will help you pass the project off to someone else without a horrible transition period. Good tests will also help you reject bad code if the person they hire is overly ambitious in updating the code.

Answer 2

I've explained the concept of "bus factor" to my manager (who is the CTO of the company; there is nobody above his head to go to) and to other senior people in the company, and their answer is "we need this done fast, you know how to do it, just do it and don't waste your time or company time teaching or coaching others".

Does anyone have any suggestions as to how I can decrease my own personal "bus factor" in this situation?

The CTO told you what to do. You need to follow his directions.

You can create really good documentation in your spare time, and build simple, straightforward systems and processes. Both of these will help should you no longer be around.

But basically, this is not your problem to solve. By definition, if you are "hit by a bus" (or otherwise aren't around), others have to solve the problem of your absence.

The CTO gets to decide how his team's work is allocated. You'll just need to go along with it.

Answer 3

It's somebody else's problem.

It is very considerate of you that you do not want to be the single point of failure for your whole organization. More people should be that thoughtful of their colleagues and that loyal to their company.

But if your warnings fall on deaf ears, then you did what you could. So instead of wasting any more time and energy on preventing the CTO from making such a grave mistake, just use it for your benefit. Enjoy the job security. Next time you want to renegotiate your salary, do not forget to mention how dependent the company is on your niche knowledge and in how much trouble they would be if you would decide to leave.

Answer 4

I'm going to echo a few things others have said with a different emphasis:

• Having a low bus factor is good for you.
• Having a low bus factor is bad for the company.
• You are taking too much responsibility for the company.

You have brought the issue up to your superiors, and that is good and honorable and you've tried to make the company more robust. If increasing the bus factor fails to happen, then that just increases your personal value and leverage in the next raise/salary negotiations. (It's a very common joke that someone might work to make themselves indispensable in this way.)

Do not take the company's side in your thinking about responsibilities. (Unless maybe you're the owner, which you clearly are not.) Make sure you use the leverage you've been handed in your next negotiation. This may seem unkind or ungenerous, and a bit weird that most days you're pulling cooperatively for the company, but in salary negotiations you need to look out for yourself and not the company. They would almost surely drop you as soon as the business logic made sense. If they are burdening you with more responsibility for the company's well-being, then they must be willing to pay you more, or else suffer when you leave for greener pastures (with a well-burnished resume, given all the things you can say you've handled).

But: It sounds to me like you may be selling the idea to your superiors as, "hire more people so I can teach them stuff", which even to my ears sounds like a waste of resources (hire people who just learn stuff and don't do anything, like bench players?). The sales pitch here has to be in terms that the business people understand, like, "We need to hire someone who can manage the server, because I'm losing too much time context-switching from development tasks". You need to pitch an actual job or project for people to do, not just be a recipient of learning. Once you have extra people assigned to your project, then it should be easy to hand out a variety of tasks so they learn different parts of the technology. That wouldn't cost the business any extra money, and will be much easier to get the senior people to accept -- or maybe they just don't need to know about that part at all. Regardless, the first sales pitch to the business has got to be, "We need more people working on this project to make it better/faster", not "We need more people to do more learning".

Answer 5

It's a startup, so the rules of the game are very different.

Most of the time, a high risk strategy of just do it without overly planning for all eventualities is absolutely the way to go. Typically there are loads of things that can only be done by one person - there simply aren't enough resources to hire for redundancy of skills. It's the nature of the game.

I have a bit of a problem.. the company I am working for.. is beginning to give me more and more responsibility and trying to get me to be responsible for more and more pieces of the application

That's not a problem at all, it's a fantastic opportunity for you - one of the best things about working at a startup. Seize it!

I've explained the concept of "bus factor" to my manager.. and to other senior people

Their answer is "we need this done fast, you know how to do it, just do it and don't waste your time or company time teaching or coaching others"

They have full information, you've done your professional duty to make sure of that, and they've decided on this legitimate strategy. Execute it!

Answer 6

I think you're misreading the situation. Modern tech companies tend to appeal to the younger workforce by offering what appears to be indispensable and very important part of the organization. They do this by either making you the sole responsible person, make you appear to be the "go to" person for some subject, and offer you seemingly pricey things like laptops, corporate cards, training/classes/conferences, and even your own bed or 24/7 gym access. Things that were once available only to CEOs and upper management now offered to the lowest tech employee as part of their onboarding process.

With that said, you are not the "bus factor." I hate to say it. I can tell because they already told you to stop complaining and do the work they said.

My advice: don't worry about it. It's not your issue if the company goes under. However, my thought is that you are not as important to the organization as you think you are. That's a bit mean but it's the truth. Just do your work and if you start to get overworked, it means you allowed them too much. Make yourself busy and say you can't do it because you have prior obligations. You'll get less of the emergency demands and you'll see they'll find that new "go to" guy all by themselves.

Answer 7

I'm in agreement with most of what everybody else is saying, but something I think is missing:

There's a potentially cynical side to this as well. Unless your CTO is very inexperienced, he should perfectly understand the operational risk presented by having one person responsible for so much of the tech stack. It may be that he really believes that he needs to squeeze every drop of efficiency out in having everybody work in silos, but taken to this extreme doesn't seem realistic. In this market, hiring software talent for startups can be very difficult and I've seen/heard of startups doing a number of insidious things to dissuade their talent from going elsewhere.

It's possible that your CTO wants people to have sole responsibility over things so that they might feel guilty about leaving. If you receive another offer, you might feel less guilt about taking it if you knew your current employer would only suffer a minor setback from your departure. Instead, because there's so much you are responsible for, leaving them could cause a major blow. Assuming you have goodwill towards your current coworkers, causing them immense trouble would naturally lead you to feel guilty. They may be exploiting your compassion in this way.

Answer 8

I agree with the highly voted answers that basically say "this is not your problem" but I'm writing an answer to frame challenge your question, and the conclusion that there is actually a problem, because I think there's a learning opportunity present in this issue that's being glossed over.

Companies make decisions about who does what work based on a number of factors. From an employee's perspective, this can be confusing and very easy to misinterpret for a number of reasons:

• Sometimes they change over time, or are inconsistent
• Sometimes they're intangible, or unconscious "gut feel" factors
• But often, they are related to factors that individual contributors don't have any exposure to or direct knowledge of, like budgeting, resourcing, or professional development plans for other individuals

Because of this, it can be really hard to interpret work assignment decisions - which is a big part of why the "it's not your problem to solve" answers are correct, but should probably be taken a step further: it's not really even "your problem" to identify as a problem.

This is relevant to "bus factor" issues because individual contributors are often not in a good position to understand the bigger picture about how decisions are made, and can miss important factors. Something that looks like a problem to you might be perfectly okay to the leader who is responsible for it.

As an individual contributor, it might sound ideal to have full redundancy on every role, fully trained and capable backups for every single process, and a team of people who are expert in every skill instead of just a single person. Having every single process documented to the degree that any person could pick the documentation up and solve any problem would certainly reduce the stress for everyone!

However, from a leadership position, when you're trying to balance expenses and profits against risks, taking that "back up every person and always have a plan B for everything" approach would likely be prohibitively expensive.

My first exposure to this sort of decision making process came early in my career, but in a slightly different context: maintenance management and the science of reliability and preventive maintenance planning. I was working in a software role for a consulting firm that set up asset management software for large utilities, including several water treatment facilities. Our software could manage regular preventive management programs for every piece of equipment in the facility. However, I quickly noticed that many of our customers chose not to perform preventive maintenance on some of the equipment in their plants. That was a little alarming to me: wouldn't you want to rebuild that pump every year, and thus keep it from ever failing? Isn't the ultimate goal to reduce or eliminate failures and corrective maintenance, no matter what? And shouldn't there be a backup sitting right next to it, so the process can continue when there is a failure?

Ultimately, I learned that the goal isn't redundancy and prevention at all costs: the goal is to achieve the lowest total cost. Sometimes, that means letting a certain pump fail. Of course, the pumps that were critical to the operation got careful preventive maintenance and had online spares, so failures were rare, and even if there was a failure, it would be handled just fine. But the pump for a less important process didn't have any backup and wasn't regularly maintained. When it failed, it might cause some disruption, but it was addressed and life went on. It was - quite literally - not worth having redundancy for that pump.

The same approach holds true in process management for IT and knowledge workers. Sometimes, there are processes or infrastructure that are quite critical to the business. Those should have contingency plans and lots of attention. But the server sitting in the corner that's a test bed for something not critical to the mission? It might not be important for anyone in the company to understand every little nuance of how to manage it, much less for there to be two people who do. Basically, the lesson is: just because some task doesn't have full documentation, full staff redundancies, and 100% knowledge sharing, doesn't mean there is an actual problem that needs to be solved. Most organizations are chock full of processes that aren't that thoroughly shored up, on purpose. Organizations make decisions about how much they are willing to invest in things like cross training, redundancy, and knowledge transfer, and those decisions often legitimately result in do nothing, let it fail and we'll figure it out.

To bring this all back around to your specific situation:

On the one hand, you need to look out for yourself. If your employer is doing something that clearly has a negative impact on your career, or puts you in a position you're unhappy with, you should identify that and seek to work with your boss to resolve it - or, get a different job if it's not something the employer will budge on. If you are worried about "bus factor" because your employer is abusing the employment relationship by preventing you from taking vacations, or calling you every night at 2 AM to reboot servers, then you should absolutely raise that as a concern.

But, if your concern is simply that you're the only person who knows how to do something, or the only person responsible for doing a specific task, and there are no further actual ramifications that impact you personally, that - in and of itself - might not actually be an issue. If you are concerned because of the potential impact to your employer should you not be available to do that task, you should raise that concern. But, your employer may have legitimate reasons for not changing anything, if they determine that the risk is acceptable based on their plans. In this case, reporting the issue will help get it off your mind, and then you can move on with life knowing that it's not your problem and you've alerted the people who are actually responsible.

If you do decide that being in this situation makes you incredibly unhappy regardless of all of the above (or if your employer is abusing you), and you're unhappy enough to decide to look for another job, make sure you take a step back, identify the factors that lead to your unhappiness, and evaluate potential future employers based on those factors. If you don't want to be a single point of failure in your next job, make sure you research potential employers to learn how likely that will be - for instance, working for a tiny startup will probably be a bad idea, because in a tiny startup, pretty much everyone is a single point of failure all the time. But on the other end of the spectrum, an large and well established employer in a tightly regulated field like healthcare or finance will likely have thorough redundancies and lots of cross training - that might be a great environment for you.

Also, as you interview, make sure you ask relevant questions that give potential employers the opportunity to explain these factors to you. You can ask about team size, cross training, work assignment, or other related factors, in order to help you determine if that employer is a good fit for you or not.

Or, if you find yourself in a position of really wanting to actually be the person who decides these sorts of things for a company, consider working your way into leadership roles, where you can be in the driver's seat of addressing things like the bus factor, instead of just being the "victim" of someone else's choices.

Answer 9

First, you're not as indispensable as you think you are. Key people leave all the time, and things slow down for a while, then the people remaining figure it out. Life goes on.

There are a couple things you should do, though. One is making sure you aren't the only one with access to log into key infrastructure, even if no one else actually uses that access. The other is making sure you're getting basic reviews of your decisions. People don't need to understand your tasks to the same level you do, you just need someone to run your decisions by to make sure they're reasonable.

Answer 10

Sounds like it's time for an Engineer Appreciation Day!

Do you have paid time off that you can take advantage of soon?

Take a day or two off, and make yourself unavailable by phone / email. Appoint whoever knows the most about your responsibilities as a backup, but make it clear to them ahead of time what's going on.

Your organization needs to understand in real terms what the "bus factor" feels like, before they lose an employee.

This is a quick, easy way to clear your head when things pile up (mental health is important!), and teach the management a valuable lesson about resourcing and documentation.

When you come back to work, make sure to take note of what didn't get completed, and make specific suggestions for how to prevent bottlenecks in the future. Management should be a little more receptive this time around, especially with a fresh example in mind.

And if old habits persist and you find yourself in the same situation in the future, give some warning, and follow up with another Engineer Appreciation Day.

(Don't actually call it that, tell them you're taking paid time off for personal reasons and leave it at that, but you'll know what day it really is!)

Answer 11

I don't want to be the guy who never gets work done because everyone is always asking me to take over things that are their dependencies. E.g. server goes down, I'm the only one who knows how to get it back up, I have to drop whatever else I'm doing to get the server back up. I'd like it if the person who notices the server is down also has the expertise to get it back up without bothering others.

This comment should have been in your original answer as everyone telling you to ignore it is failing to realize that it also has negative repercussions for your career.

I see two potential pathways:

1. Exaggerate the difficulties/be terrible at one key thing in your duties. A friend of mine is very good at fixing bugs and got hired due to that talent. However, this company forgot to tell him that he would be fixing bugs on a musty old system using things like Perl and ancient versions of Java. He obviously didn’t want to learn old and out of date technologies, so his solution was to make a mess of it but do good work on the greenfield project (his time was split between them). He got moved 100% to the greenfield as he was "useless" on the older systems. Being excellent at work nobody wants to do and nobody really values is a way to make sure you get stuck doing it. This has the benefit of forcing their hand but has the consequence of making you seem less capable. Whether that matters depends on whether this is a company you are sticking with long term (lifer). You can use the extra time gained from incompetence to upskill yourself. So maybe you are now terrible at server configuration, forcing them to find someone with that skillset. You can share the burden with them.

2. If you are a lifer, write the documentation and do informal coaching anyway. When someone has a problem, you send them first to the documentation and if it is insufficient, then make sure they stick around while you solve the problem. If you plan to stay with this company long term, just do it. You will either succeed at your goal or realize that you will soon be moving anyway due to frustration and thus there is no reason to put in discretionary effort which is not valued or recognized. If after this the boss still doesn’t want it, the other answers become correct in that it is not your problem.

Answer 12

You might teach them what bus factor means, by showing some consequences. Take three weeks of vacation, say you go hiking to the mountains and won't be able to take your mobile phone with you. For other people it is surprising, how often they have to rely on you. Maybe you will find your boss displeased by your trip and your unavailability. But then you can ask him, what would happen if you had an accident and would be lying in the hospital for three weeks.

Answer 13

I do not agree with other answers this is good for you.

One good argument is that there is a need for rest and holidays time.

I once were in your shoes, and whilst I did not stabilized fixed the infra-structure that I "inherited", it meant holidays spending a medium of 2h-4h in the phone giving support to others, because nobody else could do it. (short story, there is a longer story for it)

Also, having a team of at least two, in means in crisis situations, there is an extra pair of eyes to help prevent mistakes, or even someone to pick up your work while you rest. Once in a similar situation and under a persistent cyber attack I logged easily 100 hours of extra time...in a single month.

Also having help, means things can be better planned, documented, and there is more space to do proactive work and new projects.

So, it is just not the bus factor that is at stake here. You can have much more solid arguments.

As for the reasons your CEO is doing this, I suspect it is a matter of controlling things. They prefer to have it on the hands of someone they trust, and not having too many prying eyes on sensitive matters. However, that can backfire easily for several reasons.

Answer 14

Obviously, they're either not getting the concept of "bus factor" or pretending that they don't understand. I would stop trying to find ways to explain this if they didn't get it after the first time you explained it.

Much better to instead frame you concerns as needing a mechanism for temporary support for key responsibilities prior to taking a vacation or when you need to take on other tasks.

Usually, when management acts weird or non-responsive about important issues that you're trying to bring up, it's because they're not telling you something or they categorically disagree. If you don't have the kind of workplace where you can talk about things frankly across hierarchies, you can only guess what their reasoning is. It could be anything ranging from "if @Ertai87 leaves, we'll just hire a consultant to take over" or "@Ertai87's job functions aren't critical" or "@Ertai87 said something about 'a bus', he's going to leave, let's surreptitiously start a search for his replacement".