Managing Managers: A System, Not a Team

From the field: seven months, two rules

At that time I had three managers and 21 engineers under them. Two of them had become team leads five months earlier. One had been a manager for two years. I had stated the on-call rule out loud in a meeting the May before: “Whoever is paged at night rests the next day.”

The orders team’s manager understood it as “do not come in before noon”. The accounts team’s manager understood it as “take the next day off”. Both were loyal to my sentence. Neither mentioned on-call in their weekly report, because for neither of them was there a problem. The problem started when engineers from the two teams talked in the coffee queue.

What I did in that skip-level made it worse. I said: “It should be a full day, I will sort it out.” The next morning the orders team’s manager heard the decision from their own team. Not from me. I learned two things that day. A rule I had not written down was not really my rule. And every decision I made in that room went around the manager.

The job changed: a system, not a team

When you manage one team, you see the work. You are in the standup, you see the pull requests, you can read on someone’s face that they are struggling. When the team grows and splits, you lose that view and a different job takes its place. It is not a bigger version of managing a team. It is a different job.

The last row matters most. If three managers make three different decisions in the same situation, you have three separate companies. Your job is not to make their decisions one by one. It is to build the system that keeps their decisions consistent. Going from developer to manager was a change of job. Becoming a manager of managers changes it again.

Skip-levels without undermining the manager

A skip-level is a meeting with the people who report to your managers. Its purpose is to collect information: to hear what the manager cannot see, or does not say. Done badly, it teaches the team one thing: “The real decisions are made above. Go around your manager.”

After the on-call story I wrote down the rules. Now I meet every engineer once a quarter, for 30 minutes. With 21 people, that is two meetings a week.

BEFORE
  - The manager knows about the meeting in advance.
  - No agenda. One question ready: "What slows you down most?"

IN THE ROOM
  - No decisions. Say: "I will talk about this with your manager."
  - I neither defend nor judge the manager's decisions.
  - If there is a complaint about a person: "Did you tell them?"

AFTER (within 48 hours)
  - The manager gets themes, not names.
  - Example: "3 people said the same: test env is down 2 days a week."
  - The manager takes the action and announces it to the team.

The third part is the most important one. If the team hears about a fix from me, they will bring the next problem to me too. If they hear it from their manager, they will bring it to their manager. Who announces the fix decides where the next problem goes.

The hardest case is a complaint about the manager themselves. In the first year I got this wrong. I listened, took notes, and told the manager: “some people on the team feel this way.” In a team of seven, the manager found out who said it within two days. That person never spoke in a skip-level again. Now I first ask: “Did you tell them?” If not, we think together about how they could say it. If I hear the same thing from two different people, it becomes a theme, and I raise it with the manager together with my own observation. Passing on one sentence does not give the manager information. It gives them a suspicion.

A skip-level does not replace the one-on-one. A one-on-one is a weekly relationship; a skip-level is a quarterly sample. The manager owns the first. The second is there to complete their channel, not to check it.

Information gets filtered on its way up

Two months after the on-call story, a second lesson came. The accounts team’s weekly report had been “green” for six weeks. In that quarter’s skip-levels, four of the seven people on that team said the same thing: every release waited four days on average for security approval.

The manager was not lying. For them the wait was “normal”. It was not a risk to put in a report, it was part of life. In the managing up post I wrote about the side that writes the report: give bad news early. This time I was on the side that reads it, and I saw this: every layer filters out what feels normal to it. It is not on purpose. But after two layers of filtering, the information that reaches you does not include the problems everyone has accepted as normal.

One channel cannot fix this. I look at three sources and trust where they overlap:

• The manager’s report. It tells you what they see and what they think matters.
• Skip-level themes. They tell you what the team lives through.
• Data. Lead time, release wait time, number of on-call pages. It does not pass through anyone’s opinion.

If all three say the same thing, it is true. If two say something and one is silent, the silent channel is the topic to discuss. On the accounts team, the data and the skip-levels said “four days” and the report said nothing. My conversation with the manager was not “why did you not tell me”. It was “why does this feel normal to you”. The second question did not bring a defence. It brought a list.

One rule, two versions

After the on-call story I sat down with the three managers and listed everything we treated as a cross-team rule. We found 11: on-call time off, remote work days, training budget, leave approval, the number of approvals needed in code review, and others. 4 of the 11 were applied differently across the three teams. None of them were written down.

The fix was not complicated: a one-page rule book, with four lines for each rule.

RULE      : On-call time off
SAYS      : Anyone paged between 00:00 and 07:00 takes the whole
            next day off. The day off is written in the on-call calendar.
WHY       : A tired engineer should not touch production.
EXCEPTION : The manager grants it and notes it in the rule book with a date.

-- once a month, 30 min --
The three managers read last month's exceptions together.
Question: "What would I have done in the same situation?"

The last line does the real work. Writing the rule down reduces the difference but does not remove it. Reading the exceptions together brings the difference to the surface before engineers complain. In the first reading, two managers saw that they had both postponed on-call time off because of “urgent work”. One did it once a month, the other four times a month. Same reason, four times the difference.

There is one thing I am careful about: the rule book is not a regulation. A rule that leaves the manager no room to think turns them into a relay. The book only holds rules that need to be fair across teams. How a team works inside itself is the manager’s decision.

Growing a new manager

My first one-on-ones with the two people who had become managers five months earlier were about their teams’ status. Which work is where, who is struggling, how the sprint went. I could already read that on the board. It taught the manager nothing.

Now the first half of the one-on-one is about two decisions: two decisions they made this week and are not sure about. Three questions:

1. “What did you choose, and what did you leave out?” Did they see the options, or only one path?
2. “Who did you tell, and how?” Most decisions go wrong in the announcement, not in the content.
3. “If it happened again, what would you change?” They answer first. My view comes last.

In the first weeks it was hard to find two decisions. They said “I did not make any important decision this week.” By the fourth week the list grew by itself. They were making decisions where they thought they were not: who goes on call, which pull request waits, which meeting they skip. Noticing a decision was the first step to reviewing it.

The second lesson came with hard conversations. One of the new managers postponed a conversation with an underperforming engineer for three weeks. In the fourth week they asked: “Can you talk to them?” I said yes. The conversation went well, but afterwards that engineer started bringing every problem to me. The conversation I had in the manager’s place had changed who the team saw as their manager.

I do not do that any more. Instead, we prepare the conversation together. They write the first sentence, I play the other person, and we rehearse twice. We already have the pattern from the negative feedback post. What is missing is not the pattern, but the tension of saying it out loud for the first time. They have the conversation, and the next day we review it together. This is what I described in the delegation post, applied to a manager: letting go of the outcome, not handing out tasks.

Six months later

I started the skip-level rules, the rule book and decision-focused one-on-ones in January. These are the numbers that changed by July:

I care most about the first row. If the manager already knows what I hear in a skip-level, the information flow is working. Skip-levels no longer produce surprises. They produce confirmation. That is how it should be.

What to track

What did not work for me

• An open-door policy. I said “anyone can come to me directly”. The people who came were the ones who did not want to talk to their manager. The open door became the official way to go around the manager.
• Group skip-levels. I put five people in one room. The two most senior people talked and the other three nodded. I collected the loudest voice, not the themes.
• Joining sprints as the manager of managers. For two months I went to all three teams’ planning meetings. In every decision the teams looked at me, not at their managers. I stopped going and started reading the planning notes instead.

Checklist

Conclusion

That Tuesday, I had not made a bad rule. The rule was fine. The problem was that it had one meaning only in my head. Three managers gave it three meanings, and all of them were right.

When you become a manager of managers, the job moves from seeing the work to building a system: written rules, skip-levels that do not go around the manager, information checked through three channels, one-on-ones built on decisions. None of it is impressive. All of it exists to change what happens when you are not in the room.

The test: if you disappeared for two weeks, would your three managers give the same answer to the same question? If yes, you have built a system. If not, you do not have one team. You have three separate teams, and you are the only thing holding them together.