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?

  • 1
    Comments are not for extended discussion; this conversation has been moved to chat.
    – Neo
    Commented Jan 17, 2020 at 12:44
  • There's a suggestion to close this question as a duplicate of "how can I prepare for getting hit by a bus." With respect I disagree with that suggestion: this question is "how can I persuade my company to ...."
    – O. Jones
    Commented Jan 20, 2020 at 16:28
  • It clearly appears as there is an important delivery to be made on schedule, and you are the one to do it. Focus on that and then come back to the rest when the delivery is finished. Commented Jun 3, 2020 at 15:38

14 Answers 14


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.

  • 4
    Another thing you could do is take a week off. Then (maybe) they'll realize what a problem this is.
    – Ben
    Commented Jan 15, 2020 at 18:46
  • 15
    OP has been there for 7 months. If he gets "hit by a bus" the most they lose is 7 months worth of one employee's work. Perhaps they don't consider that a huge loss and are willing to play the odds, hope it doesn't happen and be able to achieve a short-term goal within a certain timeframe instead. Taking more time to perform tasks because you're documenting them might not be what's wanted of OP or best for the company.
    – Aubreal
    Commented Jan 15, 2020 at 19:12
  • 22
    In response to "why are you doing documentation" I would reply "I'm getting so much extra work I need notes I can refer back to." I would stress that the documentation should be of the "notes" variety not a complete user manual for everything. "procedure to do X" is useful to make sure I don't miss a step, "Y State Machine" is useful to double-check while debugging. "Why the company originally planned Z" is not. But even notes will be useful to OP's replacement.
    – Dragonel
    Commented Jan 15, 2020 at 19:34
  • 3
    @dbeer Neither have I, but I have also never worked at a company where I was explicitly denied from reducing my bus factor. Fundamentally, OP noticed something he thought was a problem and brought it up to the CTO. The CTO said it's not a problem. Ergo, it's not a problem. If OP doesn't like this decision, he needs to either work on convincing the CTO, or understanding the CTOs reasons, or else start polishing his resume. Trying to work around the CTO is not a plan for long term success. Commented Jan 15, 2020 at 19:59
  • 14
    I can see many good reasons for that: a startup may be almost out of money. If you will implement that crucial feature as quickly and cheaply as possible - they may get more funding. If you spend time/money on testing and documentation - they will certainly die. I would try to talk and understand your CTO's reasons. Try to be his partner rather than opponent.
    – jhnlmn
    Commented Jan 15, 2020 at 21:56

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.

  • 51
    I disagree with this answer. He's in an understaffed startup. He most likely doesn't have "spare time". Plus, he'll most likely be told "don't waste your time writing documentation and don't waste your time refactoring the code", since they essentially told him the same thing about training replacements. Commented Jan 14, 2020 at 19:46
  • 145
    "The Company" has been informed... and has made their decision. This answer is brutal but simple
    – WernerCD
    Commented Jan 15, 2020 at 2:47
  • 63
    The bus factor doesn't need the OP to be "dead". He can be a consultant earning 3x the salary. Nothing teaches a company better than hitting their bottom line.
    – Nelson
    Commented Jan 15, 2020 at 3:31
  • 15
    Is spare time used as out of office time like in being at home? Or is it used as in office time when there is nothing to do? I doubt with his workload he wouldn't have much of time in office when there is nothing to do. And for other type of spare time, after that much workload, I think he deserves some away from work mindset.
    – Ege Bayrak
    Commented Jan 15, 2020 at 7:57
  • 19
    +1 for this answer. This is not OP's problem. This is the company's problem. The "bus factor" does not affect OP in the slightest.
    – user21030
    Commented Jan 15, 2020 at 9:11

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.

  • 6
    This. I have been in this position (although to be fair to my employer it was out of difficulty in recruiting people, not stubbornness in refusing to address it) and I’ve done very nicely out of it without even having to make the point myself.
    – Darren
    Commented Jan 15, 2020 at 5:06
  • 6
    Could it mean employer will complain and refuse whenever OP takes any time off (vacation or even sick leave)?
    – gerrit
    Commented Jan 15, 2020 at 13:01
  • 9
    @gerrit In that case, I would start interviewing and leave for greener pastures ASAP - which is exactly what the company should want to avoid. Wouldn't be the first company that sinks itself.
    – Alexander
    Commented Jan 15, 2020 at 14:49
  • 1
    You're absolutely right, @TeroLahtinen. A key distinction between the cost of redundancy and the cost of gambling on a single point of failure is that the cost of redundancy is predictable. You can predict the cost of adding employees or training your existing ones over a year or more. You can't predict the cost of someone being hit by a bus to anything like the same level.
    – Beejamin
    Commented Jan 15, 2020 at 23:42
  • 1
    @gerrit: You can always leave. Leaving for vacation means that you come back, and it appears the company has no choice in that matter.
    – MSalters
    Commented Jan 16, 2020 at 8:10

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

  • 34
    I agree with everything you've said except that first point. Having a low bus factor is often very much a bad thing. My immediate boss in my first job quit because he couldn't take holiday, was always on call and was getting stressed out of his mind by being personally responsible for everything. When he left, myself and the other Junior took over his role and had exactly the same problems. I left due to a nervous breakdown about 18 months later. Low Bus-factor is bad for everyone. There are some good points like job-security, but it's more "no escape" than "secure". Commented Jan 15, 2020 at 9:29
  • 4
    @Ruadhan2300: That's a fair point, thanks. I was on the cusp of addressing that, but it's unclear to me whether the OP is experiencing that kind of stress or not. Their language seems more focused on wishing the company were more successful; e.g. in comment OP wrote, "I'm the type of person who wouldn't care about that sort of thing". I've asked a question in comments above to clarify if it's personal stress they're feeling, or not. (I know I would personally feel the same way you did.) Commented Jan 15, 2020 at 14:06
  • 3
    @Ruadhan2300 Respectfully disagree. High bus factor is separate from having too much to do. They may commonly come together, but having a high bus factor by itself does not imply a high workload for the employee. Commented Jan 15, 2020 at 18:18
  • 1
    I'd argue that having too much to do is more or less inevitable when you're the only one who can do things. If only you know how to deal with something fundamental, then everything that naturally requires knowledge of that is also your job. In that job, I was the only one with any meaningful knowledge of our older projects after the senior left. meaning every little thing that needed doing on them became my sole personal responsibility and I couldn't go more than a weekend away from the office. Bus-factor is a problem that compounds with time. It should be nipped in the bud early. Commented Jan 16, 2020 at 9:20
  • 3
    Having a 'low bus factor' (where you are the indispensable expert) can make you unpromotable, it can be quite bad for you.
    – mattumotu
    Commented Jan 16, 2020 at 10:20

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!

  • I'm unclear that it's a startup, how do you know that? It sounds like OP has a large number of "senior people" above them. Commented Jan 15, 2020 at 14:11
  • @DanielR.Collins How do you know that? - the startup tag on the question :-)
    – davnicwil
    Commented Jan 15, 2020 at 14:12
  • 3
    +1. The context matters. If this were an established company and the project was their main cash cow, the OP would be justified in doubting the company's viability. But this is a startup, which is a high-risk high-reward type of deal and they are racing against other competitors to establish a market share. At this point, having a good succession plan is less important than having a product out the door.
    – Wayne
    Commented Jan 15, 2020 at 14:33
  • I'd argue that a startup still needs to have a high bus factor on projects. If a single point of failure causes 3 years worth of work to come to a screeching halt or crumbles into dust, that's more than just a "high risk" situation. A startup that has to retrain someone from scratch can lost significant momentum and time, to the point where the venture completely fails due to that one point of failure. Commented Jan 16, 2020 at 17:18

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.

  • 8
    What is your basis for being so certain that this is all just some ploy by OP's company to trick OP into feeling important just so that they can "appeal to the younger workforce?". This sounds more like a conspiracy theory than a serious answer to the question. Why should we not take the OP's description at face value? Commented Jan 15, 2020 at 1:59
  • 1
    How is offering a company laptop a good thing? It's a liability. It raises the expectation to work from home.
    – jaskij
    Commented Jan 15, 2020 at 7:13
  • @JanDorniak It's strange you see working from home as a bad thing. Many of see it as giving us the option to avoid wasting time and money on commuting. Of course the expectation that you'll work extra hours would be bad, but that's a separate battle.
    – Graham
    Commented Jan 15, 2020 at 8:51
  • 2
    @Graham bad wording. I meant doing after-hours work at home.
    – jaskij
    Commented Jan 15, 2020 at 10:10
  • 1
    @Dan Never attribute to malice that which can be adequately explained by stupidity. Your argument depends upon your assumption that "presumably there are others who can take his place immediately", but that is not at all a given. Commented Jan 17, 2020 at 12:22

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.


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.


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


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.


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.


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.


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


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.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .