The Engineering Manager

This article is part of a series on managing managers.

When I was writing my book, I referred to “skip-level meetings” in the text. My copyeditor left me a comment: “What are these? You’ve not mentioned them elsewhere.” It seems that I’ve also previously mentioned skip-level meetings twice on this website without offering any explanation. I’m sorry about that. It seems that I’ve always assumed that people know what they are. So let’s change that.

Skip-level meetings are typically semi-frequent meetings between staff who have a layer in the org chart separating them. It’s a meeting between someone of a given depth m and another of depth m+2. In more relatable human terms, if you were a manager of managers, then a skip-level meeting might involve you having a meeting with one the individual contributors on your direct report’s team.

Don’t worry, I can hear you already: “Another article about more meetings?” Well, yes. But skip-level meetings can pay dividends for you as a manager of managers. They build trust and break down barriers. But before we get into why they’re good, explore the frequency that you should do them, and suggest some example topics of conversation, I’d like to remind you of a particular scene in my favourite television show.

These are for you, McNulty

In a previous article about workplace politics, we highlighted that in particularly old-fashioned workplaces, not going through the proper channels can be problematic. But what do I mean about the proper channels? Well, there is a particularly memorable scene in The Wire (warning: extremely strong language) where Jimmy McNulty, in his usual casually reckless way, talks to a judge about previous murder cases that he feels did not get solved properly. This results in the judge speaking to the Deputy, and then the Deputy calling the Major into his office to explain the situation that he knew nothing about. Hence all of the swearing and the punishment of all-night report writing.

The org chart – whether on purpose or not – can create the expectation of knowledge boundaries where the “proper” way of sharing information is to send it up and down the chain, as McNulty probably should have done with Rawls. However, we all know that this can be counter-productive, bureaucratic and just plain annoying. Sometimes it’s just easier to talk to the person you need to talk to, even if that person happens to be your manager’s manager. 

So why not just have that happening as a regular arrangement? That’s what skip-level meetings are about. You can, with transparency, probe deeper to build rapport, uncover issues, and help your staff grow.

Benefits

There’s a number of benefits for having a culture of skip-level meetings, and those benefits are gained at both ends of the skip-level relationship.

Here are some reasons that skip-level meetings are good for you as a manager of managers:

• They build rapport with the people in your org. Although you could manage entirely through the interface of your managers, your impact, output and availability as a leader is greatly increased by building strong relationships with those in their teams as well. 
• They show that you’re just another human. Sometimes people higher up in the org chart become shrouded in mystery: an important person with a fancy job title that they people aren’t allowed to talk to. However, that’s entirely false. You’re there for them as they fundamentally work for you, so you can show them that you’ve got their back and are open to talk.
• They give you additional insight into how your teams are doing. You don’t have to wait for performance reviews in order to gather a picture of how your teams are doing. By regularly speaking to the staff on those teams, you can build a better picture of how that team functions by looking at it from above and below.
• You get additional insight into how your direct report is performing. Related to the above, you can gently probe into how they feel about their peers and their manager and whether they and their team are getting the support that they need to succeed.
• They demonstrate that you value everyone, regardless of their position in the org chart. By making your time – your most precious commodity – available to more people, you show them that you truly value them. You also show that you don’t entertain politics, where information must always filter through the chain of people in the org chart.

There’s also plenty of benefits for the other member of staff:

• They open the door for fairness and transparency. By knowing that their manager’s manager has time for them, they know that their performance and path at the company isn’t only viewed through the lens of their own manager. 
• They get an insight into what’s going on in other parts of the department and company. Being a couple of levels higher in the org chart, you’ll have access to interesting operational or strategic information about what’s going on in other teams, forming the bigger picture that they’re part of. 
• They get a direct line to give feedback, raise concerns and suggest ideas. Maybe they’ve got suggestions about people, processes, product and tooling ideas that are beyond the scope of their manager to solve. However, you might be just the right person to pick these up and look into them.
• They demystify what goes on at a leadership level. They get the opportunity to lift the lid on what happens higher up the org chart by talking to you about what you spend your time on and what’s important. This not only builds rapport, but it gives them an insight into what the management track might hold for them in the future.
• They allow opportunities for more connections. You may know many more people in the department, so you could make a mentor or mentee connection across different teams, or introduce them to someone that has been working on similar problems before.

So, hopefully I’ve convinced you that they’re a good idea. Now we should think about the practicalities of doing them.

How often should you hold them?

If you have many teams reporting into you, then that’s potentially a lot of people in order to arrange skip-level meetings with. If you’re already having weekly one-to-ones with your direct reports, then you could imagine your calendar becoming even more of a mess than it is already.

A way of tackling this conundrum is to list all of the people that are a skip-level away from you and then bucket them into different meeting intervals depending on the relationship that you want to form with them. I don’t recommend having skip-level meetings weekly, since you’ve already got your direct reports to meet with at that frequency. 

However, you can consider the following intervals:

• Fortnightly: A very small percentage of staff should be in this category. Perhaps you have a few superstars that you see growing quickly, or individuals who are at the core of an important initiative for the department that you wish to lend more support to.
• Monthly: This is a good “normal” cadence. 30 minutes once a month is a good amount of time to check in, catch up and discover what has been going on. Of course, you can always have follow up meetings if anything particularly interesting or worrying arises.
• Quarterly: Some individuals are less chatty, or may not particularly need or want your time (and you’ll know who these people are based on your initial conversations). Checking in once a quarter makes the arrangement more easy going, and enough time passes since you’ve last met for some topics of conversation to arise.
• Occasionally and/or on request: And of course, there may be members of your staff that prefer to have as few meetings as possible and may not get huge value from the relationship, and that’s perfectly fine. You can forgo a planned schedule and just let them grab you when they need you, or vice versa.

The intervals that will suit various members of staff with ebb and flow with time, so don’t be afraid to switch it up depending on which projects you have running, or whether particular staff are going through a period of career growth or a difficult time. Be flexible and offer your support where needed, and work with your direct reports to get this information.

Getting them started

So, get those skip-level meetings kicked off. Before you start causing panic by booking in meetings without any context, perhaps you could send out something like this, after having let your direct report managers know that you’re going to do it.

Hey everyone,

I’m going to start doing skip-level meetings. There’s no bad reason for doing this, in fact, it’s very much for good reasons: I want to get to know you all better, understand what you’re working on more clearly, and – where I can – help you succeed.

What this means is that I’ll be booking in some semi-regular catch-ups where we can have a chat about whatever you want. It can be as formal or as informal as you like. 

Perhaps we could talk about what you’re working on and what I’m working on, or what’s coming up in the future for our teams. We could touch on your career progression, or discuss any concerns that you have about your role or the company.

Your manager knows that this is going to be happening, so don’t worry about that. Also, if you’d rather not do it because you feel you have enough meetings already, then that’s totally fine! Just let me know. But do know that you can come and chat to me at any time.

Best,

A. Manager

This message is written from the viewpoint of a manager getting them underway. But what if you’re an IC and are interested in getting this kicked off?

I’d suggest you start small: speak to your manager about whether you can set up skip-level meetings with their manager. If they’re unsure as to why, then why not just direct them to this article? 

And if you’ve been directed to this article because someone would like to do skip-level meetings with you or your manager, what are you waiting for? Trust me, it’s worth it. Go on.

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.