I have been working for one year on a data science project, from finding the stakeholder and the work to running A/B tests and finally to productionising the project. Part of running A/B tests required a lot of manual running of the code and the deadlines around Christmas necessitated back to back work until 9/10 each day.

Because of this I got sick and had to take 2.5 weeks off with a chest infection. I also had 3 weeks of annual leave over Christmas/New Year, but didn't feel rested and recuperated afterwards. I was very burned out on the project.

The final stage of the project was not something I could do - at my firm an engineer has always done that stage. This is because of the wider tech infrastructure my project needs to fit into which I don't understand. Before Christmas, I agreed to one part of this stage - setting up some Airflow DAGs.

When I returned in the new year the project deadlines were not extended due to illness. I made my supervisor aware of burnout. I was told there were more stages I would need to complete - disagreed but committed. Still, project deadlines were not extended. I ended up with about 4/5 weeks of work to do in 2 weeks.

The process for putting a project live is mostly in our engineer's heads - the documentation doesn't describe what you need to do, just copy and paste the steps.

I also had other work to do as well, so was working in parallel and missed deadlines in both projects by a week.

Escalated the need for dedicated engineering support to my manager's manager (on our regular catch up). Got the ok - but couldn't get the time of an engineer for 3 weeks.

End up working 2 projects, find out there is an infrastructure bug that's blocking the original project. It takes 2 weeks to get resolved.

Once everything is resolved, follow the procedure to get my project live. Think everything is ok, but when I switch the project on another infrastructure issue pops up.

Because of this, my manager has taken over productionising the first project - to do the final steps.

Am now dreading work (and our 1 to 1) on Monday.

In fact, I generally feel negative about this role, but also about moving to any other similar role in another company.

My question is: what should I do, and how do I avoid this sort of situation in future?

  • 38
    @Stian I think it's clear what the OP means... He was overworked which left him open to a bad chest infection. Stress is well known for causing physical illness as well as mental. Especially (for this case) causing a weakened immune system.
    – Gamora
    Mar 3, 2020 at 10:59
  • 25
    Do I get you right - you had 3 projects in which ou were the bus factor of 1? If yes this is what you should do. Never ever do such things again. Mar 3, 2020 at 12:02
  • 16
    Are you good in saying no? If not, this is something you could try to improve.
    – guest
    Mar 3, 2020 at 13:27
  • 33
    your title says "messed up at work", but reading the rest I don't see anything you did wrong
    – Ivo
    Mar 4, 2020 at 8:48
  • 5
    @mars "requested"? I mean... "chest infection".... I don't think you need to request time off if you have something like pneumonia :/...... If the company isn't immune to someone taking an unexpected sick leave for 2 weeks.... it's a big problem :/
    – Patrice
    Mar 4, 2020 at 15:27

5 Answers 5


what should I do, and how do I avoid this sort of situation in future?

Perhaps there are details omitted, or I'm particularly bad at reading today. But honestly, there is nothing in the question that points to a particular mistake you made, that would be "your fault".

I find the best question to ask myself is:

What specific things did I do wrong, what specific alternative did I need to take instead that would have prevented this?

If you cannot answer this directly, and you don't have a specific list of steps that would have actually changed the outcome - then it simply is not your fault.

The normal advice is always, flag up scheduling problems early and make sure people are aware that you're going to need more time before it reaches that point. You did this, you were told that you didn't have extra time.

That's a decision you didn't get to make, and if it caused the project to fail - then you can also figure out quite easily whose fault it was.

PS: Just to be really clear - "being sick" - doesn't count as something you did wrong, as there is no reasonable step you could have taken to guarantee not being sick. Any business that can't deal with a single employee being absent is taking a risk.

  • 33
    And being overworked almost certainly caused "being sick" so it's still not his fault.
    – Clonkex
    Mar 3, 2020 at 22:29
  • 1
    I, and I am sure many others have been in a similar position. The problem is that the role feels like a constant pressure, and of course mistakes then happen, but tackling the constant pressure becomes the priority and sole responsibility and so it becomes difficult to think something/someone else could be to blame too. That all changes though when you see your boss invalidate all your hard work because of absolute stupidity. Mar 4, 2020 at 3:28
  • well getting sick could have been his fault since he overworked himself so much
    – Aequitas
    Mar 4, 2020 at 5:31
  • 6
    @Aequitas Based on how he describes the work, overworking wasn't his decision. Mar 4, 2020 at 8:46
  • 3
    @Aequitas OP writes, he notified superiors about feeling burnt-out. I don't know about your workplace, but here it would set off several alarms, probably HR and employee rep. getting involved. Dismissing it would be counted as major malfunction on the part of the superior, probably ending in him getting reprimanded in some way.
    – Fildor
    Mar 4, 2020 at 17:00

Any software project that requires a year of work of a single individual before any deliverable or production staging is made is fundamentally misplanned and mismanaged. In the future, if you find yourself doing more than a couple of weeks of individual contributor work without some sort of stakeholder validation or control feedback treat it as a red flag about your team/department/company.

  • 1
    Not to mention a lack of Quality Control, what seems like a lack of project management and requirements capturing, and no one even handling a risk analysis for the final integration or staged environment testing... Either the OP was expected to be responsible for ALL of these things, and should be getting paid a lot more, and/or the project was mismanaged and had too few resources to be successful.
    – Shorlan
    Mar 4, 2020 at 22:26
  • 1
    There is not a single statement that I can find that justifies your premise of no feedback/validation. This seems pretty off-topic
    – Mars
    Mar 5, 2020 at 1:06
  • 1
    @Mars I see a lot of those in the OP, where they talk about how things fail for unexpected reasons when they try to deploy them.
    – ObscureOwl
    Mar 6, 2020 at 10:07
  • @ObscureOwl How are deployment failures linked to stakeholder validation or control feedback? In my experience, a project that hasn't been approved by stakeholders wouldn't proceed to production.
    – Mars
    Mar 6, 2020 at 10:14

I was told there were more stages I would need to complete - [I] disagreed but committed [to it].

There's your mistake.

I ended up with about 4/5 weeks of work to do in 2 weeks.

I feel for you because I have been in your situation, and I have also learnt how to avoid these situations. As a generalisation (perhaps a gross one), programmers tend to be introverted, while bosses tend to be extroverted. When a disagreement arises, it is usually the more forceful personality that "wins".

You rightly objected to your boss's deadline estimate but then agreed to get it done in that time anyway. The professional thing to do would have been to reiterate that in your professional opinion as a developer that there was still four to five weeks of work left and that it was simply not possible to do it all in only two weeks.

I was burnt out after a particularly bad job/boss and I couldn't return to work for two years. Two years after returning to work I had learnt to push back unreasonable deadlines. My team leader told me I had to do a task in three days (estimated by him based on the boss's deadline). I estimated it myself and told him it was impossible to do in less than six days. He told me it had to be done in three. The boss had promised a client it would be done in three days so it was my duty to do it in three. I should work late every day until it was done and do unpaid overtime. I wasn't a team player for refusing.

As you see, a lot of pressure was put on me to capitulate. My team leader badgered me every day to lower my estimate. However, none of this pressure could change the size of the task or the work required to complete it. I ultimately got it done one hour before close of business on the sixth day, my most accurate estimate to date!

Because of my background, I am now very sensitive to unreasonable deadlines and giving false promises. However, when your energy levels are low it's hard to push back. It seems easier to give up and agree. But this has a number of problems:

  • You've given your boss an unreasonable expectation of when the work will be finished
    • Your boss will use the information you've given them to make business decisions. They might just report to their boss, or they might organise something to coincide with the launch date. Either way, a bad expectation will lead to bad decisions and outcomes. The project could fail if it's time sensitive. Your boss could lose their job (extreme situation).
  • You're at risk of further burnout
    • Your health can suffer. Your recovery could be prolonged. You will make more mistakes and more bugs. It will take you longer to complete your work if you are able to. You might lose your job (extreme situation).

You have two things you can negotiate on: the length of time, and the number of features. It might have been possible to complete the project on time if fewer features were completed, with the remainder to be done after launch. It's your boss's job to get the work done as efficiently as possible, in terms of money, resources, time, etc. It's your job to communicate honestly when a project or a task will need more money, resources, time, etc. than allowed for. You should also communicate any problems as soon as is practical.

I would advise reading Robert C. Martin's The Clean Coder - A Code of Conduct for Professional Programmers, particularly chapter 2: Saying No.

It might seem like I'm being harsh, but I do understand how being burnt out affects your mental state so that you prefer to "just go with the flow" and "not make waves". You need to focus on your health. I know from personal experience how bad health can prevent you from working, and how it can negatively impact your performance.

The professional thing to do is get well! If that means working less right now, then so be it. When you are well you can work at full capacity. Only when you are well can you work at full capacity. You need to learn to say "no" and present alternatives. When your boss says "It has to be done in two weeks" you say "I would do it if it was possible, but there's at least four weeks of work here. Can we move the deadline or remove some minor features?"

In your one-on-one tell them you recognise that you should have been more forceful in communicating accurate information and that you will keep your boss informed of issues as they arise (which can be as soon as they speak). Let them know your health is still an issue and you're working on it to get back to your usual performance, and that long hours at the moment will impact your health and make the situation worse due to your recent burnout. If you can, get a doctor's certificate stating that you are still capable of performing at your job but that you need more rest than normal until you have recovered. They will probably give a date to review your recovery and advise further.

  • 2
    "You have two things you can negotiate on: the length of time, and the number of features" – This is very important. There are way too many people who don't understand this: There are two proven working ways to deliver software: fix the set of features and release when ready, or fix the release date and release whatever features are ready (Ubuntu, current Windows). There are also two proven non-working ways to (not) deliver software: fix the set of features and the release date (iPhone OS 2.0), or fix neither (Debian 3, Windows Longhorn, WorkplaceOS, Taligent, Chandler). Mar 5, 2020 at 10:57
  • 1
    Just to add if every you're told you're "not a team player" for pushing back on an unrealistic deadline, remind the person you're talking to that if they were a team player, they'd have checked with you first before committing to the short deadline ;-) Mar 5, 2020 at 15:06

what should I do,

I think you're already doing it. You're looking at what went wrong, asking why, and looking for tactics to prevent it happening again (or mitigating the damage if it does happen). You could hold a formal retrospective, but remember to list the things that worked well too, so you keep doing them.

how do I avoid this sort of situation in future?

I ended up with about 4/5 weeks of work to do in 2 weeks.

There's your problem. Allowing your boss to set impossible expectations leads to stress, and stress leads to illness and mistakes.

When you're given multiple things to do, estimate how long each one will take, and ask your boss to prioritise them. Then provide updates so your boss can see how much work is still to be done, and can change the priorities as necessary.

When this sort of situation comes up, the boss is portrayed as a bully who thinks shouting at an empty fuel gauge could avoid the need to stop and fill his car. In reality they usually just don't understand what needs doing and how long it's likely to take - or maybe you don't understand exactly what they want and are overcomplicating things.

Don't see this as 'failing to do an impossible amount of work in the time available' so much as 'failing to communicate the amount of work and negotiate a workable plan'.

find out there is an infrastructure bug

This is another issue, and easier to address. When there are unknowns in a project, it's best to tackle them early on. Obviously you can't deploy until you're finished writing the code, but you could have tried a simple proof-of-concept. New things rarely work first time.

Your boss may have vetoed spending engineering effort before it was really necessary, but then you wouldn't feel it was your fault.

  • Sound advice for the next project. Doesn't help OP 'on Monday', though. Mar 3, 2020 at 21:03
  • @knallfrosch, not all of the OPs question was geared towards Monday. But adding a bit, if possible, to address that part of the question could make this answer better. Mar 4, 2020 at 0:35

There are few things that learnt from experience:

I was told there were more stages I would need to complete - disagreed but committed. Still, project deadlines were not extended. I ended up with about 4/5 weeks of work to do in 2 weeks.

If the project needs 4/5 weeks, it will not be done in 2 weeks just because your boss wants it that way. As early as you understand that let your boss know, that you need 4/5 weeks to implement expected features. Most importantly, however, talk to your boss about what is needed and two weeks, and what you can do in two weeks. Very often, depending the situation, there is something that you can do in two weeks that is enough for your boss to show progress and ask for extension.

This is because of the wider tech infrastructure my project needs to fit into which I don't understand. Before Christmas, I agreed to one part of this stage - setting up some Airflow DAGs.

It sounds like you were giving estimates on parts of the project you are not familiar with. You should have told you manager that you cannot give an estimate because you are not familiar with this part, and requested that an engineer, who is familiar with this part be added to the team, and then she would provide an estimate. Also, you should let your boss know, the parts of the project you will need help with as soon as you know, so she can book the resource as soon as possible.

You must log in to answer this question.

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