DevOps is a grassroots movement born from the passions of practitioners dissatisfied with the cultural and functional deficiencies endemic to functionally oriented (aka silo’d) organizations. The tools these practitioners employed and developed including Chef, Vagrant, Juju, Hudson and Logstash (to name a few) codified their collective feelings of how development and operations could work better together. These pioneers in effect duct taped together the development and operations teams – covering a chasm characterized by differences in culture, goals, leadership, philosophies, and toolsets. This technological equivalent of a “redneck” fix has been successful, but it is also time to see it for what it really is: the treatment for a symptom of the underlying outdated organizational concepts. For all that DevOps provides it cannot treat the many other symptoms of suboptimal organization construction. These include low levels of innovation, higher than necessary levels of conflict, and slower than necessary time-to-market. Why continue to duct tape together a poorly designed system? It’s time to replace the broken system and its temporary repair with one that works.
A functionally aligned technology group is a biped with a foot planted in two disjointed pasts, neither of which have a future in modern online products. One “foot” is planted in the world of corporate IT, where hosting platforms and enterprise architectures were defined to allow heterogeneous third party systems to coexist in a single, cost effective and easy to manage environment. Because IT is typically considered a cost center, the primary driver year-on-year is to reduce cost on a per employee basis. One way to do this is to standardize on infrastructure and require that third party providers conform to corporate standards – shifting the burden of cost of integration to those third party providers. Hence was born the traditional infrastructure and operations groups found within today’s technology organizations. These organizations and their solutions are awesome if you are integrating third party solutions – they are the last nail on your coffin if you are developing a product.
The other “foot” is planted in the past of packaged or “on-premise” software providers. In this past (heavy emphasis on the past), the software developer was king. Job one was to produce software that customers would buy. Forget about running it – who cares – that’s someone else’s job. In this past there was no infrastructure team. We just eat requirements and poop software. Sales engineers and systems integrators are responsible for figuring out how to shoe horn generic software into a wide variety of customer environments. As archaic and dysfunctional as this approach sounds, it actually worked because there was alignment between what the producing company created (software) and what the purchasing company bought (software). But it doesn’t work anymore because no one buys software. Get over it.
Today customers buy SERVICES not software. The mindset shift necessary to be successful in this new world is that the raw materials comprising these services are equal parts software and hardware (infrastructure). If your team doesn’t combine these raw materials purposefully, the resulting service won’t be as good as it should be. Continuing to “produce” software and “host it” on infrastructure is a recipe for suboptimal results at best and a possibly a disaster.
It’s time to move on from both functional organizations (e.g. Operations, Infrastructure, Software, QA) and the DevOps solution that duct tapes them together to organizations that can more easily design, implement and deploy these services. Organize your teams into cross-functional, experientially diverse, autonomous teams that own distinct services within your product. Each team and service should be driven by business focused KPIs. These teams should be self-sufficient enough to develop, deploy, and support their service without having to rely on other teams.
We understand this leap isn’t easy, and we are here to help. To be successful you must evolve both your architecture and your organization such that the two are compatible. In so doing, our clients experience higher levels of innovation, faster time-to-market, and lower levels of conflict than those that adopt a DevOps only duct tape solution. We call this approach to organizing the “Agile Organization”. To help our clients evolve to experientially diverse teams, we often introduce as a starting point a concept that we call “GrowthOps”. GrowthOps differs from the traditional DevOps approach in that it starts with an understanding of the desired outcomes of a product in terms of business KPIs (key drivers of growth for instance). Rather than trying to duct-tape organizations together, we start by aligning disparate organizational objectives and focusing on customer value creation. We then add in all of the tools necessary to speed time to market and monitor core KPIs. This unique approach establishes a firm foundation for a company to grow – be that growing from on-premise to SaaS, growing from collocation centers into the cloud, or growing because of customer demand – and allows for an easier subsequent transition to the Agile Organization.
We love duct tape as much as the next person but it’s time organizations stopped using these types of solutions and get to the real root-cause of the friction between development and operations. Only by embracing the true root causes and fixing the organizational issues can teams get out of their own way and grow effectively. Implementing GrowthOps as a first step and ultimately transitioning to the Agile Organization is a proven recipe for success.