Interestingly, my middle son really struggles to remember to take his allergy drops. I know, right?! You would think that someone with the irritating condition of dealing with physical reactions to something like pollen would be interested in following through with his treatment, and yet without the constant push from his parents, it seems Justin prefers his symptoms over being responsible for his own treatment. So, we control him. We ask, yank him out of bed to get it done, and otherwise focus mental energy and effort on ensuring he does what is best for him.
Sigh. The struggle is real, people! I’m beginning to wonder if our efforts to control him are killing his will to be responsible. If he knows we are there to make it happen, does he really need to concern himself with it at all? Haven’t I established that I will take responsibility for his treatment, therefore he is off the hook? What is the proper balance of control vs. responsibility?
In our companies, we see similar challenges with regards to control killing the sense of responsibility. When we centralize a team around, let’s say, networking, what gets communicated to the rest of the organization is that ‘you are no longer responsible for anything related to the network.’ So, let’s peel that apart a bit because such organizational structure can help or have detrimental effects on our digital transformation efforts.
Let’s start by breaking down the development life-cycle. When we have a great software idea as a start up, developers build it, test it, and get it to customers to prove whether we can make a difference in the lives of our users. When we grow, we add some help for the developers – a software quality team! This team is chartered with the responsibility to test the developer’s code to ensure it measures up, meets customer requirements, and generally won’t break under pressure. So, what did we communicate to the developers? We probably communicated that maybe we don’t trust them, and they are no longer responsible for testing, and are much less responsible for quality. There is a quality team in charge of that! So, developers focus more heavily on delivering code on time and under budget as those are the primary measures they now care about.
How might this play out in a real-world enterprise? Well, we might find that the development team gets recognized/awarded for getting to ‘code complete’ on time. Then, the QA team finds bugs and drives the development team to fix those problems, but eventually the code makes it to production. However, something slipped through. Some bug causes the application to melt down in production, customers are impacted, pain ensues for the enterprise. So, the developers work through the weekend to fix the bug and get our company back to running well … and we award them a second time! So, here’s the challenge: who was responsible for the outage? Well, that depends on your point of view. Shouldn’t QA have prevented the break down through their testing? Why didn’t development know this was a possibility? What about the performance teams? Was it networking that didn’t provide a clean pre-production environment for the test team to use? Was it patching of operating systems from Operations? Well, all of those things are controlled by other teams, so – no one is responsible. Or, we were all responsible? Who controls and ‘owns’ all of this?
Thus, we run headlong into DevOps. Developer Operations is not a tool chain. It is also not a team. It is a chain of responsibility. It is a development team owning their code through to production. It is a culture that says that ‘the buck stops here.’ It is taking responsibility as no one controls your destiny but you.
Well, that’s all happy path, but what about networking, Michael? What about security, etc.? Again, the buck stops here. The utility of networking should be presented through the platform (automate it), and if it is not, then the development team needs to really get into software based networking, but to sacrifice my responsibility is to be controlled by another. I’ve worked with many companies that create DevOps teams who’s primary drive is to ‘control’ the automation that development teams leverage to get to production. Not just the tools, but all of the automation. DevOps, in this scenario, owns the build pipeline. This removes the ‘responsibility’ from the development team to ensure production rolls properly. It should no longer be a part of the dev team’s lexicon because it is no longer ‘my fault’ if something dumb happened and my software deploys improperly to production. That’s the devops team’s fault, because they have control!
This is not to imply that supporting organizations are not tremendously helpful in enabling development teams to move quickly. At my company, we have a team called the ‘Toolsmiths.’ This team is responsible for keeping the most useful tools ready and waiting for our business/developers to leverage, but they do not ‘own/control’ the outcome or automation. For example, they will ‘own’ the availability of our continuous delivery software and engine, but not the automation that the teams create within that tool. In this way, we communicate to the dev teams that they are responsible for the production outcome, but don’t worry about being responsible for the infrastructure that delivers that function. This is a boon for the teams, but does not strip them of the core responsibility that they should have. The same is true of infrastructure in general. We look to automate and ‘cloudify’ everything that we can so that the dev teams are not responsible for running the cloud, but are able to take advantage of it, and stay laser focused on bearing the responsibility for the production of new business value.
So, what I am poking at is that we should really pay attention to:
- The power of psychology. Establishing teams that ‘control’ the development machine leads to reduced responsibility from that team. The more you control, the more you have to control.
- The power of language. The difference between ‘toolsmiths’ and ‘devops’ may seem minor, but it communicates the purpose of the organization, and reinforces who does DevOps. (Optimally, we want every single development team to own their own ‘DevOps’)
- Wherever you give up responsibility, you will be controlled. For the betterment of the business, leaders occasionally need to exert control in order to keep the wheels turning or prevent large scale failure, but look to lift the control and put responsibility back where it belongs as soon as you can.
A big part of our hopes in this effort of transformation is to empower individuals to unleash their creativity in solving our company’s biggest challenges, and to improve the lives of those around us. That hoped for outcome is only made real when freed people take responsibility for the outcomes they produce. My son, for example, will finally be free of my nagging when (and if?) he assumes responsibility for his allergy treatments, or he moves out (leaves my ‘company’).
Embracing the Change 
Leave a comment