Seven ways managers can respond when engineering goes wrong

When everything is on fire, it’s tempting for managers to jump in and take personal action. But this is almost always a mistake.

Maybe your team has been battling an aging codebase that no one really understands. Maybe you made a wrong decision and are the architect of your own misery. However it’s happened, your team is struggling to keep on top of everything, and crucial work is starting to come undone.

As a manager, your decisions get difficult very fast. Say you justify one person taking a little time to work on that unexpected critical defect, but now everyone is tied up in super-high-priority work that can’t afford to slip and – oh no! Another urgent request has just been raised. There’s no one free to pick this up – or is there? Why can’t you do it yourself!?

We all have technical skills we relied on back in our IC days. When a fire appears in your former area of expertise, it’s tempting to pick it up yourself. After all, everyone else is busy. What harm would it do to take over just this one thing?

The answer is, a lot. If you’re bogged down putting out a particular fire, the likelihood is no one is doing the most important work a manager can do when a team is overwhelmed with firefighting: figuring out where all the fires are coming from, and devising a plan to stop more starting.

Almost always, the best approach is to stay one step removed from the fires and focus on giving the team the access and control they need to work more efficiently (and with less stress).

But this can be easier said than done. Here I’m sharing my seven steps for responding to incidents as a manager, from unblocking your ICs and figuring out if you should get involved, to very occasionally – if you’re the exception to the rule – rolling up your own sleeves.

1. Look after your people

First of all, do the thing no one else is doing: look after the people. Firefighting is stressful and exhausting, and losing someone to burnout when the team is already struggling can be catastrophic, especially as it’s the most helpful people that will be suffering the most.

2. Assess the problem

If you’re happy the people are fine (for now), look around. Why are there so many fires? How can you make it stop without jumping in? If there’s something that can be done involving people, process, or influence (i.e. management issues), that should be your top priority. If there’s a technical solution, enable its completion any way you can, including canceling commitments. If you have the time, run through the ‘Five whys’ together as a team. Alternatively, ask yourself the following questions:

• Why does the team have more work than it can manage?
• Has something changed, causing a greater workload or an inefficiency that wasn’t there before?
• Are there any steps we can take to make the workload more manageable?
• Consult the metrics. Are the fires springing up more often in one place than another? Why? Can we fix that?

3. Don’t bring in new team members

Try to avoid the trap of thinking ‘we need more people’. If your ICs are struggling, hiring and onboarding new people will only make things worse for months. If hiring is part of the answer, then you’ll need to make other changes first to create the space to add people. This process is slow, and time isn’t on your side.

4. Instead of asking yourself, ‘can I fix it?’, ask yourself ‘should I fix it?’

The more experienced you become, the more ways you can help your team, but the amount of time you have doesn’t increase proportionally. To use it well, you must be aware that not everything you can do ought to be done by you, and conversely, there are some things that can only be done by you. This applies to any senior role with specific responsibilities; your team (hopefully) has plenty of ICs with technical skills, but they don’t have another manager.

Does it make sense for you to fix it? Does the work that needs doing belong to any of the various hats you wear as part of your role within or outside the team? If not, outside of exceptional circumstances you shouldn’t be doing it; someone else would do it faster, better, or benefit more from the opportunity.

Weigh up the pros and cons for it makes sense for you to jump in. What about everything else? Is there something more effective you can do to help? Is there any high-priority work that won’t get done if you do this?

5. Consider the long-term consequences vs short-term goals

When deciding on the pros and cons of taking personal action, consider the long-term consequences as well as the short-term goals. If you do this now, are you setting the expectation that you’ll always do this? How might this come back to bite you in the future?

We speak of managers as ‘enablers’ or ‘force multipliers’. Is jumping in an enabling action? If not, what’s the enabling approach here? Can you do something to enable the work to be completed more quickly and efficiently both now and in the future?

6. Review alternative options before you take action

Consider your options before you take action. There may well be a better approach. Can you think of a few other ways to deal with this fire, instead of putting it out yourself? 

A tech lead I once worked with insisted people came to them with at least three architectural proposals for any problem; they argued they’d have no way of knowing how good a choice is if they had nothing to compare it against. This is equally true in management. The best of three options is far more likely to result in a good idea than the first approach you think of.

7. If you’ve done all this and still think you need to jump in… roll up your sleeves 

Of course, there are a few exceptions where it’s a good idea to fix the problem yourself. The first is if you’re in a hybrid role (if you are both manager and an IC). It might be appropriate to pick the technical side of your role, but be aware that if your team is struggling, you may have more management work to do than you think.

Even in hands-off manager roles, there are occasions when what the team needs more than anything else is temporary technical assistance. Maybe there’s a vulnerability that needs fixing, and it just needs dividing up between the team and patching up. Then you can dive in as an IC, but only if there’s no better way to resolve the issue.

The other roles on the team shouldn’t shuffle; don’t disrupt the normal technical lead in the team by getting involved. In this situation, you’re acting as another IC, and should report to them and not get in their way.

Remember that old skills get rusty and you’re probably not as good as you were. If you make mistakes that add to the fires, you’re not helping anyone. Finally, consider your exit strategy. Do you know how and when you’re going to stop being an IC and return to being a manager?

Reflections

Being hands-off when your team is struggling is hard. You can feel helpless and useless. But remember that the value you bring to the team is as a manager, not an IC. They’re relying on you to guide them out of the fire, not do the job they’re already doing. Do what you should, not what you can. Good luck!