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.