Change is Hard: An Automation Story

I don’t know why it takes us so long but I also understand since I don’t pull the weeds in my yard until they are overwhelming.

Beth Fuller
Beth Fuller
Jun 19, 2023
Context in Action
Change is Hard: An Automation Story


Auto-Discovery is a tricky thing. Alice talks about it in a recent post. I particularly like how she writes about it in the blog “Who is the Ideal OpenContext User” 

Auto-discovery gives anyone in the organization the ability to see how their work connects with the rest of the system. That’s especially important when all sorts of individual roles like release manager or QA are getting squished into the developer role. We don’t have people or time dedicated to creating and maintaining a system for explicit system mapping - it needs to be built-in. Every company’s tech stack is different enough that it needs to be mapped, but most companies don’t have the resources to do it as a separate task.

While auto-discovery is amazing, I really want to focus on automation. I realized that while I know that our auto-discovery comes with automation, it doesn’t always.  

As a society, we know the importance of automation from our experience in manufacturing. There’s a whole body of work to show us what works in an assembly line and what doesn’t. We understand the efficiencies and challenges that allow folks to deliver lots of things, be that a car, code, services, or infrastructure. 

Across the Chasm

The tech industry has been through many variations of automation in order to find efficiencies. From infrastructure as code, containers, and cloud — to name a few. The innovation of going from something manual to a small piece of your infrastructure being automated was magical. It is exciting to watch folks as they move from,  manually maintaining their infrastructure and start moving toward automating their infrastructure as code to moving toward containers. 

I don’t know why it takes us so long but I also understand since I don’t pull the weeds in my yard until they are overwhelming. I figure I have time to take care of them. Humans put things off until they have to take action when it comes to chores or work. With technology, I think we wait it out until the tech has been through its paces. We don’t ALL have time to find the rough edges when we feel like we are barely holding on as is.

There are lots of books and articles about the steps of the Innovation Adoption Cycle. Some folks refer to Geoffrey Moore’s book Crossing the Chasm, but I like this summary by Barry Krawczyk. The early adopters are key to the Innovation Adoption Cycle. Without them, there is just a chasm. Early adopters are those who see the vision and feel the pain. Through their excitement about solving the problem and willingness to wade through the messiness of a new idea, they are critical to the innovation adoption cycle. They pull the weeds before they are taking over the yard.  

On the other side of the chasm, it’s more of a mainstream feature set. People feel comfortable with the concept but are willing to deal with the pain they know until the time is right for them. When we map this to automation we watch the long journey from cfengine to today. I imagine the folks who started with infrastructure as code five, ten, fifteen years ago are now focused on how they are growing their adaptive capacity and being mindful of the socio-technical systems. They understand that infrastructure as code turned into configuration management and are looking at what comes after Kubernetes. 

Can I Implement a DevOps?

Configuration management changed how we are able to scale and grow and how we manage our infrastructure, cloud, and tools. These are the technical aspects of how to grow and scale. We have tools upon tools to address the technical aspects today. We have plenty of tools beyond that Google sheet that tracks the teams.  What we don’t have is the glue between the teams and the technical stack. We need a way to be better at the socio-technical aspect of doing business in a world where it is ridiculously fast to scale up. With AI, it’s just going to get messier. 

When we think of what kind of tooling is going to support a cultural shift of tying together the socio- and the technical it’s safe to say we are at the early stages of the Innovation Adoption Lifecycle. There are some really cool tools out there starting to solve this. We even have a beautiful open-source example in  

As we are thinking of the Innovation Adoption Lifecycle, config management, containers, DevOps, SRE, and Platform Engineers we realize we are at the early stage of adoption for Socio-Technical focused tooling. It’s going to feel awkward and strange but I’m confident that life is better on the other side.

What could shared context mean for your SDLC?

Learn more strategies and benefits.

Thanks, please check your inbox
Oops! Something went wrong.