DevOps as a Title
Whenever I discuss DevOps with someone outside of engineering, there is a common theme to their reaction, something along the lines of, "Oh, is that a new position in IT?"
This bothers me because it implies DevOps:
- is new, and somehow duct-taped onto IT;
- is the responsibility of someone or a small group;
- that someone is not them.
In some ways, this reaction is not wrong. Organizations often have people with titles like DevOps Engineer, DevOps System Admin, DevOps architect; all imply that one person is responsible for DevOps. It ties DevOps to a title and makes it their job. Or worse, it implies you can stick DevOps in front of SysAdmin, and viola, you are doing DevOps. This checks the box, but does not deliver the true benefit of DevOps.
Examine high-performing organizations where DevOps has reached wide adoption, and you will see this reaction is quite wrong. In these organizations, it is not simply a job title constrained to an individual or even a small team. It is a philosophy adopted by the entire organization.
DevOps as a Philosophy
When DevOps is approached as a philosophy, it becomes:
- A company-wide priority, not duct taped on;
- Everyone's responsibility, not an individual's;
- A personal responsibility for everyone in the organization.
It might seem odd, but in practice, it further breaks down silos of action and communication. It becomes part of the culture, part of hiring and training for everyone. From support to QA, development to operations, all the way up to management. Everyone feels empowered and approaches their activities as part of the larger initiative of delivering features the customers want, more quickly, and with fewer bugs.
This philosophical approach at an organizational level has historical precedent. Lean was never a job title in manufacturing. There were no Lean production managers, there were just production managers. Instead, Lean was the philosophy Toyota applied to how they manufactured cars across the entire organization. It was not one person's responsibility to improve quality, it was everyone's. Toyota's transformation from also-ran to market leader in just a few short years is evidence a philosophical approach is a winning approach.
Adopting a new philosophy will impact many areas of the organization, and might even be painful. But it will be worth it. Most of all it is a journey. A methodical movement toward the goal of delivering more value, fewer bugs, more efficiently.
Originally posted on DevOps.com: