Hacker News new | past | comments | ask | show | jobs | submit login
Ask HN: How to deal with managers who set a hard time-limit on fixing a bug?
39 points by null_object 7 days ago | hide | past | favorite | 64 comments
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.






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.


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.


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.


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.


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!


Glad to help, I have been in your spot; until you get the structure in place just make sure that the team is in agreement on the response.

I always believe in good faith and positive intent - call me naive - so I assume the managers have their own pressure to respond to and business needs to satisfy.

The 'understanding' first step is needed to see if there is an interim solution that takes the fire away from the business, the manager and the dev team. IE: The feature with the bug is not as urgent as other features in the same drop; squirrel away the bug behind a feature flag and deliver the rest. Now you can go ahead and fix the bug with a proper pace.


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.

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.


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.

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


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


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.


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?

Also manager. I feel like the manager's communication is off, though the end result is the same. All I need to ensure is that a) you are working on this HARD and know to turn down other tasks (and possibly put in extra hours) and b) you will update me immediately if the timeline can't be met.

Usually this request, though frequently very rare takes the form of "Issue $ISSUE is causing critical impacts on $IMPORTANT_THING, if we don't solve it by $TIME, it will cause $BAD_IMPACTS. Please make this your top priority and redirect questions about all other items to me. If you think this will not be done by $TIME, please let me know as soon as possible. I appreciate your hard work" Then you tell rest of the org: "$TEAM is working on $ISSUE and is re prioritizing other commitments. If you have any questions or concerns, please reach out directly to me."

If the developer turns around and says "this won't happen in time", that's a problem for the manager, not the developer in like 99% of situations. It's not "bad news", it's the truth, and you should always be able to tell the unfiltered truth (especially to your direct manager!) without any repercussions.


Wow if you're real, I'd love to have worked for you. Typically managers don't do the other half of what you do: they want critical surprise issue fixed yesterday, and with no caveats; you better still be available for marketing bullshit and that salesforce thing and that support issue we escalated to you and also when's that feature going to be ready?

>Usually this request, though frequently very rare

Spoken like a true manager


Yes, it works, and that's why it's dangerous because it lets a manager fall into bad habits of doing it again.

It makes the people doing the work pull out all the stops - beg vendors for support, drive to the customer site to witness the problem, and generally so whatever it takes.


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


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.

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.


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

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.


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.


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


I agree, and I've been the manager in this situation. There's some reason he's saying "EOD tomorrow", so he should just share that. Like "It's likely we will lose this customer if this isn't fixed by EOD tomorrow...so please make this the only thing we're working until then".

Usually, you don't lose a customer over a bug in two days. Customers are reasonable usually and understand that it takes time to fix bugs. Most of other reasons like CEO doing a demo at a conference can also be managed. I really don't see a reason for hard deadlines ever. In fact, hard deadlines is sign of bad management with notable exception of startups and other young companies with no managers or new managers.

Sharing the reason allows for that debate, or alternatives. Maybe the customer has some sort of demo or something, and you could offer a workaround in that case.

Hard deadlines for some sort of fix or workaround do exist. Like "Earnings Call Tommorrow, and I can't just say ' I Dunno'"


I agree with statement "Hard deadlines for some sort of fix or workaround do exist". Key being get this done before CEO's big presentation or hard code something or CEO doesn't demo this feature. The point is no one dies if CEO doesn't demo it or feature is not complete by earnings call. Earnings call is known event, one should have better planned for it.

And that bring me to people literally dying because of bugs in software like in cars or medical devices etc. That might be one time where I would have no problem sacrificing my family time for getting bug fixed. But most other situations are just artificial and deserve no extra stress.


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.


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.


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

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

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.


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.

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)


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.


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.

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


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.


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?


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.


Bugs as a class have inherently unbounded time and effort to fix (or rather, they size as either "trivial" or "infinite pending investigation") but effort for individual bugs can be bounded by an assessment of how much time and effort to invest. Help your manager make this assessment by clearly delineating trade-offs. Help your manager help you and the team by clearly communicating progress and flagging unknowns/blockers.

1. Clarify the motivation for the time-box. Is there an externally imposed deadline? An angry customer? A dependency impacting another team or teams in the business? Is it more a matter of boosting the team's sense of priority/urgency and keeping a project from getting off track?

2. Clarify what outcomes are acceptable as "fixed" for the immediate deadline and whether you can do a mitigation to buy time for further investigation. Can you disable a feature, support partial functionality, do some filthy hack, temporarily do something manually, etc.? Try to give your manager some sense of the time/effort required for each possible solution or mitigation.

3. Share clear plans for investigating the bug, progress and findings so far, and next steps after the root cause has been identified. Be specific: "We have researched X, Y, and Z so far. Today, Bob will investigate Thing A and Alice will investigate Thing B. We'll give you an update by 2pm this afternoon."

4. If applicable, flag areas where lack of information or co-operation is blocking the team. DO NOT throw your team members or partners under the bus here, however, you can get into issues like "We're having trouble finding where to escalate questions for Legacy Service" and ask your manager for help.

I've used the words "clear/clarify" and "communicate" a lot here because those are the core issues. For your manager this isn't a philosophical discussion about the unknowable nature of software defects, this comes down to how to allocate resources efficiently for the business and how to reflect status to various stakeholders.


As others have said I think you need to talk with the manager and get more insight into how they came up with that number. I think it would also behoove you to white board some about the bug and be able to try to fully understand 1) what is happening 2) why is it happening 3) be able to fully understand the code that contains the bug if possible.

I dont know what the bug is that you are dealing with. It could be a low level driver or enterprise web app. I cant emphasize enough that its important to be able to understand that problem, and that usually means you can make a map of the problems inputs and outputs work flow etc


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 would do my best to fix it in the time allotted, but in the end, if it isn't fixed, it's going to take more time.

They could fire you or your whole team and that won't fix the bug either, in fact, that will make it take much longer as they'd have to hire replacements that won't be up to speed.

I would work hard to solve the issue, keep my mouth shut and if it wasn't finished by the next day and someone asked me about it I would tell them about my progress but that I needed more time.


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

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.


The 'bug' was fixed long before the deadline - this isn't about me venting some negative energy on HN when I should be working. Throughout my career I've worked with project managers who've consistently misunderstood the nature of bugs and how they're fixed, and I've often tried to explain why setting an arbitrary timeline doesn't help - regardless of whether they are trying to 'set expectations' or underline the seriousness of the situation.

I hoped that others - I'm sure pretty much everyone has at some time experienced this management style - would be able to give some good tips about ways to help the management to a better understanding of the process.


The discord you're experiencing in your career is real, and to some extent it comes with the profession. Companies are in the business of making working software on time. But you can't always make software work on time. This puts stress on you.

You're trying to get managers to stop setting bug deadlines on the theory that they don't understand that it doesn't help the situation. My assumption would be that they don't care that it doesn't help, they want me to do my job.

I've worked for management that not only showed no signs of understanding the nature of making software, but also didn't understand the nature of making money. A much more serious problem in my opinion. Their job is to bring in the business and your job is to make the software work on time.

It wasn't clear to me earlier that you may be dealing with executives by proxy of a project manager. That's a worse situation because you can't level with a project manager, they are stuck in the middle. You may want to go over his head (if you report to the p.m.) but if you do that, do not complain about him or anything else, bring only solutions and charm.

See my other comment for some more constructive and specific suggestions.


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

Management is just setting a clear objective. Maybe there is some specific repercussion that will occur if the objective isn't met - delay the release - or maybe it's just arbitrary. This may get better results than if no objective is set.

I'm getting PTSD flashbacks imagining how little of your time is going to be able to be used productively over the next couple days, rather than co-opted into a series of status meetings with various layers of management where you say the same thing over and over.

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.


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.

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

Leave


Nine motivated women cannot have a baby in one month.

Just say “we’ll drop everything to get this fixed by the deadline, assuming the cause is not something outside of our control.”

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.

That makes it into a useless internal battle in what is probably a time of crisis. If it happens every month, absolutely, write the details down and have a very serious talk about it. But spending time to write in painstaking detail about something that is clearly a crisis while you could use that time to solve it is really not a constructive approach.

Ending your career? It's called communication.

I'd deal with it by updating my resume.

Take a sick day.

Go work somewhere else



Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: