A subject matter expert (SME) is someone so knowledgeable on a subject that others turn to them for help to understand what they need to know in order to do their jobs.

Naturally, such a person is of great value to a team, as they can readily provide answers to questions that might require days or even weeks to find otherwise. For example, if a team were developing a finance application for a client, a SME from the client side might be sought out to help the team members understand the area of finance that the application deals with. The team’s objective here is to better understand the client’s requirements.

Of course, this is an ideal situation. But what if such a SME were not to be found?

Imagine you have been tasked with joining the effort on a software project that is unfamiliar to you. After the excitement and novelty of the kickoff meeting subsides, you find yourself back at your desk, asking, “Oh, wait—who is going to train me? While I’m coming up to speed on what’s involved in the project, who can answer the questions I’ll inevitably have? We didn’t talk about this in the meeting. I wish I had asked.”

You may go back and ask your manager if there is such a go-to person, but you’re already anticipating the answer: “Sorry, you’re on your own, kid.” A sense of panic kicks in, and the excitement associated with the new project you felt a little while ago suddenly transforms to dread.

Whether you’re a software tester, a business analyst, or simply someone who needs to come up to speed rapidly on a technical subject, we often lack the luxury of having a SME available to answer our questions. When that’s the case, we have to try to become our own SME.

Here are a few key methods I’ve drawn from the writings and presentations of experts in various fields that deal with information gathering and rapid learning. You can easily use these methods, right now, to quickly gain the knowledge you need in order to move forward.

Don’t Say, “Not My Job”

In the book Lessons Learned in Software Testing: A Context-Driven Approach, Cem Kaner, James Marcus Bach, and Bret Pettichord identify the first hurdle to get around. They caution you to beware the “not-my-job” monster:

[A] temptation to say “not my job” comes when you’re placed in a difficult … situation. Your colleagues on the programming side may write crummy specs. … It’s tempting to refuse to [work] under those circumstances. You could say it’s not your job to interpret ambiguous specifications. … In severe cases, that may well be the right thing to do, but consider first whether your expectations are realistic and consider whether there’s an alternative way to get what you need. If you adopt the philosophy this it’s your job to make a reasonable effort to adapt and improvise, the programmers are more likely to consider you a boon instead of a burden. That, in turn, encourages them to make it their job to help you.

Let’s dwell on that last sentence for just a little bit. You’re developing a relationship such that someone is making a point of helping you without your even asking. That’s a big deal. We call such a person a mentor. We want to get as many of those as we can, or at least one.

Find Your Currency

James Whittaker, distinguished engineer and technical evangelist at Microsoft, expands on this idea. In his presentation “The 7 Stages of Creativity: Developing Your Creative Self,” he cites access to experts as one of the keys to learning quickly. It is much more efficient to sit comfortably on the shoulders of giants than to strain on your tiptoes. Part of this is engaging someone to be your mentor.

He goes on to relate the thoughts of Dona Sarkar, a member of Microsoft's Developer Relations team and author of You Had Me at “Hello, World": Once you have identified the right person to be a good mentor for you, you must find your currency with that person. In other words, what will it take to make them want to be your mentor? Put your own interests aside for the moment and focus on the other person’s. It really works.

Also, be sure to demonstrate that you are genuinely interested in the relationship by following up on the person’s advice. The last thing you want to do is leave your would-be-mentor wondering, “Did that person ever take my advice, and what happened as a consequence?”

Ask Questions Effectively

At this point, you’re dedicated to adapting and improvising. You’re cultivating a relationship with a mentor. What’s next?

The ability to ask questions effectively is one of the hardest skills to master, but it is also one of the most important. Software test consultant Karen N. Johnson draws on her prior experience as a journalist. She has some great ideas for approaching the often rocky path of interviewing and asking questions.

In her talk “The Art of Asking Questions,” she identifies some tactical points that resonated with me:

• Tone and timing: Taking into consideration the way you ask questions or the circumstances in which you ask them can make a big difference
• Be humble: We in the world of information technology have a cultural tendency to be somewhat cocky, wanting everyone else to perceive us as all-knowing. This sets us up to shy away from asking basic questions for fear of appearing stupid. One of her slides contains a wonderful Chinese proverb: “He who asks a question is a fool for five minutes; he who does not ask a question remains a fool forever”

Get Inside the Programmer’s Mindset

Very often, the person that turns out to be the best fit for a mentor will be a programmer.

Regarding this, Kaner, Bach, and Pettichord have some excellent advice. I recommend reading the entire chapter “Interacting with Programmers” in Lessons Learned in Software Testing. Though this work is directed specifically at software testers, I think many of the points can be generalized to apply to all who are aspiring to the role of subject matter expert.

These are my key takeaways from this reading:

• Respect a programmer’s work
• Insist that this respect be mutual (remember, you also have a job to do)
• Appreciate the programmer’s role and the demands on their time considering this role
• If you are technically inclined and have enough courage, consider becoming a programmer for a while, for the sole reason of acquiring the mindset. You may also discover a nifty side product is that you can use this skill in your “day job” going forward. In my primary role as a software tester, I’ve made a side career of developing test tools

Understand Tacit vs. Explicit Knowledge

In his book Tacit and Explicit Knowledge, Harry Collins makes an important distinction between the two. The bulk of the most important parts of an expert’s knowledge on a subject is in the form of tacit knowledge, or knowledge that they have not yet put into words. The challenge is to make this knowledge explicit—that is, to verbalize it so that someone else can share the understanding.

We can only talk about a small fraction of what we know, and we can only write about a small fraction of what we say. I think this puts in perspective very well the task that is before us. The quest to know what someone else already knows is not an easy one. We should not take lightly how we shall go about doing it.

A corollary to this is that we should do our best to educate those who have tasked us with the job regarding the “hidden work” of drawing out information from the expert. As ominous as this may sound, we should not take this as discouragement, but rather as a cautionary point to guide us. By keeping this perspective in mind while you are strategizing on how to build a relationship with a mentor or which questions to ask and in what manner, you can avoid a great deal of frustration by not setting yourself up with unrealistic expectations.

Model the Data You’ve Gathered

While working with others to gather knowledge is a good tactic, there is a great deal you can do on your own to expand the value of this knowledge. Modeling the data you have accumulated from time to time is very helpful.

I’ve found mind maps to be a great tool for this (FreeMind has free files to download). In my role as a software test engineer, I’ve also used cause-effect modeling to aid in disambiguation analysis when studying a new specification.

Find Your Own Path

The points I have cited above are snippets of other people’s experiences. I do not mean for this to be a collection of bullet points that will automatically make you into a SME. On the contrary, these are mere suggestions to try yourself. See which ones work for you, and do some more reading and viewing on your own. There are a plethora of authors and speakers on the subject beyond what I have cited here.

Remember that any matter in which you are dealing with other people will always involve complexity. Personalities (especially your own), circumstances (like deadlines), and other constraints that you cannot foresee will often present themselves as potential insurmountable impediments. It’s key to keep in mind the wise words from The Hitchhiker’s Guide to the Galaxy: “Don’t panic!”

Even the most knowledgeable person on a subject at some point in the past knew nothing about it. Just say to yourself, “Whatever someone else knows, I can learn.”