Note that this is my personal taxonomy that I developed based on other people’s experiences and my experiences having spent two decades in the IT industry as both a telco engineer and a PxM (project/product/release/program manager). By the time you’re done with this post, you’ll be able to do two things:

1. Audit the depth of your technical expertise on one specific software system with 16 universal questions so you’ll know your technical depth
2. Ramp up quickly to achieve a technical understanding within a matter of days for the level you need to achieve. By searching for answers to these 16 universal questions, you’ll quickly ramp up to the level of understanding you need.

The philosophy behind the 6-level deep dive framework

When I first joined Microsoft Azure a long time ago, I asked my manager the usual question: how much time will you give me to deeply understand the end-to-end software systems owned by his engineers. My manager’s answer was intriguing: “If you were a principal technical program manager (TPM), I’ll give you one month. But since you’re only a senior TPM, I’ll give you three months.”

When I asked him what principal TPMs do that allow them to achieve a deep technical understanding 3x faster than senior TPMs, his answer was just a general “They have more experience in this field.”

And this was a deeply dissatisfying answer.

We have all worked with principal PMs or TPMs. Yes. They do have a MUCH deeper insight and are technically more knowledgeable. And yes, they ramp up MUCH faster on new systems. But I didn’t find their memory to be spectacular or that they had more years of experience than me. In many cases, I found principal PMs and TPMs to be younger than me. More often than not, I had more years of experience in the field. So what was the reason for the difference?

Found the answer in a Netflix documentary titled “Inside Bill’s Brain.” Yes, this is a documentary on Bill Gates, the Microsoft founder and, once upon a time, the world’s richest man. What was extremely interesting was a point that Gates made on how he reads 50 books a year. He doesn’t just read a book. But rather he has a mental model or framework of questions that he asks as he reads the book and then makes notes on the side. Similarly, when talking to principal PMs and TPMs, I find a similar pattern. They have a mental model, essentially a set of questions and rules they follow on how they think. In other words, it’s a software upgrade of how they think rather than a hardware difference (super-memory, high IQ, years of experience). This is my summary of the 6-level mental model to follow if you too want to think like a principal and not a junior or senior PM to learn rapidly.

This deep-dive framework proposes a systematic way for understanding software systems (end-to-end) by asking questions that apply universally to all systems. BUT, these questions do NOT apply to stand-alone components such as services or AI models (both machine and deep learning). A separate deep-dive framework, also using a five-level structure, will be presented in a future blog post for specifically understanding and improving deep learning models.

How to rapidly understand software systems

TPMs have different methods for ramping up on new software systems i.e., the technology circle that forms the trinity of process-people-technology. Some take the machine learning algorithm equivalent of lazy learning: i.e., rather than drowning in documentation details, they wait for a problem to occur in a system and then learn everything needed to solve that problem. However, this just-in-time learning method is slow and takes months to fully understand a system and leaves knowledge gaps.

Others, usually principal TPMs, use the eager learning algorithm: i.e., pre-emptively learning about a system by asking general questions to rapidly understand a system.

The framework proposed here is the latter mental model for quickly ramping up on understanding the technology circle of the people-process-technology trinity. And within this tech circle, the focus is on understanding end-to-end systems rather than focusing on stand-alone components. Success metrics – understanding calculations, metrics dictionary, etc. – is part of the process circle which is why they’re covered in very little detail in this framework.

The goal is to provide a systematic way  for TPMs to understand new software systems in hours or days. And it also provides a systematic way of identifying gaps in understanding instead of discovering it weeks or even months later. Admittedly, there will always be details discovered later. But the hope is that those countless details will won’t be buried in a mental junk drawer. But rather will be neatly hung on six mental hooks.

If half of knowledge is to ask a good question, then this framework implements this proverb to achieve a deep, end-to-end understanding by asking general questions to the responsible engineering and science teams. While answers to some of these questions may be available in documents, most answers will be found in the heads of the scientists and engineers. Typically, answers to questions in levels 1, 4 and 5 are readily available. But answers to questions in levels 2 and 3 are still in the heads of the stakeholders (scientists and engineers). Which means that you will have to conduct multiple interviews with them to extract answers.

No software systems framework will be comprehensive enough to cover all possible use cases. Moreover, this taxonomy is a simplified model of messy reality. I’m sure there are more realistic but complicated frameworks. But a simple, useful framework is more helpful than a complicated, realistic framework. Take the example of the simplified model like the 24-hour solar day. An accurate model of a day is actually the sidereal day which is 23 hours and 56 minutes but try splitting up a day into 24 equal chunks! It’s more useful to use the simpler solar day of 24 hours and let the missing four daily minutes be added to a leap day, Feb 29, every four years.

Similarly, this six-level taxonomy doesn’t have to be perfect for it to be useful. This framework provides enough principles, in the form of 16 questions, to quickly flesh-out details for most systems. Given this useful model, a TPM should be able to write a 2-pager documenting the answers to all these questions and present it to his peers in less than a week after being introduced to a new system.

This DDF-S (Deep Dive Framework for Systems), when presented to your peers, will act as a forcing function to ensure that you truly understand the system you are supporting. And when systems change, as they always do, the DDF-S will serve as a living doc or a map for TPMs to reference.