I'm back from our family vacation. At least for a few weeks, before we head out on our next trip! Minor apology for the late email (I usually send these on Thursdays), but I was caught up in post-vacation activities.
People often interpret dives deep as a reference to a technical bar. "I dove deep into that coding problem."
However, the dives deep leadership principle doesn't mention technical skills at all.
Leaders operate at all levels, stay connected to the details, audit frequently, and are skeptical when metrics and anecdote differ. No task is beneath them. - Amazon Website
The words of the leadership principles were carefully crafted. I don't know the total hours spent on phrasing the dives deep leadership principle, but I'd bet well over 100 hours were spent on those two sentences. Each word was added for a reason.
If you skim the leadership principles, you'll miss the core aspects of each value. I'm going to walk through the phrasing of the dives deep leadership principle, and explain how the principle is used in practical situations.
Furthermore, as with all leadership principles, more is not necessarily better. For each leadership principle, you can under or over use the principle. All good things in moderation.
Operate at all levels
Most senior leaders got to their senior levels partially through careful delegation of tasks. One of the tools to reach the Director level at Amazon (for example), is recognizing what work is Director level work, and what work should be done by the people on your team. This is because (theoretically), you have more value to add on the "higher" level tasks.
The challenge is that you can't always do senior level work. The pointy haired boss in Dilbert is a joke because he doesn't actually understand how his teams operate. He is the boss, but not a leader. A leader interacts with everyone on their team, not just with those who are also senior.
The leadership principle doesn't say that you operate on all tasks. There's no need for a leader to code like their engineers, or design like their designers. However, regularly interacting with your team at all levels ensures that you understand the practical implications of your leadership choices.
One example of how to operate at all levels is "Management by walking around." This simple concept is that one mechanism for a manager to stay connected with the details is to randomly walk around and visit with their team. This might mean going on purposeful site visits (for managers with remote teams), or simply getting up and walking down the hallway. Hanging around your team, chatting about what they're doing, is an obvious but effective way of understanding your organization more.
As a small example of operating at all levels, one of my Android teams was having a challenge with a memory management issue. The team having trouble was 2 levels down from me (reported to a manager, who reported to a manager, who reported to me). I heard about the issue, and walked over to talk to the team. I spoke in detail with them about the problem, so I could understand what was going on. Now, I said diving deep doesn't necessitate technical knowledge, but I have to admit that technical knowledge helps in these situations. I walked through their debugging steps to ensure that I was comfortable with the actions being taken.
In a meeting later that day, I brought up this issue with my skip-manager (my manager's manager). He asked for some clarifying details, and then recommended we speak with another manager, three levels down from him, in another organization. That manager had a team with expertise in Android memory management. They were indeed able to help solve the issue.
These managers were many steps away from each other in the org charts. There is no internal search engine at Amazon for "experts in Android memory management" (although that wouldn't be a bad idea). Yet because I had operated on an issue a couple of levels down in my organization, and my skip-manager had previously operated on something three levels down in his organization, we were able to quickly get an issue resolved.
Stay connected to the details
Senior leaders add the most value when they're looking at the big picture. You primarily build AWS into a valuable organization by focusing on organization structure, long-term strategy, and broad market moves. If Andy Jassy spent all of his entire time in the details of S3 storage management, Amazon would have missed out on many opportunities.
However, due to their visibility into the larger picture, leaders create value through paying attention to the details.
As one example, I remember attending a meeting for a team which managed a component on Seller Central. They spoke about how their next project was to re-write some components to reduce latency (component load time).
I asked why the latency project was high priority. They said that the page their component was on was too slow, and users were complaining. At the time, I ran the latency program for Marketplace, and I had personal knowledge of how many of these pages were constructed.
I asked that team to please confirm that speeding up their component would actually speed up the page load time. Because I knew that it was a different component on the page which was the bottleneck for load times. Shortly afterwards, they explained that they had discovered that speeding up their component would not, in fact, improve user experience, so they were updating their roadmap.
This redirection of their roadmap was possible because I understood the larger picture (overall latency goals and our broader approach), as well as the details (how individual pages were built and what their bottlenecks were).