I’ve been having trouble even starting to write about this topic because it’s such an interesting topic and something I’ve learned quite a bit about over the years — and continue to grow and learn about as I take on new teams!
As I’ve advanced in my career, I’ve gone from feeling like I need to learn every new technology or programming language (and getting overwhelmed and feeling inferior by the impossible feat) to realizing it’s impossible to know everything well. In the spirit of ruthless prioritization, I have to prioritize what it is I choose to know deeply (where I get in the weeds) and what I choose to only know at a surface level (usually relying on or deferring to the expertise of someone else who is in the weeds).
This approach to staying on the surface works really well when you can to defer to a colleague who you respect as an expert on their work (e.g. I understand we use XYZ technology but for any additional detail, talk to my colleague Jane in Engineering). And often times, a colleague will see this for what it is: trust that you will mind your own business because they’ve got their area under control!
It gets much more difficult when you need to do this with people who might report directly into you. Stay at surface and don’t know enough about their work? You seem out of touch (and isn’t it their job to “manage up” anyway?). Get in the weeds about everything they are working on? Now you are the dreaded micro-manager.
So how do you decide when to go deeper? There are tactics I’ve employed over the years that can help.
Assess the Risks
You can call it the opportunity cost but, in short, what happens if I stay at the surface and don’t understand as deeply this person’s work? Are there other people within the team (a manager between you and them, others on the team who perform a similar function) who do understand? What processes or systems might breakdown if their job doesn’t get done?
Ultimately, if you do have a blind spot in your understanding, you need to understand how large it is. If this person is the only person on the team who knows or can do XYZ task, it’s probably time to start diversifying that knowledge or picking it up yourself!
Get Curious
Maybe you’ve understood it’s a moderate risk and, from the surface, you think “this is just a big mess, we need to start over” in lieu of what’s happening today. I know I’ve written about this before and it’s such a common trope at this point but it bears repeating: not everything you disagree with is broken. It’s very easy with the benefit of fresh perspective and similar past experiences to swoop in and propose what feels like an intuitive, easy solve.
Before taking any approach that might come across as swooping in and getting micro-manager-y, I always suggesting getting curious. This helps us assume positive intent and that things are the way they are because folks did the best they could with the resources they had available at the time (not that they didn’t know better – although of course, you may in time discover that was indeed the case).
Getting curious means asking lots of questions with intent. The intent is NOT to understand everything and go too deep but to get deep enough to at least validate your hypothesis (i.e. OK, my inclination that this is a dumpster fire and we need to start over is 100% valid).
Write It Down
I was reading a really great article on “Understanding” over on Substack (it inspired this piece, actually) and in it there was a note that “intelligent people simply aren’t willing to accept answers they don’t understand.” I think all managers would like to think they are intelligent (myself included) and so I thought about this and realized that yes, there are moments when I’ve asked the questions and it still feels like I’m not getting a clear picture (i.e. I had a hypothesis based on what I thought I knew, but now I’ve walked away with more questions).
It’s for this reason that I’m a big fan of tiered documentation! First, I want to ensure I have the background context down (what situation are we in that everyone accepts as truth) as well as the trigger / problem statement (why are we even talking about this right now?) and what we aim to do next at least at a high-level (that’s tier 1). Then, from a documentation standpoint, I’d want to take what’s been unveiled at this tier and break it down further in tier 2: what is the architecture of the current state?, what is the size of the problem (are there metrics here?), what are the various tasks that enable the solution? Depending on how much complexity there is, you may need to add a tier 3 as well that might be too much information for most but helps the team.
In my experience, I’ve found if my team cannot write it down and explain it in a way that makes it plain to me, then it may be that they don’t have as firm an understanding as they need. And that’s a challenge because in technology, it’s imperative to find a way somehow to simply communicate even the most complex systems/operations. As a manager, it’s my job in this type of situation to see what I can do to help build that competency up (and therefore, I need to get much closer and build up my understanding as well to be even moderately helpful). And usually, when there’s great documentation already, I rarely have to go too deep.
The TL;DR here: decide whether you even need to go into the weeds right now; make a hypothesis based on what you think you know and ask questions to try to get that validated, but no more; push for (or create yourself) documentation that can highlight expectations gaps.