DevOps challenges and transforms existing cultural norms – the entrenched social, behavioral, and communication links between people. When technology and software delivery organizations respond to snowballing business demand, the drive for swifter software delivery, and amplified operational resiliency, communications must transform if revenue-driving business process outcomes are to be realized. The pace of business quickens relentlessly, leaving unadaptable companies licking their wounds or dying off. Communications is one of the chief “make it or break it” aspects of DevOps. So, why do many organizations struggle to communicate acceptably? Let’s consider the communication link.
Communication means many different things; though, all having to do with information sharing. For DevOps, changing the organizational culture of a company is a primary talking point. Connecting people to the value-add of DevOps and then to the expected business outcomes, helps team members understand how “shifting left” (becoming engaged earlier in the process) facilitates collaboration driving faster product delivery. Once those connections are solidified, then proving to executive leadership that the investments in the adjoining agile technologies and toolsets (CI/CD pipeline, code repositories, collaboration tools, etc.) are returning value only takes the time needed to deliver a few good wins for the company. When those wins start showing up on financial statements, client and customer comments, and employee productivity, DevOps is structurally making a positive impact. Critical to this success is clear, consistent, and continuous communications. Poor, acceptable, and good communication samples are everywhere. What does good look like?
Napoleon’s Corporal – discerning communication effectiveness.
With probably a bit of legend attached, history tells of Napoleon planning with his senior officers on battle strategies and tactics. Once the battle plan decision had been made, the senior officers were dismissed to make preparations, including communicating the plan down the ranks. After some time, Napoleon would seek out a soldier of the rank corporal (usually the lowest rank of a troop leader) inquiring about the battle plan. If the corporal understood the plan, objective, timing, etc., Napoleon would proceed with a high expectation of executional success that would hopefully lead to battle success. However, if the corporal (probably a few corporals) did not understand the plan or did not think the plan made sense, Napoleon would reconvene his senior leaders for a relook. Napoleon understood that success could only come when his troops understood the battle plan, recognizing that good communication was the enabler of that understanding. When the corporals understood the plan, communications answered the question, “What does good look like?”
In today’s uber-hectic business world, senior leaders should more proactively and intentionally engage employees throughout the organization to assess communication effectiveness. Skip-level meetings are not the idea that comes to mind, as those meetings tend to be very ineffective – people feel compelled to attend but don’t really want to express real concerns in that environment. Well understood strategies make it probable that all members of the organization can communicate what the company is doing. Managers at all levels witnessing the effort put forth by senior leaders will get in lockstep, ensuring that the right message continues to move down the organization, thus improving understanding and facilitating solid strategy execution. Today’s corporals should include interns. If interns understand the strategy during their short tenure, leaders can be confident of effective communications. And since interns represent the organization’s pipeline of future talent, making sure they know and understand the strategy is a handy recruiting tool. Interns choosing to return to your company indicate that the company has proven to be an excellent place to work, or at least not a bad place to work.
Listen to Albert
Clear communication is not about the “big” words you use or the inclusion of the latest technical jargon, but rather what your audience hears and understands from what you say. Refrain from jargon and “big” words in favor of common, simpler words and phrases that most people can understand. Yes, there are exceptions – defending a dissertation, academic talks, etc. — but in those cases, your audience is specifically chosen, or chose to attend your presentation, having the knowledge and understanding of the topic to keep pace with your use of the subject’s taxonomy – “big” words.
If you can’t explain it to a six year old, you don’t understand it yourself. ― Albert Einstein
Remember, if the audience does not understand the message, the deliverer has failed to communicate effectively. I don’t mean after a single message, but over time as you continue to communicate your message, the message should resonate with more and more people. If not, consider modifying the message based on the feedback or questions that have arisen. In all cases, fine-tune your message for your audience; don’t expect every audience to respond similarly.
Researching to Learn
Constant learning is a must skill for everyone, especially for those introducing a new paradigm, or model, into an organization. That learning needs to be deeply rooted before taking the next step to introduce the model to the organization. Learning to communicate more effectively must be one aspect in the evolution of that learning. Knowing information, or formulas, or processes is good, but communicating the importance or impact of that information or data is much better, so we must learn to communicate better daily. Writing has been my outlet in sharing information within my career domain, researching new ways to communicate benefits and understanding of my message. As time progresses, my message should improve. From a Google search, I came across a seven stage communication model, which reminded me of the OSI Model, which should be a nice parallel for this technical audience.
- Source.
- Encoding.
- Channel.
- Decoding.
- Receiver.
- Feedback.
- Context.
Note: I don’t know anything about MindTools, nor endorse, nor have I profited from this reference.
These stages lead me to consider the process of speaking to an audience that speaks a different language.
Source
I was in Brazil for a week teaching at a small church. Brazilians speak Portuguese; I do not. Like most countries except for the U.S.A., many of the young people spoke multiple languages, including English, because of the country’s education requirements. However, most of them did not have strong enough English language skills to listen to an American teaching a lesson. I was the source. I knew what I wanted to teach, so now I had to get the message encoded for my audience.
The Source for DevOps messages should be a plethora of people: leaders, engineers, architects, and more. As a new cultural model is being introduced, an effective way to manage the change is to build a group of people that support, or even better evangelize, for the change. Having groups of people “sold out” for the change provides numerous pathways of communication. For example, a peer engineer can encourage other people during an informal lunch chat by just mentioning a project currently in flight.
While leaders can influence change, respected peers tend to get buy-in quicker and faster. People tend to listen with caution – skepticism of new quick-fix program – when leaders speak, but listen with excitement when trusted peers (and leaders) talk about cool new things they are doing at work. Having a core team communicating formally, and informally, the same primary message provides expanded coverage and deeper saturation across the organization. Change has to start in first gear – get the group moving in the right direction, provide a little more gas, change gears, and soon inertia should help advance the cultural change.
Encoding
As I’m sure you have already deduced, an interpreter was needed to encode the message. Working with an interpreter is a bit tricky. You have to get into a rhythm where your output is not too small – too many switches between you and your interpreter – and not too long, such that the interpreter may not be able to remember everything you said. So, pausing is critical to working with an interpreter. Encoding, in this case, was English to Portuguese at a cadence that suited myself, the interpreter, and the audience.
Encoding is more broadly about preparing the message for decoding. Again, the audience must be understood for the message to be successfully received. Who are the people you are communicating with? How can your message be encoded to help them understand clearly? For different audiences, a different encoding may be needed.
In DevOps, speaking to programmers is different than speaking with business leaders, different from even other technical team members. Therefore, leaders, engineers and everyone cultivating a new crop of DevOps evangelists, enthusiasts, and enablers must encode the same message specifically for each audience. Get advice from people you trust to review your message and to ask the relevant questions, the first simply being, “Will this audience understand and benefit from the message?” And, since we have heard, and probably have repeated ourselves, the phrase, “I know that was a lot of information – like drinking from a fire hose.” If that is something we have to say because we know we just delivered way too much information for anyone to digest, should we ever do that again? Crawl, walk, run. Increase the cadence and volume of information over time to allow the foundation idea to set like concrete, then continue the building process.
Channel
Too many people build slide decks only to read the deck verbatim to their audience. Other options include podcasts, blogs, TikTok, YouTube or the old fashioned letter or postcard. A message needs to be delivered based on the audience need, not for your ease in transmission. Say the mantra, “Everything is about the receiver, not me.”
Private or sensitive information sharing requires discreet channels. A message that could be misinterpreted deserves more than a short message service transmission. Trust me, that one bit my backside just this week. Ouch!
Decoding
Decoding in the interpreter story was simply the audience, through the translator, talking with me before and after the lesson. Listening intently was key to my understanding of what the person spoke.
Decoding in general is the audience listening actively to the message. You are not responsible for the people who don’t pay attention; that is their failure. You are responsible for those audience members who listened, bounced the ideas around in their noggins, and maybe even asked questions for better understanding and clarity. Hopefully, those individuals will provide feedback, which is discussed soon.
Receiver
The audience was the receiver of my lesson. Before delivering my lesson, much preparation was put into deciding what to teach in the given time, which topic would prove relevant and provide a way to make the lesson applicable to each of their lives. If the audience did not understand my message, did not have a way to expand their thoughts on the subject, or were not changed in some way by my message, I failed. Don’t expect change from every person in the audience, but do expect your message to grow, inspire, or help many people learn, change, or solve a problem in their lives. And, don’t be surprised if you are changed even more. Being a teacher is a great way to learn, sometimes in a very humbling way.
Fortunately, members of the team had experience working with the staff at the church in Brazil. By asking questions, I understood the people, culture, and expressed concerns of the church members. That was at least a starting point from which I could begin preparing my message.
DevOps messages require similar diligence. “Who is the audience?” and similar questions are just a starting point. What if the audience included full-time employees and contract employees? What if many attendees do not speak the language you will be speaking as their first language. Note: Rip out the “slang” from your message right now. Science shows that some people are audio learners, visual learners, kinetic learners, or a combination. Therefore, include those elements. Drill sergeants yell (audio) at you while making you do pushups (kinetic) to be followed by more yelling directly in your face (visual) until they feel you have understood the message! Encoding and decoding was never a problem in those situations.
Feedback
After teaching the lesson, people shared what they liked, didn’t like, shared personal lessons and other comments, and asked questions. For me, it was a learning opportunity about what parts of the message rang clearly and which words were just noise to the ears of the audience. Feedback is needed for improvement, but be sure to accept feedback only from people in your corner; there are too many anonymous cowards on the Internet that will try to make you feel like a failure; don’t let them get into your head.
When communicating a DevOps message, ask for feedback. Be open to criticism – positive and negative – but don’t take the negative feedback personally. Rather embrace it as an opportunity to learn and improve. Have you ever noticed that no one has to ever say “Don’t take the positive criticism (compliments, flattery) personally? Tweak your message by incorporating the value-added feedback so that the next delivery is iteratively better. Over time, your message will become clearer, easily digested, quickly understood, and resonating for more people.
Context
Context is king! That is something I say several times a week in many different conversations. If you visit a grade school to talk about being a programmer, for instance, that is a good thing. Talking to middle school ages kids like they are in the work cube next to you, is a bad thing. Remember what Einstein said. In this case, the kids are a bit older, but the rule still applies. Conversely, if you are a guest lecturer at the local college or maybe recording an online lesson as a side hustle, be ready to talk the talk and walk the walk in programming. This audience is likely very excited to hear from someone in the “real world” actually getting paid to do what they are currently learning. They really want to know that their investments in time and money learning programming is going to help them live the life they hope to live. Again, context is king.
Summary
In summary, “Everything is about the receiver, not me.” Work to improve daily. Understand that simpler is easier to understand, so use plain English except where specifically needed. Be persistent, allow time for digestion, and adjust the message, then repeat.
If you liked this article, you might also like Recruiting DBAs for DevOps
The post How to improve DevOps communication clarity appeared first on Simple Talk.
from Simple Talk https://ift.tt/3uDtOoY
via
No comments:
Post a Comment