Managing managers becomes difficult the first time two capable leaders bring you opposite answers to the same problem. A data platform manager wants engineers focused on a broken pipeline. An analytics manager needs a dashboard change before tomorrow’s sales review. Both have good reasons. If you take over their task lists, you may settle today’s argument while teaching both teams to wait for your instructions next time.
I have led large data and analytics teams and worked through the delivery conflicts that appear between business requests and technical obligations. My view is that the leader’s job is to settle the business tradeoff, set boundaries, and develop the managers who will handle the next conflict. This article uses a fictional incident to make that distinction concrete. It is a working approach, not a claim that this exact event happened on one of my teams.
What changes when you start managing managers?
As a direct manager, you can see much of the work. You know who is building a pipeline and who is waiting for a review. When you manage managers, each person reporting to you has their own team, priorities, and judgment. Your decisions reach people you may rarely speak to directly. A casual request from you can displace a week of work without appearing on anyone’s plan.
The old habit is tempting: join the project channel, diagnose the incident, reassign an engineer, and promise Sales a delivery date. You may be able to do all four. However, your platform manager now owns the incident in name only, and your analytics manager cannot make a credible commitment because you may change it. People learn to come to you for the next decision. I recognize that impulse from my own career. Early on, I treated taking on every task as proof of competence. Learning to delegate changed what I could contribute as a leader.
There is a useful distinction between accountability and direct control. You remain accountable for the team’s results and for the quality of its management. Yet a manager needs room to choose the method, allocate people, and correct a plan. You should reserve your own authority for decisions that cross team boundaries, change business priority, or exceed a manager’s agreed limits.
A realistic conflict between two data teams
At 9 a.m., a sales data pipeline begins delivering incomplete figures. The platform team identifies a failed upstream change and starts recovery. At the same time, a sales leader asks the analytics team to add a new regional view before a meeting the next morning. The view depends on the same data source. Neither manager can solve the whole problem alone.
The platform manager says, “I need two engineers on the recovery and validation. I cannot lend them for a dashboard change.” The analytics manager replies, “Sales has already promised the view to regional leaders. If we wait, the meeting has no usable numbers.” Both describe a real cost. The senior leader has to decide whether the new view can wait, whether a verified older snapshot is acceptable, and what Sales will be told.
The managers should arrive with options, not merely competing demands. The platform manager can estimate recovery time, identify a safe rollback, and state what validation remains. The analytics manager can explain whether an existing report answers most of the question, what would be missing, and the earliest honest delivery time. The leader then chooses the business priority and owns the communication upward.
The picture below captures the split. It is a decision guide for this fictional case, not a universal org chart.
Give each manager a decision boundary
“Use your judgment” sounds generous until a manager discovers that you expected approval for a decision they already made. Write down a few boundaries in plain language. They should describe the decisions the manager can make, the information they must share, and the situations that need you. Keep the list short enough to use during a busy day.
| Decision | Manager owns | Leader joins when |
|---|---|---|
| Work within one team | Sequence tasks, assign people, and agree a feasible date within the approved priority. | The change displaces an agreed business commitment or needs resources from another team. |
| Production incident | Run the response, protect validation, and communicate technical status through the incident process. | Business impact crosses a threshold, priorities conflict, or an executive commitment must change. |
| Cross-team dependency | Bring the other manager options, costs, and a recommendation. | The managers cannot resolve the tradeoff under the agreed priorities. |
| People management | Coach, give feedback, and address performance with the proper support. | Policy, serious conduct, retention, or a decision outside the manager’s authority requires involvement. |
These are examples, not a substitute for an employer’s incident, HR, or approval rules. The thresholds matter. “Tell me if a production issue affects a customer commitment” gives a manager more help than “keep me posted.” For an incident, define who declares it, who can authorize a rollback, and when business owners receive an update before the pressure arrives.
In the fictional case, the leader might say: “Restore and validate the current sales figures first. Use yesterday’s verified report for the meeting, with its date stated clearly. Analytics can build the regional view after platform confirms the source is sound. I will tell Sales what changed and when the new view can be reviewed.” That is a priority decision. It does not dictate which engineer runs the rollback.
How to coach a manager without taking the decision back
Suppose the analytics manager brings a plan that assumes the pipeline will recover in two hours. You know that validation often takes longer. Resist replacing their plan with yours immediately. Ask what evidence supports the estimate, what happens if recovery takes six hours, and who would approve the alternative report. Their answer will tell you whether they need information, a decision boundary, or coaching.
A useful one-on-one question is: “What do you recommend, and what would change your mind?” It invites ownership and makes assumptions visible. You can then add information the manager lacks or challenge a weak assumption. If the decision still belongs to them, say so clearly. “I would test the older snapshot with Sales first. You own the final plan within the agreed deadline. Tell me if you need a priority decision.”
Sometimes you must step in. A serious incident, a policy concern, or a public commitment may require it. Name the reason and the duration: “I am taking the business communication for this incident. You still own the recovery plan. We will review the handoff after service is stable.” The manager and team can then see where authority moved and when it returns.
Review the decision afterward without using hindsight as a weapon. Ask what the managers knew at the time, which assumption failed, and what signal should trigger an earlier escalation next time. If your own unclear priority caused the confusion, own that too. Coaching loses its force when every missed estimate becomes a trial of the manager’s judgment.
Set a meeting rhythm that exposes tradeoffs early
A leader of managers needs two views: the health of each team and the work that crosses teams. A weekly meeting with each manager should cover people, delivery, and decisions they need from you. A short joint review can surface shared dependencies before they become Friday afternoon emergencies. Avoid turning either meeting into a recital of every task.
For each manager’s one-on-one, try three prompts: What changed since last week? Which decision is stuck? What are you doing to develop someone on your team? The third question matters because a manager can hit every delivery date while leaving a team dependent on them for every small choice.
In the joint review, look at a small set of work that genuinely crosses teams: source changes, incidents, major launches, staffing conflicts, and promises to business partners. Record the owner, the next decision, and a date. A shared list of every ticket will hide the tradeoffs you are there to resolve.
Use outcome and quality signals together. For a data team, a green delivery report means little if failed jobs are quietly rerun by one exhausted engineer. Watch recovery time, repeated incidents, data corrections, missed commitments, and the age of blocked dependencies. Then ask managers what those signals mean. A number should start a conversation, not replace one.
Use skip-level conversations without undermining a manager
You should hear from people who report to your managers. A skip-level conversation can reveal a dependency or team problem that did not appear in a status report. Explain its purpose beforehand. You are learning how the system works and whether people can raise problems safely. You are not offering a second channel for routine task assignments.
Ask what makes good work difficult, where priorities change without explanation, and which decisions wait too long. Do not promise secrecy you cannot keep, especially when someone raises a serious conduct or safety issue. Follow the appropriate company process for those concerns. For ordinary issues, discuss the pattern with the manager while protecting unnecessary personal detail.
If an engineer says the incident rota is exhausting, do not silently rebuild the rota for their manager. Ask the manager how coverage is working, what the team has said, and what options they see. You may need to approve staffing or change a service commitment. The manager should still lead the team’s rota and follow-up.
GitLab’s public skip-level meeting guidance describes these meetings as a way to hear from the broader team. The practice is useful only if people understand how you will handle what they tell you.
What failure looks like in managing managers
One warning sign is that team members bypass their manager because your answer arrives faster. Another is that managers ask your permission for choices clearly inside their remit. A third is that every cross-team issue becomes a personal contest between managers because you have never stated the priority rule. None of these problems is fixed by telling managers to “take ownership” again.
Check your own behavior first. Did you reverse a manager’s decision without explaining why? Did you give an engineer a task directly while their manager was planning the team’s work? Did you promise a deadline to Sales before asking the delivery managers what it required? Each of those actions teaches people a different decision map from the one on paper.
Then check capability. A new manager may need practice estimating work, giving feedback, or handling an incident. Agree on one skill to develop, observe a real decision, and offer specific feedback. If a manager repeatedly fails to act within clear boundaries despite support, address the performance issue directly. More meetings and copied emails will not make an unmade decision appear.
A practical first month for a new leader of managers
In week one, ask each manager what they own, where they need approval, and which recurring decision takes too long. Compare their answers with your own. The differences are your first work items. Also learn the people and delivery risks that would matter if a manager were unavailable tomorrow.
During week two, write a one-page decision map together. Include incident authority, customer commitments, staffing changes, cross-team priority disputes, and serious people matters. Use real examples and the company’s existing policies. If the map cannot answer the last two conflicts, revise it.
In week three, test the map in a joint review. Ask managers to bring one unresolved dependency with options and a recommendation. Settle the tradeoff, state who will communicate the decision, and leave execution with its manager. Finally, in week four, ask whether fewer decisions are waiting for you and whether the teams still know whom to ask. Adjust the boundaries where work has stalled.
This is a starting rhythm, not a maturity score. A stable team may need less ceremony. A new organization or a serious incident may need more direct involvement for a time. The test is whether managers can make sound decisions, people understand the priorities, and business promises reflect what the teams can deliver.
The leader’s real contribution
Managing managers means building a system in which good decisions happen without your presence in every room. You still have hard calls to make. When two teams cannot both have the same engineer, you choose the tradeoff and accept its consequence. You also develop the managers who will make the next call before it reaches you.
For related reading, my guide to managing up as a data leader looks at the executive side of these conversations. The data team building article covers team design. In The Data-Driven Executive, I examine how leaders can ask better questions during an incident while leaving diagnosis with the team. My AI to ROI for Business Leaders also makes the case for writing down decision authority and escalation paths before a project is under pressure. For the career side of that transition, The Lost Map to Your Career draws on my experience learning to delegate and lead without carrying every task myself.
What is your team building, what data does it depend on, and which decision or blocker still comes to you too often?