DevOps And Culture: The Evolution Of DevOps In The Tech Industry

DevOps And Culture: The Evolution Of DevOps In The Tech Industry

September 2016


“Culture” has been a hot topic of conversation in the corporate world for decades. But up until a few years ago, saying the “c”-word around tech types was likely to be met with an eye roll and a prompt end to the conversation.

This certainly isn’t the case anymore and it’s due, in large part, to increasing awareness that the tech industry is collectively living through some significantly disruptive transformations.

The tech landscape has evolved significantly in recent decades. Constant innovation in the space has forced these companies to rethink and reinvent how they compete in the market. And the more I learn about these changes, the more I’ve become entranced with movements like DevOps.

DevOps as a cultural shift within the tech community calls into question the fundamental bedrocks of how work used to be done in order to remain competitive in today’s rapidly evolving business environment.

In order to conduct a deeper exploration into the topic and help provide some additional perspective, I was fortunate to spend some time with members of the leadership team at Sumo Logic, a cloud-based platform from the Bay Area that provides machine data analytics for modern web applications.

Ramin Sayar (CEO) and Christian Beedgen (CTO) shared their insights on the DevOps discussion, including lessons learned from supporting their 1000 plus clients in their efforts to drive speed and quality, as well as their own experiences living the evolution within their own organization.

Rethinking the Fundamentals

For those of us who do all we can to simply navigate our laptop and company intranet to get through the day (I put myself firmly in this camp), let me break it down for you in terms we can all likely relate to.

Change in the tech landscape is nothing new, but some of these disruptions and innovations have forced business leaders to reexamine their fundamental approach to meeting the needs of their customer base. These constant developments have forced experimentation with new ways of working in order to stay ahead of competitors and avoid the risk of extinction.

Consider the evolution of philosophical approaches to work in the tech space, from Waterfall to Agile to DevOps, and now the current continued evolutionary discussions toward concepts like DevOpsSec. These changes in approach were spawned out of the fundamental desire to deliver products to customers with more speed and quality, but they did not develop in a vacuum.

Technological innovations forced the industry, at key points, to reinvent their approaches entirely. The advent of cloud computing, for example, brought about the transformation of many historically product-based solutions into software as a service (SAAS); selling services versus products.

These developments created an opportunity to realize significant gains in velocity. Tech companies who could successfully adapt to these new ways of working were able to launch updates to their applications faster, going from what once was weeks or months cycle time, to days or mere hours. This increase in velocity means delivering value to your customers in ways that your competitors can’t.

In order to make this leap, however, people must radically change their behaviors. And, it requires an organizational change in systems and processes to facilitate and sustain these behavioral changes. For an industry where many roles were used to operating in functional silos, this requires some radical behavioral change. And, thus, the DevOps movement was born.

“Companies like Facebook, PayPal and eBay began to bring these disparate functional roles together in order to share accountability and to mitigate risk,” says Sayar. “The complexity of this way of working drove the desire for more standardization, and people from different functions began coming together.”

Unfortunately, just “coming together” doesn’t always move groups forward to work together effectively and sustainably in ways that drive the performance companies are looking for. Most people still come to the collaboration holding on to their preexisting beliefs and assumptions about their role, and the roles of others in the process.

Whether innovations or industry changes are internal or driven by the competitive landscape, tech firms must learn to identify these trends and develop the ability to adapt quickly in order to remain competitive. If they don’t, they inevitably fall into the position of trying to play catch-up as they lose market share and quickly become irrelevant.

How Has the DevOps Cultural Shift Played Out So Far?

Beedgen suggests that, “DevOps is not a job, it’s not a thing. It’s a philosophical way to solve a business problem. In an industry where functional boundaries develop quickly, the DevOps way of working creates cross-functional teams that are reliant on each other for mutual success.”

In years past, developers, for example, were not held accountable to the end delivery to the customer but, rather, were singularly focused on adding new functionality. The DevOps movement has changed this with all areas of the process. Now, cross-disciplinary teams collaborate and have a stake in the entire process in the name of increasing velocity and quality.

Aaron Feigin, VP of Marketing and Communications at Sumo Logic, adds, “The entire change is grounded in the question of what companies need to do: they need to deliver value more quickly. Cloud computing was a major disruption to the way things had always been done, because it removed the infrastructure provisioning barrier to experimentation, and DevOps is a massive organizational shift that allows tech firms to more rapidly meet the needs of their customers.”

“DevOps is not an option anymore,” states Beedgen. The real question now is how the concepts of the DevOps philosophy will expand outward to include other functional work groups?

Bottom line: Transitioning to a DevOps work environment is not as simple as making a declaration or changing job titles. It seems that many of the learnings are happening informally and organically across organizations as companies learn what works and what doesn’t.

What Has Sumo Logic Learned in Their Efforts to Move to a DevOps Working Environment?

The Sumo Logic team had the following advice for other firms looking to transition to a DevOps way of working:

  1. It’s about seeing things from different perspectives. Sumo rotates staff around to different roles so that they can learn to see the process from multiple perspectives.
  2. Cross-functional teaming is the core. In addition, the team at Sumo Logic developed Product Development Units (PDUs), cross-functional teams that cut across functional boundaries in order to eliminate some of the hang-ups that can slow things down.
  3. It’s about awareness and collective learning. For the team at Sumo Logic, success in the transition to a DevOps operating environment stems from creating a shared culture that values collaboration and velocity. By continuing to engage members of the team in creating a shared understanding of what DevOps is and isn’t, and how people will need to work together to deliver to their customers, the team at Sumo has been able to transform the way they work in the day-to-day.
  4. Make customers your focus. When you make the needs of the customer the top priority, you begin to change the conversation at its core. This focus opens the door for people to explore how they may think about working differently to deliver value faster.
  5. It takes time and collective experiences. Talking in philosophical terms about changing the way things are done is one thing. Actually doing it in a sustainable way that drives results is another thing altogether. This isn’t something that just happens. It takes intense focus, dialogue and collective learning to help prove to people that this new way of working does, in fact, add value to the customer.

The tech industry, in many ways, can be biased toward technical solutions to all problems. While the industry in general admittedly values quickly learning from successes and failures in a rapid, iterative way to shape the future and adapt to compete in the market, I believe that we’ve still only begun to scratch the surface on how the people and culture sides of the equation can be leveraged to more efficiently and effectively mitigate risk and drive speed during these evolutionary processes. DevOps will, no doubt, evolve to some other way of working as new disruptors enter make their entrance. And these events will inevitably force tech firms to reexamine the way in which they work all over again.

Technology infrastructure will certainly play no small role in supporting these transitions. But finding ways to shape the other cultural aspects to enable people to adapt their behaviors for success in the new operating environment is just as important. While sharing best practices and learnings informally across the industry is certainly helpful in increasing our shared understanding of what works and what doesn’t, I can’t help but wonder if it’s high time for a more formal approach to supporting people through these evolutions in ways that expedite the change and mitigate performance risks.

In future articles, we will explore some of the best practices the tech industry can learn from other industries in order to help continue to drive velocity and quality in their efforts to support the success of their organizations and their customers.

Chris Cancialosi, Ph.D., is a Partner and Founder at gothamCulture.


This article was written by Chris Cancialosi from Forbes and was legally licensed through the NewsCred publisher network.

BNY Mellon is the corporate brand of The Bank of New York Mellon Corporation and may be used as a generic term to reference the corporation as a whole and/or its various subsidiaries generally.  This material does not constitute a recommendation by BNY Mellon of any kind.  The information herein is not intended to provide tax, legal, investment, accounting, financial or other professional advice on any matter, and should not be used or relied upon as such.  The views expressed within this material are those of the contributors and not necessarily those of BNY Mellon.  BNY Mellon has not independently verified the information contained in this material and makes no representation as to the accuracy, completeness, timeliness, merchantability or fitness for a specific purpose of the information provided in this material.  BNY Mellon assumes no direct or consequential liability for any errors in or reliance upon this material.