In my years as a DevOps advocate and practitioner I have talked to thousands of engineers and executives in hundreds of companies. In many cases they shared their frustrations with the lack of progress or enthusiasm for the DevOps initiatives that they were tasked with leading or implementing.
This phenomenon is especially stark in larger companies but it happens to startups too. The status quo in many organisations is stronger than forward thinking and well intentioned ideas. This seems to be the default mode for most company cultures and is unlikely to change anytime soon.
There are exceptions of course – and many of those companies become legendary in their industries – but this article is not about building an innovative company culture. I am writing this for the rest of us, working in companies with normal cultures, trying to get things done and facing the daily uphill battle of effecting change on an entity that desperately resists it.
These ideas are especially relevant for those without any actual power or authority to dictate policy. They can also be leveraged by executives and leaders interested in creating long term change that lasts, rather than short term dictates that are ignored once they leave the room.
Bottom Up
This strategy is as effective when implemented from the lowest rungs of the organisational ladder as it is coming from the most esteemed leader. Once you understand the fundamentals you will be endowed with a power to effect lasting change that few in your organisation possess.
While the ideals of DevOps such as automation, communication, cooperation and ownership are generally seen as positive qualities, they are much more difficult to define in practice. Real world companies never conform to the ideal image of how things should be and organisational resistance to change is always present on some level.
Top down dictates from those with authority may effect surface level change but this change is usually focused more on appearance than results. Good leaders recognise this and seek to inspire lasting change by getting buy-in from their subordinates and showing them the benefits to be had by following or operating with a set of principles.
Fortunately for those not in leadership positions this strategy works even when you have no actual authority. Influence is a powerful force and can be developed by making the lives of those around you easier. DevOps engineers and practitioners are in a unique position to do this as they can automate away many boring and tedious aspects of their colleagues work.
Finding balance
Automating repetitive tasks is pretty easy these days but modern DevOps engineers are usually also responsible for uptime and reliability of the companies technical infrastructure. This makes it difficult to know what to work on for maximum effect and can lead to conflicts of interest, something that DevOps is supposed to alleviate.
The key resolving this seeming contradiction is balance. If you are working in a DevOps role within an organisation your first priority should be the company, they pay your salary after all. Your success as an employee is closely tied to the companies perception of you and your effectiveness. This perception is heavily influenced by how your colleagues view your effectiveness, especially the software engineers using the tools and infrastructure which you build and maintain.
It’s helpful to think of your software engineering colleagues as your customers. Your success will often be closely tied to their satisfaction – or lack thereof – with the tools and services you provide. If company leadership hears nothing but complaints about DevOps then they are likely to try and replace you to keep the developers happy.
This is why creating and enforcing policies is not a viable path to DevOps adoption. You have to show real value, not just talk about the way things should be. Demonstrate why your ways are better by building things that actually work better than the alternatives. Depending on where your organisation is at on the path to DevOps, you might be fighting for something as simple as using version control, or you could be discussing something more complex like the benefits of adding continuous deployment to your CI pipeline.
Managing Adoption
Rather than trying to mandate use of tools or processes, offer them as an option. Some people are resistant to any change and they will not adopt new tools or methods, but there are always a few early adopters as well and they will see the value in automation and tooling. Use these early adopters as advocates for phasing out the old ways. Change is always better received if it comes from team members rather than outsiders.
Create better tools and methods and get some critical mass from users who are excited about what you are doing. The rest will follow naturally most of the time. There may be rare occasions where an entire team refuses to change or adopt newer tools. In these cases it’s important to remember that unless you are a manager or executive it is not your job to dictate how they do their work.
Be prepared to explain the benefits of your solutions to management if needed, but do not try to dictate methods or processes without management buy in. There are often political forces at play that you may not be aware of, and it’s likely that management understands the situation but has some reason for not intervening.
Becoming too attached to the outcomes that you cannot control is a surefire recipe for burnout. Focus on building better tools and processes. Better tooling has a way of finding users eventually. You can advocate for your solutions with tact without coming across as pushy or obnoxious.
Wielding Influence
Your influence in an organisation is directly tied to the number of people you have helped solve problems. In the domain of DevOps these problems are usually bottlenecks in software development processes or issues with infrastructure. The solutions usually involve a mix of prebuilt and custom tools plus process and cultural alignment.
To build influence focus on solving more problems. In the beginning it will seem like many of your solutions are not appreciated or not used so don’t get caught up in metrics too much and become discouraged. Continue to offer good solutions to the development teams in your organisation and your work will gain critical mass over time.
Once you have some influence within your company your basic methods should not change. Even if you are running a team or in management you should not seek to dictate methods most of the time. Only egregious violations of policy or regulatory issues really warrant top down interventions. This ensures that your developers have the freedom to explore new tools and discover better methods that you may not be aware of.
In the same way that DevOps seeks to eliminate bottlenecks in processes you should also seek to eliminate humans as bottlenecks in a team. Rotate team members into different specialties on a regular basis. Make sure that nobody becomes the “go to guy” for any one tool or process. This applies to you as much as anybody else.
Finally, it’s worth saying that while these methods will work in most companies there are always toxic cultures that are not only resistant to change but actively hostile to it. You are unlikely to get very far in a culture like that without serious management support and a commitment to change that’s organisation wide. In these cases you should consider carefully whether you want to stay or find somewhere better deserving of your talents.
