After watching this video, you will be able to explain the importance of consequences,
describe how functional silos lead to apathy, and identify your organizational DevOps objective.
Jez Humble, the author of the book Continuous Delivery, once said,
“Bad behavior arises when you abstract people away from the consequences of their actions.”
He was referring to the fact that silos abstract people away from the consequence
that their actions have on other silos because they don’t see them or feel the effect.
One example that Jez cites is a conversation he had with an engineering director.
They talked about a company that had a series of quality problems with their software.
They didn’t have a QA team, so they thought that hiring a QA team would resolve the problem.
Much to their surprise, the quality actually decreased.
One reason for this is because the developers felt that they were no longer
responsible for testing their code. Instead of being focused on quality,
they were now focused on getting their features into "test" as quickly as they could.
They figured that it’s QA team’s job to worry about quality.
They abstracted the development team away from the consequence of writing buggy code.
When the developers stopped testing, the QA team could not manage the increased volume of testing,
and the quality of the software actually went down.
This is why we say that functional silos breed bad behavior.
I personally don’t recommend having a QA team. I like making developers responsible
for all the tests so that they take pride in the quality of the code that they develop.
Actions have consequences. Here are two things you can do to avoid the problem.
You can create cross-functional teams
so that everyone is dealing with teammates instead of ticket queues.
If you can’t create cross-functional teams, then have the developers rotate through the operations
so they can feel empathy for what the operations engineers
do every day to keep their application running. You can also have the operations engineers join
the developer standups and their showcases so that they can understand what the developers are doing.
You can make people responsible by putting developers on pager duty or
having them own the service level agreement for the products and services they build.
It’s amazing, you only have to call a developer once or twice at Sunday at 3 a.m.
and they will start writing better code on Monday. So, put them in the on-call rotation and let
them feel the pain of operations and they will start writing better code.
The message is clear. If you abstract people away from the consequence of their actions,
they will become apathetic.
Your DevOps organizational
objective should be to attain a shared consciousness with distributed, local control.
You want everyone to understand the big picture of where you are going and what
you hope to accomplish, but you want to give them local control of how to accomplish it.
This empowers people to do their best work instead of waiting for orders from above.
As Werner Vogels, CTO of Amazon says, “You build it, you run it!”
There is no difference between Dev and Ops. Everyone is responsible for delivering value
to the customer, but you must give them the means to do it.
In this video, you learned that actions without consequences can lead to apathy.
Allowing teams to feel the effect of their actions fosters empathy,
resulting in higher-quality work. Your organizational DevOps objective
should be to attain a shared mindset and empower everyone to deliver customer value.