Coffee Shop DevOps: Complexity of change

No readers like this yet.
Coffee shop photo

Florida Memory. Modified by Opensource.com. CC BY-SA 4.0

Often I am approached and asked the question, "How do I get people to change what they are doing, especially when it is always so incredibly clear that they do not want to?" As if I could understand or empathize with the situation and magic up a solution, I used to try to answer that question. I learned a few years ago that I'm not a wizard who has a perfect answer for every situation. People are the reason that question is hard to answer, and I don't know about the rest of you, but for me, interacting with people can be difficult.

I feel like the phrase "change is hard" is passed around as an excuse for why change doesn't happen. I think it is a little more complex than that. Change doesn't happen because breaking down the epic unicorns and rainbows definition of what you want into actionable steps that you can take iteratively is hard. This DevOps article series wouldn't have been born without that thought.

So, how do we break down changing others into manageable steps when doing so is difficult to begin with? The simple answer is that you don't. My observations from the years have led me to conclude that changing others often requires an epic amount of skill, an insane amount of patience, and the abilities to be neutral, to empathize, and to see from another's point of view. If you want to speed up any of that long haul, having a little bit of authoritative influence doesn't hurt. These are not the skills of the everyday employee or human on earth. To remain sane in the long run, you must start with the thing that you have the most influence over—yourself.

Impact of career stagnation

I have spent about two decades in the technology industry and have seen my colleagues' passion for different technologies. They have taken that passion and applied it not only to the technology itself, but also to how they do their jobs. However, in 2016, I still know developers who don't use version control, rarely if ever write unit tests, and wouldn't bother with continuous integration even if they had the time to do so. People are creatures of habit, and sometimes the habits that we form are not always healthy, helpful, or even remotely explainable. I'm talking about you, Eggnog Latte from Well-Known Coffee Joint.

Let's look at my own career as an example. I spent approximately 12 years at the same company. My job was optimized for that company and the people I worked with, and I like to think I did a reasonably good job at it. Around 2012, when I found myself looking for work elsewhere, I was forced to face the fact that terminology and techniques had evolved—there was a whole other world out there of technologies and techniques I was utterly unfamiliar with. Interviews were hard because I didn't have a great idea of how to fit the knowledge I had into a different scenario. Even harder for me was the interview I had with a company who was light years behind where I was at that time, but I couldn't articulate how to get them to a modern process. At that point of my career, I realized that not only did I want to be excellent at the job by that company's standards, but I also wanted to be excellent at my job by industry standards. How do we do that?

Build a community of the like-minded

I regularly started to ask myself: What is that one small improvement you can make right now that would make you more successful as a professional? Initially I had many ideas, but as time went on, I found it hard to fill the queue with new ideas. Then a few years ago, a coworker dragged me to a local Agile meetup. I was skeptical about whether I would learn anything (but there was free food). Three hours later, I walked out of that meeting with information that I still use. Heck, I have the printout tacked to a board in my office even today. From that group, I built a small circle of people whom I trust, and with whom I routinely discuss professional goals. We keep each other honest about always improving.

While I curate the community of people who help ensure I stay up to date with industry best practices, I also think that, in a company, doing the same internally is important. I am part of a community at Red Hat—I would compare this group to Spotify's Guild—in which people with similar interests connect and discuss their experiences. This helps us share ideas on what works well for others and create common understanding (a shared purpose!) on how to tackle problems that we all face.

What about those who don't want to change?

Early in the book Team of Teams, author General Stanley McChrystal writes about the military realized that what worked for them in the past would no longer work for them in today's world. The story provides an interesting view into the life and death threat that compelled a military system to change into a more distributed model in which teams and individuals are empowered to make decisions, rather than relying on a central chain of command.

The technology industry is also faced with this need to change. The reasons we will change are not based on something so compelling as the life and death of a human, but rather on the ability for companies to compete in a world that is now changing more swiftly than anyone ever imagined. Those of us who don't pay attention to both the technology and cultural changes that are happening may find themselves as I did in 2012.

Take responsibility for your career

The easiest way you can take responsibility is to type the name of your job and "best practices" into a search engine and see what comes up. A word you've never heard about? A technique or skill you don't know much about? Don't wait for it to apply to your current job. Research it, find others in your local community with the expertise, and ask them questions. Find others at your company who are interested and organize a hacking or experimentation day to try out the new skill or technique. But most importantly, if you are passionate about it as an individual, then pursue it individually—don't wait for everyone else to catch up.

"Few of us are criticized if we faithfully do what has worked many times before. But feeling comfortable or dodging criticism should not be our measure of success. There's likely a place in paradise for people who tried hard, but what really matters is succeeding. If that requires you to change, that's your mission."
Teams of Teams, General Stanley McChrystal

User profile image.
Jen Krieger is Chief Agile Architect at Red Hat. Most of her 20+ year career has been in software development representing many roles throughout the waterfall and agile lifecycles. At Red Hat, she led a department-wide DevOps movement focusing on CI/CD best practices. Most recently, she worked with with the Project Atomic & OpenShift teams.

Comments are closed.

Creative Commons LicenseThis work is licensed under a Creative Commons Attribution-Share Alike 4.0 International License.