devopsy.kinsta.cloud

Tag: communication

The complexity of communication: Are we all Masters of Disaster?
To better the communication between people in tech teams is one important issue in daily work. Although we all grew up with communication from our early childhood on, we know, that communication often fails. But what do we all do about this discrepancy? Why do we accept eyes wide open these frequently painful failures? Why don´t we really care about misunderstandings and their consequences? Are we all Masters of Disaster?

The answer is: Communication is a very complex topic on both sides of the game – on the sender´s side as well as on the receiver´s. To get aware of what is going wrong in our communication we have to do some very hard stuff: self-reflexion (which is indeed sometimes painful and hard to bear), changing familiar behaviors and leaving the comfort zone. This is really hard work besides all the tasks of our daily job! Additionally to a strong will, we need persistence, patience and most of the time aid from the outside to be successful in changing our communication! But in the end this entire struggle is worth it!

In DevOps teams, where “ship fast” is taken over from “ship faster” to fulfill the goals of “continuous of everything”, a well accepted and effective, but appreciating communication is the basic skill for success. This means that building a successful team is comparable with building a house: if you spend enough in a strong and solid fundament, it will carry the house you want to build on it for a long, long time. But you have to consider, which kind of house you want to build to develop the fundament.

In cross-functional teams with high demands – those teams we actually find in the tech industry – communication is the fundament of whatever is built on it. Communication is part of the culture and it is the tool
- people get in contact with each other
- knowledge is shared
- goals and visions are shared
- feedback is given
- failures and success are shared
- appreciation is shown.
People in such demanding environments need to trust and rely on each other. Or do you want to share your knowledge with someone you do not trust? The success of the team depends on the relationships between all teammates including the leader. Relationship and trust are built among other things through the way we communicate with each other. No it is time to say, that communication is not only what we are saying with the words we are using. Communication goes far beyond the meaning of the words. Remember “Cce” – Communication causes emotions! Even in the tech world, which is still a male dominated world, communication causes emotions and feelings – although lot of people may refuse this.

With speaking about the complexity of communication it means that there are on the one hand three different parts of sending a message and the impact on the receiver. On the other hand there are lots of possibilities how to interpret the messages. Lots of possibilities – this seem to be a source for many misunderstandings! Now be aware that an immense part of our communication – sending as well as receiving – happens in our subconscious!

Most probably you have heard about the three different parts of communication: the verbal communication and the nonverbal communication with its subitems ´paraverbal communicationand ´body language.

The verbal communication is about the wording, the language, the syntax, the grammar and yes, it is also about the logic! There you are: “Things have to be logical, then everything is fine, isn´t it?” Sorry, but: “No, it isn´t!” It is even not half of the truth. Here is the reason, why so called one-track specialists often have problems to convince others, although everything they say is absolutely right and logical. At this point the nonverbal communication appears on the human playing area! The paraverbal part of communication contains facts like the volume, the speech rate and melody, the intonation and articulation and at least the tone of the voice. This is completed by the body language with the fascial expressions the gestures, the body posture, eye contact, body chemistry and the clothing. If the expression of all three components is the same – then everything is fine! If the verbal communication says “YES” and the nonverbal communication “NO” – then people tend to believe in the nonverbal communication because its impact is much higher than the impact of the words.

Just one example at the end: at one of the DevOpsDays I have joined this year, I saw one young speaker. I guess, he is really an expert in his topic and the idea and content of his talk was excellent. But he didn´t manage to appear convincing and convinced: a wrinkled shirt, a loose jeans, unkempt hair, barefoot in his sandals, a lousy body posture and a bored facial expression. You can say that this is a superficial point of view. Maybe – but that is the way it works! Communication always needs a holistic approach – and seemingly superficial points of view are influencing the our feelings and the way we interpret messages! Or to say it the other way round: if you want to convince somebody and make her/him trust you, you have to focus on all parts of communication! It is the same when you want

to share knowledge, give feedback or want to lead a team. Communication is more than just the words!

In the next blog post you will read about the chain of communication!
October 22, 2015
How DevOps could save the world; like your colleagues’ day
DevOps is about a few things but above all, it’s about communication and understanding each other. In that spirit, I decided to create a new day to celebrate: “Like your colleagues’ day”. The rules are simple:

The first rule of like your colleagues’ day is: You do not talk about Fight…
- Each year, on the last Thursday before summer (Thursday the 18^th of June this year).
Thursdays are ideal days to make people happy since they’re right before the week-end but not totally there. Right before the summer as it’s all sunny and nice outside.
- Present a token of your affection to your dear colleagues. Remember, it is a token, not a romantic dinner for 2 in a 3 stars restaurant in Paris. It could be anything from a rose to a beer after work or anything that makes sense to you and the person who receives the gift.
- Since DevOps is all about loving each other, the day is called “colleagueS’ day”, meaning that you should make as many people happy as you can. A box of chocolates for a team is a good way to make many happy at once for example.
- Once again, DevOps is about love so you should also consider this day as a good opportunity to bury the hatchet. If you have notoriously grumpy colleagues, maybe all they need is some consideration. A smile, an uninterested chat (meaning you actually listen to what’s being said and do not expect anything in return) and maybe a sweet or a coffee are excellent ways to make people around you happy.
- Even better, try to make someone you do not know happy. After all, people you have not talked to yet might be full of surprises, right?
- Money is not the point. For once, you can bake a cake, you can offer to get coffee for your colleagues, you can listen to them and maybe even share a bit too, after all discussions are better with two or more persons.
Actions have consequences.

It’s quite simple really, once you’ve introduced your colleagues to the concept (beforehand for better results) and the day has happened, take a step back and draw your own conclusions.

The first few times I have tried this, only a few persons followed but as the actions were not focused on one person only, others got to enjoy the day and joined in in later editions. The results were above expectations, people got to talk about food, cakes and pretty much everything that can be said during mingling. Where I really saw a good DevOps potential in this is when people from different teams started to play the game and started to communicate together. Some went for beers after work and got to know each other, making things smoother and easier at work afterwards.

LYCID is also a good opportunity to have activities. While you can think of a management breakfast, it’s not too hard to imagine a technological lunch where everyone is invited or a wine/beer lottery in which everyone can play. As long as the normal work time is respected, everyone should be happy.

Don’t stop me now, I’m having such a good time.

Well, you get the point by now, make your colleagues happy and try to create a better work atmosphere by being nice to each other. But that should also open your mind a bit and maybe you could apply a layer of niceness to the world around you. Let people out before going in the subway, hold the door to the person behind you, try to smile when you think the moment is right (you have to figure that out for yourself) and why not, give your change to the first person in need you see.

This can sound naïve, maybe borderline stupid but imagine a world in which people were nice to each other, no matter the social class, gender, religion… If we were a bit more tolerant, a touch nicer to everyone and a tad less self-centered, this world could actually be really pleasant to leave in.

Add a pinch of DevOps in that and what do you get?

Repeat the operation as many times as you want, being nice never killed anyone. Make it a part of your personal and professional culture to be nice, available and polite. Through an iterative process, determine when you can smile without looking like Forest Gump and after a while it will be automatic, you will naturally become good and this will feel nice, trust me. Check the impact of what you did on your colleagues, measure their happiness and if you think things did not change enough, don’t wait until next year, be spontaneous and repeat the operation. After all, baking a cake and getting the coffee for your team should not take too much time or efforts, should it?

If you feel this could do a difference, spread the word, DevOps is about communication and sharing. Feel free to improve the rules, feel free to ignore some, in the end, all I want is to make you happy.

I’ve said this before during a conference but as we talk about unicorns, rainbows and other nice things when we mention DevOps, why not dream that we could also make a little difference in the world surrounding us. A little is better than nothing. DevOps could save the world!
June 4, 2015
Moving from Infrastructure Automation to True DevOps

Deciding on two separate teams, or an integrated end-to-end team

While a lot has been said about “the right way” to do DevOps, what we’re seeing in practice are two different approaches being tried to enable development and operations to work together as a team. On the one hand, there’s the approach to create an end-to-end, integrated development team, which you might call ‘Devops’. On the other, there’s ‘DevOps’, featuring two development teams – one working on application code, with another developing a platform using Infrastructure as Code techniques in a virtualized environment.

DevOps: providing a platform

Perhaps the most obvious way to go is to have a platform team to provide a runtime environment that “just works”, and a separate application team that develops the business logic to run on the platform.

For some organizations, particularly where one of the teams is outsourced, this separation is going to make more sense. You might buy an off-the-shelf product, build your own platform in-house (which seems to be what many organizations are looking to do with Docker right now – warning: it’s harder than it looks!) … or sign up with a PaaS vendor.

Whatever the situation, the platform should be versioned, just like any other piece of software.

This approach can be ideal for developers because they are free to work on code and focus on the business logic, and they really don’t need to worry about how it runs in production. It’s up to the operations team to make sure that the platform is stable and that it delivers what the developers need.

Communication is still key

Even with a physical or organizational separation, the importance of effective dialogue between the two teams cannot be overstated. This won’t work if the relationship is adversarial. There has to be a genuine awareness of common goals. If the operations team doesn’t understand where the development team is going, and what they need from the platform, then there’s going to be trouble. The idea that one platform is going to cater for every development need is often unrealistic, so versioning and the ability to run multiple platform versions side-by-side, or cater for exceptional situations where a particular application might need its own stack, is very important.

There has to be a clearly defined boundary, which should be close to the application code and configuration layer. The application handles the business logic, the platform handles the deployment, logging, monitoring, failover and auto-scaling.

The development team can focus on getting those new features and improvements into the live product, while operations handles the actual roll-out and manages traffic. For this to work, the platform must enable you to quickly determine who is responsible for any problem that crops up. It’s worth investing time in the setup to ensure that errors are explicit, so you don’t waste time tracking them down.

Arguments between the two teams are bad for progress and morale.

Devops: A full stack development team

For some businesses, it’s going to make more sense to put together integrated development teams that work directly on delivering the full stack from a shared code base, from virtual machine to application code. This allows you to design and optimize each system in a way that takes the application’s specific perspective and requirement into account, and can be an especially good fit if your applications differ from each other greatly in terms of the operating systems, middleware, etc., that they run on.

This approach can only work if the overall group is small (Amazon’s “two pizza” teams are a good example) and has sufficient knowledge and experience to see the big picture of the entire system.

It’s not possible for everyone to understand every part of the full stack in detail, but there are areas of overlap where greater collaboration will increase the level of shared knowledge and allow the team to build a better overall system.

Pulling together

The shared foundation of the Devops approach builds mutual respect and enables more free-flowing communication, but it must be based on shared goals and a vision of what the overall purpose of the system is. This integrated approach can give you much more flexibility, but it also means holding the whole team responsible for keeping everything running. Shared code equals shared responsibility.

The right approach

You need to take a baseline, and then put metrics in place to track your progress. You have clear goals in mind and a system to measure them. So how do you find the right approach to achieve those goals?

It would be wrong to say that one approach is better than the other. What you need to do is assess what will work in your organization. Both are means to achieving similar goals, but finding the right approach is about understanding what your company is looking to achieve. You might choose common goals, like reduced expenditure, or reduced error, or you might choose something more specific to your industry. Establish your goals at the outset, and make sure that they’re measurable.

The right approach is going to be the one that gets results for you — that’s why setting up a baseline and metrics is so important. You may find that a hybrid of the two approaches is going to be the right fit, but you aren’t going to know for sure until you have some hard data to back up your expectations.

Be sure to join devopsy.kinsta.cloud editor-in-chief Alan Shimel on Thursday, May 21^st as he hosts the webinar, “Ship Faster without Breaking Everything” to further your smarts on Continuous Delivery.

About the Author/Andrew Phillips

Andrew Phillips heads up product management at XebiaLabs, a provider of continuous delivery automation. Andrew is an evangelist and thought leader in the DevOps, Cloud and Continuous Delivery space. He sits on the management team and drives product direction, positioning and planning.

May 14, 2015
Communication: Who is to blame for misunderstandings?

Communication is everywhere and it is far more than only the spoken word and its origin meaning. Communication is one of the most complex and also complicated topics in human relationships: most of the time very thrilling, sometimes frightening but always important!

As we all grew up with communication, you might think, we should be used to communicating very well. But daily life shows us that misunderstanding is the companion of communication. We all know from our own experience how hard it is to clear up such misunderstandings and how much precious time is wasted on them!

The more people with different personalities are trying to communicate with each other, the higher the probability of misunderstandings.

To take a closer look at all those cross-functional teams like devops or agile scrum teams you will recognize at once that there are lots of individual issues because of misunderstandings in every team. Each single issue on its own is disrupting daily work, something we all know from personal experience. Now try to imagine how much of a team´s efficiency is taken away by the sum of all issues caused by bad communication and misunderstandings! It is unimaginable!

Communication is the link between all stakeholders: it determines the atmosphere in a team, the relationship between all parts, the understanding as well as the knowledge and information transfer. It influences the project times, the employees´ identification with the company or their work, individual responsibility and how to deal with mistakes. This list could go on and on.

Time in IT projects is one of the limiting factors. To save time and avoid mistakes, new tools are be developed again and again. Companies invest money in these tools; sometimes tools are integrated in the teams, sometimes the teams are arranged around the tools or systems. But the very human part – the communication – which is important for every team, no matter which tools or which systems are used, is seldom the focus of IT education! You can changes methodologies, systems and tools, but if you do not get beyond bad communication, you won´t reach the full potentials of all those efforts. No matter if you have already chosen your tools or systems or if you are still searching for the right way for your team, you should always think about the communication within your team. Instead of always asking what the ROI of communication courses will be, you should better ask what the ROI of all those tools and systems could be with optimized communication!

Before optimizing the communication you first have to find the bugs in the individual and in the team communication and eliminate them. Due to the inherent complexity, the support of an expert is sometimes useful. Just as not all people using computers are IT experts, not all people are experts in communication – even though they are communicating the whole time, sometimes even by saying nothing. Some are more gifted than others, some are able to learn by studying on their own and others need a little more time and support. Changing communication mostly means to change personal habits and this is always an extremely challenging requirement. Particularly for “brain-workers” like developers or other people from IT, it is very helpful to have some background information in combination with practical applications given by experts. First little steps of debugging the communication will soon be honored by success.

“First do it right, than do it fast!”, is a developers wisdom. Concerning the communication this wisdom could be changed into: “First debug your communication, then optimize it!”

Coming back to the question in the headline, it is not important to blame anybody for a bad communication. Everybody is responsible for it and instead of searching for the guilty one, you should start working on it. Be brave, start debugging you communication!

May 12, 2015
Social Skills for DevOps: Whose responsibility?

In his post “DevOps developers; don´t be a DevGoof” on devopsy.kinsta.cloud Parker Yates pointed out, that developers have to become more social. Devs should better realize that they need to become a normal part of the business social structure. That is really true and extremely necessary to make DevOps more efficient.

But is this the whole truth? And who is responsible for the social structures and the relationships?

First let´s have a look at the devs. For me as a consultant working with people from IT I always get the impression that developers are creating a cult in being a “nerd”. They use being “nerds” as an excuse for not being compatible with the “others”! To be honest, this is a very cheap way of remaining within their own comfort zones! But perhaps we should take some time to ask for the “why?”! Developers are human beings, too. As is the case for all human beings, there is always a reason, why someone acts and behaves the way they do! So what could the “why?” be? Often experiences in our past are the reasons for our behavior and our actions. But perhaps it is a little bit different with the devs. Most of the devs start sitting in front of PC´s and producing code mostly at the age of puberty, at a time when their own personality is being shaped. This time in front of PC´s is not used to improve their own social skills and interaction with other people. So why do they sit in front of the PC at that age? This could be simply because they are really thrilled by the tech stuff or because they like to deal with PC´s much more than interacting with other kids, perhaps because of experience. Additionally, along with the possibility that they do not like to interact with others they also have a lack of time in practicing social skills and communication. But this lack will have the effect that when “contact happens” the result could be disappointing on both sides. And for the later developers a formative experience is made. All that stuff about being the only smart person in the room could be some kind of self-protective mechanism for not being responsible!

And now, what about the “others”? They call themselves “the experts in social skills” in comparison with the “nerds”. One very important part of social skills is empathy. But empathy doesn´t mean to blame other people for a bad relationship. Rather, it means to change the point of view for a better understanding! To point a finger at the developers and make jokes about them is not the way, somebody with good social skills will act! The reason for their ways of acting and behaving would also lay in experiences and preferences. A relationship always depends on both parts!

When people choose their profession they look for jobs, which fit with their interests and personalities. And with bringing different professions together, different types of personalities are brought together, so of course there could be a gap between them. And this gap often is filled up with stereotypical thinking leading to prejudices!

One important requirement to bridge this gap is, that all parts are made to feel responsible for building up that bridge. The attitude of “I am okay – you are okay” is the only useful way! It is a process of a personal change, which has to start!

When I once started my work on IT and DevOps I was awestruck that all people were talking about tools, but nearly no one was speaking about how to train people to improve communication and social skills! When someone has a backlog in such important personal spaces, how can we expect more of this person without giving support? And why do we expect that a team full of different personalities will grow together and will reach its full potential that easily without any support from an expert?

I have made the observation that developers especially are very interested in ways they can improve their social and communication skills and would really enjoy it if their companies would offer them, for example, workshops or team supervisions.

All parts of stakeholders are responsible for their success; and in particular the company which wants to run DevOps! So do not always think about technical tools; think of the human contribution!

May 5, 2015