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

You don't. It's entirely their failure to set expectations without prior technical consultation. In this case they'll get the blame.

They'll blame you, and you can blame the external partner, but this line of blame nobody cares about.

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.

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.

It sounds like your management really wants this bug to be fixed quickly. You should think about why they try to put so much pressure using their own words, which are not the best indeed.

Your team should probably focus on this bug, to fix it ASAP. It may take longer than what the management is hoping for, they are likely aware of that.

Go work somewhere else

One job isn’t your career. Staying at a place that doesn’t understand or respect developers is actually damaging to your career.

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

Just communicate that setting a _priority_ for a bug is fine, but a timescale isn't, as you don't know what you don't know. Then let them know what resources you need to figure it out as quickly as possible (maybe it's just space and time, maybe it's people, maybe it's expertise).

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.

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)

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.

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.

Thoughts in my head:

* They should be aware from the onset that this requires investigation first of all. You would provide them with an update to see if you can actually timebox it midway into the process (be that the EOD or on another day)

* After having recognized that this problem was just a configuration issue, one should write down why that bug was so difficult to find and what is the work to be done to make that issue more visible?

* Speak to your personal manager and talk through the problem. Maybe they can share the insights with the management team.

I'd reply explaining in depth why that's an unreasonable approach, with painstaking care taken to make it sound like I assume they just haven't thought of, or aren't familiar, with these factors.

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.

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.

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?

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.

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

Leave

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.

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.

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.

I've been CTO when the CEO sent these demands. I learned you can't work for CEOs like this -- all negotiations were for naught, and it severely undermined my ability to make any agreements with the team, or for the team.

Take a sick day.

Ending your career? It's called communication.