Category: Trust

🎹 Music for this post: https://www.youtube.com/watch?v=3ixM29ZdTiU.

Special thanks to RIT Professor Scott Hawker for inviting me to his classrooms many years ago. He and I had a vision for this research a while back, and he is deserving of a lot of credit for the approach we took in what you are about to read.

Have you ever witnessed:

• An engineer’s condescension about a customer’s lack of knowledge?
• An engineer’s desire to prioritize quick solutions without affording the customer an objective discovery session, so that the engineer could get right down to solving?
• An engineer’s presumption of technical expertise on the part of a customer?
• A customer’s desire to be an armchair engineer for any number of reasons?
• A customer’s reticence to deeply engage with the engineer due to any or all of the above?

Me, too.

When I hire people — especially software engineers — I like to be able to get a sense for how they handle situations like these. Like many managers, I’ve cultivated an arsenal of interview questions to help me rapidly sense the people skills I seek, and which I tend to feel are in insufficient supply. After years of interviewing, my collection of go-to questions has narrowed considerably, and one question stands out above all others.

I began guest lecturing at RIT in 2013, and Professor Scott Hawker and I discussed the idea of a presentation to students of his class in Software Requirements and Architecture Engineering (a 400 level class) that involved a “cold open.”

At the top of the class, before I even introduced myself, I shared that singular interview question on the screen before them:

I handed a half-sheet of yellow paper to each student and gave them a few minutes to jot their answers. From September 2013 through November 2017, I collected 261 students’ answers across 16 individual classes (fifteen RIT classes and one class at my alma mater, Binghamton University; thanks not just to Scott Hawker but to Mehdi Mirakhorli and Bob Kuehl as well). During each class, I browsed through the students’ answers and shared, aloud, some of the more interesting ones to create conversation before introducing myself and the topic of the day, which is the very same topic I will share shortly with you.

---

Nine Response Categories

This particular question was designed to help me identify a way in which candidates might approach a software problem-solving exercise. Subjectively, there are good and bad answers to this question when considered in light of a dimension I call “Safety,” which I describe as the risk to a professional’s ability to properly elicit a problem from someone while developing or maintaining a good relationship.

Over years of doing this, I’ve discerned nine distinct categories of answers, presented here in the order of their frequency in my university guest lecture series. The table below summarizes these nine response types, along with the “Safety” designation that denotes my subjective feeling about the given answers in regard to the potential consequences of each approach. To illustrate each category, I’ve presented a typical “Medical” example and an equivalent “Software Engineering” example (a businessperson asking a software engineer to add a new field to an existing screen in an enterprise application):

Classification	Description	Safety	Medical Example	Software Engineering Example
Engage, Specific (36.40%)	Student does not make assumptions or start treatment; asks good questions; assesses symptoms.	Desirable	“I’d love to help you out. Tell me a little more about how you are feeling.”	“I’d love to help you out. Tell me a little more about what’s going on.”
Engage, Generic (16.48%)	Student proposes something to the effect of “Will determine whether or not you are having a heart attack” without specifics (inquiry, testing, etc.).	Acceptable	Will take one of many potential actions (perhaps dialogue, but also perhaps procedures, etc.) to determine whether or not you are having a heart attack.	Will take one of many potential actions (perhaps dialogue, but also perhaps procedures, etc.) to determine whether or not adding a field is the appropriate solution.
Trust (16.09%)	Student starts to explore reported issues (symptoms) without asking questions.	Workable	Check your heart rate.	Asks where the field should be located and how it should behave.
Solve (15.33%)	Student initiates “solving” the problem without asking questions.	Unacceptable	Administer aspirin.	Says OK, leaves, and adds the field.
Challenge/Dismiss (6.13%)	Student asks questions, but phrased in an at-least-somewhat-confrontational way…or dismisses the situation altogether.	Workable	“Why do you think that?”	“Why do you need that field?”
Couch (4.60%)	Student offers multiple answers in an attempt to safely satisfy any one of multiple conditions.	Workable	(Could be any other type(s) of approach listed here.)	(Could be any other type(s) of approach listed here.)
Avoid (2.30%)	Student avoids specifics; does not propose a specific path of action.	Unacceptable	Ignores the patient and moves on to other topics.	Ignores the businessperson and moves on to other topics.
Humor/Other (1.53%)	Student offers a humorous or other answer that does not fit elsewhere. Students will be students!	Unacceptable	“If you were having a heart attack, I’m pretty sure you would have died on the way!”	“If you needed that field, it would be there already!”
Calm/Reassure (1.15%)	Student proposes an interim calming step before any diagnosis dialogue.	Acceptable	Sits the patient down and applies other calming techniques before attempting anything else.	Asks the businessperson to go for a walk or a cup of coffee before engaging in further conversation.

We care about the nature of these responses because we want engineers to foster high-quality relationships with their customers where those customers not only enjoy and trust working with the engineers, but most especially seek the engineers’ help as a result of that dynamic.

Let’s take a deeper look at the nine response types:

Engage, Specific (36.40%)

Engage, Specific is a preferred style that presents the lowest risk to the patient, and to the doctor-patient relationship:

• The patient arrives with a diagnosis of a specific condition that could, in fact, be incorrect. In that sense, the patient is coming in hope of a solution to that specific problem.
• The doctor understands that the patient could be incorrect, and understands that there is risk in honoring the patient outright.
• Although the doctor understands this risk, he or she does not belittle the patient in any way, or use language that amplifies the status differences of the two in the relationship.
• The doctor asks good questions that do not assume that the patient is right or wrong, but that help the doctor assess what could be going on.

Engage: Specific stands out because of the tone of the dialog. Its goal is to create comfort while reducing the risk of a response that could cause emotional or physical harm.

Actual examples:

• “Asks what your symptoms are.”
• “The doctor is going to ask you to try and relax the best you can. Then the doctor will ask a series of questions to either you or who you are with to try and diagnose the problem.”

Engage, Generic (16.48%)

“Engage, Generic” is also a low-risk approach, but not quite as preferred. The first two bullets in Engage, Specific apply here. However, here are the differences:

• The doctor understands the risk in honoring the patient’s self-diagnosis, but the respondent describes the doctor’s behavior in a positive yet generic way. We are unable to discern from the answer whether or not the exchange with the patient will be of a respectful tone and nature.
• Because there is no clarity on a specific approach, there is a possibility that the respondent does not fully appreciate the value of high-quality dialog.
• We believe this presents an opportunity to better condition these professionals with the Engage: Specific format.

Actual examples:

• “The doctor will probably try to determine whether or not I am really having a heart attack.”
• “See if it’s really a heart attack and not something else.”

Trust (16.09%)

Trust is a workable approach, although with more potential risk than Engage: Generic:

• The doctor gives some credence to the patient, and rather than exploring all of the possibilities of the situation, begins to narrow down solutions to those relating to the proposed problem.
• The doctor’s trust of the patient is likely to have some form of positive impact on this delicate moment in the doctor-patient relationship.
• Presumably, if the ensuing activities discount the possibility of a heart attack, the doctor will explore other possibilities.
• We cannot immediately tell whether or not the doctor is being objective. However, a sensible doctor knows that a heart attack requires quick response, and suspending immediate objectivity to trust the patient’s self-diagnosis might only result in a short series of tests to eliminate the possibility so that the doctor can explore other options in a more leisurely manner.

Risks to this approach may be worth exploring further in future iterations on this project. In the case of a patient with a headache who insists he or she has a brain tumor, a quick Trust reaction is less useful, and might provide different insight into the thought processes of students or job candidates.

Actual examples:

• “Check your heart rate.”
• “The doctor will likely hook you up to a number of machines to determine if you are, in fact, having a heart attack.”
• “Send you to the emergency room.”

Solve (15.33%)

The Solve style is most problematic, because it could lead to the application of inappropriate treatment that puts the patient’s life at risk.

Actual examples:
– “Pump you with meds.”
– “Give you aspirin.”

Challenge/Dismiss (6.13%)

The Challenge/Dismiss style is not a preferred approach, because:

• It might betray a lack of trust in the individual being served.
• It might be confrontational in its presentation.
• It does not convey compassion or understanding.

Actual examples:

• “Why do you think that?”
• “Ask the patient why he thinks that he is having a heart attack.”
• “What makes you think that?”
• “Explain that you don’t have to worry and that you aren’t having a heart attack.”

Couch (4.60%)

The Couch style is problematic because it’s a “shotgun” approach offering multiple “hopefully” correct answers that could individually be ascribed to the other categories. It is focused on an attempt to get an answer “right” rather than owning any particular approach. It could be a sign of a lack of self-confidence, which isn’t a bad thing unto itself, but it it may be an indication that further coaching and development is needed.

Actual examples:

• “Take you to the bed. Take vitals. Use a defibrillator if necessary.”
• “Run tests, ask questions, give medication.”
• ”Check his body and give meds.”

Avoid (2.30%)

Avoid is similar to Couch but involves a single answer that is generic enough to be right without being useful.

Actual examples:

• “Assess the situation and react accordingly.”
• “The doctor will doctor the patient.”

Humor/Other (1.53%)

Humor/Other is something that is perhaps an artifact of presenting this to college students, who take delight in offering pithy and funny responses to academic questions. Luckily, I’ve never encountered these answers in an interview setting. This also includes other responses that don’t fit into the other eight categories.

Actual examples:

• “Please sign in at the front desk.”
• “Why didn’t you call 911? Have a seat in the waiting room.”

Calm/Reassure (1.15%)

In Calm/Reassure, the student proposes an interim calming step before any diagnosis dialogue. This is entirely fine, and may be the first step in almost any reasonable approach, but it is somewhat incomplete and is, therefore, somewhat less desirable than the two Engage styles.

Actual examples:

• “Have you take a seat or lay down and calm you down.”
• “Have you sit down.”

---

What Do the Numbers Tell Us?

A little more than half (54.03%) of the students responded with an approach that is, more or less, immediately consistent with a healthy doctor-patient relationship, and that would contribute to a favorable interview (Engage, Specific; Engage, Generic; Calm/Reassure).

Just over a quarter (26.82%) offer an approach that might work but would require further development and coaching (Trust; Challenge/Dismiss; Couch).

About one in five (19.16%) responded in ways that add more mystery to their ability, and would pose a challenge to hire with the sort of certainty I prefer when interviewing (Solve; Avoid; Humor/Other).

If these students were my hiring pool, they’d be a pretty good one; anecdotally, my actual interviews over the years failed to achieve such a favorable statistical distribution. I have to remember that these were all students from premier universities.

---

Opportunities

I believe that this exercise proved useful in highlighting the notion that nearly 46% of students have opportunities for improvement in their approaches. Let’s take a look at the less “Safe” response types for opportunities to correct these behaviors. To add a little texture and extend the medical metaphor (for which I seem to have a fondness), I’ve changed the patient’s problem in this series.

Trust

“Doc, I have a brain tumor.”

“Let’s explore some options. We could do chemo. Or there is surgery, but I wouldn’t recommend that until we’ve tried chemo, but it’s your choice…”

I’m sure you and I have seen many examples of people on the receiving end of a problem diagnosis. From my own perspective, I think most of us, at our most animal, are wired to solve problems as a survival tactic. There’s a lot of good in that. The problem really lies in the how. How do we solve the problem? Trusting the self-diagnosis might be a step. It’s certainly easier than responding in any other way, when any other way risks conveying distrust. It seems fairly certain to me that the Trust response is offered because the person knows the Solve response is too much, too soon. But those who tend toward Trust and Solve have one thing in common: they both feel uncomfortable challenging the self-diagnosis. That’s what makes them both a better response than Challenge/Dismiss, but it’s also where the opportunity lies.

When you are driving, what is the opposite of pressing the accelerator?

Hint: It’s not pressing the brake.

It’s taking your foot off the accelerator.

Likewise, the alternative to trust is not to distrust. It’s to suspend the trust and redirect the conversation. That sounds like this:

“Doc, I have a brain tumor.”

“Oh! I’d like to help with that! Tell me a little more about what’s going on?”

Again, the key here is to develop an understanding that the opposite of trust is to set the trust aside for a moment, rather than to discard it altogether. When we can develop that comfort, we get to Engage, Specific.

Couch

“Doc, I have a brain tumor.”

“Let’s check you out and give you some medicine.”

I believe the Couch response is a product of the classroom or interview setting. As an interview answer, however, it leaves a lot to be desired. That said, it is an indication that the practitioner wants to do the right thing…it’s just that they are not sure what that right thing is. In my experience, folks who fall into this camp learn what they need through more discussion, and from exposure to the pluses and minuses of the eight other behaviors we’re discussing here. It will take some practice and time, but these folks’ good intentions will get them there more reliably than those who tend toward Challenge/Dismiss.

Challenge/Dismiss

“Doc, I have a brain tumor.”

“Don’t worry. You don’t have a brain tumor.”

Or:

“Doc, I have a brain tumor.”

“Why do you think that?”

Nothing feels more dismissive or disrespectful than Challenge/Dismiss. At least the Solvers and Trusters seem to agree on this point.

So what’s behind this response style? Overconfidence? Carelessness? A mix? Unlike Solve and Trust, the fundamentals behind this approach seem thornier to address.

Nobody likes to feel like they are being dismissed or to be put on the defensive. The opportunity here is to ask the practitioner: Can you think of a time when you had a genuine concern that someone dismissed or challenged? How did that make you feel? Is that similar to some of the choices you’ve made in your professional work? If not, why not?

Solve

“Doc, I have a brain tumor.”

“Well, let’s get you into the operating room.”

Solve is one of the two response types I witnessed throughout my early career that inspired the interview question (the other being Challenge/Dismiss).

Both Challenge/Dismiss and Solve create risk. Challenge/Dismiss presents risk to the relationship between the doctor and patient. Solve, however, presents direct risk to the patient, and in that sense it’s the big one to watch out for. Solve is Trust with immediate execution, and it is loaded with risk. The fact that 1 in every 6.5 bright young participants tended toward this response presents a real opportunity.

Since I’ve characterized Solve as an extension of Trust, it’s fair to say that the underlying emotional foundations are similar. Solvers don’t want to convey distrust. But, for some reason, they also feel like skipping past most any discussion to just get things done.

It’s possible they aren’t well-schooled in having exploratory conversations, or that they are simply uncomfortable — introvert-like — with having much conversation at all. But it’s safe to assume that their intent isn’t to cause harm. That’s where the opportunity lies.

In my experience, sharing the doctor-patient analogy has proven to be a useful illustration of the risks of the Solve response. Once that’s realized, the next step is to explore the Trust part of the relationship — the opposite of trust is not distrust — and coach the individual through what that looks like.

Humor/Other

“Doc, I have a brain tumor.”

“If I had a dime for every time someone with a headache said that…”

As with Couch, I believe this response is a product of the classroom setting. However, I’m less certain that the student wants to do the right thing, let alone that they know what the right thing looks like.

That said, I think the opportunity is to put the practitioner into several situations to see what they actually do in situ, and to correct course accordingly.

Avoid

“Doc, I have a brain tumor.”

“I can take care of that for you.”

Even I will admit it was difficult to author that example. It’s hard to think of how this sort of behavior might occur in the real world. As with Couch and Humor/Other, I suspect it’s more an artifact of a classroom or interview setting. Certainly, from an interview perspective, it’s an undesirable answer. I think the opportunity at work or in the classroom is to put the practitioner into several situations to see what they actually do in situ, and to correct course accordingly.

---

The Power of the Question

This little question has helped me define a way of thinking about interpersonal problem-solving behaviors not just in interviews, but sometimes right in the middle of a less-than-ideal workplace situation.

We know that 46% of students who participated in my exercise had great opportunity to improve their manner of client engagement, and I’ve outlined some pathways toward that improvement. But as I’ve noted before, software engineering — and anything that looks like it — is a form of leadership, and one thing remains true above all else: these leaders have to understand why it’s in their best interest to develop their leadership skills.

At the heart of this entire dynamic is a key concept of rhetorical theory: the relationship between logos, pathos and ethos. In my own words:

• Logos: The appeal to logical thinking.
• Pathos: the ability to sympathize or empathize…to understand others.
• Ethos: respect for beliefs, and the establishment of trust.

In their academic work, engineers become highly skilled in logos. But they are not typically conditioned to devote time to become great sympathizers or empathizers, and they are likewise not typically schooled in ways to nurture trust.

Here’s the part of my guest lecture that followed the “heart attack” exercise:

What do engineers do?

We apply science to solve problems.

How do we know what problems to solve?

People are supposed to explain their problems to us.

But do they?

(Here, a great amount of discussion ensues.)

What is a good requirement?

I like to reference Wikipedia for this, but one key characteristic sticks out…a good requirement is traceable:

The requirement meets all or part of a business need as stated by stakeholders and authoritatively documented.

Is there a way to test business need?

If we merely ask, “Does this requirement meet your need,” what kind of answer do we expect?

Ponder this for a minute…

You can’t ask. You have to know.

The way to know is to be part of the conversation!

The conversation…

…is a dialogue.

It involves listening.

• Listening != hearing.
• Hearing = reception of sound.
• Listening = processing of information.

We listen in order to understand.

• When we listen, we ask questions to make sure we
  understand. We reiterate. We get confirmation.
• One of the best ways to understand is to imagine yourself in the other person’s shoes.
• When done right, this is uncomfortable.

This is how we get to pathos.

Good requirements…

…should lead to good software.

But what is good software?

It is software that gets used to solve the problem it was designed to solve.

When people’s problems are solved, they are usually happy.

When your good requirements make people happy, they see that the time spent with you was worth their while.

They come to respect your methods and to trust you.

This is how we get to ethos.

This cycle of empathy and trust (with a proper dose of
logic!) is what makes for a successful relationship
between a software engineer and a customer…a relationship where engineers feel happy because they know that all of their hard work has meant something.

Now my questions for you, dear reader, are:

How do we find place in a young engineer’s life to develop these skills?

How do we find place in a working engineer’s life to nurture these skills?