Being in the details
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.
Bonus content: Tech Lead Journal
Tech Lead Journal recently published its 200th episode — and it was an honor for it to be me!
Have a watch on YouTube or a listen on your favorite podcast application to get my thoughts on everything engineering leadership as we take a journey through some of the topics in my new book Become a Great Engineering Leader.
Great article, James. I would say this advice applies to any business. If you watch Undercover Boss, it reveals what not being in the details leads to and the discovery, empathy, and positive change that happens when you get back into the details.
Conducting an in-depth discussion with peers and direct reports will be beneficial, but it should be approached in a way that doesn’t come across as micromanagement.
Conducting regular or frequent deep dives can sometimes convey an unintended message to the other person. Therefore, it is essential to connect these reviews to a clear objective and drive the discussion toward that goal. Without a defined focus, deep dives may lead to inconclusive outcomes that are difficult to predict.