How do we bring newbies into the DevOps community? Until they know the melody, they can’t appreciate the song.
While leading a DevOps event, the speaker polled the audience about their knowledge of DevOps. All of the attendees were well acquainted and actively engaged. It was obvious there were no newbies in the room. It made me wonder if we were yelling into an echo chamber filled with people who were already on board. Where were the newbies?
My concerns that day reminded me of a 1990 Stanford University study led by graduate student Elizabeth Newton. She assigned groups of two people to play a communications game. The first person picked a simple song that everyone would know (like Happy Birthday), and tapped the rhythm of the song on the table. The second person was the listener and tried to guess the song. On average, the tappers anticipated a 50 percent success rate. In reality, the listeners only guessed the song correctly 3 out of 120 attempts (2.5%). [Source: Health & Health, 2007 pp. 19-20]
That happened because the tappers already had the multidimensional melody playing in their heads. Conversely the listener was unaware of the melody in the tappers’ head and was limited to the one-dimensional tapping patterns. When tapping was the only means of communicating the song, the listeners almost always failed to guess the song title.
What’s the Point?
As DevOps enthusiasts we have experience and expertise — we know the melody. We have pre-existing knowledge and confidence that this new model works. Many of us have years of experience, experimentation and a network of insightful supporters to advance our learning. We know the DevOps founding stories and have read a myriad of blogs, articles and books. We have listened to the webinars and podcast cafes.
As the DevOps message tappers, we hear the melody of innovation and progress. And, in our minds, we assume we are communicating our DevOps stories with clarity. We point to effective projects, tools and teams, and create new models and terminology, expecting everyone in the IT community, or those still working in more traditional silo-ed organizations, to comprehend our activities. The listeners, however, may not have the same experience, confidence or base of knowledge. This is especially true of IT teams in enterprise organizations. Many of them have never read the books or heard the compelling stories. They have achieved success and grown their careers with Waterfall, in silos, with hand-off challenges and with technologies from past generations. Maybe they have never even played with Open Source technologies, worked with an open community, or explored the benefits of Agile methodologies. Thus, when many DevOps enthusiasts speak, their message is not understood by traditional IT professionals or those still working in silo-ed organizations.
Break through the IT barriers and silo-ed structures!
Breaking through to traditional IT professionals and silo-ed enterprise contributors begins with making the assumption that some may not have sufficient knowledge or experience in this area. This does not mean enthusiasm in DevOps presentations and conversations have to be toned down. Rather, it means they need to begin at the shallow end with stories and then move listeners to the deep end with more technical and detailed information (e.g., new ways to systematically reintroduce lean, agile, continuous integration, continuous delivery, continuous improvement models, etc.). The best way to accomplish this goal is to think specifically about traditional IT professionals and their specialty niches. When making presentations or engaging with them, consider their view, context, roles, work silos, and lack of opportunity to see their contributions make a difference. Then endeavor to inspire them to increase their knowledge base and expand their network by exploring collaboration opportunities internally with co-workers and externally with other groups.
Some presenters and team leaders find it effective to begin their group sessions and new conversations with stories from their initial exploration or foray into DevOps. Others employ familiar IT language, ideals, expectations and activities before transitioning into a DevOps melody. This will serve to expand the community to those who are well entrenched in older models (e.g., traditional Waterfall-based organizations, etc.).
Through greater understanding and deliberate behavior, much can be accomplished when legacy and DevOps groups collaborate: common goals are often more rapidly reached; polarization between old and new models avoided; and DevOps practices expanded across a wider IT community. Externally, this would ensure a wider community of support for DevOps and an ongoing flow of cross discipline collaboration and insights: and internally this can lead to faster innovations, improved corporate unity and accelerated success in the marketplace. Leaving new invitees outside of the DevOps conversation (intentionally or unintentionally) could hurt our DevOps efforts more than we might ever know. Without building in correlation or transition concepts between old and new, in everything we do, speakers and leaders could spend endless amounts of time and effort tapping “Happy Birthday,” but very few “newbies” would ever have a chance to recognize, support or see the value in our DevOps melody.
