In his post “DevOps developers; don´t be a DevGoof” on devops.com 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!