The Beauty of Culture, the Incentives of DevOps
Traditional software development looks something like this:
- Product management defines the product specifications, gives it to technical leadership
- Technical leadership / architecture defines the technical specifications, gives it to the engineers
- Software engineering builds the product, gives it to quality assurance (QA)
- QA tests the product, sends it back to engineering to fix any failures, when passed gives it to operations
- Operations deploys the product, and maintains it in production
While this process varies somewhat in steps 1-2-3 for agile development, creating more of a feedback loop, the essentials of steps 3-4-5 remain the same.
In the last several years, the "Development Operations" or "DevOps" movement has grown. Under DevOps, the operations team does not deploy product or manage it or respond to issues with it. Rather, infrastructure engineering creates tools to allow the developers to deploy the product and be notified when there are issues.
Day-to-day operational responsibility for deploying and maintaining the software product itself (as opposed to the underlying infrastructure) belongs to the actual software development team.
While it seems simple, those who have been inside the software and online industries for the last decades recognize this as a radical shift. Never before was a software engineer given the right to deploy software into production, nor would they expect to be woken at 2am with a page about a failure; that was operations' problem!
The goal of DevOps was always to enable very rapid deployments. With ownership of individual software products in the hands of the engineers who built them, combined with the necessary tools to do so, they could deploy software as often as necessary to meet business needs, sometimes orders of magnitude more often than before.
In non-DevOps, online deployment of once a month is considered pretty frequent. DevOps-driven companies deploy as often as once a day, and some, like Etsy, multiple times per day. The business benefits and competitive advantages are enormous.
However, as I became aware in a conversation with an extremely talented - and business-conscious, which is rare - security, compliance and certification consultant, Daniel Blander, the most interesting part of DevOps is the culture change. When a software engineer is aware that:
- She can make the change whenever she is ready (not dependent on outside groups like QA or Operations); and
- If it breaks, she will be the one to be woken at 3am as first responder
then the software engineer has incredibly strong incentives to:
- Deliver value as quickly as possible
- Deliver as stable a product as possible
The incentives of each team owning the products it builds and deploys positively change the culture of the company.