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.
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.
Generally, when I've had to do this, it's been my fault for not manangeing properly.
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.
When you have a bug, you are still figuring out what is wrong.
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.
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.
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.
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.
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)
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.
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.
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.
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?
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.
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.
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
* 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.
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.
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.
They'll blame you, and you can blame the external partner, but this line of blame nobody cares about.
Leave