After decades of separating operations and development teams, many are now shifting to what they call ‘DevOps’. But what is this DevOps thing, really?
If you ask 10 people for their definition of DevOps, you’ll get 10 different answers. Some of the variations I’ve heard include:
- Using continuous deployment to put software in production faster
- Having the development team solve support tickets
- Have the operations team build a platform for development teams to manage their own services
- Developing and maintaining software in cross-functional teams
- Empowering teams to be self-organizing
- Letting teams decide/solve how to run the d*mn thing
Most conversations I have about DevOps quickly turn to conversations about DevOps tooling: continuous integration/deployment, release management, automated testing, monitoring, etc.
That is like talking about twigs and leaves, instead of growing trees.
So forget about the tools for a second? Let’s talk about ownership. To me, that is what DevOps is almost entirely about. A team’s sense of ownership of their product / service / company.
Ownership
Ownership is caring about the users of your application; why are they using your products? What is their experience with it like? Are they happy using it? Frustrated? Do we even know what they are experiencing? How can we find out? How can we make it better, or faster?
It is also about quality and pride; how does the product feel? Does the code smell? Is there technical debt? Do we have confidence that it works as we expect it to do? Let’s write tests to make sure. Let’s make it simpler, more mission-critical, cleaner.
Feeling responsible for a service or application leads to the team’s desire to improve monitoring; to see what users are actually experiencing. It leads them to adapt tooling to release fixes and improvements to production more quickly, such as CI/CD, release management, containerized applications, etc.
It makes sense
Ownership translates to a relentless focus on quality for the end-user, adapting test-tooling, such as automated tests, integration tests, smoke tests. It leads to the desire to take responsibility for the whole chain.
And, most importantly, it helps drive that same spirit to other teams; to hold them accountable too, and empower them to use technology that helps them feel more like the owners of their domains as well.
Regardless of whether they are developers or operations teams. Ownership unites craftsmanship.
So in order to move your engineers to DevOps in a similar organic way, teams who are up to the challenge must take ownership.
And if you are in charge of making that cultural shift, all you need to do is empower your craftsmen. Support them in their efforts, and don’t let the old processes get in the way.
Let them grow the tree by finding the roots.
