devopsy.kinsta.cloud

Tag: culture

DevOps Is Not a Role — It’s a Culture
The full-stack developer is becoming increasingly rare these days. Due to the accelerating complexity of modern software development, programmers often specialize in specific languages, frameworks or levels of the software stack, such as frontend or backend.

These same fractures seem to be occurring within DevOps, too. Nowadays, large companies no longer have one strain of DevOps—there are often many flavors of rapid deployment and various DevOps toolchains used across an organization’s development teams. DevOps now requires specific training in the nuances of each cloud service provider’s platforms, too, requiring specialists trained on individual cloud platforms, like AWS, Azure or GCP. The role is expanding and taking on new forms, with platform engineering and site reliability engineering coming of age.

Therefore, companies should be viewing DevOps not so much as one specific role or a set of tools, but as a culture. I recently met with Sashank Purighalla, CEO and founder of BOS Framework, to gather insights into the evolving role and culture of DevOps. According to Purighalla, “DevOps is a combination of culture, practices, processes and tools.” Below, we’ll identify the challenges that come with introducing DevOps and consider the right blend of technology, human specialists and governance required to get the job done.

The Challenges of Implementing DevOps

One challenge of implementing DevOps is simply defining the position itself. “DevOps is not really a job,” Purighalla explained. Instead, it encompasses many aspects, such as CI/CD, provisioning, maintenance, and compliance, all of which now adopt a plethora of different tools. There is also overlap between CloudOps and DevOps, an ambiguity that makes it tricky to write a job description for a DevOps engineer.

Various roles make up the teams responsible for modern cloud-native operations. In the same way that programmers have particular specialties, DevOps has specialized areas too. This segmentation might be based on the cloud vendor suite or the tools in use, such as familiarity with Jenkins, Docker or Kubernetes. Particular domains, such as DevSecOps or BizDevOps, may require dedicated focus as well. Purighalla shared some example roles that often exist in a modern CloudOps team:
- Cloud architect
- App architect
- Security expert
- Compliance expert
- DevOps engineer for AWS
- DevOps engineer for Azure
- SRE for AWS
- SRE for Azure
Complicating things further, DevOps can transcend cloud-based systems and be applied to on-premises or edge network maintenance. Given the many possibilities, crafting a job description for a DevOps position requires “awareness of and vision for how you want to build the DevOps function in your organization,” said Purighalla. Unfortunately, most people don’t have a clear picture of where to begin, he said. Setting this roadmap will vary from sector to sector and require intimate knowledge of and context about the company and its technological assets.

DevOps Shouldn’t Create Another Wall

DevOps is a mechanism to deliver high-quality code more quickly—this business outcome has been the guiding principle since its origin. To get there, DevOps sought to place development and operations ‘in the same room’ to reduce friction. Yet, in some organizations, DevOps emerged as an entirely new role on an org chart. “In certain cases, it created a wall,” says Purighalla. “Developers can’t think beyond when they hand off code to the infrastructure team.”

If this wall stays in place, it could further divide team motivations. Of course, building a healthy DevOps culture will vary from company to company and will require clarity about the end goal. But creating common incentives could include shifting left some security and provisioning responsibilities so developers have more perspective and can participate in DevOps.

Another reason to embrace a DevOps culture is simply the talent scarcity in this arena. This is a problem facing businesses of all sizes. Startups may not be large enough to hire a DevOps or site reliability engineer, but are beginning to see the necessity of greater focus on reliability and compliance as a core business function, says Purighalla. Enterprises typically have multiple clouds and hybrid environments, which are challenging to find talent to support. Middle-market companies often lose out to the attractiveness of startups and the big bucks of large corporations.

Outsourcing DevOps: Is It Ever a Viable Option?

So, given that it is so challenging to find engineers, is outsourcing DevOps ever a viable option? According to Purighalla, “outsourcing is a good option if your company has pre-built solutions for clouds and if it’s able to give you similar capabilities without requiring ground-up custom work.” A cloud enablement solution could be used to reduce the barrier to entry but is never a replacement for an entire DevOps practice.

The reason is that software programming is a creative engineering process. “I’ve never found an engineer that does the same thing every time.” People continue to experiment with a ‘build and fix’ mindset. This means that, in general, hiring external engineers is tricky as they don’t have intimate knowledge of the system at hand.

Furthermore, a platform that applies a standard way of working with multiple cloud providers must be flexible and open to change, as backend infrastructure is constantly evolving. As such, DevOps must be viewed as something that’s much more continual and requires ongoing maintenance. It’s not something you can outsource once and be done with.

“It’s becoming like accounting—you’ll fail an audit if you don’t do it,” said Purighalla. “Outsourcing needs to be viewed that way. You need to bring in a cloud enablement solution in combination with experts. You can’t have one or the other.”

DevOps: Not Just a Role or Toolset

Many assume that DevOps is just a set of tools. Instead, some experts argue that DevOps is more of a combination of varying roles, tools and processes. “DevOps started as a model—it’s not a tool,” Purighalla reiterated.

In essence, it’s more of a culture than a specific job title. And when viewed this way, organizations can begin to eliminate silos, which DevOps ought to eradicate in the first place. With the right technology and collaborative spirit, a company can create a culture that meets the goals of efficiency that DevOps aims to achieve.
July 8, 2022
Why Your DevSecOps Initiative Will Fail

When you’ve been in and around the security industry for long enough, you get used to the industry hype machine turning a cool innovation into, uh, meh. This hype cycle starts at the RSA conference each year, and folks like me look for new hot stuff on the show floor. For perhaps only the second time in 25 years, I wasn’t at the show in person, but it seems that DevSecOps was the preferred bandwagon on which every vendor jumped. Sigh.

I’m not sure whether it’s my increasing age or this business that has made me cynical, but here we are.

To be clear, from a customer’s perspective, there is great value in the concept of DevSecOps, as evidenced by the upcoming DevOps Connect: DevSecOps @ RSAC 2022 virtual event. Having these (sometimes) mortal enemies working together toward a common goal is great, in theory. But alas, in practice (and similar to what happened when DevOps hit the scene), it’s easier said (or displayed in a vendor booth) than done.

Thus, I’ve come to a sobering conclusion: Your DevSecOps initiative will fail.

Most organizations will talk a good game for a while and they may even try some stuff, buy some kit, send folks to training and the like. But in the end, despite all these efforts, you guessed it—they will still fail.

Is this a foregone conclusion for every organization? Well, no. But this isn’t my first rodeo, and I’m pretty sure this one will end like the others—in failure.

But let’s say you want it to be different this time. Really, you do. And you are willing to take some actions to give yourself a chance at success. If that’s the case, here are a couple of tips to increase your chances, however small.

Culture

First and foremost, DevSecOps is not a thing. It’s not a set of tools (no matter what the vendors tell you); you don’t buy it on a VAR line card. DevSecOps (like DevOps) is a cultural shift. Your teams need to work together. They need to collaborate. They need to have shared incentives. And they need to experience the consequences of not playing nicely in the sandbox.

Cultural shifts are hard. People don’t like to change. They resist. They undermine. They sabotage. It all sounds nefarious, but they do. So unless you can change your culture, you’ve got no shot.

Shift Left

Another one of these security-marketing-terms-run-wild is shift left. It means you want to integrate security testing directly into the development process as early as possible. You should be running security checks in the developer’s IDE to ensure they don’t violate security policy (like hardcoding API keys in their source, for example) before they even commit the code.

You must also integrate security testing into the CI/CD pipeline(s). Thus, you need tooling that works with your preferred pipeline.

Security Champions

Security testing will create angst for your developers. They will have false positives. They will have to fix things that they probably don’t understand. It will cause them to miss delivery dates. Of course, they should build it right the first time, but in their mind, they’ll see it as the security folks causing delays.

The developers will be annoyed, and you’ve got to manage that annoyance—or have senior management quash any rebellions, but that’s not a long-term solution.

On the other hand, you could establish a security champions program, which anoints (and trains) developers on each team to “represent” security within the development team. They help educate the developers on the tools and secure coding. They diffuse irritation when something goes wrong.

A strong security champions program is one of the leading indicators of DevSecOps success.

Break the Build

Finally, the security team must have the juice to break the build if a critical issue is found during the deployment. We talk about this with many organizations and they nod their heads. But they are lying to me and to themselves. When it comes down to it, someone on the dev team calls someone in senior management and, all of a sudden, that critical issue is now an alert, not a failed deployment.

Not being able to stop a build will kill your DevSecOps program. It’s like when a quality control issue forces someone to stop the assembly line. If you don’t stop the line, faulty products can result. In a security context, that means some critical vulnerabilities will be much more expensive to fix later.

So, there you have it. If you can evolve your culture, integrate security testing into your toolchain, empower security champions and empower your team to stop a deployment, you’ve got a chance at a successful DevSecOps program.

Unfortunately, you probably can’t do these things, and you’ll likely fail. In that case, I have some lovely property by a waterfall I’d like to sell you.

July 5, 2022
How to Manage and Engage Remote Engineering Teams
As engineering teams look to remain remote or hybrid, executives need to fundamentally change how these teams are managed. After tackling the tactical aspects of a distributed workforce—like home office equipment, a comfortable space where employees can get work done and reliable meeting, calendar and communication tools—more nuanced issues come into play.

Before the COVID-19 pandemic, when a minority of engineering team members worked remotely, those team members knew that they needed to make a concerted effort to connect and to be part of the group. When the majority are remote, however, the expectations of offsite employees have shifted dramatically. For organizations that had built their business with an in-person team, this brings up entirely new questions of communication, culture, loyalty, problem-solving and retention to the forefront.

Fundamentally Shifting Engineering Team Structure

Inspiring change requires fundamental shifts in the ways engineering teams work. Our own engineering teams have experimented with some changes that have proven effective, including:

A globally revised team structure that embraces a culture of autonomy and breaks larger engineering teams into smaller groups. Smaller groups help engineers feel more engaged, valued and empowered; it keeps meetings short and focused and allows for more parallel streams of work.

Overhauling our design process to get a champion or ‘anchor’ from the dev team involved in key features early on. This anchor is responsible for translating product and design requests into technical specs and is the de facto technical lead of the feature. Having this role rotate between team members for each feature means each member gets a chance to grow their skills as a technical lead.

Assigning dedicated designers to smaller groups to empower them to make small adjustments mid-flight. This would allow standups to operate as mini working sessions to iron out technical details that would normally be resolved through ‘shoulder taps’ or in-person quick questions.

Placing a strong emphasis on sprint retros as a way to make real changes to the way work gets done. When used in conjunction with an initiative to empower devs, sprint retros became a powerful tool to get dev feedback on improving the process.

Keeping teams accountable by encouraging transparency and clear communication as a tradeoff for their autonomy. We encouraged note-taking and regular updates, as well as clear goal-setting from the teams at the beginning of each sprint. By holding teams accountable to the goals that they set, it became easy to see when things were and were not working.

Experimenting with a four-day workweek to see if we can drive both greater happiness and productivity. This was perhaps the boldest of our experiments; we demonstrated trust in our team and set clear expectations around outcomes rather than hours. This has motivated our team and raised their morale in crucial ways at a time when switching jobs was both tempting and easy.
Hacks That Worked in Person

What are some of the things that worked in the office? This list will be different for each organization; for us, it was group brainstorms, in-person one-on-ones, summer Fridays and ongoing vibe checks. Here are some of the ways we hacked these to make them work for remote teams:

Group brainstorms: Digital whiteboards like Miro or Mural have been great. Digital sticky notes, too. This has enabled distributed engineering teams to contribute either all at once or asynchronously.

Summer Fridays: Give people the afternoon off even if it isn’t technically “leaving the office early.” Or try having everyone shut off notifications on Friday (or Monday morning) so they can get some undisturbed work done before shutting off for the weekend. Monthly mental health days off for the whole company can be a great idea too.

In-person one-on-ones: With Zoom, something is definitely lacking. Try spending half the one-on-one meeting chatting casually about things other than work.

Vibe check: Open office hours dedicated to work culture; surveys from time to time to gather quick informal feedback or think about other ways to elicit ongoing feedback from every employee, including engineering teams.

Generate Culture and Well-Being

What keeps most employees at companies is social bonding, inspiring projects and the possibility for growth. A question a lot of executives at previously onsite organizations are asking themselves is, “How do you fulfill the need for social bonding when most employees, including your engineering team, are remote?” In other words, how do you bond socially and do so remotely? Two goals we have identified are getting team members talking outside of work while avoiding Zoom fatigue issues and ongoing opportunities to share personal successes with colleagues.

Some of the ways we have built culture are:

Having (non-mandatory) Friday lunch and games like trivia, Jeopardy!, games or online games

Different ongoing events like photography challenges, health challenges and even an at-home Iron Chef-style cookoffs.

Having leaders share how they spent their weekends and time off. We believe in demonstrating a healthy work-life balance from the top down and encouraging our team to take the time they need to unplug and recharge.

Figuring out how (and how not) to surface urgent issues via Slack; working on a system to avoid pinging people after hours for non-urgent issues.

Above All, Manage With Empathy

These last two years have been exhausting for most people. Hands down, the best way to manage and engage the people you work with—no matter if they are in engineering or marketing—is to be empathetic to the difficulties that they may be going through outside of work. Executive teams can make all the tactical changes to their teams they want, but without managers that really care about their teams, you will inevitably fail to keep the best people around. Empathy-driven leaders lift their team members up and drive the kind of culture people want to be part of.
June 7, 2022
Making DevOps Smoother
Being a DevOps developer isn’t just about technical expertise necessary to build a product. It is also about learning the operations that facilitate the entire process. That means working with a fast-paced, high-performance, cross-functional team using Agile methodologies. But because of these sometimes-conflicting demands, it can sometimes get rocky.

Here, we’ll offer six tips for DevOps developers to ensure a smoother development process.

Set Measurable Goals

While working toward a specific goal, precision is paramount. Defining the problem accurately leads to a faster solution. For instance, “Configure deployment to a new region” is too vague compared to “Configure the deployment of all components of service X for North America.” The more specific aim of the latter makes it easier for the parties involved to identity the problem, make a plan and resolve the issue quickly.

Most DevOps developers use the acronym SMART while setting goals in a sprint.
1. Specific: Define exactly what needs to be done.
2. Measurable: Highlight the parameters and values necessary to indicate completion.
3. Achievable: Define how the task will be accomplished and decide who will be responsible for doing it.
4. Realistic: How realistic is the goal based on the above details?
5. Timely: Set the date and time when the task has to be completed.
While setting goals for a particular sprint, keep the above five points in mind to make sure that the tasks are precisely defined.

Document Everything

Proper documentation during the entire course of development is valuable to everyone. In many cases, DevOps developers join the project after it has started, and having them review documentation created by other developers is the easiest way for them to get up to speed. Not only that, but documentation also helps with debugging, troubleshooting and guiding the clients.

Documentation of the process is often seen as boring and a waste of time. However, thanks to online documentation tools, logging information has become a lot simpler. Using a document template with good formatting makes things easier down the line.

Communicate and Collaborate

Essentially, the efficiency of a DevOps development team boils down to how well they communicate and collaborate within the team and with the external stakeholders. Gaps in communication will slow down and possibly derail the entire development process. This is especially important as more and more teams are going remote and popping into your coworker’s physical workspace to ask a quick question is no longer possible.

In a remote working environment, communication can be slower. Sending a text, waiting for a reply, scheduling a call, etc., adds a lot of steps to the process as opposed to simply pointing at a screen and asking a question. Although there are a lot of visual collaboration tools and more integrations for video conferencing tools, it is still not the same.

Therefore, it is important to set firm communication and collaboration rules and make sure expectations are set from the beginning so that team members and stakeholders know what to expect. One of the easiest ways to do so is by having specific tools for specific channels of communication. Typically, there are three types of communication tools that are necessary:
- Team communications: Messaging apps like Slack and Microsoft Teams.
- Stakeholder communication: Basecamp, Workzone or regular email.
- Video conferencing: Can be used for internal and external communication. For example, Zoom, Google Meet, etc.
Automate Repetitive Tasks

If there are certain recurring tasks that happen at a local level, you can use Bash or PowerShell. Bash is older and used by a lot of IT and DevOps teams. PowerShell, developed by Microsoft in 2006, is newer and has replaced the command shell in Windows environments.

Although both Bash and PowerShell are cross-platform, generally Bash is preferred by Linux and macOS users whereas PowerShell is preferred by Windows users. Ultimately, it comes down to personal preference. No matter whether you choose Bash, PowerShell or a newer automation tool, automation will save a lot of crucial development time and remove toil from a developer’s workload.

Choose the Right Tech Stack

Every team is different in terms of their requirements and the tools they prefer. “DevOps tools” is a term that covers everything from server orchestration tools, cloud platforms, code management and many other categories. In simple terms, DevOps tools are instruments that make it easier to write, test, host and deploy code. There are many DevOps tools that a development team can choose from. Here are three of them which are worth considering.
1. Git: Git is a version control and distributed source code management. It makes it easier for developers to collaborate, experiment and merge code on the main branch.
2. Cloud IDEs: Fully hosted cloud integrated development environments (IDEs) protect your progress in case your local system fails. GitHub Codespace, Cloud9 and Glitch are the most popular ones.
3. Containers: Containers simplify the build, test, stage and deploy pipelines. They can either be locally hosted or fully hosted on the cloud. Containers help to identify and fix issues before they are deployed.
While choosing your tech stack it is important to keep the user experience and user interface, usability, scalability, available integrations and pricing in mind. Your tools should fit into your process, not the other way around.

Value DevOps Culture

The work culture is essential for the cumulative success of the entire DevOps team. The way the team interacts with each other defines the way they work. When a team is provided with a sufficient amount of freedom to make its own decisions, it will come up with innovative ways to make the overall process more efficient. Overcoming the divide between “dev” and “ops” in its own way will empower the team to do its best work.

With that being said, remember that a culture is something that develops over time organically, not forced upon people.

Wrapping Up

Developing software while collaborating with IT operations doesn’t have to be hectic or frustrating. By following these simple tips you can improve your entire team’s productivity. We hope that this article has provided you with some insights that will help you smooth out any development hurdles.

Happy developing!
May 17, 2022
CircleCI Survey Shows the Need to Prioritize DevOps

A CircleCI survey of 2,013 business leaders in the U.S. and UK published today finds nearly all respondents (97%) recognize that the success of their business within the next year depends on their software development teams. Despite those findings, well over one-third of respondents (39%) admit their organization is challenged when it comes to innovation and acquiring and maintaining developer skills.

A full 89% of respondents said they also have a good understanding of how to measure the performance of their engineering teams. However, 40% of companies are still using antiquated metrics such as the number of lines of code written, while another 37% measure story points.

More troubling still, less than one-third of respondents (30%) said they plan to make adoption of DevOps best practices a priority. On the plus side, only 15% of respondents said they are implementing a continuous integration/continuous delivery (CI/CD) platform for the first time.

The CircleCI survey suggests that improvements in how software is delivered could be worth, on average, up to $126 million per year. Nearly two-thirds of respondents (65%) said their business is involved in digital business transformation initiatives of one kind or another. Another 20% said they have completed one.

Jim Rose, CircleCI CEO, said it appears that while more organizations now realize how dependent they are on software, many of them have yet to address issues that fundamentally impact developer productivity. For example, more than half (52%) of respondents don’t allow their software developers to choose their own tools, noted Rose. While there is a clear need for a consistent approach to building and deploying applications, Rose noted that DevOps best practices should not require developers to employ a specific set of tools. Developers are only able to truly innovate when they are able to experiment with different tools, said Rose.

In general, Rose said DevOps adoption tends to go through various cycles. Many organizations today are looking to reduce the number of tools that make up a toolchain. However, those efforts shouldn’t curtail the ability of developers to innovate. A CI/CD platform that provides the foundation for DevOps workflows needs to be easily extensible, noted Rose.

It’s not clear to what degree adoption of DevOps best practices have stagnated, but the number of organizations that have implemented DevOps across their entire enterprise remains limited. Most organizations have individual teams that might have adopted DevOps to one degree or another. In many cases, those teams are using disparate tools and platforms.

Most organizations clearly want to be able to build and deploy applications faster. The challenge isn’t so much mastering DevOps platforms as overcoming many of the cultural issues that conspire to limit DevOps adoption. In time, however, the need to rely more on digital processes will force the DevOps issue. As one organization makes advances—thanks in part to their ability to effectively employ DevOps processes—the more keen rival organizations will be to make sure they don’t lose ground. It may be a while before business executives connect the dots between their ability to compete and the degree to which organizations have mastered DevOps, but it’s increasingly apparent that day is not too far off.

July 28, 2021
Then and Now: The Evolution of DevOps Culture

There are many available resources dedicated to delivering better business value faster. Based on this advice, many organizations and teams are adopting common software delivery practices — even outside the usual use case of providing software (take, for example, SpaceX teams using agile, or leadership teams that use scrum practices and have daily stand-up calls). This progression into faster, better, cheaper and easier – no matter what you’re delivering – is what makes incorporating DevOps into business practices critical to delivering unmatched value for end users.

Then and Now

A great perspective to consider when approaching the subject of DevOps is how technology has changed just about everything – how we build, connect, share and educate. Up until the 2000s, for example, the standard turnaround time for taking and sharing pictures was one to three weeks, if not longer. This process used to involve film cameras, darkrooms to process the photographs, photo finishing labs and hard copy, physical prints. Today, our mobile devices allow us to snap hundreds of professional-quality images and share them immediately online.

These earth-shattering changes don’t apply to photography alone, but to many other industries including financial services, banking and IT. Consistently, technology is finding new ways to disrupt industries, priming them to be more efficient to fit into our fast-moving lifestyles.

The DevOps Life Cycle

Now, let’s look at software delivery. In the past, the process of traditional software delivery was linear and sequential; waterfall methodologies offered little flexibility and did not succumb to the nature of change and demand for technology services we see today. What we’ve experienced with software delivery now uses DevOps to leverage new insights through people, processes and technology, giving organizations the ability to deliver continuous business value. Yes, that means businesses are adding value to our lives all the time, whether you see it or not. For technology organizations, this process for delivering business value is modeled through what we call the DevOps life cycle — understood through the graphic below.

Getting to a DevOps Culture

Often, an organization’s challenges with DevOps do not lie in the technology or processes themselves, but in the people part of the equation – how we work together to deliver value via cross-functional teams. To understand what building a DevOps culture means, we need to look at what culture encompasses and how our people, process and technology work together to enable a successful DevOps life cycle.

This layered graphic features all the various components related to culture. Each layer encompasses the next.

· Mindset

· Values

· Principles

· Practices

· Tooling

Getting to a DevOps culture involves articulating change both from the bottom up and top down in our organizations and is, therefore, no easy feat. Before we can introduce or discuss tooling, we need to understand how our practices and principles help us achieve our outcomes. Each inner layer requires the outer layer to be successful before we can truly get to defining and strengthening a DevOps culture.

Here are my tips for getting to a DevOps culture:

· Learn from and develop skills from mistakes

· Focus on the important priorities

· Capture collaboration

· Perfect your tooling

The DevOps Principles

DevOps is the collection and collaboration of people, processes and technology to deliver software value continuously. Here are some core DevOps principles you can use to guide you on your DevOps journey.

Create With the End in Mind

High-performing teams work best when leaders and individuals understand their role in the team. Therefore, creating with the end in mind involves reassessing and often asking big picture questions, like “Who is this delivery for?” and “Why are we doing it this way?” Keep the vision in mind and make adjustments along the way.

Even the most famous photographs in history involved many adjustments and numerous attempts to get it right. Creating with the end in mind means knowing we may not have everything right the first time around. That’s okay! Similarly, life isn’t without its own distractions, conflicts and changes. Keeping the target outcomes in mind helps us align to initiatives and actions, and to question when they don’t align.

Cross-Functional Teams

Many products and deliveries involve multiple people. For example, some of the best Marvel cinematic universe (MCU) movies were made thanks to the help of multiple production teams and partner companies coming together to build the powerhouse we know today. Not to mention, in my opinion, some of the best superhero movies of our time. We succeed with software delivery in the same way: by having fully responsible cross-functional delivery teams.

The best engineering teams I’ve been on are made up of independent and autonomous individuals who know how they can contribute to the work in progress. They’re also willing and unafraid to collaborate with others to get this work done.

Commitment to the Journey

“I am not here to be right. I am here to get it right.” – Brené Brown, from the book Dare to Lead.

Even with cross-functional delivery teams and creating with the end in mind, our teams still may not get everything right the first time around. Committing to DevOps is about accepting any failures that come during the journey. Committing to the journey doesn’t mean you can’t define what it involves, even if it’s out of the ordinary. Experimentation is also a part of how we, as developers, adapt to change and adopt novel approaches to delivering faster, cheaper and better software.

The DevOps Principles as Guides

Use these principles as the foundation for how to work together, but also use the right tools, and define and improve processes along the way. In photography, there are three components that serve as building blocks to the final images we capture: aperture, shutter speed and ISO. In DevOps, it’s our people, processes and technologies. Achieving high performance with DevOps involves all of these components working together and adjusting to our environment, situation or team.

The key to getting to the results you desire? Not getting blindsided by any single component of getting to that result.

The DevOps Practices and Tools

I like to consider this section the call to action; the one says to our teams and individuals, “Gear up!” No reasonable photographer would leave for a photoshoot without their camera and camera gear, right? Similarly, DevOps practitioners and teams need the right tools to get the desired results.

Source Code Management

Source code management is about allowing teams to collaborate, have version control, correct and revert software code. This is fundamental for many teams to increase not only visibility and collaboration, but also start automation workflows.

If you are an individual just starting out with writing code, I recommend learning the basics of Git, such as how to add, commit, push, merge, branch and clone code. If you’re a team, I recommend discussing the practices and standards you want to use for collaborating. Always fit your Git structure and workflow to your codebase and team dynamics.

Continuous Integration

What continuous integration (CI) does is take code away from local machines to package it into a deployable artifact in a CI server. What this is designed to do is automate the integration of newly committed code changes. This process is often triggered by code changes pushed into your Git repository. Using checks and other tools, teams can version and release artifacts that have already been vetted for quality and security.

Continuous Delivery

Continuous delivery, on the other hand, takes artifact code to production environments. CD aims to deliver code changes of all kinds to users in a fast, repeatable and safe manner. CI/CD consists of both CI and CD pipelines working together to deliver code to users.

Infrastructure-as-Code (IaC)

Infrastructure-as-code allows users to define hardware through code. We can improve how we provision, configure and maintain hardware systems. Infrastructure provisioning tools like HashiCorp’s Terraform and AWS Cloud Formation, configuration automation tools like Ansible, Puppet and Chef and package managers like Helm allow teams to accomplish much more when software scales and demand increases.

Secrets and Identity Management

Security is everyone’s responsibility. Secrets management and identity management tools make accomplishing DevSecOps easier by securing and managing sensitive information. Teams should consider how they are handling secrets and users within their architecture. HashiCorp Vault, KeyCloak, KMS and other similar tools can help you achieve your goals around security.

There are many other practices and tools DevOps teams and organizations can use to achieve their desired outcomes. What works for one team may not work for another — hence the need to innovate and experiment in a controlled and well-led manner. Other practices that can increase your team’s ability to deliver value include value stream mapping, progressive delivery, GitOps and chaos engineering.

People, processes, and technology belong together in a DevOps culture. While practice makes perfect, what’s more important than perfection is gathering the right answers along the way. Everything doesn’t need to be right the first time around. Just remember that no leader, individual or team in DevOps is alone. We started by defining what it means to build a DevOps culture, change mindsets and set principles and practices, so now I ask you: What does DevOps mean to you?

June 1, 2021
ADOC: Assessing DevOps Culture

The Assessment of DevOps Capabilities (ADOC) is crowdsourced, vendor-neutral and designed for individuals, teams and organizations who want to baseline their current DevOps state, identify the next target state, gain insights into how to improve their organization and team capabilities and measure and accelerate continuous improvement during their DevOps journey.

The assessment models five DevOps dimensions – the human aspects, process and frameworks, functional composition, intelligent automation and technology ecosystems – to help you gauge your DevOps maturity and identify areas for improvement. In this TechStrongTV interview, Alan Shimel talks with Garima Bajpai, Louise Cermak and Brendan O’Reilly about reshaping culture to get the most out of any DevOps journey. The video is below, followed by a complete transcript.

Announcer: This is Digital Anarchist.

Alan Shimel: Hi, everyone. Thanks for joining us on another segment here for TechStrong TV. This is a special segment panel for TechStrong that I’m gonna be conducting, here. I’m happy to have you join us. I’m also really happy to have three interesting people join us. Let me introduce you to them. And if I mispronounce people’s names, I apologize; we do the best we can here on TechStrong TV, right?

But we’re gonna start with Garima, is it Bajpai? Fair? Good? Okay. Garima, why don’t you introduce yourself?

Garima Bajpai: Thank you, Alan. I’m Garima Bajpai from Ottawa, Canada. I am the Founder for the DevOps Community of practice here in Canada, which has three chapters, Toronto, Edmonton, and Ottawa. I’m also the organizer for the DevOps Summit which happens in Canada November 8th and 9th, and I am Ambassador with DevOps Institute, as well as an Ambassador with the CD Foundation. So, today, we are going to have a very interesting dialogue on DevOps assessments. So, I can’t wait to get started, right?

Shimel: Yeah, thank you, thank you. Thank you for all you’re doing for the DevOps community. Next up, let me introduce you to Brendan O’Reilly. Brendan, welcome—a little bit about yourself?

Brendan O’Reilly: Sure. So, my company is called Daysha DevOps. We’ve been working with the DevOps Institute now for about five or six years, predominantly delivering their training. And I myself am a consultant, and like the other speakers here today, really looking forward and excited about what’s happening with ADOC, because I see a big opportunity for our customers to get deeper into their DevOps journeys, to progress those journeys.

Shimel: Fantastic, and thank you. And then last, but certainly not least is, we have Louise Cermak—Louise, did I get that right?

Louise Cermak: Almost, yeah.

Shimel: Well, say it right, because you’re entitled to have your name said right, it’s my fault. So, please, how do we pronounce your name?

Cermak: Thanks, Alan, it’s “Chermock.”

Shimel: “Chermock,” okay.

Cermak: Yeah, so, I’m Louise Cermak. I’m a Principal Consultant with Catapult CX. We build software ourselves, and we also consult in agile and DevOps and have been doing so for sort of 10, 15 years. And we’re excited for ADOC, because actually, having the combination of being engineers as well, we can really understand the capability and how to apply it.

Shimel: Absolutely. Well, all three of you, thanks for joining us. So, a couple of you have mentioned ADOC, right, and this is something that our friends at the DevOps Institute announced, I guess it was last week or the week before now. And ADOC, for our audience who may not be familiar, stands for Assessment of DevOps Capabilities. And this is a new assessment model that the folks at DevOps Institute have been working on.

Look, you know, I know they’ve been working on it for over a year already. It’s been primarily driven by Helen Beal, who is a—Helen is a very well-known DevOps person in the community, but she’s also the Founder of the DevOps Institute Ambassadors, and has been a DevOps consultant herself for many, many years, as long as I’m doing devopsy.kinsta.cloud.

And then Helen was really helped with this by Eveline Oehrlich, who’s a DevOps Research Director at DevOps Institute, a former Forrester VP. And then I also know that she’s been helped a lot with people like the three of you, who are real world DevOps consultants who are helping organizations every single day with their DevOps transformations and capabilities.

So, before we jump into ADOC, though, let’s take it up a notch and talk about DevOps assessments in general, right? Are they—why are they important? Why are they important, and if anyone wants to give us sort of a brief history of evolution or time around these assessments and how they’re used, let’s say, by consultants and/or end user organizations.

Garima, I know you have a lot of experience, so if you don’t mind, I’m gonna ask you to kick it off, and then have the rest of the panel chime in.

Bajpai: Right, and I actually term DevOps transformations as a journey towards remaking culture. So, it has been largely a complex journey, because of two factors, actually. The first factor is that the complexity brings along with, you know, a lot of focus on how you can upskill people, how can you actually transform your knowledge based and skill set to a journey which is basically based on experimentation, on learning, and learning from failures, right?

And the second aspect is that there is no such literature available. You know, there is a lot of talk about DevOps transformation, but the literature is in the making. So, there is limited academic support as well as support from a best practices perspective how to do this transformation, right? So, these assessments come very—it is very crucial, because it will help you assess where you are, and every organization will have unique challenges, right?

So, it is important to assess where you are in your journey and what you can do. You know, it’s not like a traditional transformation journey of three to five years where you are relying on a lot of targets ________ models which were already defined. It’s continuously evolving, right? So, you will have to have a view on what you can do today and how you can incrementally, in short cycles, transform.

So, what happens in this process is that, you know, assessment becomes more crucial and essential, because there are discrete efforts. There are efforts in short cycles, and this assessment and measurement will help you course correct, will help you understand where you are heading to in your journey and what is needed as next steps to ensure that you incrementally build value, right?

So, that’s why, I think, these assessments are extremely important. We will talk along this conversation how ADOC can actually help you on this journey as well as what are the major impediments and challenges organizations have and what should they look out for.

Shimel: Fair.

Cermak: I think, over the last few years where we’ve been helping organizations, what we’ve noticed is that many of them are trying to do their own assessments, and I’ve been into so many organizations where people have got Excel spreadsheets and they’re trying to measure how they’re performing.

Because, you know, Garima’s right—there’s a lot of learning and experimentation. A lot of it is self-learning, which is what we encourage, right, from a DevOps culture perspective. But people wanna know that they’re going in the right direction, so they start with their own spreadsheets, fill them in, try and measure their capabilities. And a tool like ADOC helps organizations have a much more structured way of doing that, and obviously, it’s more scalable than an Excel spreadsheet, but people wanna know that they’re doing the right things.

Shimel: Agreed.

O’Reilly: Just a little bit about the history, perhaps Alan—you know, ADOC is brand new, but there was a progenitor in the form of DORA, if you recall.

Shimel: Sure, sure.

O’Reilly: Yeah, so, that was with Jez Humble and Nicole Forsgren. So, when they produced their State of DevOps report, it was a means by which organizations could form views about what good looked like, so you have your release and then so on.

And it definitely raised people’s curiosity about—can we do this, can we measure? And of course, one of the principles with any DevOps transformation is to be data-driven. And so, the 180-odd questions that are included in the enterprise edition are very much about trying to capture and turn subjective opinion into something quantitative, a good first guess. And I think DORA has been successful, it’s now part of the Google organization, I believe, but this is a nice independent offer from the DevOps Institute.

We’re really looking forward, here at Daysha, to taking that to our clients. I see some really interesting use cases. Some of the people that I’m talking to right now are just starting in a CTO role, and they want to baseline what they’re doing.

Shimel: Absolutely.

O’Reilly: So, they can look—you know, six months from now, they can say, “How much have we done?” They wanna get an understanding of what have they got in-house right now and then look at it again to see if they’ve been effective in those changes that Garima was—really well-made point by Garima—nice, short, sharp, Plan Do Check Act type changes that are gonna take place over the next six months.

Shimel: I mean, for me [Cross talk]—

Bajpai: Right, I mean, I also want to focus on two specific aspects of ADOC, which stands out. So, a lot of people have actually understood that you cannot remake culture without people-centricity, right? So, that’s a given. And we also understand that emerging technology can be a tool in your toolbox when you’re trying to kind of transition from X state to Y state. And a lot of focus has been placed on processes and frameworks.

What ADOC has been standing out for me is, they have actually reflected to other different things, which are equally essential. The first thing is functional silos. And if you look at large enterprises, what they struggle with, like, what has been in the past is that we have large, functional organizations and units with their own business goals and objectives. And when these people are trying to [Audio skips] towards ________-centricity, towards DevOps capabilities. That’s a large challenge, because you know, it’s not easy to actually break down the functional silos, burn all the ships so that there is no, you know, way back. It has to be carefully done so that we have a possibility of course correction. That’s the first important point.

The second important point which stands out for me is automation. And when I look at automation, I see that data driven approach towards DevOps and how that will ensure that we automate good processes, we automate the capabilities which are creating value, not only end to end, but also within the practices, right? So, that’s—those two things, I think, put together with people, technology, and process would actually make a kind of, a full house for, you know, doing this assessment in one way rather than looking at it in pockets.

Shimel: Agreed. In my mind, you know, Brendan, you mentioned the DORA folks, and of course, Nicole has moved on from Google, she’s over at GitHub, and I don’t know if Jez is even with Google anymore, frankly. But really, with DORA, it wasn’t necessarily a consultant’s tool, though consultants used it.

I think one of the interesting things with ADOC and what I know about how it came about is, it really was designed for consultants to use as part of their consulting practice to help you collectively help your clients get a baseline, a roadmap to show where you’re strong, where you’re weak and going forward so that that consultant can be more helpful, more impactful and, frankly, more efficient, which translates to less dollars, right, that clients waste in kind of circling around to figure out where the ground zero is.

So, I would just point out that, now, that’s one use of ADOC is as a consultant’s tool. There’s also the community version for individual organizations and large enterprises can do it on their own, they don’t necessarily need a consultant. But it really was designed with that in mind, and I think it’s gonna be interesting to see, you know, DevOps especially, it was one of the knocks on DevOps, right? And I’m devopsy.kinsta.cloud, I’ve heard this from day one—it’s squishy, there’s no manifesto, like in agile. There’s no real definition. It’s, how do you put your finger on it? You know, it seems like a unicorn or a mythical beast or something.

Well, with ADOC, a lesson I learned early in my career in technology was, everything can be measured, and we measure everything, right? And ADOC kinda gives us a little bit of that certainty, at least as opposed to where you are in DevOps. I’m wondering, have you guys actually had a chance yet to try ADOC out with real world clients and what some of the results or findings were?

Cermak: Yeah, we’re doing that right now with a client and we found that it was much easier to prioritize the activities that they needed to do, so we could align the activities with their roadmap and make sur that they were incrementing in the right direction to address some of the challenges that they had with their own customers.

So, we took a very customer-based approach to prioritization of the activities, and they could really see a difference in the way they were able to engage the customer, deliver the features much faster, get the features agreed properly and through improving their continuous delivery pipeline, for example, and their lead time to change would improve and stability and reliability. So, we were able to prioritize exactly the things that were important right then to them with their customer base.

Shimel: That’s great. Anybody else?

O’Reilly: Well, just to echo, I personally haven’t had experience with the product just yet, but I have had that experience of walking the corridors with a spreadsheet, meeting people, capturing data—yeah, and that’s a really slow, inefficient way to capture a picture that evolves very, very quickly. So, I’m excited to do it this way, which is just way more efficient and lower cost to the client.

And I think in terms of the consulting add-on, it’s that experience of having been through several transformations that allows us to analyze the results once they’re produced. And then, exactly like Louis has pointed out—prioritize, right? So, what changes can we make that will fit in with the natural rhythm of this company if they’ve got, if they’re not yet delivering on a regular basis? So, that kinda stuff I think is where the consulting value add is.

Shimel: Interesting.

Cermak: And the other thing that’s quite nice is, you can get the marginal gains as well, because you don’t have to tackle everything at once. You can improve one metric and then go and do the next one and the next one and continually improve, which I think the teams that we’re working with have really appreciated that, because they can see an uptick quite quickly, they get motivated, they wanna change more, they want to get better, and they keep going and keep going and getting those marginal gains.

Bajpai: Right, and this is actually an extremely good point, because it gives us a perspective and this is something which I actually have experienced myself. I went to experience ADOC myself and, you know, I wanted to bring my team in as well. But what has happened in this journey, I have realized that organizations have overestimated the potential of short-term gains. And when I say that, often, people do not realize that whatever transition or transformation from a DevOps perspective they are doing, they are looking at short-term gains and probably losing out on the long-term potential of, you know, larger, creating larger value, long-term value, right?

So, this is also a reflection that when you take this kind of an assessment, you would potentially have two aspects—what you can do in short-term, and what you achieve through several initiatives put together incrementally and how that outcome would look like in long-term, right? So, that is where these assessments would become very crucial for organizations, at especially big organizations.

Shimel: Agreed, agreed. With all three of you being involved in consulting, I’m gonna ask you to take off your consultant hats for a second and for end users, end user organizations out here watching this, is ADOC of use to them without a consultant?

Cermak: Oh, definitely, yeah. You know, we do build software, and we use those metrics ourselves, and we’re constantly monitoring those dials and—okay, we do some consulting around this stuff as well, but actually, we’ve got customers that we need to deliver to, and for us, being on top of all of that all the time is really helpful.

So, anyone taking the assessment would be able to identify changes that they could make in their own engineering. That’s straightforward. It’s really set out very easily to understand.

Shimel: Very good.

O’Reilly: Alan—

Shimel: Go ahead, Brendan.

O’Reilly: Yeah, so, there’s a friend of mine who’s a lawyer, and pretty much any time I ask him a question, the answer is, “It depends.” [Laughter] So, in answer to your question about whether end using organizations can benefit from this or that consultant, I would say it depends. It depends on the mindset in the organization, the appetite for learning, the appetite for change, and so forth.

But for sure, even just to kind of get started and to understand where they’re at, there’s huge value here without a consultant just to get a picture of where you’re at.

Shimel: Agreed. And I think that’s part of this, too, and I think that’s also where there’s the—I forget if they call it the enterprise edition, which is the full, I forget how many questions there are already, hundreds of questions, versus the community edition, which I think is just, like, 30 questions or something like that. But even the community edition, you know, I think brings value to an end user organization who may just want to—you know, let me stick a flag in the ground as a marker and then see where we go from there.

Guys, we’re about out of time, but I want to thank you, all three of you, for joining us. I should mention that if you’re interested in ADOC, right, Assessment of DevOps Capabilities, you can find out a lot more about it at the DevOps Institute site, which is DevOpsInstitute.com, and I know that there’s licenses for consultants, end user organizations. We’ve also launched the membership association, so as a member of the association, I think you get some use of it as well.

But for now—Louis, Brendan, Garima—thank you so much for joining us on TechStrong TV. Good luck, and keep us posted with ADOC.

Cermak: Thanks, Alan—pleasure.

Bajpai: Thank you.

O’Reilly: Thanks, Alan.

Shimel: Thank you. Alright, we’re gonna take a break and we’ll be right back with our next guest.

[End of Audio]

April 22, 2021
5 Steps to Successful DevOps Culture

The late business management guru Peter Drucker coined the phrase, “Culture eats strategy for breakfast,” and the phrase has endured through the years. Your people must be passionate and enthusiastic about executing business strategy, or it – and your business – is doomed to fail. But remember that company culture itself needs a strategy to complement the business.

DevOps, too, will not succeed without the right culture. As I said in my book “Engineering DevOps,” “Culture is a door to Engineering DevOps,” because if leaders and people do not work in accordance with DevOps principles, then no tool or engineering process will be sufficient to succeed with DevOps. In my (and others’) experience, culture challenges are the No. 1 obstacle that many organizations need to overcome to succeed with DevOps. But changing culture is not easy. Values, beliefs, behaviors and work habits are deeply ingrained in organizations. Organizational inertia and deep-rooted habits are much harder to change than tools or process changes. Transforming organizational culture for success with DevOps requires a strategy, goals and sustained commitment.

In her article, “5 Steps to Change Your Company Culture,” Kate Heinz prescribes five practical steps for cultural change which also are highly applicable to DevOps culture transformation.

Step 1: Determine Core Values

Start by clarifying the values that are most important to accomplishing the long-term strategic goals of the organization. With DevOps, typical strategic core values could be responsiveness to customer needs, speed of innovation, technology leadership and software products and services resiliency, for example. Collaborate with all the key stakeholders including executives, long-term employees, sales teams, key suppliers and HR to obtain alignment on core values before executing the next steps.

Step 2: Set Your Culture Goals

In his article, “7 Key Principles for a Successful DevOps Culture,” Kaya Ismail identified seven principles that can form a framework for determining your DevOps culture goals.

1. Foster a Collaborative Environment – Break down silos to bring people, processes and tools towards a unified focus on the customer.
2. End-to-End Responsibility – All people in the value stream need to be fully accountable for the application and outcomes from beginning to end.
3. Encourage Continuous Improvement – Optimize value streams using integration toolchains and automated processes to realize quick lead times and fast customer feedback to continuously improve performance.
4. Automate Almost Everything – Automated CI/CD processes, infrastructure provisioning, testing, deployment and security compliance require a skilled workforce.
5. Focus on Customer Needs – DevOps teams must continuously pay close attention to ever-changing consumer demands and be ready to respond quickly.
6. Embrace Failure and Learn – A “climate for learning” in which failures are viewed as opportunities to learn makes people feel safe and empowered to transform their work.
7. Unite Teams and Expertise – The scope and complexity of DevOps requires team members to share knowledge and cross-train so they are well-rounded and have a balanced set of skills.

Step 3: Assess Your Existing Culture

Conduct interviews and surveys with employees and key stakeholders to determine where there are deviances from the culture goals set in Step 2. Communicate an analysis of the assessment findings to all stakeholders, pointing out important gaps, areas for improvement and the general plan to close the gaps.

Step 4: Map Out the Plan

Develop a roadmap to address the gaps identified in Step 3. Include specific tasks, timelines, benchmarks and responsibilities. Tasks and items may include targeted workshops, training, selective new hires, organizational changes and, most importantly, rewards and consequences – the real drivers of behavior and culture. One caution about training: as Thane Bellomo explained in his article, “Training Doesn’t Change Culture,” training alone does not have the power to fundamentally change culture.

Step 5: Evaluate Your Progress

Communication, surveys and interviews are important so individuals can provide feedback and track progress. Use the feedback you receive to verify that culture goals are being improved upon, and to reinforce to everyone that the culture changes are important. Use DevOps metrics such as lead time, release frequency and time-to-restore service to demonstrate that the culture changes are helping the organization achieve the strategic values set in Step 1. As you monitor progress, be mindful of pitfalls. As Larry Senn explained, “The Top 4 Reasons Culture Change Initiatives Fail” are: lack of consistent leadership from top management, inadequate personal involvement, disconnected initiatives and lack of top-to-bottom momentum. Be prepared to make corrections based on the evaluations to ensure your culture transformation stays true to your DevOps strategic values and culture goals.

What This All Means

Success with DevOps requires the right kind of culture. Changing culture is no small feat, but it can be done if approached strategically. The five steps described in this article provide a framework for organizational culture change that supports DevOps.

March 10, 2021
Building (and Nurturing) a Product Team During a Pandemic

Building a successful product team is difficult under the best of circumstances. Building one during a pandemic raises the level of difficulty by an order of magnitude. But it’s not impossible.

In early 2020, everything changed. For months now we’ve been scrambling, adapting to a new normal that none of us had the foresight to plan contingencies for. We’ve moved from a world of in-person collaboration to one that relies heavily on technology to keep the proverbial wheels turning.

The shift to an at-home workforce has brought with it the productivity you might expect when you strip away lengthy commutes and other inefficiencies. We’re left with an operation that’s run lean, on the back of technological solutions that push deliverables out the door in a matter of weeks, not months.

Traits of a Team That Can Weather the Storm

Now that digital transformation is no longer optional, a digital-first product team isn’t either. These digital natives were nice to have before, but in a world driven by Zoom meetings, Slack and Google Docs, they’re essential. Entire operations, quite literally, could fall apart without them. Without a doubt, a good product team starts with a good leader, and that leader these days needs a firm grasp on the tech challenges faced by their teams and the solutions that keep every part of the business moving in times of uncertainty.

But it’s not just technology. The DNA of the perfect product person starts with curiosity, an ability to poke and prod and find inefficiencies by asking the right questions and always seeking a better solution.

They should also have a growth mindset. An effective product person is always pushing the limits. It’s this ambition, this desire to keep moving forward regardless of the current situation, that often moves an entire team to keep up or risk getting left behind.

They aren’t followers. The ideal product person is willing to argue against a decision that the rest of the room agrees with. They stand their ground and explain their thinking in a way that’s productive and respectful. They might not be the typical extrovert, the person always willing to step up and lead, but when they speak up, their words have purpose. These types don’t follow orders blindly; they question them, looking not only at the task but also the desired outcome, in an effort to find a better way. “Because we’ve always done it that way” falls on deaf ears, as these types understand that what brings you success rarely keeps you on top without the ability to adapt and evolve.

The Collective Consciousness Inherent to a Product Team

It’s important to zoom out and remember that a great product team is about more than a group of individuals. When done right, it’s a collective that moves as one. Individual achievements become all but meaningless and the focus is always on the team.

This really boils down to culture. While a product leader chooses the shared beliefs, ideas, attitudes and knowledge that make up the team’s identity and work ethic, it is only the team that can internalize this collective consciousness and make the desired culture a reality. This is why one person can so easily make or break a team, so ensuring a good culture fit becomes the gel that holds the entire thing together.

For the most part, product teams need individuals that are team-oriented, individuals that care about propelling the team forward rather than just achieving individual goals. Understanding is everything, and an empathetic individual understands not only their own struggles but the challenges faced by those around them. The importance of these individuals cannot be overstated, not only for the culture of the team but that of the company as well.

Last, but not least, we look for people who make good decisions. This doesn’t mean they always make the correct decision. They are human, after all, but they are decisive in their decision-making and willing to take responsibility for decisions that go wrong. We don’t typically see the results of these decisions right away. Often, they play out several months, or even years, down the line. But we have to know that the person making these decisions is capable of weighing all the options, seeing all the angles and being decisive when called upon. This is particularly true at the senior level, the driving force of the team’s decision-making capabilities.

Culture starts from within, and though teams are of the utmost importance, they are composed of individuals. If we were to build a product team in 2020, in the midst of a pandemic, we could do worse than identifying these characteristics in each member. One individual could propel the team to new heights or serve as a speed bump on the road to success.

November 6, 2020
Debunking Misconceptions About Engineering Management in 2020

2020 will be a year we all remember for so many reasons. It has been a year full of uncertainty and confusion, and also one in which misconceptions abound. In the world of software engineering, we feel this acutely as all eyes are on the engineering team to continue building innovative new products and solutions—maintaining the lifeline of the business—even as we grapple with new realities of universal remote work, new constraints on resources and countless distractions.

Given all of that, it should come as no surprise that go-to-market and other business leadership has grown increasingly concerned with the performance and success of the engineering teams on which they depend. Some of their worries are legitimate, but many are merely misconceptions about the state of software engineering and the efficacy of engineering management. To help foster alignment, the Jellyfish Data Science team investigated by looking at engineering management and team data across dozens of software development teams representing thousands of engineers. Below, three important misconceptions about engineering management in 2020 are debunked.

Misconception 1: Software engineering teams are working less or being less productive amid COVID-19, universal remote work and lack of management oversight

The idea that teams are being less productive is not altogether unfounded. Nor is it surprising given the fact that it’s much more difficult to see what’s being built by the engineering team and how the team is being managed directly. It’s true that among the many teams sampled, productivity decreased across the board about a month or two after the shift to universal remote work (after a spike in productivity initially). However, as things have settled into a new normal, productivity metrics on engineering teams have rebounded and in many cases even increased.

The reality is that engineers are working almost the exact same amount of time as they had been before the pandemic. In fact, the average number of coding days per week has increased 2% (it stands at about 2.2 days). The difference is that engineers are adjusting their working hours to accommodate family schedules. Peak coding hours have shifted four hours earlier, and software engineers are working longer and less regular hours during COVID-19.

Across the board, engineering metrics suggest productivity is up relative to the same period last year. The number of commits has increased, merged pull requests are up more than 10% and the number of issues resolved has increased a whopping 8.7%. The exception here is issue cycle time, which has increased more than 21%. Engineers may be taking on meatier projects, and are working equally, if not more diligently, to ship them.

Misconception 2: Communication on engineering teams is breaking down due to remote work during COVID-19

Again, this worry is not unfounded, especially for older companies where co-located work was important for effective communication and for larger companies where communication is crucial to maintain business continuity across divisions and departments. But among younger, and especially software companies, the move to remote work was not so painful and communication did not break down nearly as much as might have been anticipated given the already widespread adoption of videoconferencing tools such as Zoom or Google Hangouts and messaging platforms such as Slack.

The reality is it’s difficult to say what has happened with communication. Certainly, informal office banter and hallway catch-ups have taken a nosedive. But communication about engineering work—communication that is measurable—has actually increased, possibly enough to fill those gaps. Review and comments on pull requests, for example, have increased by 5% and 4% respectively, and Slack’s CEO reports the number of Slack messages per user per day has increased 20% (which echoes our findings that Slack messages in engineering work channels have increased). The conclusion is that while informal communication may be down, measurable communication—especially around engineering work—has actually increased.

Misconception 3: Engineering management has lost visibility into the work their teams are doing as their teams have gone remote and they can no longer walk the proverbial “floor”

Visibility into the work of engineering teams has not broadly decreased in recent months, but that doesn’t mean visibility is not a problem. Visibility remains a top challenge among engineering leadership.

The reality is engineering management has had poor visibility into their teams’ work long before they went remote. According to the “2020 Engineering Management and Alignment report,” this poor visibility has led to a misunderstanding and misrepresentation at the highest levels of what types of work need to get done and how many resources they’ll require. The report found, for example, that engineering leaders polled overestimated the amount of resources available for road map and new feature work by 62%! Without a more complete understanding of what work is being done, the study asked, how can engineering leaders take corrective actions and ensure the right projects are being prioritized?

But not all is lost in this regard. The study also found that visibility dramatically increases, by 60% on average, on engineering teams that have implemented engineering management platforms. Those teams report 16% less time spent on customer support work and 35% more time available to work on “road map work or strategic customer development—the work that moves the business forward.”

Ensuring alignment with the business is critically important for technical leaders during times of uncertainty. If you can get ahead of these misconceptions, you will better enable your team for success now and in the future. Data-driven engineering leaders already know this to be true when times are good and resources are easier to come by. If you’re not already, strike the misconceptions your business leaders may have by sharing the realities on your team.

November 2, 2020