How to Help People When You Aren't the Subject Matter Expert


Author :: Kevin Vecmanis


The ability to help a colleague or direct report when they’re stuck is an important part of being an engineer. Sometimes, you lack the same context or technical expertise as the person seeking help. This is a strategy I learned for being helpful in these situations.


Table of Contents



Introduction

I’ve had two experiences in my life when I was promoted from an individual contributor (IC) to a manager. Once in the oil industry when I was working as an electrical engineer, and once as a software engineer working at my current company, Clearbanc - a fintech startup. Despite these being two radically different industries, the process for me was very familiar. Each transition had the following in common:

  • Both teams, when I started as an IC, were small and the engineers on the team were “generalists”. By that I mean the scope of the work the team performed and the number of projects on the go at once was small enough that everyone on the team was “up to speed” on what was happening in everybody’s day-to-day.
  • In both situations, these teams grew to the point where knowledge started to become more specialized and the number of concurrent projects began to grow.

This is a difficult “phase change” for any team because ICs tend to perceive a lot of their value by how much they understand about the totality of the systems being worked on.

When I became a manager at Clearbanc a lot of my self-perceived value was predicated upon my own ability to ship units of work (code). I think this is a problem a lot of managers and tech-leads have when they inherit teams of people - especially teams with high performers.

The key to getting through this phase is shitfing your paradigms on the value you’re bringing to the team. As a manager you’re facilitating, unblocking, planning, listening, and course-correcting. The reality of this is that your direct reports will quickly gain domain knowledge in areas you lack. This is fine, and in a lot of ways desirable.

In this article I’m going to talk about a strategy I was taught in the oil industry for helping direct reports and colleagues work through techinical problems when you’re not the expert. It’s served me well and I hope it’s just as valuable to the reader.


Assigning Structure to the Problem

The engineering problem solving process is a straight-forward one on paper and can be applied to any industry. The steps are as follows:

  1. Define the problem
  2. Hypothesize potential causes/solutions.
  3. Rank the potential solutions by likelihood.
  4. Test each solution in order.
  5. Is problem is not resolved, revisit step 1.

Getting people to start thinking quanitatively in terms of this process is a surprisingly effective way of getting engineers through mental blocks. Your goal as the colleague with inferior context on the problem is to help your friend assign structure to the problem and think through things more methodically.

Note: One thing I’ll say here is that even if you know the answer, I think it’s important to allow engineers the dignity of arriving at the solution through a bit of a struggle. As a leader the personal growth of your team should be top-of-mind at all times. Constantly giving people the answer can be stifling, set low expectations, or in some circumstances be demeaning to the individual. For this reason I think it’s always a good idea to have this line of questioning in your tool-belt when assisting colleagues.


Questions to Get Them Thinking

The following are examples of questions I use when helping engineers assign some mental structure to the problem at hand:

  1. “Can you define the problem to me, in your own words?”
  2. “What potential courses of actions are you considering?”
  3. “Of all the possible causes, what do you think the root cause of the problem is?”
  4. “What happens if you do nothing?”
  5. “Tell me how you’ll know when the problem has been solved?”
  6. “What have you already tried?”
  7. “Which part of the problem are you struggling to understand the most?”
  8. “How long have you been stuck? - surprisingly effective question to get people to start thinking quantitatively.”


Why They’re Effective

All of the questions begin to align the person’s thoughts with the engineering problem solving process.


“Can you define the problem to me, in your own words?”

In my experience, the number one pitfall that engineers encounter is not spending enough time defining the problem. When a direct report or colleague comes to me with a technical problem this is always what I start with - “Describe the problem in your own words”. If someone can’t describe the problem succinctly they haven’t spent enough time on step 1.


“What potential courses of actions are you considering?”

Once it’s clear the problem has been properly defined, you want them to start quantifying potential solutions.


“Of all the possible causes, what do you think the root cause of the problem is?”

Here you’re trying to engage the engineer’s instincts. It’s not always possible to determine what the likeliest solution must be, but teaching engineers to use their gut can be a valuable exercise.


“What happens if you do nothing?”

In order to start considering secondary and tertiary impacts of certain actions, one needs to have a strong understanding of the situation and the variables at play. Asking this question forces a person to not only think about the problem, but also start considering knock-on effects.


“Tell me how you’ll know when the problem has been solved?”

In order to know when the problem has been solved, you need to have a clear understanding of what the problem actually is.


“What have you already tried?”

This question gets the engineer to focus on the spectrum of solutions. A good follow-up question for this is “Why did you try those things”.


“Which part of the problem are you struggling to understand the most?”

This question gets the engineer to look at the problem from another angle. Almost always, the part the engineer is struggling with the most is the aspect of the problem that’s poorly defined. Problem discovery is often not a brief or trivial thing - encourage engineers to invest energy in the problem definition and discovery process.


“How long have you been stuck?”

This another question whose purpose is to get the engineer to disconenct from the process for a second and reflect on what they have been doing - and get more mentally organized, if required.


Summary

As teams grow knowledge becomes more specialized and siloed. If you’re a manager overseeing the work of developers, you won’t always have the luxury of knowing as much as tbe dev does about a problem. Having techniques in your team’s toolbelt to help guide people to a solution or unblock them is important in maintaining the network-effect benefits you get from teams.

Kevin Vecmanis