devopsy.kinsta.cloud

Tag: Remote work

  • How to Build Creativity into Distributed DevOps Teams

    How to Build Creativity into Distributed DevOps Teams

    Today, more people than ever work remotely or are part of distributed teams. The DevOps world is no different. While working remotely has definite advantages, it also poses distinct challenges for teams trying to build strong internal cultures, coordinate product launches and hit shipping deadlines. It’s not enough to just slot in a communications app anymore. Teams need tools and processes that foment creativity and the frictionless sharing of ideas.

    Leaders know that the greatest ideas often come at the most unpredictable moments. With distributed teams, the risk of losing those great ideas in the shuffle dramatically increases. Given these realities, how can DevOps teams replicate the spontaneity and creative energy of an in-person brainstorming session when employees are located in different places around the world? 

    Get Personal

    It’s human nature to withdraw when feeling uncomfortable in a new group of people. Be it a party or work function, people will choose not to participate in conversation if it risks embarrassment among strangers. The same thing can happen due to the seemingly cliquish nature of certain distributed teams. If a new employee doesn’t know anyone personally, it is imperative to bring them into the fold and establish comfort as soon as possible. Then they’ll feel more confident sharing ideas.

    For extroverted people, this rarely poses a problem. However, introverted team members may not take so easily to unstructured casual conversation, and will need to be drawn in. This is where a bit of planning can go a long way.

    Leadership should start every team meeting with an icebreaker question that draws people out of their shells and reveals new aspects of their personalities. There is no need to get too intimate. These questions can be playful and funny. For example, asking people about their favorite hobby, restaurant or vacation destination is an easy way to kick start a conversation. Questions about long-term personal or professional goals—perhaps completing a marathon or learning to code in new languages—can also spark meaningful conversations or potential mentorships. The goal is not necessarily to force friendships (though that is not discouraged) but to make everyone comfortable interacting while knowing the company is a safe space for the expression of new thoughts, ideas and strategies. 

    Use Both Live and Asynchronous Video

    Modern DevOps relies on a high degree of automated processes. With modern pipelines that deploy code live several times a day, it becomes incredibly important to have a tight communication loop across the DevOps, Site Reliability Engineers (SREs) and development teams. In the unfortunate event that there are production issues, it becomes crucial to engage in meaningful conversations with team members and stakeholders while working on a terminal or actively fixing issues.

    Instant audio-visual collaboration plays a key role in creatively solving these types of problems. Text tools are clunky and slow. Plus, anyone late to the Slack channel then has to wade through piles of messages that further delay action. The ability to leverage synchronous and asynchronous workflows becomes indispensable when teams need the agility to communicate effectively. 

    With live video, details and nuances that are difficult to relay via text can be instantly shared without the worry of misinterpretation. Plus, talking is faster than typing, and allows for an easier back-and-forth when problems need to be solved quickly. Voice and video encourage free-flowing conversation. When a DevOps team spends less time thinking about how to communicate, they can better concentrate on how to solve a problem. 

    Because distributed DevOps teams often operate across different time zones, live video may not be practical if someone is asleep or enjoying life outside of normal working hours. This is where recorded video has special advantages. For example, recorded videos express context clearly and more effectively than sending an email when dealing with “show and tell” walk-throughs, bug reproductions, release audits, commentary on visual assets or user feedback. A lightweight video recorder can also aid in memorializing and documenting fast-changing deployment models, pipelines, scripts and configurations. These videos excel at capturing a thought in an instant, bringing energy and clarity to a conversation.

    Make Flexibility Fundamental

    With a DevOps team scattered across the world, standups and regular team meetings often take place during odd hours. Someone might be joining during morning coffee while another hops on after putting their kid to bed. Now think about how creative you feel in the morning versus the evening. If a scheduled check-in constantly fell during a time you felt mentally and physically drained, it would be hard to bring your A-game. Have you ever successfully brainstormed first thing in the morning, when hungry or right before bed? 

    Regularly switching the times of these check-ins is key. This way, leadership can show DevOps that it understands some hours of the day are just not as conducive to creativity and brainstorming as others. By accommodating employees through switching the call times weekly or monthly, leadership gives each team member the opportunity to shine. Plus, this approach gives people a fresh perspective to share unique ideas.

    Random, on-the-fly check-ins can also be a boon to remote developers. Hopping on the phone or a video call when hitting a snag can help quicken the solution process. After all, two (or more) heads are better than one. This can also relieve some of the pressure associated with sharing a new idea in front of the whole team during a formal meeting. Perhaps just bouncing a nebulous thought off of a trusted coworker is enough to bring that idea from half-baked to reality. This is certainly faster than a Slack message or email chain.

    The ability to encourage creativity with remote teams is only growing in importance as more and more people work offsite. Building a strong, open culture where team members know they can express themselves freely without fear of negative repercussions is paramount to successfully navigating these changing workplace environments. Hence, we strongly urge that modern DevOps concepts, new tools, strong releases and tight team coordination must jointly evolve to help establish a strong culture and bolster the importance of nurturing creativity in-house.

    — Badri Rajasekar

  • DevOps’ Cultural Myths and Logical Fallacies

    DevOps’ Cultural Myths and Logical Fallacies

    Remember that guy you knew in college who was working on his fifth or sixth degree with no plans to stop? At some point the idea of real work must have terrified him, and instead what appealed to him was a continual state of learning. If you have the funding to master five or six disciplines, and perhaps not the ambition to get going in any one of them, why not stay and explore the next one?

    But if you work in IT, chances are you did not stay in college for more than a few areas of study, and since you entered the work force, your future options dwindled down to two: become a specialist (deep thinking in a singular discipline, but not too broad) or become a generalist (broad thinking across multiple disciplines, not too deep in any one of them).

    Managers tend to start their careers as specialists who do so well they are promoted to manager, where their career shifts and they become generalists. From time to time they dabble in a particular area of study to speak the lingo, use the right buzz words and understand what is coming, but the role they play is inherently generalist, as they are forced to deal with a number of topics beyond the realm of any one particular area of study.

    We tend to associate the title “architect” as being the specialist who is deep in an area we are forced to contend with. Examples might include, “We need to hire a network architect, or a database architect, or a software architect …” the list continues. When we do this, we have certain expectations. We are looking for the “guru” who can solve our network problems or database problems or security problems—wherever the skill set was that caused us to hire this specialist. If our new employee cannot solve our problems, we begin the search for another who can solve them.

    But the candidate has expectations as well: The network guy may have a little knowledge about databases but does not expect to have to perform at the level of his peers in that discipline. If we hire a network guy and then ask him to do everything in every other discipline, we are the ones out of line and he will likely flee our employment in haste, calling us crazy on the way out.

    The Cultural ‘Frankenstein’

    To create a true master of the multiple disciplines that exist within IT would require creating a modern Frankenstein in networks, servers, operating systems, storage, database, middleware, software and mobility. And, of course, this list is not limited to one expression of each type, but indeed multiple expressions of each type. So for example, our database discipline likely includes deep expertise in Oracle, DB2, SQL Server, NoSQL, MySQL … you name it. If it is popular or relevant to our current stack, our Frankenstein must know that one.

    As DevOps has gained in popularity, we have conflated certain aspects of it and driven ourselves off the highway of logic. Too often, proponents have taken the concept of co-location from the agile beginnings of DevOps and applied it to the operational endings of DevOps. Taking down silos is mistakenly applied to co-locating IT operational staff. This conflation occurs billed as the panacea it once was to co-locating business staff, with the developers producing products for them. In the strictly agile context, this works well. Applying it to IT personnel on the back half of delivery is the least effective means of creating Frankensteins. Co-location is a good way to share ideas, from user back and forth to innovator. In general, sharing ideas between a network guy (with limited interests outside his discipline) and middleware guy (who could care less how the network is configured in detail) has limited success.

    These operational IT disciplines do interact, but only as they have need, which is significantly less than having to sit in the cube 4 feet away from a counterpart involved in a differing discipline. Co-location is not the cure for breaking down silos or increasing communication—common backbones are. Imagine the example of the medical profession: A hospital provides the common backbone for the neurosurgeon, the orthopedic surgeon and the heart surgeon. These disciplines are inherently separate, and if you have a particular illness, you are going to want the one who specializes in the thing you need done. While each doctor understands general health aspects, they specialize for a reason—a reason you want and need—when it is your time to seek help.

    The hospital provides the common facility, the common support staff, the common electronic systems and tools we use. Our medical records are stored in one place, no matter what type of treatment we seek, so each specialist has to enter them there and can read them there. But distinctions by practice remain. There is a special surgical floor for heart surgeries, where they do not conduct orthopedic work or neurosurgical work. The tools may be slightly different; the medical journals are. The training is different. The experience is different. And none of these skills transfer by osmosis of co-location if you put all three doctors in one central cubical cluster. It takes years to get where they are. The same is true of our IT specialists.

    If instead of co-location we looked more at common systems for moving, documenting and articulating change. If we gave limited access to our DevOps tooling to the specialists, confined to the niche they have expertise in, then instead of co-location we could have remote-work-concurrence. Experts from all over the country could work on the movement of change without ever physically seeing each other, but with full visibility into what is happening in real time through a common lens. Network operations center (NOC) personnel remain physically in the NOC, but can see the entire stack from that location and change only their portion as changes are required from there.

    It is the common backbone of DevOps systems that breaks down the silos of change transparency and change participation. Prior to DevOps we were all using different tools to move change and track change. With DevOps we can begin to articulate change and document it, in the same tool or interface. Meaningful access is granted only to the portions of tools and only where it is needed. Database guys have full access to that platform and nobody else does (other than to see it). The same model works for every other specialty. And before you know it, you have a concert—or rather a symphony of moving parts—instead of disjointed sounds no one can comprehend.

    Organizations that hold to the idea that staff will become Frankensteins, equipped with deep skills in all areas because they share cubicle clusters, would do better buying lotto tickets. Where the culture will require attention is in demonstrating to the impacted teams why participating in the common backbone approach has merit for each of them. For engineers who have never had to use “something different” before, this takes work, but is the real win.

    When complete, what has truly happened is a conversion to a culture of unity. The work of the genius is still protected in this method; in fact, it is amplified as now it is visible to the entire organization. So even the prima donnas should be happy with the approach. And the ability to orchestrate change never will have been so high, with so much real-time interaction, as after the embrace of a common backbone of DevOps systems. This should offer executives new insights into product creation and evolution. In this sense, the cultural changes reach from top to bottom of the organization, and they are achievable.

    To continue the conversation, feel free to contact me.