Thought leadership is a term that those of us in the industry hear a lot. A thought leader is a person who has ideas/thoughts that push the edge and brings great ideas to the rest of us. Most vendors want to be seen as thought leaders—and some do, through the agency of rocking individual employees.
We all benefit from true thought leaders. They dream up new ways to do things (such as DevOps and agile), or find new uses for things (such as adapting agile practices to operations) that, in the long run, we can all benefit from. Good thought leaders (in any space) either look outward and see how what we’re doing today can be used to greater benefit tomorrow, or look inward and make us think about ideas and where we are in accepting them.
This Isn’t About Talking Heads and Vendors
The thing is, if you are establishing or attempting to expand DevOps operations in your organization, you are a thought leader. And that’s what I’d like to discuss.
Those of you who say, “No, not a thought leader; I’m showing how long-established DevOps practices can improve the organization,” are wrong. The key to thought leadership is that you are there, and your audience isn’t. If those long-established DevOps practices were acknowledged in the organization then there wouldn’t be a need for DevOps leaders to establish or expand. Everyone would agree and it would just happen. After sufficient meetings, of course. (The definition of “sufficient” varies by organization and falls somewhere between zero and infinity.)
In short, a thought leader must simply see what others do not (yet) see. If the audience is internal and resistant, then a DevOps leader is indeed a thought leader for that audience.
So, What is Required?
It is true that a big chunk of DevOps is communications. I’m an “automate first, streamline communications after” kind of DevOps person, but acknowledge that the opposite route is also valid. But increased communications are going to be required for long-term DevOps success. Part of that communications is with other managers both in and outside of IT. There is no better time to start than the present, by acting like a thought leader.
Target the next application/portfolio you think would greatly benefit from DevOps. Sit and refine where you think improvements and/or savings would occur, get the buy-in of line-of-business leaders responsible for the application or portfolio, and go on a PR blitz.
Thoughts are Great …
But leadership is better. Be the leader, advocate for what you believe to be right. There are those who will tell you DevOps is inevitable, and it’s not a big deal once there is at least one project in the building doing DevOps. I could not disagree more. Change—any change—doesn’t happen without a champion. If you are in charge of DevOps, yes, take the DevOps Institute Leadership Certification (Disclosure: I have written paid promotional material for this certification. But it’s good material, so I’m mentioning it here anyway), but also look outward. Bring the organization to the table; be visible; be driving.
But don’t be annoying. Know when to back off, or maybe target a different application first. And know how the existing system reporting and deploying will be mirrored in a full-on DevOps environment, so you can answer important questions such as, “How will we get through test and deploy if we re-target the application?”
Do I think DevOps is inevitable? No. But I do think it will have a lasting impact on the way we develop and deliver software, even if a particular shop doesn’t claim to be a DevOps shop, deployment automation, test automation, enhanced defect and runtime monitoring, increased communications. These are coming because they’re good ideas. It’s best to have a plan, be a thought leader and get it rolled out so the organization can reap the benefits.
