“The most valuable voice isn’t always the most technical.”

So true. Like "why does this even need to be said" kind of true.

And yet, sadly, it does need to be said.

The quote is from a recent LinkedIn post from my colleague Mike Coughlin. Mike's intention was to reassure folks who see themselves as less technical that their voices matter, even if the discussion at hand is a highly technical discussion.

As soon as I read the post, I knew what I'd be writing to you about this week.

Who is "technical"?

Let's pause to examine the word "technical." What does it mean, anyway?

Webster's Dictionary says... just kidding, no dictionary quote from me. Boring! You can look it up if you want.

More pertinent question: is it useful to call people "technical"?

We say it about ourselves. "Oh, I'm not very technical," people say, in the same apologetic way we might say "I'm not very creative," or "I'm not very athletic."

And we say it about others. "Ali and Chris are very technical," or "people who aren't as technical might find this confusing."

But is that useful?

For a while, I tried labeling the role instead of the person. "People in less technical roles might find this confusing." But if someone changes roles, their knowledge doesn't just vanish. Knowledge isn't defined by role anyway.

Let's look at a related phenomenon: the habit of some people I've worked with to refer to specific others, especially developers, as "the smart people." As in: "I'm going to let the smart people handle that question about databases." Ugh.

In addition to being a developer, I've worked with developers for two decades. I've witnessed us up close.

We're not any smarter as a group than any other profession. Be wary of people who would have you believe otherwise.

Sure, we can dazzle with lingo, but so can knowledgeable people in other professions. The developer talk can seem esoteric to outsiders. Often it seems esoteric to other developers! We just have a lot of practice at pretending we know what's going on.

Sometimes it actually is "what you know"

My take: there are people who know more about a topic, and people who know less about it.

That's it. It's not a character trait.

Someone we label as "non-technical" may have extensive knowledge of, or practice with, a given technical topic. Meanwhile, a "technical" person may have no clue about the same topic.

The folks I've heard referring to developers as "the smart people" usually have vast stores of knowledge about their own fields.

One person is not smarter than another because they have knowledge the other person doesn't. We just know different things.

How about:

• "Ali and Chris are both experts on this piece."
• "People who aren't familiar with this topic might find this confusing."
• "I'm going to let the people who know about databases handle that question."

Should I not say "technical" then, or...

I'm not suggesting that we avoid using the word technical to describe people or roles. Just suggesting that we think about what we're saying when we use that word.

What assumptions are we making? If I'm dividing the room into "technical" and "non-technical," am I assuming that someone doesn't know something when they might, or assuming that someone does know something when that isn't necessarily true?

To Mike's point: am I silencing myself when I might have something valuable to contribute? And the flip side: am I ignoring the input of others because of their role?

Once upon a time, I worked with a business analyst who was known for saying things that were out in left field. But I learned not to write him off.

Yes, he had some strange theories that made no sense. Thankfully, he remained undeterred in voicing his questions and observations, because he was also sometimes the only one who saw something important that the rest of our team missed.

Listen

Developers (anyone, really, but I've seen developers do this):

When someone asks us a question or presents us with a problem—especially if it means we might be wrong about something—we often try to shut it down.

Rather than listening.

"Oh, no, that can't happen because... users won't ever... the system can't possibly... no, we don't need to worry about that," we say, with some hand-waving.

What if we take the questions and suggestions seriously?

Here's an example:

Your colleague says: "Would it be a problem if the user exits after they save?"

You think: what a bizarre question. Why on earth would it be a problem if they exited after saving??

"No, that won't be a problem," you say.

If you have looked up from your laptop, you'll see just a second of "but... wait..." in their eyes before they decide you probably know best and give up. Conversation over.

Same conversation, with some questions instead of shutting the inquiry down immediately:

[Note that these are genuine questions, the kind where you are actually looking for an answer. "What are you carrying on about this time?" is not a genuine question.]

Your colleague just helped you unearth two problems:

• Saving is taking much longer than expected, and
• The user could exit during saving. You didn't think that was possible. It's probably fine if they do... but you'd better look into it.

Technical knowledge

Note that your colleague needed no special technical knowledge. They didn't have to know about API calls or resource management.

They just recognized that, computers, like people, get cranky if you pull away what they're holding while they're in the middle of using it.

Specialized knowledge can even be a disadvantage. When you've been looking at a system from one perspective for a while (as a developer, say), you start to miss things that are more obvious from some other perspective (as a user).

We need the perspectives of people who think outside the box, sure. But our personal "box" is a lot smaller than we might want to believe.

So, yes, the most valuable voice in a technical conversation is not always the most technical, and may not even have a "technical" perspective at all.

Kindred spirits disadvantage

Bonus note, but related:

Ever have a colleague who approaches things the same way you do? You think alike. You're kindred spirits of the workplace. It's so validating, so comforting.

Until you try to troubleshoot as a pair.

It looks like this. (This may look familiar to one of my readers...)

Ooof. We kept tripping over each other while troubleshooting, and when we were out of ideas, that was it. The solution eventually came from some third person, and we were both surprised! We didn't think of that...

Drop me a note

Personal note: solar panels are up, battery is in place. We need a city inspection, some intervention from the electric company... and then we're ready to switch it on. Exciting!

I would love to hear from you. Hit reply and let me know what's on your mind.

This newsletter is approximately weekly. In addition, I post to my blog on my website, which also appears on Medium and Substack.

Want to start (or stop) getting blog posts by email in addition to the newsletter? Edit your preferences here.

Know someone else who would enjoy this? They can subscribe here: https://www.beyondwritingcode.com/connect/​

Thanks for reading!

​Beyond Writing Code is a newsletter from Leaf (Jessica Roy).

You are subscribed as Reader.

​Unsubscribe | Preferences | 113 Cherry St #92768, Seattle, WA 98104-2205