Communication (from Latin communicare, meaning “to share” or “to be in relation with”)

There are out there tons of articles and studies around DevOps ways of working, working frameworks, Agile Gurus, how to work in a team, shift left, no Silos, and so on, and so on… but, is hard to find any evidence about DevOps basics and the big pillar of DevOps transformation which is, in my opinion, Communication.

Usually one of the misconceptions I find a lot is the fact that people usually tend to focus on tools and automation, forgetting the Agile manifesto where it states Individuals and interactions over processes and tools, customer collaboration over contract negotiation. Forgetting that no amount of tools can be a substitute for good communication and empathy.

Isn’t DevOps a way to bring different Teams together? If so, how can you put a bunch of different people working together for the same objective or goal without Communication? Remember this: collaboration and Communication are strictly connected and dependent on each other.

DevOps is all about teamwork, all together and no Silos, but in order to achieve that we need to take into account that cultural background has a massive role on it and Communication is where sits the key or “secret” of making a difference for the success or (if that is the case) unsuccess of any team.

What my experience across the years and especially managing teams so dispersed on the planet has taught me is to level up the way I communicate to them. I am not talking about only words but gestures (even if virtual), we don’t only communicate through sounds or writing, there are many other ways of communicating and passing a message (Verbal and non-Verbal communication).

Be aware of the different cultural backgrounds and what it means for the different forms of communication, beware of the emotion around the moment and how it is affecting communication.

Invest time with your team, to learn a bit of their main language (in the case your main languages are different), discuss with them about their cultural roots and background and, along the process share yours as well. This exercise not only helped me but helped the team as well, it’s a boost to trust and Communication quality, which are pivotal when you aim for having a high performant team.

Another relevant misconception, or what I usually call a ‘classical pitfall’, is about how Teams must be able to communicate between them without a proxy/middleman! Yes, no me, no Scrum Master, no Project Manager, no Director, no CEO, no to any form of Middle Management. Unless they have the know-how for the solution they are not needed there, it will be just a waste of time for them and a waste of money for the company having them on a call monopolizing, controlling the flow of information, or even making the same a “political arena”.

Remember, tech people don’t need a middle man, they speak the same language between them and they have the delivery mindset on their DNA, they don’t need a monitor/moderator in their calls, all they need to do is to present a solution and people that are willing to contribute for the solution. They need more communication support than anything else, which means they need to communicate between them without interference from authority or other external factors.

Probably you are thinking what about when there is some friction between the teams? The classical confrontation that in human relations is often (too much for what we would like) present but by all means avoidable.

Always be the defuse element, never forget that a story always has two sides, and many times even more than two, which means when dealing with so many different teams in a proper DevOps environment, everyone needs to be heard, and the decision making is with the team union rather than one man choice without any support to that decision.

A message when conveyed less appropriately will definitely bring disunion, unneeded stress, and even sometimes it’s a call out for a toxic environment which is something that no one wants.

This doesn’t mean you need to be the Mr. Nice or the next winner of a sympathy contest. All you need is to agree sometimes that you just will disagree with different points of view without never losing empathy as at the end of the day your goal is a success like everyone else, I hope.

Many times when the discussion is more heated, or you are under stress and just received an email that pressed the “wrong” pressure button, rather than replying straight away it’s better to switch off and even sometimes to wait until the following morning before replying. Never but never reply with emotion, especially if the channel of choice is email. Always prefer “cold head” over emotions and then you will realize that actually you are part of the solution and not the problem. Contribute to defusing a potential conflict between several parts, avoid if possible endless and pointless threads of emails, which in the end are a complete waste of time (yours), resources (colleagues), and money (corporate).

Another classic pitfall, in my view, is the very long emails (even threads) usually with the wrong focus, who never had one (or several…) please raise your hand. Emails should be short, with a pragmatic approach when providing context, focus on a solution and not on the problem, the focus should always lay on Solutions or the search for the same and never about guilt.

My personal mantras for good communication:

• Transparency
• Always choose head over emotion when replying to anything
• On Virtual Meetings, give the example and always have your video on and invite (not impose) others to do the same
• On in-person meetings, close or keep away any electronic device and use just pen and paper
• Always listen to others, which means you allow everyone to finish their idea, don’t interrupt them
• In case of conflict, be the defuse agent don’t be aggressive, passive-aggressive, or even try to be a joker
• Being the one that is defusing, doesn’t mean you need to agree on something, you can always agree that you disagree
• Be pragmatic and solution-oriented when communicating with others – to point out problems or to play the blame game, anyone from any skills level or age group can do that
• Avoid “Ph.D. dissertation or thesis” for both verbal and non-verbal communication – “Working software over comprehensive documentation”
• Prefer Wiki and Instant messaging over emails

By any means I am not an authority around communication, these are my learnings through my past and continuous experience with DevOps Teams under my management and from my work career with DevOps Transformation. In my point of view, the reason behind so many DevOps / Agile Transformation failures is the lack of a culture of quality communication between teams and peers. If the communication flows freely, without any type of control or censorship, you will get a great foundation for a High Performant DevOps Team.

Good link to remember the Agile Manifesto (key values and principles behind the Agile philosophy): https://agilemanifesto.org

Written by Ricardo Moreira, DevOps Manager at Vodafone Business