Heads-down DevOps
by Arlene Andrews
(original publication: https://testingindevops.org/heads-down-devops/)
I was recently looking at the world of DevOps: the sheer number of potential changes and practices that shift both the way the company works, and the way things are approached are not easy! There are a few well-known names with a huge following that seem to attend every major conference, and are a great source of knowledge. These folks are there, advocating for the changes that are needed, and are a grand source of ready information for businesses and practitioners that need information on how a specific technique might look in the future.
And, thankfully, most of them are capable of sharing their energy and excitement — which gets the team and management to be willing to try something new. This is an important skill: any change cannot be done effectively by just a few people. The more you are able to show what a change looks like — what to expect as blockages, things that worked to improve someone else’s situation – makes the whole process still seem magical, but with enough encouragement that things may not go so well at first, but this will work!
The downside to this comes quietly — business and other people have come to view them as “this is what DevOps is”, and try to hire for only the qualities they see in them, but for their specific situation as well. And without a grounding in the current setup and the problems that the company needs to solve (and the things they want to do, which may not be the same at all!), no one can sound expert and confident without a bit of blarney in their presentation. And those that are able to persuade in this fashion might not be the best choice, in the long run.
The lesser-known DevOps practitioners
But, the folks I am looking for to provide guidance are those thousands of folks that are not as well-known: the people that make the cycle of DevOps work for their business, and are successful without making a large splash in terms of followers, or even of videos and blogs. Their companies would be lost without these people — and these are the ones I would love to learn from.
These folks can be at any level in any business. They are the ones that are willing to be a bit stubborn, and not give up after the first time, or even after a few failures, because they have a goal that they want to reach. Finding out options, and getting others to learn about them is a sure sign you have someone I would want to work with – they are focused on getting better.
Improving through small experiments
They are the ones that will make a small change, and see how it goes. Changing too many things at once is both difficult to track effectiveness, and builds resistance to trying something new if some changes make things worse in the short term.
Rooting out the base cause of a problem is a thankless task at times — it’s so much quicker to put a temporary fix in, and move the real issue to the TODO list: and might cause fewer side effects than fixing the actual problem. But having someone devote the time to finding the issue, or at least systematically eliminating where it is not (and fixing small things as they go through) will allow the gradual improvement.
Working with other sections of the business is a needed skill for DevOps — being able to share problems, options, and ideas is one that helps everyone be aware of the issues. Using a good idea learned from another person may be the best possible outcome — you not only may have cured their issue as well, but you have both one less problem, and a new outlook next time a similar situation occurs.
Practitioners: Thanks for sharing your experiences!
So, for all of you who have taken on the task of making sure that the feedback is fast and accurate, the changes improve quality, and problems big and small are addressed when they occur — thank you. Learning from you, either through informal questioning, or other methods such as blog posts, is a pleasure. Finding a new post by someone who is skilled at these tasks is always a delight, as is a new writer whose knowledge is evidenced in their approach and tone. You may not have the answers, but at least you can ask the questions that will lead to them.