I define a deep domain as the knowledge area(s) of highest expertise for the individual. If you think of this area of highest expertise as the top of a pyramid and peripheral areas to that as the next level and peripheral areas to those as the next level and so on, that very small area at the top is the area where an expert is less likely to be wrong. As we go down to each new level of the pyramid, they are more and more likely to be wrong. While I represent it with four levels, the concept could flow into a theoretically infinite number of supporting levels (extended domains). This concept is shown below:
Let’s look at a specific example of this. Imagine you work with cloud technologies. Further, imagine that you spend most of your time working with databases in the cloud and this is your deep domain. The following image represents your expertise pyramid for the Cloud Databases deep domain:
To be clear, you may be an expert in multiple deep domains, but each one would have an expertise pyramid similar to the one above. The example above is not indented to be either accurate or exhaustive, but only to illustrate the concept.
Imagine that my deep domain is cloud databases. I work with them 3-5 hours every day. I’ve been trained on them. I’ve used them in 3-4 major cloud service providers. I’ve planned, implemented, supported, and terminated hundreds of cloud databases. This area is my deep domain. I will be right far more often than I’m wrong, if you ask me a question specific to databases running in the cloud.
However, if you ask me about general cloud management, security, network, general cloud concepts, or even databases in general, I am more likely to be wrong. While I am less likely to be wrong in these areas, where I am an Advanced Professional, than in the areas where I am a professional, such as general networking, general security, general file systems, etc., it still remains that I will be wrong more often at the Supporting Domains level than at the Deep Domain level.
I am most likely to be wrong in the User level (Extended Domains). For example, if I’ve worked mostly with Cisco networking gear and little with Juniper networking gear, I am very likely to be wrong about questions related to Juniper networking unless they are general questions. Vendor-specific questions for vendors I have worked little with, do not even fall into the Related Domains level for me. For example, if you ask me how the TCP handshake works in Juniper networking, because I am a professional in Networking and an Advanced Professional in Cloud Networking, I am very likely to answer correctly. On the other hand, if you ask me how TCP filters are implemented in a firewall by the same vendor, I am very likely to get it wrong.
What is the point of this deep domain model? Simply put, it’s useful as a thinking tool to build expertise and as a filtering tool to weigh the usefulness of an “expert” opinion. Too often, we fall into the trap of valuing an expert’s opinion highly – even when they are speaking outside of their deep domain. Sadly, experts, also too often, know they are speaking outside of their deep domain or even Advanced Professional area, and they continue to speak as if they are authoritative. A key attribute of an expert in a knowledge area is that they are authoritative in that area. However, it does not follow that they are authoritative in all areas wherein they speak.
For example, an Oscar-winning actor is authoritative in the area of acting. They may be authoritative in other areas as well (many actors worked as waitresses, office managers, cab drivers, scientists, etc. and they may have built expertise in those areas as well). However, if they speak in areas outside of acting, we should simply consider that their opinion and not consider it authoritative unless we know they have developed expertise in those areas.
This is true in the technology sectors as well. For example, one may be very interested in big data, but it is not a deep domain for him. He is an expert in Oracle databases. He is far more likely to be wrong when speaking of big data than he is when speaking of Oracle databases. He may have opinions about big data, but most of these are formed from listening to and reading what others have said about it. Given that they could be wrong some percentage of the time, even if they all agree, it follows that the Oracle database expert, in this example, could be wrong at an even higher percentage.
Understanding this concept of deep domains has tremendous implications for decision making and technology selection. Finding an expert in the area of decision is vitally important to an accurate decision. The greater cost associated with the decision, the greater the importance of finding an expert (or multiple experts) to provide guidance.
It also has significant implications for those desiring to develop expertise. To become a true expert, you will need to define the deep domain first. Next, what are the supporting domains that you will have to understand at an advanced professional level to be an expert in the deep domain. Next, what are the related domains that you must understand at a professional level and, finally, what are the extended domains wherein you must have at least user level experience. Let’s walk through this.
Imagine you want to develop expertise in Python web scraping. To achieve expertise in this deep domain, you will have to be an advanced professional in Python, HTML, and possibly a few other domains. To be an advanced professional in these areas, you may need professional level knowledge in programming in general, Internet protocols, data formats, file systems, and more. Finally, you may need familiarity (user level) with multiple Integrated Development Environments (IDEs), though you will likely have Advanced Professional-level knowledge in one or more of them.
While this example is not exhaustive, it should reveal the considerations that must be made in developing expertise. Keep in mind that training, reading, and listening to information alone will not get you to the Advanced Professional and Expert levels. You will need to experience the technologies. Use them. Break them. Change them. Analyze them. All of this and more to get to those higher levels.
As a final note before closing this topic, consider that you do not have to select a deep domain immediately. In fact, if you’re just starting out in your technology career, I suggest doing general technology work and learning the fundamentals of networking, computing devices, databases, file systems, operating systems, etc. Then, when you’ve had some experience, you can identify an area where you want to go deep. You can make a good living without being an expert. That can always come later and, in my opinion, usually should.
So, you want to become an expert? Make a plan. Ensure the foundation is there and build on it. As you study your deep domain, always evaluate lower levels that about which you may need to learn more to go deeper still. For example, when I first started studying wireless communications about twenty years ago, I realized I needed to get more insights into electromagnetic waves. This meant studying Physics. Am I a Physics expert? Not even close. But I needed an acceptable level of knowledge in that area to truly understand wireless communications as a deep domain.
So, you’re listening to an expert? Listen carefully. When they speak outside of their deep domain(s), do not place the same weight on their comments just because you are awed by their true areas of expertise. History has shown that many brilliant people with ultra-deep knowledge in some areas hold ridiculous ideas in others. Don’t forget that.
-Tom