MANAGEMENT / PRIORITIES / RESPONSIBILITY
After Setting Priorities, What Does a Manager Still Owe the Team?
Imagine a firmware team responsible for both new releases and maintenance of existing products.
System TL Alex wants to address a recurring problem that keeps disrupting delivery. Wi-Fi TL Chris wants to preserve the planned integration work. It has already been delayed once. Another pause would mean rearranging verification and coordination downstream.
They see different risks. But they need the same engineers and test resources.
Engineering Manager Ryan initially wants both efforts to continue. He knows the technology. Perhaps taking on more work himself could keep the original plan intact.
He has often done this when work gets difficult. Stepping in is easier than renegotiating commitments, and progress becomes visible sooner.
But after several rounds of coordination, Alex and Chris still have to decide every day who gets support first and who waits. Both efforts are moving, yet neither TL can say when they will finish.
Ryan finally acknowledges that keeping both efforts running has left the team to make the trade-offs day by day. The commitments look unchanged on paper. Engineers absorb the cost through context switching, and TLs through repeated coordination.
He asks both TLs to explain the impact of delaying their work.
Alex points out that the existing problem has repeatedly interrupted engineers' other tasks. Carrying it forward makes both workstreams difficult to plan reliably.
Chris reminds him that integration involves commitments from other teams. Freeing up firmware capacity can make other teams wait and compress downstream verification schedules.
Ryan leans toward addressing the existing problem first. But he needs to establish whether the cost of delaying integration is still manageable.
He revisits the plan with the relevant teams. Some preparation can continue; some timelines need to change. They agree to reassess the allocation when preparation starts needing integration results to proceed.
Ryan decides to concentrate resources on the existing problem.
His reasoning is that recurring interruptions are affecting both workstreams, while the impact of delaying integration can still be managed through rescheduling.
Even with concentrated resources, however, it remains uncertain whether the investigation will make enough progress.
Chris does not fully agree. He believes the delay accepted now could become harder to absorb in the next phase.
Ryan keeps that concern on the review agenda. He updates delivery expectations with the relevant teams: which preparation will continue, which work will pause, and which dates need to change. Alex leads the investigation. Chris retains technical ownership of integration and tracks which dependencies the delay begins to affect.
After the decision, Ryan's attention naturally shifts toward Alex.
That is where he has chosen to invest. He wants to know which possible causes have been ruled out, which unknowns still affect the next step, and when the recurring interruptions might ease.
With fewer resources allocated to Chris's work, it also receives less attention in progress discussions.
Then, during a review, Chris reminds him that preparation is nearly complete. Integration results are needed next. If they keep waiting, other teams will stall too.
The condition they agreed would trigger another discussion has arrived.
Ryan brings both TLs and the relevant teams back into the same resource discussion.
Alex explains which possible causes have been ruled out, what the remaining investigation needs, and what will remain unknown if its scope is reduced. Chris identifies which integration work must restart first and which commitments further delay would affect.
Ryan restores some integration resources while continuing the investigation with a narrower scope. He agrees on the revised plan with the relevant teams, updates the expected investigation and integration timelines, and makes clear which verification work still has to be done. Delivery commitments need to change with the allocation; the two TLs cannot be left to make up the difference with fewer resources.
This adjustment does not make both efforts faster. Alex must accept less capacity, and Chris does not get all his original resources back.
But the team no longer has to compete for support day by day or guess which work matters more today.
Ryan still cannot guarantee when the problem will be resolved. But both TLs know what to move forward now, which commitments have changed, and what evidence to bring to the next review.
Priorities Include Responsibility for Deferred Work
Neither TL in this scenario has lost their sense of responsibility. Once each has understood the problem in their domain, someone still needs to make the trade-offs across domains.
Ryan initially used his own effort to keep both workstreams moving, making the resource conflict less visible for a while. Choosing a direction gave the team a plan it could execute.
But he nearly let deferred work fall out of view.
Deferred work still has value. The people waiting for it still have commitments and costs. A manager who supports one effort also takes responsibility for tracking the cost to the other.
Technical depth helps a Manager understand evidence and challenge assumptions. Management judgment also connects that understanding to resources, dependencies and commitments, and revisits the plan as conditions change.
A manager should also revisit the decision before deferred work comes under pressure. If the investigation keeps consuming capacity without narrowing the key unknowns, what still justifies that investment? Should the team change its approach, seek support or reallocate resources?
The value of the choice depends on both the evidence gained from the investment and the cost imposed on other work. After setting priorities, a Manager still owes the team this: keep tracking both, and make another decision when the original reasoning no longer holds.