This article is part of a series on managing managers.

Making the switch to managing managers, and hence managing many teams, can be taxing on the brain. If you’ve not done it before, then you may look at others in more senior roles, potentially running organizations of hundreds of people, and wonder to yourself how they ever find any clock time or mental time for getting anything done.

If you’re used to running one team, that’s a reasonable thought to have. After all, running a team is a tough job. It involves balancing your time between managing others and making your own contributions, working with people outside of your team, deeply understanding the personalities and desires of your staff, and, of course, let’s not forget the most important thing: shipping software.

When viewed through this lens, the thought of having multiple teams may seem quite overwhelming. How are you meant to carry everything in your head that you did before, but at many times the scale? Well, the answer is that you shouldn’t have to. That’s exactly why you have managers reporting to you, which allows you to work at a higher level of abstraction.

Working at this higher level of abstraction allows you to focus your efforts on what’s important; whether that importance manifests in the operational running of work streams or strategic planning for the future. It allows you to step back and to focus your energy where it pays the greatest dividends: the outputs of tens, if not hundreds, of people.

Since those that read this website typically have a background in writing software, I’ll lean on a software engineering analogy in order to explain how you use your managers to work at this higher level of abstraction. We’re going to be looking at the interface between yourself and your managers by looking at, erm, interfaces. How handy.

Interfaces

The programming language that I have the most experience in is Java, so I’m going to lean on it for this particular analogy. An interface in Java, like in other languages, is a type that allows you to define abstract methods that other classes must have if they implement that interface. 

So, for example, you may define an interface for a CurseGenerator:

interface CurseGenerator {
  public String curse();
}

Of which we could then implement a British version:

public class BritishCurseGenerator implements CurseGenerator {
  public String curse() {
    return “Oh, bloody hell!”;
  }
}

An interface allows extensibility in software systems because a particular piece of code can work with any class that implements a given interface, since the interface’s methods are checked to be present in the implementing class at compilation time. 

Most importantly, the code that works with an interface does not need to know the details of the implementation. The implementing class can do whatever it wants as long as it abides by the contract of the method signatures. The interface delegates the implementation to the implementing class.

Do you see where this is going? I’m sure you do. Back to the management analogy:

• As a manager of managers, you define what the interface that represents each of your teams looks like. For example, you may define particular measurements that are important, such as KPIs like application uptime, daily active users, and so on. You may also require that your managers hold weekly one to ones with each of their staff, write a report on progress to the rest of the company every two weeks, or to fix critical priority bugs in one business day.
• Each of your managers has the flexibility of deciding exactly how those teams are run, as long as they follow the interface contract. So the way in which they decide to tackle improving the uptime percentage or the number of daily active users is entirely up to them. Which member staff works on which part of the codebase is down to them and the team. How and when they schedule their one-to-ones and the content that they discuss is for them to decide. But fundamentally, they should be done to abide by the contract of the interface.

Clear interfaces allow you to not have to worry about the exact implementation details of how each of your managers run their teams, but they allow you to make it clear exactly what you expect of each of them in doing so, and therefore how you define success. OK, I’ll stop the programming analogy now.

Defining the interface

So you start by defining that interface with each of your managers. There’s a neat exercise for your first one-to-one meetings (although you can do it at any time) called Contracting, that I’ve written about before. You can expand on that Contracting exercise by having you both think about the answers to the following questions, which make up the interface:

• What success looks like for the team. What measurements are being used to prove that the team is being successful? Is it working towards an outcome, or some KPI, or shipping particular projects on time? Does it also take into account the happiness, productiveness and psychological security of their staff? How will this information be gathered and made accessible to you?
• Which processes will be used to run the team. In order to be successful, how are they going to compose themselves? Will they use scrum, kanban, just get on with it, or something else? How do they intend to ship to production regularly? How will they prioritize and execute on their work? Each team of yours may operate differently depending on the skills and seniority of the people on each.
• How the manager interfaces with each of their own staff. They’ll need to think about the different personalities, skills and career development trajectories for each of their staff and consider what that means for how each of them can operate with autonomy, mastery and purpose. What is an acceptable cadence for one-to-ones? Do they prefer synchronous or asynchronous communication? 
• How will you know if something is going wrong? Code throws errors or performs slowly, bringing problems to your attention. How will issues with the team be made visible so you can work on them together?
• Whether you’d occasionally like to inspect the implementation yourself. Although defining an interface is meant to hide the complexity from you, occasionally it’s interesting to look under the hood and see what’s going on there. You might have some suggestions to make it better, or you may even learn something new. You can arrange a cadence for skip-level meetings, occasionally pop-up in their group meetings to listen, and get feedback from the individuals and the team as a whole.

With a little work up front on the interface, you can make it absolutely clear at what level of involvement you both feel comfortable with having in your relationship. This allows you to abstract away from issues you don’t need to know about as a manager of managers, and gives your direct report the freedom to run the team how they want, as long as the fundamentals that you expect are being implemented. And that’s great, because you can build a great coaching relationship from that foundation, rather than being at risk of micromanaging or firing and forgetting.

Debugging problems

Occasionally things will go wrong, as they do in code. You may need to get the debugger out to see what’s going on. But that’s OK, since you’ve already discussed the interface between you, your direct report, and their team. That interface gives you a number of methods to attach your debugger to.

Perhaps if the team’s cadence is slowing down, you can dig deeper into the processes that are being used to run the team. How often are they shipping? If that’s not very often, why is that? How does code get written, reviewed and deployed? You can keep asking why in order to get to the bottom of quirks that might be bugs. And then you can fix them together.

Sometimes it’s interesting to attach the debugger out of pure curiosity. You can do this in your one-to-ones with your direct report. Focus on one area of your interface and go deep into the implementation by asking questions. You’ll always find something worth discussing, and often there’s some neat performance optimizations to try out.

Beginning with the end in mind

So why have interfaces? 

The ideal end state is that you have clear expectations and boundaries between yourself and the managers that are reporting into you. When you’ve made it clear which high-level functions that each of your managers should be performing, you can delegate the implementation to them so they can do so in whichever way they feel is best for them and their team.

This allows you to move away from details that you don’t need to spend your time focussing on, enabling you to work at a higher level of abstraction. If you were programming, this abstraction would allow you to concentrate on making the system surrounding the interface more efficient, extensible, performant and elegant. That’s exactly what you’ll be wanting to do with the organization, structure and strategic direction of teams as well.