3 ms·

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

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.

null_object 5y ago
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!
- fabbari 5y ago
  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.
alunchbox 5y ago
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.
wombatpm 5y ago
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.
troelsSteegin 5y ago
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 5y ago

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!

fabbari 5y ago
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.

alunchbox 5y ago

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.

wombatpm 5y ago

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.

troelsSteegin 5y ago

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.