Ask HN: Advice for a new manager whose team is fire fighting with incidents - rahulskn86
======
JohnFen
I think more information is required here in order to get pertinent advice.

My general comments about managing a team that is engulfed in firefighting
activities:

1) Don't pile on. Not everything can be a "#1 priority". An important part of
the job of a manager is to guide the setting of priorities. Determine the
priority ranking, and assign tasks according to it. Shield your team from
pressure from other parts of the company when it comes to the items that
aren't currently assigned.

2) Set proper expectations to upper management. This is part of your "protect
your developers" role -- you are the firewall. Accurately and honestly keep
upper management informed of what is currently being worked on, what is not,
and why.

3) Don't push your team to work faster than is sustainable. Pushing for extra
effort is fine when done occasionally, but it's not fine when it becomes
standard operating procedure.

4) Keep track of progress. If it's taking longer than it should to put out a
given fire, find out why and grease those skids if possible. If "why" is
because it's a trickier job than expected, consider temporarily swapping that
task out for a different task of equal priority, or reassigning that task to a
different dev, and so forth.

5) Be aware that simply adding more people to a task will not necessarily
speed up the completion of that task (and will often slow it down).

6) Celebrate all victories. It's very hard on a team when all they are doing
is firefighting. Every time a fire is put out, celebrate that with your team.
It doesn't have to be a big deal -- it can be just a department-wide email
recognizing the victory, an afternoon off, a cake, or even just a short
victory dance in front of the rest of the team. The idea is to provide a sense
of completion and a job well done, rather than just letting the team do
nothing but dwell on the raging infernos that still await them.

~~~
twunde
JohnFen's answer addresses the incident response side. The other half is that
you want to fix problems upstream to prevent these incidents in the first
place. A general process that you should take and edit:

1\. Run blameless post-mortems to figure out what caused the incident and more
importantly what actions would have prevented the incident from occurring in
the first place 2\. Prioritize doing the corrective action. This can be as
simple as checklists for specific procedures or could be the addition of
automated tests/static analysis/linting or automating a procedure. Focus on
low-lift quick wins here if possible. You should be selling these corrective
actions as required maintenance such as changing the oil in your car. 3\.
Rinse and repeat.

For SAAS products some things that really make a difference are automated test
suites, monitoring, and _documented_ procedures

------
karmakaze
In addition to the other good comments, manage firefighting as it's own
activity.

Create a time tracker where anyone doing unplanned work records it as either
firefighting or other unplanned non-firefighting work. Whenever doing planning
take the history of these times into account.

Assign one person to be the go-to for any and all fires, have them assess the
situation bringing in select other team members as necessary. Having everyone
respond to every fire with only a few key people actually doing the
extinguishing leads to no scheduled work getting done.

Tech-debt. In my experience a lot of fires result from the tech debt of
incomplete or poorly designed/implemented features. Schedule a certain number
of hours to reduce this and have a groomed backlog of tech debt prioritized
when prioritizing regular schedule work.

