For context: I am new to managing managers. This person has been an experienced consultant lead and IC, but has been managing for <1 year. The team is trying to fix issues with a legacy system and incrementally build pieces of the next one, but seems to be constantly swallowed up in firefighting.
How should I collaborate with this manager? What’s the right way to help guide forward? (I struggle sometimes to keep track of why there always seems to be 2 steps forward, 1 step back progress around firefighting). I am not sure this person enjoys being a manager and they often seem overwhelmed by the meta tasks (reporting on progress, developing plans, talking to stakeholders, attending meetings) vs actually developing solutions. That said, they’ve built a highly motivated team that seems to be collaborating actively and working together well AND they have great stakeholder trust and relationships.
Things I’ve considered:
* Asking for clear roadmap and criteria for firefighting, plus a roll up summary of firefighting time over past month. * Joining the team as a partial IC to get the lay of the land. * Asking what to cut from scope of team to make progress
My core management goal is to empower my reports to work independently, but this manager is clearly struggling. I even wonder if they should move back to an IC role instead.
Another possibility is that they do know how to fix the problem but don't have the resources. This is where jumping in as an IC would help, but that is a band-aid, and a dubious one at that. If they are short on resources, fixing that falls directly into your job. I've seen new directors jump in too much instead of going to the leadership to argue for more resources. It doesn't often go well. Go fight for what your teams need. And if you cannot get the resources for your teams to get the job done, then figure out how to reduce scope. But do not demote someone for problems that are a result of you not getting them enough resources (if that turns out to be the case).
Now, it's possible that the manager in question doesn't like being a manager, and only took it because they wanted the raise. But more reporting and "roadmaps" on firefighting sounds like a low-value-added response. The most important thing is whether or not any refactoring/improvement is happening in addition to the firefighting.
Cutting scope from the team so they can make faster progress, does seem like a reasonable option to investigate. The main danger to look out for is that the time required to transfer that scope to other teams might end up requiring more meetings and firefighting to deal with the transfer itself. But if it can be done without too much of that, reduced scope might allow for a better result.
Your comment on "criteria for firefighting" suggests that another possibility is that the manager doesn't feel empowered to say "we're not going to spend time fighting that fire", even when the problem is actually not big enough to be worth the distraction. In this case, some support from on high (you) to say that certain kinds of problems should not be considered urgent enough to derail development, might be a thing you consider. I don't know if any of the firefighting being done is actually something that could be ignored until the new system can be created, but it's one thing a second-level manager may feel more empowered to decide than the lowest level.
Or spin up a seprate Core/Platform team to solve the underlying issues that cause fires
Def sounds like the manager has too much on their plate