Welcome to The Long View—where we peruse the news of the week and strip it to the essentials. Let’s work out what really matters.
This week: Passkeys is getting another big-tech supporter, and the four-day workweek train picks up speed. (more…)
Category: DevOps Culture
-
Kill the Password: Google on Board | 4-Day Week Proves Worthy
-
Five Great DevOps Job Opportunities
DevOps.com is now providing a weekly DevOps jobs report through which opportunities for DevOps professionals will be highlighted as part of an effort to better serve our audience.
Our goal in these challenging economic times is to make it easier for DevOps professionals to advance their careers.
Of course, the pool of available DevOps talent is still relatively constrained, so when one DevOps professional takes on a new role it tends to create an opportunity for others.
The five job postings shared this week are selected based on the company looking to hire, the vertical industry segment and, naturally, the pay scale being offered.
We’re also committed to providing additional insights into the state of the DevOps job market. In the meantime, for your consideration:
Indeed.com
Harnham
Remote
Senior DevOps Engineer
$160,000 to $180,000Monster.com
Riley Consulting Services
Folsom, CA.
Senior Full-Stack .Net Developer
$150,000 to $180,000LinkedIn
Flowhub
Remote
Senior DevOps Engineer
$140,000 to $160,000Dice.com
Northrup Grumman
Aurora, Col.
Senior Principal DevOps Engineering Lead
$120,000 to $180,000SimplyHired.com
OBMedia
Remote
Senior DevOps Engineer
$120,000 to $160,000 -
Linux 6.0 is Faster, Cooler | Debian Goes Proprietary | Google Africa Region
Welcome to
The Long View—where we peruse the news of the week and strip it to the essentials. Let’s work out what really matters.
This week: Linux 6.0 promoted to Stable, Debian 12 will include closed-source binaries, and Google Cloud opens its first Africa region. (more…)
-
How to Prevent Turnover in DevOps Teams
Turnover is all too common in software engineering. The Bureau of Labor Statistics 2021 report found that the average software engineer turnover is 57.3%. It’s a programmer’s market, and these sought-after folks might jump ship for a higher salary, better work-life balance, different team dynamic or perhaps even for a company with a better ESG footprint. Yet, constant changeups in a development team can stifle progress when there’s pressure to meet new digital demands and rapidly deliver new features.
IT skills shortages can impede innovation across the board. But turnover can be especially problematic in the field of DevOps, as the practice relies on collaboration between teams and a shared sense of operational standards. Here, a gap in shared knowledge can impair ongoing platform maintenance.
I recently met with Nathan Sutter, global VP of engineering at CoderPad, to examine the core reasons behind engineering turnover and look at specific ways to prevent it in DevOps teams. In a nutshell, he advocated for reducing context switching, giving both engineering and product teams a seat at the table and not underestimating your teammates’ flexibility.
Reduce Context Switching
Engineers like having ownership and pride around what they’re creating—take that away, and it can lead to burnout and even an exit from the company. The more you context switch, describes Sutter, the less you focus on building a core project and the less attached you feel to the code or architecture you’re creating. “Engineers like to build cool stuff, ship it, and use it,” he said.
Context switching may occur for a couple of reasons. First, it may just result from poor planning, in which case engineering time is wasted. Secondly, context switching might arise due to legitimate emergencies, such as incident response or necessary bug fixes. Furthermore, enterprises traditionally ship operational concerns to a production team, thus increasing the number of applications a developer oversees and decreasing their role in ongoing maintenance.
Instead, Sutter is a proponent of allowing developers to own everything about an application end-to-end. Essentially, the DevOps or infrastructure team builds the scaffolding and the application teams own the rest, such as writing Terraform configurations, Docker containerization, monitoring and alerts, and on-call assistance. In other words, you operate what you build and own the component throughout its entire lifecycle. This practice has already been embraced by full-cycle developers at Netflix.
Specifically, in DevOps, the on-call cycles can be challenging when you have so many things to own. “When you have 25 apps to look after, something is always going off,” said Sutter. “This is an “exhausting, thankless and horrific way to work.” This imbalance can affect the work-life balance and decrease your time to focus on upgrading core infrastructure.
Don’t Separate Engineering and Product Teams
Another setback that might manifest itself in turnover has to do with inefficiencies caused by siloed teams. For example, suppose a product team spends months outlining a complex software design in a black box. In that case, they will most likely encounter many issues once the schematics are finally sent to engineering teams. Without collaboration between the two groups earlier on, organizations can increase time-to-market for new features and encounter frustration between teams.
Instead, Sutter believes product and engineering teams should counterbalance each other and collaborate more in the product design phase. Whereas product teams can “skate where the puck is going” and identify trends in the market, engineering teams figure out how to technically implement these designs and build a sequence of work that’s scalable for the long-term. Of course, the other side rings true, too—engineers can overplay their hand and plan minute details too far into the future, described Sutter. This underpins a need for ongoing collaboration where both sides have a voice at the table.
Don’t Underestimate Flexibility
Even though software engineers like to have a sense of ownership, we shouldn’t discourage flexibility—people easily become bored working on the same thing for years and years. There’s also the fallacy of sunk cost to keep in mind, which states that we tend to value things more because we’ve put more time and effort into them. Thus, providing flexibility to pivot when it makes sense can increase overall satisfaction and output.
Accordingly, flexible management is also crucial to embrace pivots when they are necessary. For example, if a project is well underway but an engineer identifies a new solution that is more elegant, team leads should be open to recognizing and acting on changes. But to realize this sort of relationship, trust and openness must be bidirectional, said Sutter. If engineers can’t express their ideas or are afraid to tell their boss they’re wrong, these important conversations can’t happen.
A flexible structure is also necessary to attract talent that prefers more modern work-life balance. As big tech companies with multimillion-dollar commercial leases now want workers to return to physical offices, small-to-medium companies now have an unprecedented upper hand to attract and retain talent if they embrace flexible remote-hybrid working options, added Sutter.
What Matters Most?
The majority of developers working on open source projects are open to changing jobs in 2022, according to the EDB Open Source Talent Survey. Job satisfaction is challenging to wrap your head around, and each engineer may be motivated by various reasons.
But having assembled and led many software engineering teams over the years, Sutter recognized an interesting change in the attitudes of what matters most to software engineers in their day-to-day job. Pre-COVID, software engineers were definitely interested in higher compensation, he said. After that, it was building something they’re proud of, team camaraderie, the worth of a brand name and a positive work-life balance. Post-COVID, compensation and other benefits are still just as valid. Yet, hybrid flexibility is often table-stakes—some are even willing to take a pay cut to obtain these benefits. This underscores the high importance of flexibility in managing modern software engineering teams.
Executives and engineering leads have their work cut out for them when it comes to obtaining and retaining top talent. Yet interestingly, many roadblocks are not so much technical problems but people and organizational problems. As we’ve covered, reducing context-switching and placing more ownership on singular products could increase satisfaction. One of the tenets of DevOps is also de-siloing teams to increase collaboration. Reducing toil could also go a long way toward increasing satisfaction. Whatever your chosen strategy, it’s always good to “display openness and understanding to hear people when they’re not happy,” said Sutter.
-
Driving Organizational Success With the 2022 State of DevOps Report
“Ship it!”
We have just completed the research and analysis for the 2022 Accelerate State of DevOps Report (SODR) and oh boy, do we have some interesting things to share! First, let me take a short step back for those of you that may be new to the DevOps Research and Assessment (DORA) and our annual report, the SODR. DORA is an academically rigorous research program that seeks to answer the questions, “What practices enable teams to be high-performing software teams? And how do these practices impact organizational performance?”
Since 2014, we have surveyed 33,000 practitioners around the world spanning all major industries. The project is intentionally–and staunchly–tool- and platform-agnostic. The research builds on itself, and each year we seek to both evaluate previous findings and expand in other directions or areas of research. This is important to note because many of the core findings, such as “software delivery performance drives organizational performance,” have been validated year after year. I would encourage you to go back and read all the reports from years past.
Security
This year, we doubled down on our 2021 research into software supply chain security by looking at the technical practices that improve software supply chain security and the non-technical practices that impact an organization’s ability to excel at securing their software supply chains. We leveraged two frameworks to focus our research: Supply Chain Levels for Software Artifacts (SLSA) and NIST’s Secure Software Development Framework (SSDF). Below is a summary of some of our key findings in this area:
- Shifting left on security is a broadly adopted practice. Our research shows that two-thirds of respondents are actively pursuing software supply chain security by seamlessly baking security into the development process.
- Culture is the primary driver of security practice adoption. One might expect that technology is the primary driver, but our research showed that a generative organizational culture (eg. performance-oriented, highly cooperative, shared risk) leads to healthier software practices.
- Technical practices around CI/CD predict success in security. Companies that use source control, continuous integration (CI) and continuous delivery (CD) have more established SLSA practices. These practices shift security left to the developers and ensure consistent security scanning.
- Cloud enables secure software practices. The five characteristics of cloud computing as defined by NIST enable the successful adoption of software supply chain security which, in turn, predicts greater organizational performance.
Our research showed that companies who prioritize and excel at securing the software supply chain experienced fewer service outages, anticipate fewer security breaches and demonstrate high levels of both software delivery performance and organizational performance. The data showed that through the use of modern practices like continuous integration, teams can improve their security posture and even amplify the positive impact these security practices have on software delivery metrics (MTTR, deployment frequency, lead time-to-restore service) and overall organizational performance.
Culture
We saw above that the biggest predictor of an organization’s application development security practices was the presence of a generative organizational culture based on shared risk and information sharing. We also see that elements of these types of cultures lead to higher overall organizational performance, as well. Our research showed that high organizational performance can be achieved by fostering environments that are:
- Supportive: Teams that felt supported and that they had buy-in from leadership (e.g., more financial support, more allocation of resources, sponsorships, etc.) were associated with high-performing organizations.
- Stable: Teams that did not experience much change in membership over the last 12 months were more likely to be a part of high-performing organizations.
- Flexible: Organizations with higher levels of working flexibility around where work was performed–remote, in-person or hybrid–were higher-performing overall.
We also looked at burnout again this year and expanded the scope to understand which elements of culture contributed to lower levels of burnout. We found that generative culture, team stability and work flexibility all contributed to a reduction in burnout among employees.
Reliability
In previous years, our research told us that those that excelled in technical practices also excelled at organizational performance. This year, we have more nuanced data about this topic. This year, we saw that software delivery does not predict strong business outcomes unless these practices were paired with reliability. Think about it–will a customer be satisfied with new features if the service isn’t stable? What is the benefit of pushing code quickly into a fragile environment? Reliability is an essential component of driving organizational performance through software delivery performance.
We also see that site reliability engineering’s (SRE’s) impact on organizational performance is non-linear; reliability engineering practices often do not result in additional reliability or organizational performance until a certain maturity is reached. It’s important for teams to know this and approach their SRE practice as an investment. It will likely not be sparkly ponies and unicorns initially as you build the reliability muscle but, as you advance, high performance and success are likely.
Cloud
Public cloud use is up a whopping 36% over 2021, whereas companies reporting no cloud usage at all are down by 50%. The use of hybrid cloud is up by 25%. Unsurprisingly, the use of cloud computing was associated with higher organizational performance. In past years we saw that it wasn’t “using cloud” per se that led to organizational performance, rather it was the achievement of the five essential characteristics of cloud computing–on-demand self-service, broad network access, resource pooling, rapid elasticity and measured service. This year, we saw that cloud computing enabled things like reliability, continuous delivery and improved supply chain security which drive organizational success.
Over 50% of folks who took our survey reported that they leveraged multiple cloud providers. We asked respondents what benefits they realized from using multiple cloud providers. Here are the top three:
- Availability
- Leveraging the unique benefits of each provider
- Trust is spread across multiple providers
Given the fact that reliability seemed to be the key to being a successful software delivery shop as well as a successful organization, it is not surprising to see availability listed by almost 63% of respondents as a benefit derived from using multiple clouds.
Summary
Our research continues to progress and we continue to dig deeper and deeper into the capabilities and practices that impact your business. We see broad adoption on the topics of security and reliability which are both heavily anchored in culture. Good culture leads to success. Period. There is no magic culture button and it takes work, but it is very achievable. Start by defining organization-wide or line-of-business-wide goals and then just start continuously improving. Don’t worry about creating a three-year plan for improvement; create a one-month plan and just get to work instead. At the end of that month, evaluate your learnings, refine your focus and get back to work. With a commitment to hard work and continuous improvement, your investments should start paying off and, as an added bonus, you’ll have a better culture.
We hope you have enjoyed these juicy findings as much as we have and we encourage you to read the entire 2022 State of DevOps Report.
Also, please join us at dora.community to continue the discussion about these findings and to share and discuss your experiences on your journey toward excellent software delivery and operations.
-
Is DevOps Dead? I Don’t Think So!
A lesson I have learned over my 30 years in the tech world is that technology and frameworks never truly die—they evolve and they grow. When I read a recent article proclaiming, “DevOps is dead!” and that we should all be embracing platform engineering, I had a chuckle.
No, DevOps isn’t dead, and rumors of its demise have been greatly exaggerated. In fact, DevOps is more alive than ever and the truth is, it is going wherever software goes. When I went back and read the article again, I realized that it appeared on a website owned by a venture capital (VC) company and that the article itself was a sponsored post from a company promoting platform engineering. That’s a good reminder to take that article with a grain of salt. I also realized that the headline was meant to be controversial, if not downright clickbait.
That said, I feel that the article demands a rebuttal. To be fair to the author of that article, I believe the point they were trying to make is that there is a major issue with DevOps—we have put too much on the developers’ plates, and that one more straw may break the proverbial camel’s back. Certainly, this is a valid point. We need to balance what we ask our developers to do in relation to the rest of the team. We see this with security in DevSecOps; we see it with testing and we certainly see it with operations. In fact, in many ways, the rise of the SRE has better defined the ops role thereby lessening the load on developers.
I have no doubt that platform engineering will also lessen the load on developers and better define the role of a platform engineer. However, SRE did not kill DevOps and neither will platform engineering. At one time, it was very fashionable to talk about a full-stack developer. Today, many people think that the so-called full-stack developer is a myth and that role is not really what is needed in most organizations. The job of a developer, though, is never and will never be easy, even with the advent of AI/ML-generated code. The developer always has many plates spinning in the air at any given time. And to that point, the high levels of compensation they are paid is not unwarranted nor is it unearned.
I look forward to seeing how the platform engineer role and platform engineering as a practice evolve and how they interact with SREs and DevOps teams as well as developers, security testers, etc., but I am fairly certain that no matter how the role evolves, it will not be the death knell for DevOps.
As we proclaimed for our upcoming DevOps Experience event on November 16, 2022, it is going where no DevOps has gone before. We see DevOps-of-things; we see DevOps at the edge. We see distributed DevOps, too. DevOps has taken root in our software development life cycle and beyond. While the frameworks may change and evolve, DevOps changes and evolves with it.
If you say DevOps is dead, I disagree. I say long live DevOps!
-
Five Great DevOps Jobs Opportunities
DevOps.com is now providing a weekly DevOps jobs report through which opportunities for DevOps professionals will be highlighted as part of an effort to better serve our audience.
Our goal in these challenging economic times is to make it easier for DevOps professionals to advance their careers. Of course, the pool of available DevOps talent is still relatively constrained, so when one DevOps professional takes on a new role, it creates an opportunity for others.
The five job postings shared this week are selected based on the company looking to hire, the vertical industry segment and, naturally, the pay scale offered.
We’re also committed to providing additional insights into the state of the DevOps job market. In the meantime, for your consideration:
Indeed.com
Level Home
Redwood City, California
DevOps/SRE Manager
$175,000 to $275,000Monster.com
Jobot
Houston, Texas
Senior DevOps Engineer
$150,000 to $180,000LinkedIn
Lenovo
Colorado, New York City, Nevada and Washington
Software DevOps
$125,000 to $145,000SimplyHired
Spring Health
New York, New York
DevOps Engineer
$110,000 to $150,000Dice.com
Black Knight, Inc.
Remote
DevOps Engineer III
$91,000 to $125,000 -
Atlassian Aims to Improve Collaboration With DevOps Teams
At an Atlassian Presents: WorkLife event today, Atlassian furthered its efforts to integrate the tools technology and business professionals use to manage processes.
Erika Trautman, general manager and vice president of product for Work Management for All at Atlassian, said that as organizations increasingly rely on digital processes to engage customers, partners and employees, the need to facilitate collaboration across a diverse set of knowledge workers is becoming more pressing.
As part of that effort, Atlassian is now making generally available a Smart Links capability within the Atlassian platform. Smart Links can be used to integrate both Atlassian applications such as Trello and Jira as well as third-party applications. That capability is now critical because there has been a Cambrian explosion of adoption of software-as-a-service (SaaS) applications that all need to be integrated into a common set of workflows, noted Trautman. Otherwise, each SaaS application environment becomes yet another walled garden that prevents any meaningful collaboration, she added.
In addition, the company announced that Atlas, a directory that tracks projects and simplifies communications across teams using disparate applications, will become generally available next month. DevOps teams, for example, will be able to synchronize Jira events with projects being tracked via the Atlas platform.
Atlassian has also streamlined the tools it provides to reduce the number of steps required to administer its applications and onboard new users.
Finally, the company also has launched Atlassian Together, a single subscription offering through which organizations can license its Trello, Confluence, Atlas and Jira Work Management applications delivered via the cloud. An enterprise organization with more than 5,000 users can now, for example, license those applications for $11 per user.
Atlassian is making a concerted effort to enable organizations to more easily collaborate at a time when they have become more dependent on software than ever, noted Trautman. In many cases, businesses are now trying to adjust to the rapid rate at which software is being delivered thanks to the adoption of DevOps best practices, she noted.
As such, there is a greater need for integration between tools such as Jira that development teams use to manage projects and a wide range of tools used by knowledge workers residing in various departments, said Trautman. In effect, Atlassian is trying to enable organizations to reduce the “collaboration tax” they incur as workflows span multiple silos, she added.
In fact, in many cases, organizations are struggling to keep pace with how agile software development teams have become. The irony is that not too long ago business executives routinely complained about how long it took IT organizations to adjust as business conditions changed. Now, many businesses are rolling out additional digital capabilities via software updates that can be made multiple times a month.
The rate at which organizations will collaborate across departments will naturally vary, but the days when each department was a fiefdom unto itself are coming to an end. The challenge and opportunity may now be determining how modern organizations should be structured once it becomes easier to collaborate.
-
‘The OG App’ Devs’ Facebook Ban | WFH Vs. NYC Real Estate | Calif. Pay Law is GO
Welcome to
The Long View—where we peruse the news of the week and strip it to the essentials. Let’s work out what really matters.
This week: A third-party Instagram app causes ructions, remote work causes office slump, and more on Cali’s salary transparency law. (more…)
-
Latest DORA Report From Google Surfaces Raft of DevOps Challenges
The annual Accelerate State of DevOps 2022 report published today by the DevOps Research and Assessment (DORA) team at Google found the percentage of high performers is at a four-year low, with the percentage of low performers rising dramatically from 7% in 2021 to 19% in 2022.
Based on a survey of 1,350 DevOps professionals, the report evaluated organizations based on the five DORA metrics: Deployment frequency, lead time for changes, time to restore service, change failure rate and operational performance. The DORA team also identified clusters of DevOps teams ranging from “starters” to “flowing” based on their overall maturity. Only 17% of respondents achieved a ‘flow’ state defined by high reliability, high stability and high throughput characteristics.
The DORA survey sample shifted this year to include more respondents that are earlier in their careers than in previous reports. However, Claire Peters, DORA research lead at Google, said that while there are a lot of factors that impact those metrics, the current hypothesis is that the COVID-19 pandemic has taken a toll on DevOps productivity as more DevOps professionals continue to work remotely.
The report noted a marked shift in deployment targets requiring new skills, with 54% of respondents now working with container artifacts.
Overall, the report finds software delivery performance is beneficial to organizational performance when operational performance is also high. The challenge is the number of organizations that have achieved high operational performance is relatively small. In fact, the report also noted that site reliability engineering (SRE) practices had a negative impact on software delivery performance until an organization achieved a high level of SRE maturity.
The report also concluded that organizations that built software on and for the cloud tended to have 1.4 times higher organizational performance than those that didn’t. The percentage of respondents using public clouds is 76%, up from 56% in 2021, while the number of respondents not using a cloud stands at 10.5%. Usage of multiple public clouds is at 26%, while 35% reported using a private cloud.
Less clear is the impact on DevOps teams of shifting application security left. The report suggested the biggest challenge organizations face when it comes to achieving application security have more to do with cultural issues than any technical shortcomings. The report notes that organizations that focus on accelerating software delivery without implementing meaningful DevSecOps best practices find themselves in a vicious counterproductive cycle that results in applications being successfully deployed in production environments less often.
Peters noted that there is greater developer fatigue because organizations attempt to address security issues either just before an application is deployed or they remediate applications after they are deployed. Organizations that have low levels of security practices are 1.4 times more likely to experience developer burnout.
The DORA team used both the supply-chain levels for secure artifacts (SLSA) framework defined by Google and the Secure Software Development Framework (SSDF) defined by the National Institute of Standards (NIST) to evaluate organizations. The most widely-adopted practice is application security scanning within a continuous integration/continuous delivery (CI/CD) system, with 63% of respondents reporting these tools are “very” or “completely” established. Preserving code history and using build scripts are also highly established, the report finds.
In general, Peters said the report suggested the biggest predictor of application security success was whether an organization had a high-trust, low-blame culture focused on performance. Organizations that have these cultures tend to have higher organizational performance. Similarly, organizations with teams that felt supported through funding and leadership sponsorships tended to have higher organizational performance, the report noted. In addition, team stability and positive perceptions about one’s team also tended to lead to higher levels of organizational performance. Lastly, companies that offer flexible work arrangements tended to see higher levels of organizational performance.
Each organization, as always, will implement DevOps best practices in ways that best fit its internal culture. However, the latest DORA report makes it clear that the more empowered a DevOps team is the more proficient they tend to become.