The Engineering Manager

It’s more important than ever to be in the details of what’s going on in your organization. Are you?

In recent years companies have been flattening, creating fewer layers of management between the top and the bottom of the org chart. This is a reversal of the rapid growth during the zero interest-rate policy (ZIRP) phase during COVID-19, which created a glut of new managers under which to slot newly hired engineers.

Efficiency is the play now.

Tech companies are opting to keep their size fixed as they ride out the current economic phase that has higher interest rates and less cheap investment available. As a result, managers are now expected to have more direct reports, less layers, and to be more hands-on with their teams.

Some newer managers find this strange. Being hands-on, however, is not a new thing.

In the 1980s, Andy Grove, the CEO of Intel, wrote about the importance of being in the details in his book High Output Management. In the book, he talked about how he would regularly walk the floor of the factories to see what was going on, and how he would ask probing questions to workers at all levels to understand the details of what was happening in his organization.

This might sound familiar: we’ve seen this in recent years with Elon Musk, who is known for being deeply involved in the details of his companies. Building a full picture based on your own experience of what is going on means you can make better decisions and intervene and correct course when necessary.

So, we need to be efficient as the economy is calling for it. And we need to know the details so that we can achieve that efficiency by using our time and people wisely.

Yet, there has been some cultural resistance to this trend from some managers, claiming that the job of management is to be strategic and to delegate all of the details to others. Getting close to the details has been seen as meddling or even as a sign of having a lack of trust in your team.

It’s true that an organization of several hundred or thousand people can produce far more than one person can. However, that’s no excuse for not knowing what is going on and being able to have a firm handle on the most important initiatives.

Sometimes being in the details can be conflated with micromanagement, which in turn has become a meme for bad management. This isn’t entirely fair.

Micromanagement done well is not a bad thing at all if you are bringing focus, knowledge, and expertise to the parts of your organization that need it most. In fact, it can be energizing both for you and for your team to be collaborating on the most important work together.

Getting delegation wrong

Good management comes through delegation of responsibility, without delegating away accountability.

In order to be accountable for what your organization is doing, you need to be in the details. For all of your engineers, what are they doing today? What about last week? What are the top three most important projects? How are they progressing? Are they blocked? Are you making the right trade-offs? Are you making the right decisions?

At organizations that have a high performance bar, and especially those that are founder-led, managers with hundreds or even thousands of engineers will be expected to know the progress on all their key projects, what the key technical decisions and strategies are, and for the most critical projects, to be able to answer detailed questions (e.g. scale, architecture, throughput, latency, etc.) about them.

Middle management is not just a communication bus. You should be making things happen.

New senior managers who have become highly effective at managing smaller teams may overdelegate in larger organizations to the point that they require someone else to answer all of the key questions for them. This is a bug, not a feature. You need to know what your org is doing if you are accountable for it.

You can test your own knowledge of the details by asking probing questions about your organization such as:

• What is person X working on right now? What did they get done last week?
• Why is project Y estimated to take this long?
• What is the proposed architecture and trade-offs for project Z? Why were other options not considered?
• How many incidents did you have last month?
• How are you performing to your KPIs and SLOs this quarter?

If you can’t answer these questions, you’re not in the details.

It’s your organization: why don’t you know?

Do your job

As someone who has written a lot about management in technology companies, and also as someone who has given and watched many talks in recent years at conferences, I sometimes I observe managers missing the point about what their role is about.

Yes, it’s about creating high-performing teams. I get that. Yes, it’s about psychological safety and creating a culture of learning. Why wouldn’t it be? Yes, it’s about setting a vision and strategy. Sure. And yes, it’s about coaching and mentoring and fostering future talent. Definitely. Yes, it may be about doing additional committee work and support groups. I can see that too

However, if all of that is coming at the cost of not knowing what’s going on in your organization and not actively steering the output, you’re not doing your job. Period.

All of those things listen above are in support of your primary goal: ensuring that you are getting shit done. You cannot get shit done to a world-class level by leaving all of the details to other people.

Because if you do, what are you actually doing?

You can’t fix problems, unblock issues, question things from first principles, or make good decisions if everything that you do is entirely delegated to others. In fact, when you don’t know what’s going on, you’ve not actually delegated: you’ve abdicated.

You’ve given up your accountability altogether. Then it only takes one major incident or deadline miss to expose that you weren’t running your org after all.

And let’s face it: it’s so obvious when a manager is only book smart on what’s happening in their org versus when they truly know because they are hands-on every day.

If you’ve ever attended exec reviews, or presented at them yourself, you’ll know it only takes one or two cutting questions to reveal who’s in the details and who’s not.

Don’t be that person.

Techniques to try

So what exactly can you do in order to be in the details? And is it possible to do this without micromanaging? The answer is yes, and here are some techniques that you can use to get there.

• Have ICs report to you. This is the most obvious one, but it’s surprising how many senior managers don’t do this. If you’re a manager of managers, make sure you have a direct reporting line with the key ICs in your organization. Don’t make it so that your only view of your organization is filtered through your direct report managers. Ideally, for each area of your organization, there should be a manager and a tech lead who report to you directly. Overindex on skip-level meetings with your ICs, rather than your managers.
• Area deep dives. Schedule regular deep dives into different areas of your organization. My organization has five major areas, and I enumerate them weekly, so each area is revisited every five weeks. Invite the key managers and technical leads in that area and avoid canned presentations. Instead, you can either ask probing questions about the status and decisions in each active project, have a roundtable discussion on notable issues, or pick an area of the codebase or architecture to discuss in detail (e.g. draw diagrams, jam on the future). In order to encourage everyone else being in the details, don’t require preparation up front. Even better, don’t require any preparation at all, and make the topic a surprise.
• Mix up your 1:1s with pairing. If you’re a manager of managers, you can pair with your direct reports on projects in their area. This too encourages them to be in the details. Look at PRs together, pair program on their active project, or do a deep dive into a technical decision that they’re making. If you have senior folks reporting to you, the amount of hands-on coaching you will need to provide weekly may lessen, so this is a good way to continue to meet weekly but also to be in the details.
• Choose an area each week to get really close to. In a large organization, in a given week, there will always be a handful of areas that are particularly hot. You can overindex your time in these areas. You can do so by muting other chat channels and being active in theirs, pairing with individual contributors on their projects to learn more, and attending their standups and meetings. Done right, this can be a great way to be available, interested and helpful.
• Write a weekly brag doc for your manager and peers, and encourage them to do the same. All of the activities above, if you also take notes, can form a brag doc which is a great tool for keeping track of what you’re doing and for sharing it with others. If you’re a manager of managers, you can ask your direct reports to write a brag doc for you, and you can write one for your manager. In order to keep the toil down, you could use automated prompts in tools like Slack, or if you use Google Docs, you can set your notification settings in your staff’s brag docs to notify on activity so you get a ping when they update it, and you can hop in and comment.

Being in the details is actually extremely fun. Your goal as a manager isn’t to set up your organization so that everything gets done for you. It’s to set it up so that you can spend your limited time on the most important things.

One week this might be a deep dive into an upcoming technical decision by building various prototypes, and another it might be pair programming while trying to hunt down a performance issue with one of your teams. Your presence ratifies the importance of the work.

Getting close to the details is how you form the true knowledge frontier of your organization and form true opinions on what’s happening: they are true because you observe them firsthand.

Try it out: spend a month getting in the details. Make notes, go deep, and don’t be afraid of code. You’ll be surprised at how much of an impact you can have.

As you begin to lead organizations that are of a reasonable size, such as in the hundreds of engineers, you will find that staffing is one of the most repetitive and challenging aspects of your job.

Ensuring that you have enough people focused on the right things, with the right skills, and in the right places is a never-ending task. It is also by definition unsatisfiable: you will never have enough people to do everything you want (or need) to do, and you will never have the perfect mix of skills and experience either.

Organizations of this size typically span a wide range of products, technologies, and geographies, further complicating the issue of having the right number of people working on the right things.

You’ll have production code that needs to be maintained, new features that need to be built, and bugs and support issues that need to be addressed. It’s a balancing act.

When inevitably a team’s project pivots, expands in scope, or is just plain harder than expected, you’ll be asked to provide them more people to help. However, this isn’t straightforward as everyone else is equally busy. If you find yourself in wartime it may be the case that you can’t rely on hiring your way out of the problem either.

So, let’s imagine that one of your 30 teams is asking for more people. What do you do?

Stack ranking: it’s not that simple

Before we think about what to do, perhaps we should imagine ourselves in that team’s shoes. What are they expecting you to do when they ask for more people?

If they have a new and important thing to do, they may assume that you will prioritize their work over other lower-priority work, thus allowing people to move from the less important thing to the more important thing. This assumes that you have a continual stack ranking of all of the work that needs to be done at any given time and that this team’s work is somewhere near the top of the stack.

It may be the case that you have a stack ranking like this. And if you do, good on you. However, if you’ve ever tried to do a stack ranking of, say, hundreds of projects and teams that span multiple products and pieces of infrastructure, you’ll know that it soon becomes quite complex: how do you compare scaling infrastructure with a new feature that could drive revenue versus another new feature that could unlock some big strategic deals?

These stack rankings also often rank ongoing projects and initiatives and do not always take into account the need to maintain and improve existing products and services, which is especially true in SaaS: nothing is ever really done, it is running in production and needs to have a base level of maintenance and improvement over time.

Instead, many organizations operate, often implicitly, on a pool of investments approach: there are X products or services that exist in production, spread amongst Y teams, and your optimization is to ensure that those products or services are being maintained and improved in a way that is consistent with the overall strategy of the organization.

This is a much more nuanced approach than a simple stack ranking, and it is often the case that the right thing to do is to not move people from one team to another, even if the other team’s work is more important, since it leads to an unacceptable level of entropy in the overall system.

Stack ranking taken to the extreme can lead to a situation where the pool of investment approach breaks entirely: you could argue that whatever the top 3 projects are, they should get all of the staffing, and the rest should get nothing. This is clearly not a good strategy as everything else would need to be abandoned.

Given that you are likely operating in a pool of investments model which is more nuanced than a simple stack ranking, is there a more nuanced way to think about staffing challenges?

Concentric circles

When you are faced with no obvious way to solve a staffing challenge, it can be helpful to think about the problem differently. One way to do this is to think about the situation in terms of concentric circles.

What I mean by concentric circles is imagining that the team asking for more people is at the center of a series of circles:

• The innermost circle is the team itself which is asking for more people.
• The next circle out is the team’s immediate neighbors in the org chart. They will typically share a common manager.
• The next circle out is the team’s broader organization. This could be a product group, a business unit, or a division. This may be the org that you run.
• Outside of the circle is the entire rest of the department, outside of your organization and control.

It looks a bit like this.

The idea is that you should try to sequentially work your way out from the innermost circle to the outermost circle, looking for ways to solve the staffing challenges at each level. You do this will the manager of each circle, asking them to help you solve the problem.

For example, this could look a little like this:

• Starting at the innermost circle, you work with the team to see if there is any work that can be stopped, delayed, or de-prioritized to free up capacity without needing to add more people in the first place. You may be surprised at how effective this can be.
• If the above does not work, then you work with the manager of the team and its immediate neighbors to see if there is any way that people could temporarily or permanently move between sibling teams to help out. One benefit of this approach is that the people moving are more likely to have context and have a shared mission or goal with the team they are moving to.
• If that does not work, then you work with your direct reports to see if there is any way that people could move between teams in your broader organization. This is effectively what you would likely have been asked in the first place, but by working your way out from the innermost circle, you have a better chance of finding a solution that is more nuanced and less disruptive first.
• If all else fails, then you work with your peers in the department to see if there is any way that people could move between organizations. However, this is the most disruptive and should be a last resort, and in large organizations, it is often the case that this does not work without further escalation.

There are several benefits to this approach. Firstly, from experience, you often solve the staffing problem by the time you’ve gotten to the second bullet point. This makes it faster to solve and less disruptive.

Secondly, and importantly, you are implicitly coaching your managers that you do not need to be the arbiter of all staffing challenges and that they should be working with their peers to solve these problems themselves with the trade-offs that they need to make. This is very healthy in the long run.

Next time you have a staffing challenge, try thinking about it in terms of concentric circles. If you’re on the asking team, why not think of solving from the inside out first?