My boss likes our engineers to work overtime to fix bugs. One of his favorite arguments is that being a responsible engineer, when you know it is exactly your codes that cause the bugs how can you sleep well without fixing them?! You just have to do whatever it takes to fix them, if that means work overtime, well you are being responsible.

The company culture is somewhat based on this "shame based culture" that how can we let our software products have so many bugs, we "voluntarily" work overtime to fix bugs.

I am a responsible software engineer. Sometimes I worked hours to fix a bug in my spare time. But I really hate to see my boss thinks it is natural to work overtime to fix bugs. How can I argue against that?

I am from China but I don't think this fact is relevant here. I want to know any reasonable arguments to my boss's claim.

BTW, you guys probably heard about 996.ICU. My employer has not gone that far to demand 996 but it does like we work overtime to fix bugs/problems "voluntarily".

---- UPDATE -----

I left out some details on purpose b/c I am afraid that may sidetrack the answer, from the answers I got so far I think I better add them back.

So my boss is the owner of the company and I lead a team of 10 engineers. My employer has been in business for about 10 years but it should be still be seen as startup b/c the business is not thriving.

And by work overtime we are NOT compensated.

Of course there are deeper problems that are not being addressed here but please, can future answer still focus on my original question?

------ UPDATE 2 --------

One comment mentioned this Employee lack of ownership. It did sound like my boss's tone (a lot) lol. Another argument he likes to use is others work overtime to fix a problem while you go home, that is not teamwork!

I think that also confirms my judgement that I am Chinese and I work for a Chinese company is not relevant to my question.

------ UPDATE 3 --------

I checked all the answers again and again. I have to say the 2 answers that both said "don't argue & update your resume" were probably the best even though my original question was "how can I argue against ..."

I am not sure if there is a culture difference but I realize that most people in China with long working experience will probably give me an advice that "if you are not satisfied with your job either find a new one or just shut up".

  • 39
    "Well, being a responsible administrator when you know that your engineers are over worked, how can you sleep well without fixing that?" – OnoSendai May 10 at 5:50
  • 5
    "Sometimes I worked hours to fix a bug in my spare time." - Doing work in your spare time is not the same as overtime. Overtime means you should be compensated for the extra work in some way (e.g. extra pay). – Brandin May 10 at 5:52
  • 6
    @Qiulang Then that's even worse. Working overtime (with reasonable compensation) is a burden, but it might be reasonable if it is not too often. Working extra time for free is just unreasonable. – Brandin May 10 at 5:57
  • 4
    @Qiulang but participating in the error isn't a fix. A real fix would be proper evaluation of development costs (which should include debugging time) planned to take place during normal work hours and not a minute more. – OnoSendai May 10 at 6:30
  • 3
    What would happen to you if you simply refused to work unpaid overtime? Would you be fired? Would your boss physically prevent you from going home? Would your colleagues ostracise you? – Aaron F May 10 at 8:22

14 Answers 14


I think there are already answers covering many aspects, but if you're looking for a good response to this emotional manipulation, you could maybe say something like that:

If I am not rested, I cannot work focused, more errors sneak in, and that is irresponsible! So I take responsibility, go home and try to sleep well!

  • 3
    it"s uncommon to see such a short, yet efficient and accurate, answer. Good job. – gazzz0x2z May 10 at 8:52
  • 1
    Well I hope it can be that easy but it is not. For example (a real example and it happens a lot) some engineers already work overtime and that gives the boss another excuse that you can't just go home while your colleagues are working overtime. That is not team work. – Qiulang May 10 at 10:12
  • 4
    @Qiulang That's easy and repeats this answer. If you are not rested, you are not productive and thus are of no use for or help to yourself, your team or whatever else one can think of. – ivan_pozdeev May 10 at 10:17
  • 2
    If you stay late working overtime and writing bugs while your colleagues rest to be efficient, you are not helping. That is not team work. – aloisdg May 10 at 11:09
  • 3
    There are a large number of studies that show that working more than 40 hours is just not productive, productivity just bottoms out at this point due to fatigue. See for axample cdc.gov/niosh/docs/2004-143/pdfs/2004-143.pdf – Borgh May 10 at 11:26

What your boss is doing is called emotional manipulation and as you see in the quick search there is stacks of information about it.

If that was my boss I would be asking if the engineers of Fukushima should consider seppuku because that would be a good overly dramatic counter argument to expose the ridiculousness of his claims..

  • OK I don't understand this part "I would be asking if the engineers of Fukushima should consider seppuku " What is that ? – Qiulang May 10 at 4:24
  • 4
    It follows your managers logic: if an engineer is responsible he should stay back and fix things. Then it makes sense that if an engineer fails he should take responsibility. If the failure is catastrophic (as in the case of the Fukushima Nuclear Plant engineers who designed the place) they should do the Japanese honor suicide (Seppuku). It is stupid but so is your managers logic. – solarflare May 10 at 4:37
  • 6
    It’s your manager who has ultimately the responsibility for the product. If there are bugs, he should work overtime. – gnasher729 May 10 at 6:37
  • 1
    @T.J.Crowder thanks for answering my questions about promise at SO and seppuku here lol – Qiulang May 10 at 10:17
  • 2
    I really don’t think the mention of it is appropriate, not to mention the multiple, graphic descriptions of the act. Let’s try and have discourse here which isn’t going to offend people. – Tim May 10 at 22:35

As you mentioned and probably understood yourself, the company culture is the problem here. "Critical" incidents are that - critical. They are not supposed to be regular things.

Working overtime is already working extra, mandatory unpaid overtime is very unprofessional, unethical and maybe in some jurisdiction, illegal.

The series of events you mentioned point to two things:

  1. Poor planning and management.
  2. Not honoring the time, efficiency and eligibility of the employees.

Where (2) is a derivative of (1), eventually.

Your manager most likely understands the need of expanding the team to meet the deliverable, however, averting it by emotionally forcing you and team to work in unpaid overtime. They feel they are saving some money by pushing the existing team to produce more results - but in effect, excessive overtime (even if it's paid) takes a toll on the overall productivity and quality and eventually turns out to produce poor results.

Whatever you do to try to remedy the current situation, don't argue, i.e., don't get into an argument. Make the approach systematic - at least show the effort to solve the problem from your side, even when your manager is being irresponsible and unprofessional.

Depending on your situation, you can do two things:

  1. Make a record of all the overtime you had to do in recent past, ask for an official 1:1 discussion with your manager and bring up the matter. Tell him clearly that this is a constant event that keeps on happening and it's impacting the work-life balance.

    Tell him either you would need the payment for overtime (considering you're OK with it), or, you want to have the work hour restricted to the standard timelines, give or take a couple of minutes.

    If he gets back with that stupid argument of "how can you sleep..." etc, tell him (be straight and firm)

    I feel we work to live, not the other way around. If I do not get enough sleep, next day I'll be tired to work, eventually causing more bugs. I need to get rest to refresh and re-energize myself and to have a life outside office.

    Then, wait for their response / action.

  2. Polish your resume and start looking for other jobs. (Which might as well be the continuation of the previous action, too. In either case, the most you'll lose is a bad manager / management).

  • I am thinking about option#2 but as a software engineer over 40, my chance is ... (even thought I like to think I am still young :$) – Qiulang May 10 at 4:23
  • 2
    @Qiulang You never know until you try out. :) – Sourav Ghosh May 10 at 4:36
  • Hi I left out details originally but have added them now. – Qiulang May 10 at 5:54
  • @Qiulang Thanks but I don't think that changes the answer - it's all the same. – Sourav Ghosh May 10 at 5:58
  • 1
    @Qiulang I would say that CRITICAL bugs are results of overworked people. If they are not critical then there should be time allocated for fixing them during regular day. If they are not critical but treated as such then the management have problems with trust toward employees that they are able to recognize the weight of the bug. So I would argue that Critical bugs are ok to fix in overtime, non critical are to be fixed during next working days – SZCZERZO KŁY May 10 at 7:45

Since everyone has covered the escape attempts, here are some arguments to answer your original question:

  • Work hours exist because humans have a limited attention span in a day.

    You will not give 100% at all times because such thing is impossible even if you are doped up on stimulant drugs. This is also why military workers have defined shifts.

    Edit: Citations

    In the 1910's, Britain during World War 1 ruled out worker's laws for munitions workers and made working hours as long as production supply was available in an attempt to keep output at a maximum - a national life and death difference. A study on how to potentially increase productivity shortly followed, and the conclusion? Have workers work less.

    The evidence is conclusive that Sunday labour by depriving the worker of his weekly rest offers him no sufficient opportunity for the effect of recovering from fatigue, and is not productive of greater output except for quite short and isolated periods; seven days’ labour only produces six days’ output" - Report on the Health and Physical Condition of Male Munition Workers” (1916)

    "[...] long hours, much overtime, and especially Sunday labour, upon health is undoubtedly most deleterious” - Industrial Efficiency and Fatigue (1917)

  • Exhausted attention leads to more bugs

    Even worse than a sleepy guard watching over a power plant, a spent developer has increased potential to produce destructive effort, for every bug they fix they might spawn 2 or more in its place from simple lack of attention. Overworked devs are a ticking bomb.

    When your manager rolls eyes over worker's laws, he's being foolish. Those are not there to allow you to be lazy and happy. They are there so your boss doesn't damage the economy:

    "[... ] employees at work for a long time may experience fatigue or stress that not only reduces his or her productivity but also increases the probability of errors, accidents, and sickness that impose costs on the employer. [...] It implies that restrictions on working hours may be viewed not as damaging restraints on management but as an enlightened form of improving workplace efficiency and welfare "- The Productivity of Working Hours IZA DP

  • All software has and will always have bugs.

    Every single one of them. Everything is garbage. Even Google's code is garbage (Patrick Shyu, ex-googler). They pack the codebase of their projects every few years or so and throw it in the trash because of how insufferably garbage it gets.

    Quality Assurance (QA) Engineers are a dedicated bug finding branch of their own for a reason. And they mostly cover the main workflows, that is, it is impossible to test all cases therefore it is impossible to conclude your code is bug free. Losing sleep over it is the equivalent of worrying there are bacteria in your bowels.

In the end, your manager either knows all this and is manipulating you to cheaply produce questionable quality products or he has simply been treated the same way and thinks it is appropriate.

So, this is less about convincing him but forcing him to provide better compensation and/or management since his excuses are deeply flawed.

  • 1
    Thanks for the answer that I was looking for – Qiulang May 10 at 8:47
  • 4
    small detail on QA : on some specific areas, like the aerospace industry, all workflows are being tested, every line of code is being reviewed. It's horribly costly, and even like that, some bugs still pass through, Ariane 5 or Boeing MAX8 come to mind(though there are others). – gazzz0x2z May 10 at 9:21
  • YES why would you have such question ? – Qiulang May 10 at 11:06
  • @JoeStrazzere since 2016 we are required to work on Sunday and I average about 60 hours per week. I feel tired although not exhausted. Of course I also hate to see my boss thinks it is natural to work overtime. – Qiulang May 13 at 14:09
  • @JoeStrazzere I realize my words may confuse you and my English is not good enough to know the nuance of being tired and being exhausted. So I googled the difference and I found this article, sheevaunmoran.com/blog/master-energy-coach/…. So I think I am exhausted b/c according to it being exhausted means " when the all of the following (energy/thinking...) are drained and need outside help" – Qiulang May 14 at 0:20

How can I argue against the idea of working overtime to fix bugs?

I would advise you not to argue against working overtime. Why would you? Pack your things and leave when your usual work time is over. If your manager asks you where you think you are going, tell him you are going home. If he mentions bugs, respond that they are still going to be around tomorrow. If he mentions that they are urgent, tell him that sucks and that maybe someone planned too much features for the development cycle and maybe it's going to be better next time.

Et cetera. You get the idea.

The only thing your manager can do is to argue for unpaid overtime work. Let him do that and politely decline.

But, as for the bigger picture: Update your CV.

  • 1
    This answer sounds too risky but it is the truth and the only way to stop it. If you think about it your boss is making you feel bad to make you stay around. He's not saying you'll be fired or let go of, only that he's trying to persuade you to stay and any arguments by you falls on deaf ear. You just need to get up and leave no matter what he says but at the same time be respectful and say you'll do it first thing in the morning. – Dan May 10 at 13:15

I disagree with most of the answers posted on this forum. It is obvious that the argument given by your boss is nonsense. You know it, he knows it, it's just an excuse!

Being realistic, I do not think there is a way to change that. Your company already knows that you are overworked, they simply could not care less about the issue.

In conclusion, I do not think there is too much you can do except for leaving



I am not an expert on Chinese labor laws or culture, however, from my perspective, it sounds as if the problem is not your boss necessarily. Your boss is just the proverbial "symptom of the larger disease". It sounds like the problem is systemic in the company due its culture (or at least that of the engineering team). Typically, the most effective solution for an employee in this case is to consider employment opportunities elsewhere.


General Perspective

Manager's Experience

Depending on how long your manager has been at the company and how he/she got his/her position, the practice of having subordinates or engineers working large amounts of overtime to fix bugs could be seen as perfectly fine considering the history of the department. However, if a manager is relatively new, then it might be a sign of inexperience or a difference in management style compared to the previous manager(s) of the department and/or your experience. It does not sound as if your manager is new though, so I would error on the side of assuming that the practice is considered standard operating procedure at the company.

Senior Management's Approach / Philosophy

Consider senior management and their approach to the business. How often do managers, directors, VP's, and other executives work overtime, off-hours, the weekends, and/or holidays? While it is not uncommon for management and white-collar workers to work a lot of off-hours time, it can be a glaring red-flag if they repeatedly do so with the expectation that subordinates and/or non-management employees follow suit. It can also be considered that some management professionals consider I.T. and Software Development/Engineering a white-collar oriented field, thereby expecting off-the-clock work being done very regularly (I know this is the case in many companies here in the United States).

Company Culture

You mention that the company culture is based upon a "shame culture" ideology. I am not sure what that is, exactly, but based on the name I would gauge that it is one where mistakes are ridiculed by colleagues and the offending developer(s) are flogged by management for making them (metaphorically, of course)? If that is the case, then I think it might be in your best interests to apply for a job elsewhere as the company culture may not be a good fit. While I do understand that mistakes and bugs are bad for business, I would argue it is much worse for the product if developers feel like they are under pressure to deliver perfection every single time and the very first time. Unless the developers making the bugs feel they can learn and ask for help/guidance, the product will never improve and neither will the team. - Essentially, a toxic company culture.

Technical Perspective

On the technical side, how often do the same problems/bugs come-up and where? This may indicate you have a bad apple in the group who is either intentionally causing the problem(s), or worse, is unaware he/she is causing bug regressions in the source code. This could be something to note to your manager privately (if you have valid proof and evidence):

You: Hi [Manager Name],

I wanted to chat with you for a second about some recent commits to the codebase of project A. Considering how many bugs we have been fixing in the past few weeks, I've been trying to find the root cause to some of our more common bugs. Essentially, by submitting higher quality code in the first place, we can reduce bugs in the future and for our end users.

It seems that code checked in by "John" on date X, date Y, date Z, etc. may be causing bugs #1 - #5 of the current queue. It seems that he repeatedly pushes untested or incorrectly written patches to system X which is business critical. Could you talk with John to see if he needs some help with this system or if we need to hand maintenance of that system off to someone else?

Furthermore, you could note that causing such bug regressions results in wasted time/money for the company (of which most managers, technical and non-technical alike, will want to fix ASAP). A good manager will know who causes more problems than they fix and how to redirect those resources from the more dangerous parts of the project.

One word of advice on noting such a complaint: you may end up contributing to the shame culture if your manager is inexperienced in handling a junior or novice developer (i.e. they tell the offending developer publicly, mention you in the discussion, or have you micromanage all of the code submitted by the offending developer) thereby making the situation worse.

Best of luck and hope the situation improves! :)

  • Hi thanks for the detailed answer. Really appreciate you taking time in doing this. I updated my question to make question more relevant. – Qiulang May 10 at 5:51
  • 1
    @Qiulang Ah ok. I think the details you added are very important and add much needed context to the question. A company with less than 25 employees or thereabouts is very different from one with 250+. I think my answer is geared more towards the enterprise level of 250+. However, I think I would say to read a short book called "The Phoenix Project" -- It is about a newly promoted VP of an IT team of a fictional company going through a similar situation to what you're going through now and how they get through it. It was written by some IT business people, so it is highly relatable IMHO. – B1313 May 10 at 6:03
  • 1
    OK I will check it out. BTW about the shame culture if you read the book called peopleware there is a chapter talking about what you said/imaged. We did not go that far(thankfully) – Qiulang May 10 at 6:06
  • My employer has about 250 employees, R&D about 50 engineers. – Qiulang May 10 at 6:09
  • @Qiulang You manage about 20% of the the R&D team then, correct? If you and your team are the only ones working overtime a lot then you either have a technical codebase problem somewhere (not enough code reviews, tests, or too many changes to unknown/undocumented systems) and/or a communication problem between the team and the other 80% of the department. What is the other 80% doing/team style like? I am thinking it is likely not a company culture problem that is causing the overtime (that's just the current attitude towards the problem: work harder, not smarter) but rather actual oversights. – B1313 May 10 at 6:18

I always like visiting problems from the technical side, because it makes it simpler. Emotional manipulation? Yes, definitely. But I think your only problem is that you're not getting compensated for the extra time.

If all the engineers there are required to work extra time for free to maintain the work, that only means that your boss needs to hire more engineers. Usually the math is done by calculating the cost of overtime and realizing that it's more effective to just hire more people.

From my perspective, you just need to tell your boss to compensate you and your colleagues for the overtime you're doing. Everything else will solve itself automatically afterwards. Your boss has to be aware that if he doesn't do that, he'll most probably lose his employees to someone who treats them properly.

  • "But I think your only problem is ..." not the only problem but one of the main problems – Qiulang May 11 at 8:16
  • @Qiulang If that problem is solved, every other problem will be solved. That's why this is the only problem. – The Quantum Physicist May 11 at 9:23

Your bosses argument is nonsense.

You write code, and then you pass it to a dedicated team that does nothing but find the smallest problem in it. What would happen if your boss was treated the same way? If everything he did today was scrutinised the same way?

Every single email he sends would be rejected for having bad spelling, being unclear, writing things that are unnecessary, leaving out things that are required. Or worse, for mailing information that is just wrong (with a whole team checking it).

Every interaction with his team, with customers, with other managers would be recorded and checked the same way. And every small mistake he has to stay at work, do overtime, and fix each of these mistakes. I bet he would work more hours than you do.

So the bosses argument is nonsense. But that is not helping you, it should just make you feel better. What the boss really wants is you to work unpaid overtime, and he’s not honest enough to admit it. An honest boss would say “I want you to stay and do unpaid overtime, and if you don’t like it, get a job elsewhere.” Just as bad for you, but at least it’s honest.

  • I don’t understand why your answer got downvoted. You saw the root cause “he is not honest enough to admit that “ – Qiulang May 11 at 8:45

Company founders have a tendency to assume that employees are company co-founders. Although the origin of this bias is recognizable and understandable, it is also their duty to realize that they cannot demand as much drive from others as from themselves.

As an employee, your involvement in keeping/raising the company's standing is governed and limited by contractual agreements, and common sense.

Possible argument: Lack of sleep leads to burn-out, not to lack of bugs. You fix bugs sharply and effectively after having slept long enough and well.

Sleep is a means to have you full speed tomorrow, not a checkpoint for your being exhausted today.

  • Of all the answers I got so far, you were the only one sees this "Company founders have a tendency to assume that employees are company co-founders... " !! – Qiulang May 10 at 12:27
  • If the association with sleep is not too tangential to this topic, there is a TED talk about sleep (and among other, learning capabilities) that just came up. For those interested: ted.com/talks/matt_walker_sleep_is_your_superpower – XavierStuvw May 11 at 17:37
  • Thanks for the link but I think you know that this is not about sleep. – Qiulang May 12 at 2:46

Your boss is manipulative, but you both have the same goal, which is bug free code.

So push back, hard, in the planning phase for each release. I've regularly been involved in heated arguments where we, the development team, has told management that there isn't time to do what they want us to by the release date. Cite the extra overtime you've worked then as an argument that what they want done is unsustainable. Include time for writing tests. Your goal is essentially to get the workload down by the amount of overtime you're working.

If management refuse, then it's a great reason to not work overtime. "Boss, we told you it was going to take x amount longer than we had for this release. It's taking x amount longer than we have. Now, what features shall we drop?"

This sort of assumes you're involved in the planning. If you're not, as a team, you should be discussing the plan with your boss, and making clear which bits are going to be impossible to complete.


I haven't seen any other answers address a point in the update: that you're managing a team of 10 engineers.

So your behaviour doesn't just affect your own life and wellbeing, but (indirectly) that of those 10 engineers too.

If you accept the culture and work 60+–hour weeks, then your staff will feel some pressure to do so too (whatever you say).

Whereas if you push back and refuse, then they may also feel free to work more reasonable hours.

You mentioned ‘responsibility’ — for this reason I think you have a responsibility to your staff to work shorter hours, for their benefit as well as yours.

(BTW, I think your location does have some bearing, as in many other locations such a culture would probably seem much less acceptable.)

Also, to underline what others have said: long hours can be counterproductive.  Googling for e.g. ‘IT productivity long hours’ finds many studies showing that in general you can get more done by restricting your hours.  (You may want to show some of them to your boss if necessary.)

  • Of course I know longer hour can be counterproductive. To be honest I hate to see people keep mentioning this like I don't know. – Qiulang May 10 at 17:00
  • I see your answer got downvoted NOT from me because you were the only one talking about my responsibilities as manager! – Qiulang May 11 at 8:28

They need you more than you need them. If all of you stop working OT at the same time, they're gonna have to take you serious. If nobody wants to do that then you slow down. The more OT they make you work, the longer things take to get done and the big guys see their spending more money for less work. They gonna learn quick to back off.


"Knowing that we have found the bugs lets me sleep very well... it's the bugs that our engineers aren't reporting because they don't want to be bothered to work for free to fix that keep me awake."

  • If you have noticed I have worked for the company for almost 10 years you probably would know I just don't have the guts to say that. – Qiulang May 19 at 6:42
  • Perhaps you could word it more as a concern then, "Are you concerned that our engineers might not be reporting bugs due to the fact that they may not want to work overtime to fix them?" – Glen Pierce May 19 at 6:45
  • But ... the bugs are mostly reported by the test team – Qiulang May 19 at 6:46
  • Or "We're adding to our technical debt load and slowing down overall development by putting in very low quality code to bug fixes due to the fact that people are fixing bugs with hacks rather than addressing root problems." – Glen Pierce May 19 at 6:47
  • 1
    I will go with "don't argue & update your resume". See my update 3 – Qiulang May 19 at 6:54

protected by mcknz May 12 at 22:23

Thank you for your interest in this question. Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).

Would you like to answer one of these unanswered questions instead?

Not the answer you're looking for? Browse other questions tagged or ask your own question.