, ,

Tech has a Toxic Tone Problem — Let’s Fix It!

, ,

When it comes to communication, especially involving engineers, tech has a toxic tone problem. I know because I’ve not only been surrounded by it for the past decade, but during less enlightened moments, I’ve contributed to it.

Just to be clear, by tone, I am referring to the “attitude expressed by the words that someone uses in speaking or writing,” and by toxic, I mean “harmful to an organization, including either its property or people.”

Software engineers are not generally known for their stellar communication skills. Many reasons have been proposed to explain this phenomenon: the possession of specialized knowledge, the amount of time spent with computers compared to human beings, the personality types that traditionally lean toward programming, etc. Most of these potential reasons are problematic—the last one is especially stereotypical—and none of them excuses engineers from acting like decent human beings to those around them.

Poor communication by engineers is not a new phenomenon. Gerald Weinberg wrote this back in 1971’s The Psychology of Computer Programming:

It is possible to be too smart for programming — if the person is not smart enough to use his intelligence to modify his social behavior and methods of conversation.

In addition to crippling a team’s productivity, these communication issues discourage people from pursuing engineering and also discourage existing engineers from participating in the social activities of programming, e.g. asking and answering Stack Overflow questions and contributing to open source. Therefore, improving the communication surrounding programming is essential to creating a more inclusive development community.

In order to address the problem, we must seek to understand it. I’ve observed that the tone problem comes in three common varieties. This is certainly not an exhaustive list, and engineers are not the only people who experience these communication issues.

The toxic tone generally presents as a condescending tone, a robotic tone, or a pessimistic tone—or some deliciously toxic tone cocktail containing all of them.

The Condescending Tone

When you gain any sort of technical skill, you come to possess specialized knowledge that others around you may lack. Unfortunately, learning a technical skill doesn’t necessarily come pre-packaged with the ability to communicate effectively with those who lack this skill. A common result? In discussions with others, your inability to empathize with those who don’t share your understanding can make you seem like a condescending jerk.

Did you ever see Jimmy Fallon’s hilarious Nick Burns: Your Company’s Computer Guy sketch on Saturday Night Live? While Nick may technically be a fictional I.T. professional and not a real-life programmer, his behavior, caricatured as it may be, is a surprisingly accurate portrayal of the condescending tone that pervades tech.

I’ve listened over the years as colleagues called other engineers or interview candidates “idiots” who “couldn’t program their way out of a paper bag.” I’ve seen the eye rolls when junior engineers ask questions. I’ve heard the judgmental comments about bootcamp grads or self-taught programmers.

You can also see it in the way many engineers talk to and about employees working in marketing, sales, product, and customer service. It’s especially apparent when an engineer labels someone as “non-technical” to dismiss their input, which, incidentally, is one of the reasons I think we should ditch that term altogether.

The condescending behavior is not always so blatant, though. Let’s look at a subtler example. Someone asked the Stack Overflow community for help understanding the difference between Observer and Observable because even after time spent searching online, the individual was still struggling. Here was the top-rated answer with over 100 votes:

Here's the condescending part, for easier reading:

I'm not sure I know how to spell it out in plainer English.

You have the definition above. It's two sentences. Not much to digest, even if you have to read it ten times.

The distinction between the terms seemed so clear to the person answering the question that he couldn’t imagine how someone possibly needed “plainer English” in order to understand. I wonder how the original response made the question submitter feel. I can’t imagine it made the individual feel supported or more confident. I know from the ensuing discussion on Twitter that people who had just stumbled across the exchange found it disturbing.

Luckily the Twitter discussion seems to have inspired someone else in the community to edit the answer, removing the condescending preamble to an otherwise helpful response. If only the community as a whole valued kindness enough to cast their upvotes accordingly!

The attitude behind any case of condescending tone is essentially, “I know something that everyone else around me doesn’t, and my superiority exempts me from showing them my full respect.”

This is a dangerous attitude. It’s reminiscent of Raskolnikov’s “superman” complex in Crime and Punishment. He sees himself as above the laws of decency governing the rest of humanity, which enables him to commit murder.

We may not be dealing with behavior that extreme, but it’s still not healthy for our development teams. As Sarah Mei, founder of RailsBridge, has said:

So what’s the solution? 

The Compassionate Alternative

Well, first of all, those of us in leadership positions need to stop rewarding arrogant, condescending, or insulting behavior. The evidence of true mastery of a concept is being able to explain the concept in simple terms to someone less experienced. That is type of behavior to reward.

What about on the individual level?

If you’re actually feeling superior to a colleague asking for help, and you know you’re about to say something condescending, ask yourself how you would feel if someone spoke to you that way. Will your words make them feel better? Or worse? Do you actually know more than this person? Does that actually mean you don’t need to show them respect? Might they know something that you don’t know? Might they just look at problems differently from you?

Let’s suppose the person you’re talking to is indeed as ignorant of the subject matter as you think. Imagine how much of a struggle it will be for him or her to understand. Have compassion for the suffering this may entail, and see what you can do to minimize that suffering. It may help you to think back on a time when you were learning this subject for the first time. What was helpful to you? Consider:

  1. What questions did I have and what were the most useful responses?

  2. What resources might provide additional perspectives to help this person understand the issue?

Also, be compassionate toward yourself. Is trying to help this person draining your energy? If so, would it help to take a break? Is there someone else who could step in to help? Is there a relevant article you can send that adequately covers the material? (Caution: Sending a “Let me Google that for you” link usually counts as condescending unless of course you’re confident that it’ll be happily received as as joke.)

Check in with your motivations. Is it possible that you actually feel a little insecure about your knowledge in this area? Are you tempted to use condescending remarks to protect your ego? Don’t beat yourself up if that’s the case. Interviews and employee reward systems in the tech industry usually favor inflated egos, so it’s probably not your fault. That said, perhaps some introspection can prevent you from saying something insulting.

If you can respond with compassion instead of condescension, people are more likely to enjoy working with you because you’ll make them feel better about themselves. Consider this story from Olivia Fox Cabane’s The Charisma Myth. 

In 1886, a woman had separate dinners with the two candidates running for prime minister of the United Kingdom. Here is what she had to say to the press about the dinners:

“After dining with Mr. Gladstone, I thought he was the cleverest person in England. But after dining with Mr. Disraeli, I thought I was the cleverest person in England.”

Needless to say, Disraeli ultimately won the election. Which type of person do you want to be? Do you want to assert your superiority by speaking condescendingly? Or do you want to help others realize their own potential? Similarly, which type of person do you want to work with?

You might check out The No A**hole Rule for more on this subject.

The Robotic Tone

“Hi Pat, your cousin died.”

This is a message my dear grandmother once left in a flat tone on our answering machine when I was a child. There was no emotional verbiage to delay getting to the point, just an efficient statement of fact. I like to think I got my directness from her.

Unfortunately, not everyone appreciates this emotionless directness. I shared earlier that I’ve contributed to tech’s toxic tone problem, and this robotic version of the problem has been my weakness.

As engineers, when we’re dealing with computers, we can generally get by without being mindful of people’s feelings. We tell the computer very directly what to do, and it complies. It’s a beautifully efficient and logical process, and it’s probably what drew many of us to engineering in the first place. 

For better or worse, people are not the same way. We do have feelings. We can’t just share facts directly with no consideration for how they’ll be received—I mean, we can, but then we get labeled as “abrasive” or “blunt” (trust me). If you talk to humans as if they’re machines, most people are not going to enjoy working with you.

Perhaps thanks to my grandmother, I’ve always considered directness to be an asset in engineers (and everyone, actually), but I’ve come to accept that it’s also important to be mindful of your audience and allow that to shape your delivery.

If your site goes down at a critical moment, delivering the news bluntly without providing hope in the form of assurances that you’re working on a solution may not make you the most popular person in the office. Sharing this kind of news in a robotic tone may also bring into question your empathy for the customer. Staying calm is important, but it’s also important to at least acknowledge the impact on the customer.

The robotic tone is also an issue in delivering feedback. For example, imagine you work with a designer who has assured you multiple times that he loves your direct feedback. He asks for your input on his latest mockup for the pet management app you’re working on together. He has assembled the detail screen for one of the user’s pets. It depicts statistics about her cat, Neil. On the top of the page is the title, “You.” Imagine something like this, but much higher fidelity:

After seeing the design and thinking logically through the scenario, you say, “Shouldn’t the title be something like ‘Your Cat’ or ‘Your Pet’ or even ‘Neil’ since this page isn’t about the user, but rather a subpage specifically about the pet?” You believe your logic is sound, and since the title appears at the top of the page, it’s the first thing you notice, so it’s the first comment you make.

Now, if you have a great relationship with the designer, if he’s fully confident in his abilities, if he’s in a cheerful mood, and if he really does appreciate direct feedback, then maybe he’ll thank you for pointing out the error and agree to update the title. Or perhaps he’ll happily explain why the title does indeed make sense.

If, however, the stars are not so perfectly aligned and anything in that long conditional statement is not true, he may not feel so great when the first thing you point out is a problem without acknowledging the effort that went into creating the design or recognizing any of its strengths.

You may think you’re just being efficient. Why waste time going through everything that’s right with the design or tiptoeing around what’s wrong when it’s much faster to just get to the point about what needs to change? Well, the issue is that people have feelings, and these feelings influence their productivity. 

When you dispassionately point out someone’s mistakes without recognition of their strengths, this can make them feel threatened, and that can hurt productivity. As explained by researcher David Rock, 

“the threat response impairs analytic thinking, creative insight, and problem solving.”

So what you think is the most efficient way to proceed may be causing painful emotions that are actually holding your team back.

The same goes for code reviews. If all you do is flatly point out someone’s errors, you’re likely killing their spirit, counterproductively squashing their motivation to improve.

The Compassionate Alternative

It’s not enough, then, just to refrain from being a condescending jerk; to truly support positive collaboration on your team, you need to take it a step further and consider how you can best inspire the others on your team with positive emotions and avoid causing them to suffer. 

Remember that you’re talking to human beings, not machines. As Karen Armstrong has warned,

“If it is not tempered by compassion and empathy, reason can lead men and women into a moral void.”

When it comes to feedback, one technique is to rely on questions — genuine questions. The pet app example feedback above starts with “Shouldn’t,” and although it is phrased like a question, it is actually closer in spirit to a judgmental statement. A kinder option might be, “Could you talk me through the choice of title for this screen?”

You also might temper your critical feedback with positive feedback. Some people appreciate the “sandwich” method of delivering feedback: offer a compliment, provide constructive criticism, and then offer another compliment. Other people — myself included — can see through that and just want you to get to the point. 

In any case, what’s most important — whether you’re delivering bad news or potentially ego-threatening feedback — is to simply give some thought to the emotions of the person you’re addressing determine how you can share your point of view while causing as little suffering as possible.

I can anticipate resistance to this advice because I have resisted this advice for most of my career. Young April said things like, “Well, people should just learn how to deal with the truth.” Perhaps there’s something to that. I do believe that if you build strong relationships with people, you can communicate with a certain level of directness that might be inappropriate when there’s no rapport. I also think that in truly egoless programming and product development, feedback can be given directly because there are — in theory — no egos involved.

Then again, you never know — someone who can normally take your direct feedback may crumble under your words if her dog just died. So, I don’t think there’s ever a time when you shouldn’t at least consider the impact of your words on the emotions of the people with whom you’re interacting. 

The Pessimistic Tone

The last toxic tone is the pessimistic tone. I’ll start by saying that I believe a healthy amount of skepticism is important on any team, so that is not the problem.

The problem is when nearly every creative new idea or tool or approach is shot down, usually by an embittered senior engineer who’s “seen it all before” and thinks it’s all terrible.

“That won’t work.” 

“That won’t scale.”

“That new tool is just as bad as the old one.”

For some reason, engineers often belong to a group that former USC President Steven Sample has called “congenital naysayers.” He describes them as follows.

“Rather than imagining how a new idea might possibly work, they instinctively think of all the reasons why it won’t. They sincerely believe they’re doing everyone a favor by reducing the amount of time spent on bad or foolish ideas. But what they really do is undermine the creativity that can be harvested from thinking free.”

That second sentence perfectly describes the allure of pessimism to engineers: saving time. If you’re right about your pessimistic prediction, you might very well be saving people time by rejecting their idea. 

What happens all too often, though, is engineers reject an idea with an air of certainty when they really can’t be certain at all that the idea will fail. They pass judgment before receiving all the facts. Perhaps they’ve seen a similar approach fail in the past. Or they’ve seen so many useless project management tools over the year that they can’t imagine any new one working well. Or perhaps every time they’ve tried to have a wiki in the past, the team hasn’t kept up with its maintenance, so they don’t expect this time to be any different.

That is all useful information for the engineer to provide to the team, but it doesn’t immediately lead to the conclusion that the given proposal will fail. There’s certainly no need to deliver the past data points with a sigh and a negative tone.

Maybe you had one bad experience using Rails on a previous project. That doesn’t imply that it’s a bad tool — perhaps it wasn’t suited to your use case or perhaps your team didn’t fully understand it. 

Engineers who have seen many projects fail over the years can come to expect failure, which leads them to project a general negativity in everything they say. For every time your naysaying has saved the team from pursuing a dead end, there have probably been 10 times you’ve hurt morale and prevented what may have been fruitful experiments.

What’s dangerous, too, is that it’s usually the bitterest engineers of all who are most revered by the newer engineers. Presumably the thinking is, if they have so much to complain about, they must know it all! This only perpetuates the negativity.

Sidenote: Interestingly, engineers do tend to be optimistic about at least one thing—the amount of time it will take to complete a task. Unfortunately, the main result of this optimism is a woefully unrealistic timeline.

The Compassionate Alternative

It’s useful for engineers to be on the lookout for possible sources of failure — this is how we prevent bugs and downtime and security breaches. But we must be careful to balance that ability to identify potential negative results with a belief in the possibility of success.

Why? Because as Shawn Murphy explains in The Optimistic Workplace,

“When our brains are opened by positive emotions like joy, we can better see connections and more options to solve work problems.”

He also cites a related statistic:

“People in positive work environments outperform those who work in negative climates by 10–30%.

Before you shoot down an idea or predict failure for a new project, ask yourself — are you certain the idea will fail? Remember what Voltaire said about certainty: 

“It is only charlatans who are certain; doubt is not a very agreeable state, but certainty is a ridiculous one.”

If you’re not certain, then why speak as if you are? Does “That won’t work” really need to be your response? Can you instead respectfully share your concerns and past experiences with your team?

If you are indeed certain that the idea is doomed to failure, first read the Voltaire quote again, and then consider how can you communicate your doubts to the rest of team without crushing morale. Is there a way your response can start with, “Yes, and…?” For example, “Yes, I see why it seems like that’s a great idea, and here’s why it’s better suited for this other context.” Or, “Yes, that is an interesting idea, and perhaps it will be more feasible in a few months when we’ve accomplished Y.”

This is another time when it helps to have compassion for yourself. Are you frustrated about something else, and is that the real cause behind your distaste for the proposed idea? Are you just tired? Try taking care of any personal needs you have, and see if you still object to the idea.

It may also help to remind yourself of the company’s mission or your personal mission — why are you here working on this project? What gives you hope? Can you channel that hope into openness to new ideas?

You don’t need to pretend everything’s going to be perfect all of the time, but being open to new ideas is a prerequisite for doing truly innovative work, and it also makes you a more pleasant and supportive coworker.

The Future

“Computer programming is a human activity…and yet…many people — many programmers — have never considered programming in this light.”

Gerald Weinberg wrote that back in 1971, and unfortunately, it is still too often the case. I think the time has come to give communication in engineering the attention it deserves.

We may be skilled engineers who love building beautiful masterpieces of software, but can we also be kind, compassionate people who support each other and inspire each other with our words in both spoken and written communication?

I envision a brighter future for tech, where we ditch the toxic tone in all of its varieties and instead embrace a tone that is positive, humble, hopeful, clear, and inviting — inviting because, as we know, we’re going to need many more engineers and other contributors to build all that we want to build. 

As Fran Allen says of engineering in her Coders at Work interview:

“It’s such a transformative field for society as a whole. And without the involvement of a diverse group of people, the results of what we do are not going to be appealing or useful to all aspects of our society.”

So, in the interest of progress, let’s not scare anyone away with needless, ego-driven negativity.

 

Want to learn more about effective communication on software teams?  We offer workshops on emotional intelligence for engineers. Let’s talk!

If you want more articles like this, sign up for our mailing list!

You can also follow us on Twitter!