Ask HN: How to deal with managers who set a hard time-limit on fixing a bug?

[null_object]

What would be a good and not career-destroying approach to deal with managers who set a hard time-limit on when a bug will be fixed?

For some context, this arose in a pre-release application-critical bug that several people had attempted to solve, but which we had no insight into the cause. As it turned-out, the external partner for whom we were building the application had supplied one wrong piece of configuration - but this information was confidential to their setup, and we had no insight into how it would break another part of a complex flow (or even that it existed).

The essential problem, is that the management simply sent out a mail to the whole team saying the bug should be fixed by the next day at 'close-of-business'.

Question is how to deal with this sort of management behavior without ending your career?

I'm aiming to find some constructive way to help them in the future to see why bugs can't always yield predictably to time-boxed developer effort.

[fabbari]

First: discuss with your development team the issue, make sure you get buy-in on replying to management with one voice. A.K.A.: avoiding you saying "We can't do X" and someone else goes: "Of course we can!".

Second: talk to your manager. Don't send an e-mail. That would just turn in a long, and possibly bitter, battle of 're:re:re:re:' or be interpreted as a C.Y.A. fig leaf. Make sure you start by understanding where that timebox is coming from and how 'un-elastic' really is. Then proceed to explain that for your team it's hard to commit to a timeline when the - currently unknown - fix to the bug could be a line of code or rewriting a whole component of the software. Reach an understanding that - of course - your team will try an deliver in the gives timebox if at all possible, but that you will keep him informed of any findings that may indicate that it will take longer.

Third: proceed working on the analysis and fix keeping them in the loop; make the messaging short, meaningful and to the point. "We found the issue: X", "We're designing a fix: Y", "Current estimate for the fix is Y". Make sure that the communication is timely. One thing is to say at 10AM: "We think it's going to take two days", and another is to say the same thing at 5PM.

Ideally this should come from the Dev team lead - which is what I do for a living. We are there to take the fire.

If you get pushback, no answers and management doesn't respond well to this pattern - well, you want that career destroyed and to move to some other place.

[wombatpm]

Step 2 is key. You need to understand why the pressure exists. Is the CEO demoing the software and does not want a big error screen to pop up? Is your biggest customer complaining? Does you CTO need his Etch-a-Sketch reset?

You also need to understand what constitutes success. Can you disable feature X?, Can you catch the error and log it but not display or stop execution? Can you do a quick hack workaround while you take longer to fix it.

[alunchbox]

Yep, take a look at how GGG handled latest POE patch. Seems there was an issue with db paging but it's hard to find and took about 13 hours or so to fix.

Sometimes bugs are really hard to track-down, it's important to learn and not make the same mistakes going forward though.

[troelsSteegin]

Agree, and will suggest generically that, fourth, that post-crisis, you sit down with your manager to understand and learn from the experience. Root cause of the bug? Root cause of not seeing it earlier? What made it become a firedrill? Net, how do we avoid a next-time?

In your particular case, it might help to understand what was at stake for your manager in this instance. You may gain some leverage from having come through.

Also, with partners who are integrating your stuff, it can help to provide a reference client or reference integration, so that they can see what you did to make things work - the partner would have helped you by self diagnosing.

[null_object]

I think this is probably about as close as we will come to a process that would work.

I'd say that right now the company I'm working for doesn't have the structure in place - no team leads, for instance - to dissipate the heat when it's on, and no procedure to follow when things go wrong.

These are definitely things to think about as we grow. Thanks for the constructive reply!

[quadcore]

I disagree with most comments. Thing is simpler than that. Just dont take it too seriously. They do their best to get some shit done and if it fails, it fails. They gave you some instructions, do the best you can with it, get back to your familly when you think you should. It's the best way to deal with it, I'm not saying this is an ideal situation.

[sdgasg]

Yes, this is correct response. This applies to both, bugs and feature deadlines. Early in my career, I would freak out whenever there were hard deadline, spent hours of personal time trying to meet deadlines. Now that I have friends in management and higher, I understand their motivations. They don't care about deadlines.

The best approach is to show concern, managers love meetings, so schedule a meeting to discuss. Don't fight back on deadline but try to understand seriousness and inform them of your status. Really it maybe waste of your valuable time, but your manager needs to report to their manager. They will love you for scheduling a meeting, you are speaking their language. Give them daily or weekly update via email or Slack. That shows them you are serious about deadline. They really just need to stay informed.

Finally, don't waste your personal time on fixing the bug after work. After 5PM spend time with your family and friends. Don't let management fool you in thinking that this is the last hard deadline. They will abuse you if you let them. It is just simple human nature. Don't let them abuse your coworkers either. It takes just one overzealous employee to destroy work-life balance for everyone.

Ever since I have realized that deadlines are mostly meaningless, I have missed many and there were zero negative consequences. In fact, opposite happens most of the time, management stop setting ridiculous deadlines. You just need to make sure you are doing solid work everyday for 8 hours and that's it.

[lr4444lr]

I'll play Devil's Advocate here: there are sometimes critical business deadlines that absolutely require timeboxing a bug at the risk of losing a contract. I wish the world could conform to SDLC best practices, but sometimes reality is messy, and hindsight is 20/20. So that said, I think the real problem here is what you alluded: several people attempted unsuccessfully to solve it: how many man hours was this? How any calendar days? Did you report this up the chain early on, or was management blindsided by it because you kept hacking on it as shadow work, or didn't communicate how critical it was? If you did your due diligence early on, then I agree with everyone saying you should leave. If the people issuing the directive didn't receive adequate warning from your team, fix that next time.

[andrewla]

> deadlines that absolutely require timeboxing a bug

To be clear, timeboxing is usually used in the opposite sense, to say "if this bug is not fixed by end-of-day then we should abandon the effort because the value of fixing it is limited".

It can be useful to timebox the amount of time that you spend trying to find the "right" fix before falling back to a workable solution -- like "if you can't fix the problem with the email sender by end of day we're going to send out the emails manually".

[bjohnson225]

> I wish the world could conform to SDLC best practices, but sometimes reality is messy

Reality is messy, but what the OP describes is the denying rather than dealing with that reality. Putting a two day limit on a bug fix is not going to make what could potentially be two weeks of round the clock work suddenly become two days worth of work.

[benjohnson]

As a manager - I've had to do crap like this now and then to light a fire under people. It can be done to indicate extreme urgency. There also are real-world implications to some delays - for example not being able to run payroll is a legal nightmare and an ethical nightmare for hurting your employees.

Generally, when I've had to do this, it's been my fault for not manangeing properly.

[analyst74]

I'm curious, does it actually lead to faster resolution or does it lead to engineers spending time thinking about how to deliver the bad news versus actually focusing on the problem?

[happytoexplain]

>Generally, when I've had to do this, it's been my fault for not manangeing properly.

This is key. Sometimes it's reasonable for a manager to coerce a team member into going above and beyond, but it's important that the team understand that it's not just because the manager really wants to meet their targets on the business side, and that somebody above the team member is responsible for the situation's existence.

[fxtentacle]

1. Ask how they came up with the deadline?

2. Ask how much they need it, meaning how many extra hours will they allow? And will they pay a bonus for those people who forfeit their evening and night just to get this fixed on time?

Chances are, the deadline will vanish as soon as it becomes obvious that there's a price attached.

[toddh]

The usual approach when management is this dim is to give a well couched opinion as to the reality of the outcome and then say sir yes sir or mam yes mam and that you'll give it all you got captain. The bug will take however long it takes to be fixed. Schedules will slip out as necessary and life will somehow magically go on. If you have reason to believe adding more resources of various types will help, then by all means ask for them, but there's usually no dealing with this kind of management dictate and arguing up front will just put you in an even worse situation than not making the deadline. You will be labeled the obstructor, not the realist.

[snarfy]

If you go to your mechanic and tell them "car won't start", does your mechanic have idea how long it's going to take to fix or how much money it will cost? Realistically, you will be charged a fee to figure out what is wrong, and another to fix the problem.

When you have a bug, you are still figuring out what is wrong.

[lainga]

When you have the luxury of telling someone that in software, it's called consulting!

[bwh2]

Earlier in my career, I would hear my manager say something about a specific situation and I would extrapolate that into a general belief and theoretical/academic debate that frustrated everyone. Make sure you're not doing that.

As a manager, sometimes you need to say things like, "This bug needs to be fixed by EOD tomorrow" so that your team understands the urgency and your expectations. The more technical the manager, the more likely they can understand whether that expectation is reasonable.

[decebalus1]

> As a manager, sometimes you need to say things like, "This bug needs to be fixed by EOD tomorrow" so that your team understands the urgency and your expectations.

I'm sorry but you can do that without sounding both clueless and unreasonable. You can put everything else on hold, stop the line, explain why it's important for this to be fixed, etc.. to get the point across.

"This bug needs to be fixed by EOD tomorrow" would chip away at the trust I have with management and depending on other factors would lead me to brush up my resume...

[towergratis]

Ignore them and fix it at your own sweet time not working longer than 9-5.

Why you ask? Well look at the big picture.

A manager's ambitious is moving up the corporate ladder. To do this he takes up projects to prove herself. To complete the projects she uses the resources(people) assigned to her. Part of the resources are her core team, that she trusts and will carry with her when she gets promoted. The rest, which is the majority, will stay where they are for the next manager that will come along.

A manager would never give hard time-limit on fixing a bug to his core-team people. The people she trusts. The relationship there is completely different. So we know that you are part of the core team. Hence you have nothing to win career-wise for stressing and working extra hard.

Pushing back, asking questions, and in general being a pain in the ass is also not good career wise, as you may get negative visibility further above.

So the best thing you can do stay invisible, ignore and don't stress about it, and work as fast as you can, while not working more than what you get paid for.

If the bug is really critical and urgent then more resources will be allocated to help you with it.

In most cases however, that deadline is set to multiple people to help with manager's ambition.

So my advise is, relax, don't overwork, but don't rock the boat either.

[davidhyde]

The best thing to do is to put yourself in the manager's shoes.

1. They probably know less about the issue than you do, including the fact that they don't know what you don't know. 2. The cannot fix the problem themselves; they have to find the best people to fix the problem. 3. They also have managers (or customers) harassing them for answers.

They have two choices. The first is to get the issue fixed as quickly as possible so that they don't need to learn any detail about what the issue really is. If an issue is fixed quickly then everybody cools down and all concerned parties generally become disinterested. The one day deadline is most likely an attempt at option no. 1. The second option for the manager is to find out as much detail about the problem and be confident that they have the best team working on the problem. That way when they have to report to management above them (or to customers) they can do so with relevant information and confidence. Remember, everybody has a boss.

So, now that you know what your manager needs, you need to convince them that they need to follow option no. 2. You need to explain the problem in such a way that they can parrot that information upwards. You need to convince them that you are the best person to do the job. Furthermore, and this is the tricky bit, you need to tell them that you don't know everything but as soon as you find material information you will tell them. After your high level synopsis, swamp them with technical updates. Although these details may not be understood or relevant to your manager they contribute to the trust you need to build up as time passes. If your manager is good and you have been transparent with them they will begin to defend you in higher level meetings.

[hashkb]

It's never your job to empathize with your manager. They get paid more to manage you. If your manager needs coddling, you're managing them. Or you're being a friend; but as a subordinate they are responsible for enabling you, not the other way around.

When I'm a lead/mentor, I know my job is to protect and enable people. When I'm a cog in the machine, I expect leadership to have their shit together. When leadership doesn't have their shit together, I quit.

[potta_coffee]

The honest answer to this is to find an employer that actually understands software development.

[danpalmer]

It's also important to remember that one person is not the whole employer.

[longhairedhippy]

I think being honest will not affect your career in a negative way. In this particular instance, it could potentially harm this job now, however if telling the truth gets you fired, that is not a place where you want to work.

Hearing your baby is ugly is painful but a necessary part of business, if we can't be ruthlessly honest with each other, then no one wins.

[wsostt]

All bugs need to have workarounds in case it can't be fixed by some deadline. A group works on fixing the bug while another group makes some tentative plans to implement a workaround. Bugs can have deadlines for legal, reputational, or other reasons. But there needs to be other ways to mitigating the risk without fixing the bug itself.

[raverbashing]

The problem will solve itself by the time the deadline comes and the bug is not fixed.

Meanwhile, don't promise anything, don't commit to anything but don't burn any bridges. Be professional, explain what do you think it is, what might be wrong and why is it hard.

"This bug will require a longer investigation and we cannot commit to any timeframe for its resolution" (unless you have a fallback/workaround ready or it is something you don't expect to be complicated)

[dchess]

Sounds like your team/company needs to establish SLAs. When it comes to troubleshooting the important timelines to commit to are communication timelines. First response with X hours. Updates every Y hours/days depending on severity/priority. You'll also want a clear process for establishing the criteria for diagnosing priority and what escalation paths should be when there are roadblocks.

[avmich]

> Question is how to deal with this sort of management behavior without ending your career?

Don't be afraid too much. At most you'll be fired from a not good place, big deal. Software engineers are in demand.

I'd make a good faith efforts to help with the problem. And perhaps complain about the management behavior to their superiors. Let them square the circle.

[tailrecursion]

In order to influence your boss in this case requires understanding what is intended, so you can offer a better alternative. As you know, setting a deadline doesn't require that management believes bug fixing is predictable. They could well know it's unpredictable and set a deadline anyway.

You know your bosses better than I do, but all I can make from this example is a boss who wants to make fixing this bug top priority. Possibly the boss wanted to say, "Stop all other work until this bug is fixed" and then, thinking what that might bring -- after all, developers are lazy -- decided to set a false deadline. The intent seems to be to set priorities.

An executive once told us -- a small group of developers -- in a meeting that work must be finished by the deadline come hell or high water. We looked at each other and didn't know what he was trying to say. Obviously there are trade-offs here, so do we trade off quality? Features? What exactly was the executive thinking to sacrifice -- besides unpaid overtime of employees. That's a given.

Maybe the boss can remove obstacles or get help from other departments. These are things that bosses can do that you can't do. Maybe all the boss wants is to get you to say what the hold up is, for example "we need some more information from one of our partners", in order to assist you.

Maybe your boss gets colicky when bugs aren't fixed. You could suggest setting a zero defects policy, which more or less states that bugs are fixed before new features are added. This is one way to meet deadlines that trades off features in return for being able to ship more or less at any time.

It could be there's even a missing role here that you can fill over time. If you can be an expert at treating your boss as a customer, interviewing to discover what exactly is desired, and suggesting technical and management solutions, you'll be a great deal more valuable.

[grey-area]

1. Communication is key here - it sounds like you have a breakdown in communication with your manager, or a breakdown in their understanding of your work.

2. You're attempting to turn something very specific (please fix this bug), into something very abstract (some bugs can't be fixed, some bugs take longer than expected to fix). That's not going to help, particularly if this was in the end a simple fix, it just makes you look obtuse and out of touch.

3. The manager's proclamation is probably born of frustration with previous experiences where bugs were not fixed quickly and they have no idea why. Communication is the answer - if you communicate before and during a bug fix, they won't wonder why, they'll know why if it is not fixed, and they'll know what you are working on or have to sacrifice to make that happen. They'll know when you are installing logging to track it down, or when you eliminate modules one by one in tracing it, they can follow along and explain to their manager why it is not yet fixed.

4. You need a process which you both agree on for escalating bugs or setting priority - this clearly isn't it, but what is it?

Instead of complaining to them if you possibly can fix this bug quickly (perhaps you already did), then talk to your manager privately about process, talk to them about timeframes and how best to frame them, and try to find a process that works for both of you. That process will involve compromise on both sides - the manager accepting that sometimes things go wrong, sometimes bugs are difficult to pinpoint, and that scope/quality will sometimes be cut to deliver on time, you accepting that your job is to communicate upwards (particularly when things are unexplained), and accepting that sometimes corners will be cut on quality to deliver on time, and some things which are important to devs are not as important to the company, and that schedules and estimates are required, even if they can never be completely accurate.

[908B64B197]

I assume you are working at a exceptional company (FAANG level at least) since your management team is capable of estimating time required for bug fixes in such a precise manner.

But seriously, the best management I've seen had a pretty good way of communicating what was important to work on. For something like that they would simply have emailed the dev team and stated that "bug X is an absolute release blocker" along with a list of engineers in charge of leading the fix (said engineers would have been contacted privately and whatever tasks they had deprioritized). Then the email threads would be used to share the latest details on the investigation.

You can't put a hard deadline on something like a bug fix, but you can maximize your chances of meeting that deadline by making sure the right folks are 100% focused on that fix.

Now, is your management technical at all?

[mouzogu]

I would say you have a right to know why a bug needs to be fixed at 'close-of-business'. You just have to try and ask it in an indirect and non confrontational way.

This will better help you determine a practical and pragmatic approach because you will have a better understanding of how serious the issue actually is and it's implications may be simply overstated or exaggerated as most shitty managers are known to do without consideration of the stress and harm it may cause to others.

In any case I would try to push early that we need two plans, one for a solution and one without.

Try and manage expectations as early as possible by making the possibility of no solution viable in their thinking.

If you feel they are unresponsive or unwilling to accommodate a reasoned approach then as others have said maybe better to be fired - does not seem like a healthy environment.