When I started my career, I was rewarded for being creative, stretching the boundaries, getting changes through the system to bring more revenue to my company. I was a developer.
When my SecOps colleague started his career, he was rewarded for keeping people like me from destroying the business with poorly planned implementations that make us vulnerable to attacks.
When my Operations colleague started her career, she was rewarded for taking the crazy ideas that the developer wanted to implement and translating them into something that will actually work, subject to the rules that the SecOps person dictates.
In the natural state, we have all created value in our careers by trying to work around the flaws of the other groups.
To the developer, SecOps and Operations needlessly slow everything down.
To SecOps, developers are dangerous and operations are unreliable.
To Operations, SecOps are paranoid and developers don’t have a clue.
I vastly underrated the power of these cultural scripts when first initiating our change initiatives around DevOps and automation. In fact, I mindlessly continued to follow my script. I went to SecOps with the attitude of: here’s this awesome change I want to do that will change our business, please approve of it. They followed their cultural script with the response of oh look here is a developer who just walked in with a weapon that can wipe out our entire business. There is no partnership there; there is only conflict. And unfortunately, conflict is what I began with. I’m still working to undo the damage I did in those early days.
Instead of the attitude I learned as a developer, I should have taken an attitude of a business person: What are the problems that are or have the potential to drag down revenue and increase costs, and how can I help fix them? It turns out that SecOps and Operations both have extremely valuable roles, and they aren’t getting in the way of my awesome developer changes. They have problems just like the rest of us, and if I take the time to understand them, perhaps we can partner and solve them together.
Instead of coming to SecOps to try to get approval for the tool, why don’t I start with their compliance challenges and how we solve those? If I can use a tool to get their system more compliant, then that’s a better baseline from which we can do some other great things, like configuration management.
Instead of coming to Operations to merely implement the tool, why don’t I start with the problems they are having and iteratively help them solve those problems? Instead of just relying on the development teams, maybe I should start going to the Change Advisory Board meetings and then show up when the deployment happens. Then after that I can follow up and say, “For a couple of days of work, we can automate that. How does that sound?” All of a sudden I go from being a developer who doesn’t get it to partner who will make my life easier.
When the cultural roles shift away from conflict and towards cooperation, magical things will happen. I’m working like crazy to make that happen right now.