Design Thinking and DevOps
The job title was DevOps, that was the first red flag
There appears to be a common misconception that “DevOps” is a job title that describes the role of an engineer who is responsible for automating IT operational practices (such as deploying new code). This job title represents a fundamental misunderstanding of what DevOps is. DevOps actually refers to the culture of an engineering team that includes both Developers and Operators.
Why is DevOps a “culture”
In a traditional IT Environment the Development team is focused on delivering new features as quickly as possible; When they complete a release they “throw it over the wall” to Operations for deployment. The Operations team is focused on making sure that the application is always up and running. They know from experience that the best way to bring the system down is to deploy new code, so they are naturally at odds with the goals of the Development team. Instead of two separate departments that are constantly at odds with each other, DevOps is an approach to “tear down the wall” between Developers and Operations.
Tearing down this wall requires software developers to be involved in operations, and operators to embrace the risk of rolling out new code. DevOps is a culture that by its nature is more prone to internal collaboration and greater interpersonal understanding between teammates. I would question any potential employer who advertises for a DevOps Engineer, to make sure they understand that DevOps is a culture, and SRE is a job title.
Automating IT with Design Thinking
As software engineers, we recognize that the value we create for many users is one of improved productivity. If we want to engineer our own productivity improvements, we can start by Focusing on User Outcomes - and recognize that, in this case, the engineer is the user. By taking a human centered approach to DevOps, and focusing on designing a delightful developer and operator experience, you can build an exceptional DevOps culture.
Incident Retrospectives
Another example of how Design Thinking can be used to improve DevOps practices is in the area of incident retrospectives. Effective incident management depends on retrospectives that identify root cause, and more importantly potential remediations. The Design Thinking retrospective exercise is a great tool to rapidly accomplish these goals in a blame-free environment. Of course all of this needs to exist within a service management framework, but Design Thinking and Service Management is a topic for another post.
How to get started
When departments break down walls with the intention of developing a deeper understanding of one anothers roadblocks and triumphs, businesses thrive. This particular type of practiced, intentional collaboration is infectious and is rarely contained within the development and operations spaces alone. DevOps culture is one of the Cloud Native innovations that is commonly misunderstood. Design Thinking will drive a healthy DevOps culture, just as an Open Source Culture will reinforce community in a DevOps team. Any attempt to implement a DevOps culture will be more likely to succeed if you have a good roadmap. A shared understanding of the meaningful outcomes will serve as the foundation for building an effective DevOps culture. If you need help building a DevOps culture, or your attempts at using modern DevOps tools have not lived up to the hype, reach out and schedule a free 30 Minute consultation.