Soft Skills - Part 1 - Communication

Introduction

A few years ago, maybe the first part of 2019, I was asked to contribute a chapter for the PowerShell Conference Book Volume 2. So much has happened since then and I don’t remember who did the asking. The odds are decent enough though to guess Mike Kanakos.

This article is the first in a series of three which will be a republishing of my chapter on soft skills. I’ve only gently edited a few items from the original material.

On the Road to DevOps, Don’t Forget the Soft Skills

Hard skills like coding, debugging, system design and the ability to schedule and deliver work on time, give you permission to start your technical career. You can’t go far if you don’t master these. But it takes a lot more to be effective and to accomplish big things. Big things are accomplished by effective teams. Soft skills like communication, collaboration, negotiation, and motivating others transform collections of people into effective teams. People that can do these things are force multipliers and are worth their weight in gold.

—Jeffrey Snover, Ex-Microsoft Technical Fellow, PowerShell Inventor

Art suggests, “Life is a journey, not a destination.” The same can be said of DevOps. It’s about the journey of continual improvement of relations and processes. It’s about a contributor, a team, and an organization delivering a product (such as an application, service, or platform) more efficiently through effective collaboration.

The first PowerShell Conference Book chapter, “PowerShell as a Gateway to DevOps” by Brandon Olin, provides some additional guidelines on what DevOps is and isn’t. It also provides a sampling of tools that helps to reinforce a DevOps culture.

This chapter focuses on a few key soft skills, such as communication and collaboration, that you need in your technical career, especially when practicing and applying DevOps principles and methodologies.

The Great Division

Before exploring soft skills, consider the following statements which many of you could have heard, or even said, this morning.

• Developers just don’t care about security.
• The systems team is a roadblock. They were supposed to build that VM over a month ago.
• They don’t even know how this works and they’re lecturing me on the security implications?
• We’ll never get to zero downtime deployments. They must have lost their minds.
• They won’t even listen to my ideas in meetings.
• I just don’t understand why they refuse to help.

These statements reflect a division between programmers, also known as software developers, and system administrators. This division, the Chasm of IT, poses a significant challenge to any organization on the path of cultural transformation to implement DevOps practices.

Near the dawn of time, around January 1^st 1970, the line between programmer and system administrator was blurred, especially in Unix environments.

[M]y strong impression is that setting up and operating early Unix systems pretty much required a programmer. As a result most or all of the people who ran early Unix systems were effectively system programmers out of necessity.

—Chris Siebenmann, @thatcks, Overcommitted Sysadmin, Operators and system programmers: a bit of System Administrator history, 2012

As the Unix systems matured, programming was required less and less, giving way to a more specialized system administrator, one that could focus on the configuration and maintenance of the system. Developers and sysadmins paths diverged even further with the proliferation of personal computers and friendly user interfaces. The increase in users meant an increase in demand for new applications and services to support business and personal requirements. Operating systems and applications required software developers to write the code. Services, such as email and online communities, required complex configuration and operational stability which became the focus of the system administrator.

The division between developers and sysadmins grew with each passing year due to advancements in technology and expansion of services. The more technology changed, the more the mindset shifted in each group to handle the new demands until the Chasm of IT became larger than the Grand Canyon.

Being a professional in the IT industry often brings about egotism. After all, the “I” in IT is information. With information, comes power and control. And with those, comes a sense of superiority, most often unwarranted.

A natural mistrust exists between divided groups of people. In turn, this mistrust creates and nourishes a mistrustful culture. This culture colors the viewpoint for each side and creates preconceived ideas when dealing with the opposite group.

Now that you have a foundational understanding of how the division was born, here are a few skills that you must master to build a bridge spanning the gap between developers and system administrators.

Communication

A good guess is that no one reading this shares ideas and information via a subspace communications network like the Borg. Collaboration would be much easier if everyone had that capability. If that were true, the entire planet would already be functioning at optimum capacity and perhaps would have evolved beyond DevOps.

Instead, you rely on the communication skills you’ve learned over your lifetime. Communication is more than just hearing what the other person is saying. It involves actively listening and understanding the message they’re trying to convey.

Like network protocols, negotiation occurs on how you are going to transmit and receive data. This could be via phone, Skype, email, discussion board, GitHub issue, or a face-to-face in a meeting or in the hallway. Next, choose the language. You then open the floodgates and let the data pour out of your brain and into the receiver’s. Or so you would hope.

Static on Your Frequency

Several factors can hinder communication.

Language and Culture

The first requirement of communication is having a common language. On diverse teams or with vendors or the community, you may interact with people who don’t speak a common language as skilled as you.

Even speaking the same language doesn’t guarantee that the two of you would be able to communicate effectively. Pop, native, or regional culture references, whether current or from a specific time, may be lost on someone who doesn’t have prior knowledge of the reference.

Consider this quote:

“Dave, this conversation can serve no purpose anymore. Goodbye.”

While it seems to be pertinent to the topic at hand, perhaps the speaker was trying to make a subtle comment on artificial intelligence (AI). An audience comprised of early twenty-somethings would probably fail to infer that your statement was about AI, unless they were avid cinephiles.

By the way, the quote was said in the 1968 film, 2001: A Space Odyssey, by the ship’s computer, an AI named HAL.

A Telepath, an Interrupter, and a Know-it-all Walk into a Meeting

Some people must believe they’re telepathic and know exactly what you are going to say. Or they know you so well that they’re able to finish your sentences. Or they know the subject matter better than you or anyone else, so they feel obliged to hurry the conversation along.

By interrupting someone, they’re sending the message that they’re more important than the speaker or the speaker’s message. Maybe they don’t mean it that way. But that’s how it will be perceived. In actuality, the person that does any of these is rude and disruptive.

Disclosure
I have a predilection to interrupt. As a long-time sufferer of fastidiousness, it’s difficult for me to stop myself from jumping in with a minor correction or clarification. Impatience also compels me to slip in some predictive statements, in the guise of saving time.

The Rambler

On the subject of being rude, it’s likewise just as rude to begin speaking and dominate the entire conversation. It’s rude to begin talking, but never give pause so the listeners can digest what you’re saying. It’s rude to keep on talking, raising your voice to drown out when others try to interrupt just to slow you down or to verify something you said five sentences ago. Something compels the Rambler to be an over-talker, to bully a conversation with ego and arrogance. Perhaps, they could be simply unaware they’re rambling.

Emotions

Human emotions can block communication. For instance, just learning of some incredibly sad news, it’s unlikely that you would be able to focus enough to fully comprehend a message that you receive. Your mind, and heart, are simply overwhelmed.

Likewise, getting into an argument before communicating, regardless with whom you communicate, your guard will be up, and you may not be receptive to another one’s ideas. An adversarial stance, whether born of mistrust or disgust, could negate any chance of effectively communicating with another. They in turn would sense the aggression and, most likely, would become adversarial as well. In these times, communication breaks down before it can even begin.

This has played out on numerous occasions. In one corner of the room, a developer prepares to bring her ideas to the table. In the opposite corner, a sysadmin fumbles with his papers, angered that he must take time out of his busy day for the meeting. His hackles are up before anyone utters the first word. This meeting could have taken place over email, right? Maybe, or maybe not. That isn’t the point. Any chance of having a productive meeting is lost, along with everyone’s time.

Aggressive or negative interactions could take hours, days, or even weeks for the emotional damage to subside. Often, this leaves scars, emotional baggage, which makes any future engagements just that much more difficult.

Emotional Baggage

Imagine that emotional events (parts of your history, even recent history, having a significant emotional impact) can be packed away into different suitcases, backpacks, handbags, or luggage. If you attempt to carry all these events at the same time, you’ll be encumbered and, effectively, immobilized. Much like boarding a plane, each day you have to decide which emotion-laden luggage is checked (and put in the plane’s cargo hold) and which you accept as a burden (as your carry-on).

Imagine that your backpack, the only luggage you’ll carry with you, is full of the most recent emotional events. Give it a fictitious weight of 40 lbs. If this were a real backpack, with real contents of the same weight, carrying it would definitely be a greater drain on your physical energy than without.

The same is true for your emotional energy. For virtually everyone, interaction with others can have a positive or negative emotional influence.

Preferred Method

While it’s a minor facet of communication, the fact that each person has a preferred method of communication is something to consider. Some may prefer face-to-face and don’t readily digest any written information. Others may prefer email and avoid direct human contact.

Target Audience

If you were to send a technically detailed email to the VP of Marketing, the chance your message will be fully comprehended would likely be slim-to-none. Similarly, say you just implemented a new solution but don’t have the time to provide full documentation before a scheduled trip. If you were to send a generalized email to your team and omit key details about the new solution, your team would most likely not have enough information to handle an outage while you are away and your vacation would be disrupted.

How to Communicate More Effectively

You can address communication issues by approaching how you communicate with individuals, or a larger audience, using the following guidelines.

• Handling Language and Cultural Differences

  You can overcome a language barrier where you and the other person has some skill in a shared language. In fact, listening to others with accents is a skill that can be learned, but you must be patient and allow yourself enough time. If after a while you are still struggling to understand, let the other person know that you are having trouble understanding them. Perhaps written communication would be better in this instance.

  Keep pop/native/regional culture references to a minimum or, at the least, only use those references which has had a global reach. Without trying to invoke ageism, simply consider the age of the audience when using a reference from a different time.

• Become an Active Listener

  If you often find yourself interjecting or interrupting a speaker in a discussion, the first step, and perhaps the hardest, is to realize your current part in the discussion. Even if you are telepathic and know what the person is going to say, give them the opportunity to say it. You are a listener and listeners listen. Don’t think about what you want to say or ask. Don’t think about what the speaker might say next. They will give you the chance to ask questions or make comments between their topics because they know their part of the discussion. Actively listen to the speaker and digest the information they’re presenting.

• Don’t Ramble On

  Remember, communication is about what the listener perceives just as much as the message you are conveying, maybe even more so. When the roles reverse and you become the current speaker, your first job is to convey your message. Your second job is to ensure the listeners understand what you are saying. Help them to understand by giving them time to assimilate the information you are providing. Give enough pause between the box-cars in your train of thought so they can ask you questions to clarify their understanding.

• Only One Carry-On Allowed (Keep Your Emotions in Check)

  The heated discussion between the developer and sysadmin, in the previous pages, generated a negative emotional event for both. When either prepares for the next meeting or starts thinking about the other, they transfer the emotional event to their current backpack. They carry it with them to the meeting or set it on their lap as they write the email to (or about) the other person.

  Instead of putting the emotional event into the backpack, examine it objectively to determine the cause of the argument. What was said and who said it? Were there other factors (known to you) that caused the aggression?

  Take this objective information and leave the emotions that were stored in the event in the luggage you will check for the day. Use this information as warning markers during the upcoming meeting or interaction to help you steer clear of volatile and incendiary topics. At a minimum, allow the markers to delicately guide the conversation.

  For all emotional events, you should distill the content from the emotion and store them separately. Discard emotions for events that have no value, like road rage. Retain the emotions for events that do have value, like rescuing a stray puppy or mentoring a peer.

  Once angered, you should step away from the situation and allow yourself to cool down, before you can process and separate the emotions. Take your time and ensure that you are as calm as possible. Diffusing your anger is a critical skill and, like all others discussed here, can be learned.

  Interacting with others can consume emotional energy, especially for introverts like myself. Give yourself time to recharge your emotional batteries between interactions.

• In-Person, Call, Text, or Email

  Learning a person’s preferred method of communication takes some small amount of observation. Watch or listen for signs when you are talking with someone for clues if they’re receptive to the mode of communication. If you can’t tell, ask them.

• Target Your Message to Your Audience

  When you are writing an email, drafting a slide-deck for a presentation, or providing input at a meeting, you must consider your target audience. For a presentation to end-users on how to use a new feature or application, steer clear of industry jargon and provide simple analogies for concepts that are technically complex. When writing documentation for a new service, include precise and comprehensive details with enough examples to fully illustrate the design and current configuration.

Summary

Soft skills are just as important as hard skills, perhaps even more so, and should be nourished and cultivated.

Collaboration can only come from effective communication which comes from listening and understanding each other. Knowing that people are driven by emotions and needs, you must allow yourself and others to be human. Be sincere and genuine when you offer to help others achieve their goals; remember the times when someone helped you.

As this is the first article in a short multi-part series, please add this site to your favorite news aggregator or bookmark it to return next week when part two on collaboration will be published.

Reading Material

While this chapter focuses on improving soft skills, the books (and one yearly report) listed below illustrate the shift in mindset required for a practicing DevOps organization.

Title	Author(s)
The Unicorn Project: A Novel about Digital Disruption, Rebels, and Overthrowing the Ancient Powerful Order	Gene Kim
The Phoenix Project: A Novel about IT, DevOps, and Helping Your Business Win	Gene Kim, Kevin Behr, and George Spafford
Beyond the Phoenix Project	Gene Kim, John Willis
The DevOps Handbook: How to Create World-Class Agility, Reliability, and Security in Technology Organizations	Gene Kim, Jez Humble, and Patrick Debois
Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations	Nicole Forsgren PhD, Jez Humble, Gene Kim
Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation	Jez Humble and David Farley
Making Work Visible: Exposing Time Theft to Optimize Work and Flow	Dominica DeGrandis
The State of DevOps Report, a yearly report based on survey data	Puppet
The Goal: A Process of Ongoing Improvement	Eliyahu M. Goldratt, Jeff Cox
Theory of Constraints	Eliyahu M. Goldratt

Note: The last two books aren’t directly related to DevOps. They were, however, inspirational in establishing the underpinnings of DevOps.