staging-devopsy.kinsta.cloud

Tag: communication

  • How to Avoid Crappy Culture and Keep Engineers Happy

    How to Avoid Crappy Culture and Keep Engineers Happy

    Software engineers know how much they are worth—everyone wants them and there aren’t enough of them to fill that demand. While the need for tech talent is greater than ever, the pandemic has shifted priorities for many engineers. And they’re not alone. It’s a reality shared with millions of others in a variety of fields around the world.

    If the so-called Great Resignation has taught us anything, it’s that everyone is tired of crappy workplace culture. People are beginning to question why they’d stick around at a place where they don’t feel valued and supported. And for those companies not investing time and energy into their culture, good luck holding on to software engineers. They know their value!

    In this uber-competitive environment, the best way to keep software engineers happy and make the company a desirable place to join may seem counterintuitive, but hear me out: Just back off. Trust engineers to do their jobs well.

    Put in place the building blocks for a supportive environment where people feel comfortable taking risks and voicing their ideas—even contradictory ones—in positive ways. Then, get out of the way. Leaders have a responsibility to make these values stick and to hire people who fit them, even if that means not always picking the most qualified person available.

    Don’t Be Afraid of “Dumb Ideas”

    I’ll be the first to say it—I have a lot of dumb ideas. I’m thankful to have worked in places that encouraged me to share those ideas. It taught me to focus on building a company culture that values openness to new thought processes. Because you never know when something that might seem like a dumb idea could actually become the next big thing. 

    No one wants to feel shamed for speaking their mind. Encouraging people to share their ideas, even those that aren’t fully developed, fosters a sense of trust in the team and can lead to greater creativity and innovation. It also makes the company stronger by reducing stress on employees and avoiding negative outcomes like burnout and other health concerns that may ultimately lead to turnover.

    Getting to this point of psychological safety in the workplace is not an easy process. It has to be highly intentional given the standards that are often at play in the professional world. For too long, people have been thought of as replaceable cogs in an organizational structure, not as humans with unique and valuable skills, talent and shortcomings.

    It’s about recognizing that people are human and often want to feel authentic in how they work. That’s why it’s valuable to talk about new ideas to improve the company and its products, as well as talking about how you talk; set a defined standard for how important topics are discussed as a team. 

    Fostering a supportive culture doesn’t mean there aren’t disagreements. But there are ways to offer contrary opinions without being a jerk about it. This mutual respect between engineers allows people to look at things with a critical eye without hurting anyone’s feelings.

    At CodeSee, we do a weekly product review. And this often leads to statements like “the product does this, but I wish it did this.” This isn’t a criticism of anyone, and everyone knows that. It’s everyone helping each other in the pursuit of making things better.

    Don’t Hire Assholes

    Instilling these values in a company is a rewarding experience that allows engineers to flourish. But none of that matters if they don’t also show up in the hiring process. The same things we place importance on in our day-to-day operations are top priorities in hiring: Humility, trust and self-reflection.

    We’d rather have a decent engineer that fits our culture and embodies these values than a great engineer that isn’t supportive of others. We don’t subscribe to the idea that it’s OK to treat people like dirt just because you’re a genius.

    These ethos show up in the questions asked to prospective employees. Two of our go-tos are fairly simple. We often ask interviewees to define three strengths and weaknesses. It’s a number that requires some real introspection and helps us see if a person knows where they could stand to improve and have identified personal growth strategies. We’ll also ask, “When we call previous managers, what will they have to say about you?”

    These questions are meant to tease out some self-reflection, naturally. If they can put themselves in the shoes of their past managers, that shows a high level of self-awareness and empathy.

    Surprisingly, these questions have gotten under the skin of more than a few applicants. I’ve actually had people yell at me, the person doing the interview, because they’ve been made to feel uncomfortable. Obviously, that kind of response told us everything we need to know.

    Tools for Success

    Institutional knowledge is an asset to any team. However, it puts additional strain on senior engineers, who are already stretched thin, to hold that information in their head and teach/explain it to less-experienced colleagues. 

    This is something that needs to change to free up senior engineers to focus more on the big picture. We can solve that with tools to visualize code and by investing in models that provide these models to engineers to improve training. 

    Today, many engineers spend 60% of their time reading code. What if we could reduce that to 40%? Or 20% or even 10%?  If all our engineering talent spent 40% of their time doing other stuff, think about where we could be?

    However, productivity tools can be a double-edged sword. Instead of giving more freedom and trust to software engineers, some companies are using technology to wring every last ounce of productivity out of the workforce, efforts that are surely doomed to fail by encouraging talented engineers to start planning their exit.

    The bottom line is that everyone needs engineers. Losing at least some is inevitable. But if you are thoughtful about creating a supportive, innovative culture—and maintaining it—then it’s a lot easier to compete.  

    But it’s no simple task. Every decision you make—from who you hire to the products you build to the way you talk to each other in meetings—plays a role in shaping culture. Engineers will be compensated everywhere they go, so the best chance to get ahead is to build the best, least-crappy culture possible. 

  • Reducing Friction in Developer Collaboration

    Reducing Friction in Developer Collaboration

    Given how the individual unit of deployment has gotten increasingly smaller, such that the unit of deployment is usually a microservice, it would be tempting to think that individual developers are more able to control how well the code they write (the service they deploy) will work in production. In fact, though, almost the opposite is true. Instead, as the number of services in an environment increases, whether or not one service will work correctly in a production environment has more to do with how well it works with other services rather than the quality of the code.

    This makes collaboration between developers even more critical than ever before, but the packaging of code in microservices actually makes collaboration more challenging. Developers don’t collaborate by working together on a shared codebase — instead they work completely independently on services that could easily be written in different languages, providing the illusion of complete independence.

    In most organizations, ensuring that services work together is a largely informal process. It’s managed by walking over to a colleague’s work station and asking what updates they’re working on or what version libraries they’re using. In a remote work environment, teams rely on Slack messages or Zoom calls to solve issues relating to services interaction. This creates a lot of friction for something that is a critical part of the software development workflow. Failures in service integration can and do cause problems in production.

    Pay Attention to Service Communications

    A perfectly crafted microservice is not going to run in isolation in the production environment. Compatibility issues between each service and upstream and downstream dependencies are just as likely to cause bugs, downtime and poor performance as problems with the code deployed in a container.

    The only way to catch compatibility issues before production is for developers to work together and communicate about the updates they’re working on and how those might impact interdependent services. In the current system, however, this level of collaboration introduces a lot of friction in the development workflow, reducing the individual’s and the team’s velocity. Since developers are generally evaluated based on velocity and code quality — but not necessarily on how well their services work with other services — if the friction remains, developers will be tempted to deploy without fully understanding how dependencies will be impacted.

    Since CI/CD pipelines are generally not set up to test how well services communicate with each other, problems with service fit that aren’t addressed at the development stage generally aren’t found until either a canary deployment goes wrong or there are problems in production.

    Replacing Tribal Knowledge

    One of the other reasons companies need to focus on developer collaboration is that remote work has made it even harder to communicate tribal knowledge. In my experience, no development team has been able to completely wean themselves off of tribal knowledge. Even teams with extensive technical documentation often had or have experienced team members who maintain a unique understanding of the application’s business logic and can share that knowledge when needed.

    Tribal knowledge also relates to service integration and communication — often, insights about how services work together isn’t well-documented, even if each individual service is well-documented. Often, the easiest way to see how they would work together is not to have the two developers responsible for each service work together, but rather to have a senior developer take a look. Especially as development teams work remotely, that type of review isn’t feasible.

    How to Help Developers Collaborate

    Most teams have ways for teams to communicate — they have a Slack setup, they have internal forums and video conferencing solutions. But they often don’t realize that these communication platforms aren’t really collaboration platforms — they are not providing a way for developers to actually work together on interdependent services the way they might if working on a shared codebase. Communication isn’t enough for true collaboration to happen — developers need a way to work together and see how colleagues’ changes impact their own services.

    Facilitating true collaboration, the kind you would get from two people looking at the same screen and coming up with solutions together, is more challenging than making it easier for developers to talk to each other. Without true collaboration, teams will continue to have trouble with communication between services — and there’s no Slack for that.

  • Should Conway’s Law Be Applied to DevSecOps?

    Should Conway’s Law Be Applied to DevSecOps?

    Strictly adhering to Conway’s Law could lead to less innovation and the inability to keep up in a fast-changing market

    When it comes to determining how an organization should be structured, the 1967 Conway’s Law provides a plausible direction that many software companies could follow. However, in today’s ever-changing cloud environment, it is arguable whether it can be used in DevSecOps companies, a quickly growing organization structure. While Conway’s Law is helpful to consider, it should only be used as a guideline and not strictly followed because it can lead to less innovation and the inability to keep up with the fast-changing market.

    What is Conway’s Law?

    Conway’s Law is a term that originated from engineer Melvin Conway’s 1967 thesis paper to Harvard Business Review. In his submission, he wrote that “any organization that designs a system (defined more broadly here than just information systems) will inevitably produce a design whose structure is a copy of the organization’s communication methods.” Based on his observations in the engineering world, he believed that the success of a software is based on the organization’s company structure and communication style. As a result of this paper, software companies began to emphasize collaboration and teamwork and implemented it into the company’s work culture.

    How Can Conway’s Law Apply to the DevSecOps Field?

    Conway’s Law has many valid points. The law emphasizes the importance of a company’s structure and the necessary balance of business and design to ensure a viable product, as the quality of a product “comes from within.” However, there is no right way to organize a company, and it should be structured in a way that makes the most sense for an evolving, cloud-based product.

    In the DevSecOps field, many solutions are run by enterprises that are cloud-based. This means that all the data and networks are stored in remote servers, making it easier for companies to constantly develop new technology and improve existing products. This new norm is redefining the way companies are structured today, and traditional standards cannot be followed. If a company strictly follows Conway’s Law, it will be difficult for them to innovate.

    Here are a couple of takeaways from Conway’s Law that can benefit DevSecOps companies:

    Small Teams With Equal Representation

    Conway’s Law explains that the bigger the team, the higher likelihood of miscommunication and tension, causing unproductivity. Many tech companies, such as Microsoft and Amazon, structure their employees in small teams (around 10-15 members) to oversee and specialize in a specific aspect in the company’s product, but aim to achieve the same business goal. This type of structure allows more leeway to experiment different ideas and quicker response time to fast-changing needs.

    Collaboration is Key

    Some argue that following Conway’s Law may decrease the company’s overall cooperation and lead to small team allegiance. While there is a fine line between small work groups and department cliques, collaboration needs to be a core concept embedded in the company’s organization.

    If the organization’s culture is based on companywide collaboration, it will solve these problems, as collaborative processes and platforms prevent cliques from forming and allow teams to be independent, creative and agile. For example, for security teams to successfully collaborate with DevOps teams, they need to intentionally create solutions that can be embedded with existing DevOps pipelines.

    Conclusion

    While Conway’s Law is an important social contribution to organization principles, it should only be used as a rough guideline because following it too closely can stymie innovation in a fast-changing cloud environment. Conway’s Law highlights the importance of company structure and implies that a successful organization is structured with small teams focusing on one sector of the company, and with consistent collaboration established throughout the company to systematize unification and togetherness.

    As organizations compete for the greatest slice of pie, it is critical for leaders to look inward and ensure internal structures and processes are setting their products up for success.

  • AWS Aligns With Slack to Foster Dev Team Collaboration

    AWS Aligns With Slack to Foster Dev Team Collaboration

    Amazon Web Services (AWS) and Slack Technologies have formed an alliance through which they are moving to transform the way development teams collaborate.

    Under the terms of the multi-year agreement, Slack will migrate voice and video calls to the Amazon Chime real-time communications service.

    In addition, AWS and Slack are integrating Amazon AppFlow integration with Slack, which enables data to be transferred securely between Slack and AWS services such as Amazon Simple Storage Service (Amazon S3) and Amazon Redshift. The two companies are also promising to make it possible to transfer data bi-directionally between multiple Slack channels and AWS services in a single flow.

    AWS and Slack have also integrated the AWS Key Management Service with Slack Enterprise Key Management (EKM) to distribute and control cryptographic keys. That capability builds on an instance of EKM for Slack’s Workflow Builder automation tool that was released last month.

    Finally, the two companies are committing to make the AWS Chatbot service accessible from directly within Slack.

    Slack, which already makes extensive use of the AWS cloud, has emerged as a de facto collaboration tool within many organizations that have embraced best DevOps practices. Eron Kelly, head of product marketing for AWS, said this alliance will make it easier for development teams to employ a wide range of communications tools at scale.

    Many DevOps teams already rely on Slack Calls to launch video and voice calls whenever a subject being discussed using text messages requires a deeper level of interaction. As reliance on Slack Calls increases, the software development kit (SDK) for the AWS Chime service that Slack will invoke will ensure the quality of the video and voice calls, said Kelly.

    In many ways, DevOps processes revolve around a mix of asynchronous and synchronous communications. The challenge has been to find a way to enable DevOps teams to use those tools in a way that enhances rather than detracts from productivity. Managing multiple Slack communications channels can easily become overwhelming, especially if developers are working on multiple projects at the same time.

    Ideally, DevOps teams will eventually become more adept at determining, for example, what messages, such as status updates, are best delivered asynchronously versus urgent requests that need to be made via a communications medium such as Slack.

    In the meantime, the COVID-19 pandemic has clearly increased reliance on communications services delivered via the cloud. With most members of DevOps teams working from home, tools such as Slack have become a virtual substitute for walking over to the next cube in an office to resolve an issue. Once development teams return to the office, it will be interesting to see to what degree tools such as Slack have become the default means of communication, even with fellow employees who may be only a few feet away. In fact, such tools may play a critical role in helping organizations adhere to social distancing policies even after employees return to the office.

    As philosopher Marshall McLuhan once observed, the medium is the message. Today, however, those messages increasingly are being delivered within a stream of real-time communications that is becoming more challenging to manage.

  • DevOps: The Ultimate Way to Break Down Silos

    DevOps: The Ultimate Way to Break Down Silos

     Let’s imagine Jim works on the development team for a food company and his colleague, Julie, works on the operations team. On a daily basis, Jim focuses on analyzing users’ needs, testing and developing software, while Judy manages IT infrastructure and policies.

    Although they share the responsibility of software deployments and application support, Judy and Jim rarely interact with each other. In other words, they operate in siloed functions that do not encourage teamwork.

    Many organizations recognize these silos. So, to enhance cross-team collaboration and reduce repetitive work, they are implementing the DevOps mindset. This methodology facilitates constant feedback and creates an environment where the building and testing of software occur simultaneously. But to successfully implement DevOps, business leaders first need to understand what a silo is, how it’s created and its impacts on employee morale.

    What is a Silo?

    Take development and operations teams as an example. Development and operations work with two distinct mindsets. Operations values stability, which can slow down software updates. On the other hand, development values speed and is encouraged to create, innovate and generate as much as possible.

    Silos develop when these departments are structured to work as separate entities with their own visions, goals and responsibilities. If development employees aren’t passing information about software bugs to the operations team, then workflow quickly becomes bottlenecked and productivity suffers.

    How Silos Impact Employee Morale

    The lack of information-sharing across teams takes a toll on employee morale and transparency, preventing development and operations teams from forming trust and mutual respect. Within silos, the development team might not report a software bug to operations out of fear of being reprimanded. Without an honest and open information sharing system, workflow is not only delayed, but the potential for misinformation increases.

    Silos create a structure in which departments focus on their own goals instead of working toward organizational objectives. Eventually, this mentality can lead to hostile relationships between departments, which negatively impacts efficiency and harms the bottom line.

    How DevOps Can Eliminate Silos

    Implementing DevOps is the natural first step when shifting employee attitudes from departmental focus to organizational goals. This way, employees don’t have to face the daunting task of completely eliminating all silos at once.

    By breaking down silos with DevOps, companies can avoid overspending on departments that may be resistant to change. Employers can create momentum for upcoming changes in other teams with the end goal of cultivating a collaborative mindset within every department of their organization.

    To facilitate this transition, organizations should assign a DevOps administrator to act as a mediator between departments. This administrator works to communicate and apply the DevOps methodology across teams while navigating cultural differences to facilitate cross-team collaboration. To successfully implement a DevOps mindset, the administrator should keep the following strategies in mind:

    • Direct teams toward common organizational goals. Team leaders should set specific goals that align with overall business needs. It’s crucial for leaders to point out how departmental goals directly support common objectives.
    • Design shared metrics. A consistent measurement tool holds everyone accountable and encourages stronger teamwork by enabling leaders to track progress and assign workloads accordingly. For instance, organizations can set up delivery cycle metrics for both development and operations teams to measure how much workflow speed increases for both teams while maintaining continuous delivery.
    • Organize regular meetings. Inviting team representatives to participate in recurring meetings creates an opportunity for everyone to give updates on project statuses.

    How DevOps Impacts Organizations 

    Today, IT is no longer an isolated function but an essential department within organizations. It’s important that future leaders invest in technology that drives business success while keeping its employees in mind. For example, enterprise, or employee, service management is popular among businesses for its ability to deliver automated insights and support. Many organizations are turning to a modern IT service management platform to bring their employees fast and quality service—two central qualities of the DevOps mindset.

    DevOps’ culture of continuous delivery helps shorten resolution time and encourages collaboration among development and operations teams. At first, businesses can struggle with continuous delivery due to siloed IT functions because these established support structures often come with lengthy and outdated processes that slow down delivery speed. However, a DevOps-focused culture supported by an IT service desk empowers developers and operators to deliver configuration changes and resolve issues at a faster pace.

    In today’s competitive environment, a silo mentality is a detriment to the innovation required for companies to stay ahead of the curve. Through effective management strategies, the integration of the DevOps mindset will eventually break down silos, increasing collaboration and productivity.

    — Michael Mazyar

  • Breaking Down Data Silos in Your Organization

    Breaking Down Data Silos in Your Organization

    Today’s organizations can finally use advanced technologies to unlock the true value of all of their data. This enables them to make better decisions, serve up better customer experiences, accelerate innovation and respond to crises faster—even preventing them from occurring in the first place.

    Even so, many organizations are unable to do this because their systems are too isolated from each other. Getting the most value out of your data starts with shattering data silos, or isolated “islands” of data that the majority of folks in your organization aren’t aware even exist.

    Created by the increasing use of multiple systems to store and analyze data, data silos are have become all too common in today’s organizations. Data silos create disjointed customer views that result in sub-par data analytics, which worsens the customer experience.

    Without the ability to access and analyze all of your data in a fluid manner, it becomes very difficult to deliver exemplary customer experiences and uncover what your customers truly want.

    Ridding the Data Silos

    Getting rid of data silos isn’t as hard as a lot of organizations think—in fact, there are many ways for organizations to break down data silos to make the most of their data. Here are the five best ways to break them down:

    Make it a Top Priority

    Data silos won’t get rid of themselves. If you want to eliminate data silos at your organization, make it a top priority. Develop a comprehensive plan as to how exactly you’ll get rid of them and make sure all involved employees are aware of your intentions. If necessary, put together a cross-functional team to oversee the consolidation process to ensure smoother sailing and quicker results.

    Encourage Communication and Collaboration

    Many data silos are created due to a lack of communication between teams in different departments. A marketing team, for example, might maintain a repository of content in a random Google Drive folder while sales might have a ton of assets stashed on Dropbox. Both groups might be unaware of where the other is storing their files.

    Get rid of data silos by encouraging your employees to communicate with one another regularly. It’s also important to embrace a company culture that celebrates collaboration. You’ll get better results, and the increased chatter will reduce the chances data silos go unnoticed.

    Simplify and Consolidate Tech Infrastructure

    The number of technologies requires by modern organizations to capture revenue these days is staggering. Many major organizations use more than five databases at once, with countless applications spread across them, forming an endless tangle of data silos.

    There’s an easy fix: Simplify and consolidate your tech infrastructure as much as you can. As a result, you don’t have to rely on several different databases to store, process and analyze all of your data—helping you avoid data silos.

    Avoid Costly Vendor Lock-in

    By 2020, 75 percent of organizations managing their data in a public cloud will be subject to vendor lock-in—making it costly and time-consuming to migrate data from one platform to another. Break down data silos—or avoid them in the first place—by using platforms that give you the ability to transfer this data easily.

    Develop New Processes and Procedures for Storing Data

    If your employees aren’t sure where to store data or what systems to use, can you really blame them for storing files in various locations and inadvertently creating data silos? Make sure your employees understand, very explicitly, how they are supposed to handle data and which platforms are approved. That way, you’ll reduce the chances data silos are created—while reducing or eliminating shadow IT.

    Data silos are common in businesses across all industries. The good news is that if your organization has data silos, all hope is not lost.

    By developing a plan on how to store data, encouraging employees to communicate with each other frequently and using the right tools, you can avoid data silos—making it that much easier to tap into the full power of your data.

    — Jonathan Lacefield

  • ‘Yehbut’: Communication in the Age of DevOps

    ‘Yehbut’: Communication in the Age of DevOps

    Effective communication is integral to success in DevOps transformations

    Ever since the dawning of mankind, or should I say “humankind,” we, as a species have invented ways to communicate with our fellow men and women and gender-neutral colleagues (and, soon to be included, robots). From grunting and bashing (bashing gets the message across quite effectively, albeit rather limited in scope) to cave paintings, symbol-based languages such as Cuniform and Hieroglyphics to modern complex languages that evolve across cultures.

    Fast forward a few thousand years …

    With the emergence of IT professionals as a species, we took a step back into the caves (data centers) and reinvented our own grunting and technobabble language to fit our own IT culture. Our cave wall images became PowerPoint slides, and we would “bash” users with SLAs. Symbols became replaced by acronyms: SLA, UPC, CI/CD, XML, and our modern languages became the language of the “framework” (e.g for the purpose of this article, DevOps). IT evolved and became embedded and entwined in every aspect of business and society, and we have been forced out of our caves and are now expected to “communicate” with these other alien cultures. Yet, our business colleagues feel we still cling to our technospeak to confuse them. (Read “Communication between IT and Non-It is a state of crises” – it was written in 2015 but business leaders I speak to still recognize this).

    Even within IT we have our own sub-tribe languages, spawned by the frameworks and practices we adopt. The framework becomes the “Word.” Framework fundamentalists and framework dogma rule, as we throw terms at each other “incident,” “problem,” “defect,” “release,” “deployment,” “User … pain in the neck.” Sometimes the framework and language becomes a brick in the invisible wall that divides us into IT silos.

    We defend our language as it becomes part of our identity and what binds us together. In fact even the framework name itself takes on a meaning and life of its own. When we say “ITIL,” some interpret this to mean “Bureaucratic set of control processes that stifle innovation.” When we say “DevOps,” some take this to mean “Cowboy developers trying to push lousy code on to us without any controls.” (More on this framework interpretation shortly, as it is central to my rambling).

    There seems to be one term that is common to all frameworks, something that binds us together. Finally something we can cling to and ALL understand. It is the word “Yehbut!” Whenever anybody from a different silo tries explaining something we say, “Yehbut” (“Yes, but,” meaning in fact “No, because”). In fact, to speed up the flow of communication (as speed and flow are now catchphrases in the age of Agile and DevOps, we even say “yehbut” before the person has finished speaking, thereby eliminating “waste” (wasteful words).

    We in IT do not need to hear everything to know what was going to be said or even the intention, we have our own “artificial intelligence” engine built in—it is called “assumption intellect (AI).” We apply “Assumicide”: assuming that we know what the other meant when communicating to us and assuming the other understood what we said. This is obviously a core IT capability, as we see it consistently applied in just about every team in our latest “Phoenix project” DevOps simulation. It would appear that we don’t listen to understand, we listen to give an answer. Shift left. Give an answer before the question has even been asked.

    It is the same with the word “DevOps.” People assume they know what it means and interpret the term in their own way. In our simulations we strongly urge BizDevOps, the importance of the role of the business. This receives criticism from experts; quite rightly from their perception, interpretation and intention, they declare that DevOps always included business, sec, QA and the rest of the stakeholders. However, that original intention has gone through the “assumption intellect” filter and has come out primarily as Dev and Ops when it comes to adoption, with the business somehow plugged in, on and somewhere in the middle—if we are lucky. Which is why we make it BizDevOpsBiz: to make it explicit. Mark Smalley has written a thought-provoking DASA whitepaper around this topic. Gene Kim, at a recent Executive Connections session, also stated that product owners also need to shift their mindset from “features” to “business outcomes.”

    There also seems to be a common “taboo word” that binds us all together across frameworks. It is a common agreement to avoid asking or answering the question “Why?”—”Why are we doing this framework?” The framework becomes the “goal” in itself. “We are going to implement DevOps, ITIL or any other framework.” We send the different silos onto framework training to learn the latest “terminology” so we can confuse other teams and departments who don’t follow the training.

    It seems that our motto is, “Ours not to reason why, ours but to do and die.” (Alfred Lord Tennyson)

    The Importance of Communication in DevOps

    Why am I ranting on about communication and words?

    Three reasons:

    1. Communication and collaboration seem to be critical enablers or barriers for DevOps success.
    2. The word “DevOps” seems to have taken on a meaning and life of its own, which is limiting the potential value.
    3. Communication issues are very costly (see this article from Forbes).

    I recently played a Phoenix Project DevOps business simulation with a group of senior leaders at the start of a DevOps transformation. These were their key takeaways. I decided to try and analyze their discoveries in terms of communication.

    • Answer the questions “What’s in it for me?” “What if we don’t?” – make this clear to all to ensure the “Why?” (are we adopting DevOps ways of working) is understood and felt. Remove the current FUD (fear, uncertainty and doubt) caused by the latest reorganization.
    • “We noticed in the simulation that poor communication leads to assumptions, assumptions in an environment of FUD are negative, and lead to poor decision making, lack of trust, resistance and lack of buy-in.”
    • We recognized the “yeahbut, yeahbut”! People were not seeking to understand and explore before answering. People were not confirming understanding or soliciting feedback and understanding. “We recognize that people listen to give an answer, not listen to understand.”
    • Coaching for teams in start-up phase. Not “telling teams what you expect and what to DO,” asking teams questions about “behavior” and “impact” (help them to learn to apply continual learning and improvement, to organize effective stand-ups, to apply active listening). Learning new behaviors and letting go of old ways of communicating and behaving requires practice and feedback.
    • Tell teams (including product owner) we support and commit to reserving WIP time for them to learn, create cross-functional teams and improve.
    • Applying “consequence” management—verbally recognizing, rewarding and reinforcing “desirable behaviors.” Directly communicating and giving feedback on “undesirable behaviors” and “falling back into old behaviors.”
    • Fostering open feedback on “undesirable behaviors,” asking questions about feedback and behaviors. (When nobody says something about it, it is implicitly accepted behavior).
    • Foster a culture of active listening, understanding. “Good ideas when not heard or acted upon are ‘waste’, and demotivating when not given recognition or heard.” Not recognizing and giving room to innovative ideas will stifle a culture of experimentation.
    • Have teams develop own visual management systems together with coaches, to aid insight into workloads and priorities, communication and decision making—The MT (Management teams) must communicate guidelines around priority (portfolio, strategic goals). The visual management board became the modern cave wall painting, a new language of post-its, tape and swim-lanes.
    • Start capturing and understanding WIP, WIP limits and constraints to flow. Start capturing and visualizing team pain points and improvements. This will aid communication, open discussion, decision-making and expectations.
    • Foster a culture of “measures to improve” (not measures to punish): measures to show behavior change, measures “DevOps” metrics (releases, time to release, quality of release), agree measures of “value” and “outcomes” with product owners, measure team skills and growth, measure impact of iterative “improvements” (see 8-field model).
    • Introduce FUBAR of the month with rewards for most impactful learning and improvement. (Remove fear and blame associated with failing). Talk about failures, impediments, constraints, waste. MT will start with own!
    • Revisit VSM (value stream mapping) training and make visible value streams with all stakeholders, Pin these up where they are visible to all, ask people to put “pain point” stickers on VSM (allows all to communicate continual learning and improvement needs, focusing on eliminating waste). This also helps recognize the “information” and “communication” flow through the value stream and foster dialogue.
    • Calling “Stop” is a very effective communication tool, if “respected.” Calling “Stop” to discuss and agree to eliminate “waste” and improve “flow” through the value stream.
    • Engage and involve end-to-end stakeholders in these simulation sessions to foster a dialogue, to practice effective communication, reduce assumptions, create buy-in and stop the “yeahbut, yeahbut” responses.

    Although DevOps success clearly relies up technology for the continuous integration, automated testing and continual delivery, it is underpinned by effective communication and collaboration. Communication is not just about terminology or language: Listening is probably more important than talking. It is also about demonstrated behaviors—walking the talk, leading by example. This is what ultimately creates trust. And trust is the foundation for effective collaboration.

    — Paul Wilkinson

  • 8 Reasons Why DevOps Needs Competent Writing Skills

    8 Reasons Why DevOps Needs Competent Writing Skills

    It’s a fact: DevOps practitioners need to have competent writing skills to help them in their career. It may seem a little antithetic—after all, software engineers and programmers are well-known to be the kind of people whose brains are wired toward math, not English. Written communication may not be an area of strength for people who spend their days looking at code; however, it could set someone on the path to success.

    Here are eight reasons that highlight exactly why DevOps practitioners should work on their writing skills to advance in your career.

    There Are Similarities Between Writing and Code

    This may not be immediately apparent, as most English students would pale at the thought of writing code and most computer science students would cringe at the thought of producing an essay. However, writing and coding are very similar in the sense that they both require a clear mind, have a set beginning, middle and end, and normally address a problem. Plus, as writing is essential in finding and landing a job, you can boost your skills by practicing writing for CVs, resumes or cover letters.

    Learn from Each Other

    Software engineering is becoming an increasingly collaborative area of study; however, for people to get involved with your project, they need to know what it is and understand it. Being able to write well helps people understand and follow simple instructions and communicate clearly on what they want to achieve or add to a project. If you’re unsure how to write a proposal, you can find great advice in the writing forums or from online editors and writers.

    Become a Proponent of Literate Programming

    Codes are fundamentally written for a computer; however, literate programming supporters state that it should be written for humans, too. The code can have a longer shelf life and be a lot clearer and high-functioning if the people who write it have the interests of a human at the other end in mind, and if the code has a purpose that can serve human needs.

    The Role of Writing is Increasing

    Programmers do have to work with others at times, and even programmers who work on individual projects have to communicate progress and setbacks to their employers, universities or the people who provide funding. If you want to be able to keep all of these people happy so you can carry on with your work, then you need to be able to write quality emails and progress reports. You can find plenty of email and written communications help by using online proofreading free tools on the web.

    Improve Your Professionalism and Reputation

    If you can sell and market yourself well, then you’ll be better-received within your own specific field and within the organization that you work for. Poor writing, littered with spelling and grammar mistakes that leads to miscommunications, just makes you look bad and can make people doubt your ability.

    Make Sure You’re In Line for Promotion

    Programming is a competitive field, even if many of the people who work in it work independently. This means you need to stand out from other programmers when you want the best projects to work on, and getting advice from a professionals is the best way to present your ideas and goals can go a long way.

    Show Your Authority

    A lot of people you work for will not understand code, so you’ll need to employ other means to convince them that you know what you’re talking about. This could include using sources and references to describe why you’ve taken certain courses of action.

    Develop Better Relationships

    It’s always good, and sometimes useful, to maintain good relationships with colleagues, so you can make sure you aren’t being too curt by checking your emails with word count tools, to make sure you’re engaging and approachable.

    Writing and DevOps may not seem to go together; however as the list above shows, they are actually compatible and both necessary for anyone to really succeed in the workplace.

    About the Author / Gloria Kopp

    Gloria Kopp is a digital marketer and an elearning consultant from Manville, Wyoming. She is a regular contributor to such websites as Engadget, Ukwritings and Huffington Post. Connect with her on LinkedIn.

     

  • How IT is More Like an ATV Than a Sedan

    How IT is More Like an ATV Than a Sedan

    There is an analogy for IT being like a car and it often goes something like this:

    IT should run like a well-oiled machine. I don’t get in my car and think about how it works, I just work some controls and it does what I need it to and it goes where I need it to go. No assembly required!”

    When people think IT, it seems they’re hoping for their IT department to work like a Tesla luxury sedan that drives for you. They like to think of IT in this “it should just work” kind of mentality. The internal dialogue of some may be, “I have this goal, IT is this tool to get it done, and I have paid for it! It should just work by itself! Heaven knows, I have spent enough on it!” They want something that’s comfortable, doesn’t require much interaction and gets them where they need to be.

    The problem with the sedan metaphor is that sedans are not really what companies need.

    Sedans are built for paved roads, made to go to places that others often go. The average sedan can’t really explore much else other than what is well-paved and well-traveled by others. They’re a comfortable ride for drivers who want all the amenities of the home wherever they are. Anything too far off of the beaten path and the car is being torn to pieces by the rough terrain. Sedans perform consistently and reliably in consistent and reliable environments.

    This is not to say that IT should not be reliable. By all means, IT has to be reliable. If IT isn’t operating reliably, much like a broken car it should either be fixed or replaced. Why would anyone pay for something that can’t perform the tasks you need it to do?

    However, organizations know they have to take calculated risks, and the larger the risk, the larger the payout. This means going into unfamiliar territory and going down paths that are not mapped out. Even a Tesla is going to struggle over terrain that isn’t already mapped out.

    On top of that, we know customers and technologies are constantly changing. There is very little consistency from the world outside of the enterprise. Every day brings new fluctuations and challenges that companies need to anticipate and adjust to.

    So why do we expect IT to behave in a consistent way when the environment around us is constantly shifting? We can’t act as though our business can succeed riding around in a comfortable sedan! We need something that can be flexible and can still move us forward.

    Think ATV, Not Sedan

    The ATV fits this kind of unpredictability perfectly. ATVs can adjust to a variety of terrain. They don’t need paved roads nor beaten paths. They can go almost anywhere and can get there quickly. These machines are rugged; they can adjust to a variety of terrain and, most importantly, they can go anywhere—if the driver knows what they’re doing.

    But ATVs are not comfortable. An ATV takes knowledge to drive and it takes engagement. One can’t sit back disengaged and hope to have a smooth ride on an ATV that is going full speed. The places these machines are made to go are not for the complacent or for those seeking comfort.

    The business-IT relationship should look more like an autocross driver and his ATV than a suit in a Lexus. In this analogy, both machine and driver are adjusting in unison to the environment around them. The driver (the business) guiding the ATV (IT)  where to go and pushing through hills, mud and dirt to make sure both arrive safely and quickly despite the dangerous and uncertain environment around them. At the end, the driver and his machine will have pioneered places many feared to tread and will be rewarded appropriately.

    To extend the analogy, this is not a problem only between business and IT; this is the same attitude Dev often takes with Ops. Dev says, “Here’s a build, your environments should be good enough,” and Ops is expected to just make it work. Isn’t this the same disconnect as the IT and the business?

    It is so important to collaborate in a large enterprise. It takes investment of not just money but also time. If we have an agile team with no product owner, we essentially have a car with no driver. If we have Devs who don’t talk Ops, don’t we have a car body with no engine?

    In today’s world of Agile and DevOps, the companies that build that bridges between Devs, Ops and the business are the ones who take the calculated risks and succeed. These companies win bigger market shares and know confidently what their customers need. They can experiment fast with different business ideas, use the latest and the greatest technology and not comprise on security. These same companies can leverage their IT function to accurately monitor spending while minimizing waste.

    When businesses interact with IT, they shouldn’t just toss something at them like an external vendor and expect quality. Collaboration and engagement is the key. When all the necessary members in an organization are talking, communicating and engaged with one another, then we begin to see the true power of IT.

    The power of IT is the ability to go over terrain that would destroy other organizations. It is the ability to set any vision and know that your people will have the tools to tackle whatever comes their way. It is the ability to adapt, change and continuously improve while watching organizational goals become reality.

    About the Author / Caleb Wolfe

    Caleb is an IT professional with a passion for DevOps and transforming the way IT organizations work. As a member of Delta Air Lines, Caleb has a variety of experience from working as a baggage handler, business analyst, software developer and as a technical analyst in IT transformation. Caleb uses his multidiscipline experience to identify and remove constraints, create effective throughput and work to break down barriers both internally and externally. Caleb is a perpetual student of process improvement and IT technology and uses his knowledge for the betterment of Delta’s employees and customers worldwide.