In my career, I’ve often run into situations where a new tool, technology or process that I think will solve problems or make others’ jobs easier and faster has been met with resistance, and interference.
Confusion.
And perhaps this was due to my inability to communicate the value.
While I do think that communication plays an important part in the initiation of change, I’ve also begun to see an underlying social pattern that impacts how organisations look at and respond to the new.
What we Are
Conway’s Law is an old adage in tech culture that states that organisations will tend to build systems and products that mirror their internal communication structures.
I find this interesting because how we communicate is how we solve problems, and this was the first part of my realisation. With each new problem we solve we create a new process - a formalised communication pattern - which becomes the legacy, the basis of how we analyse new problems.
What we make is made of our decisions, built with the fabric of how we communicate and the ideas we value. When we look at the work of others, we do not, can not look without the lens of our own choices and histories.
And through that lens, we find it easiest to understand the solutions of those who think like us, communicate like us and build the way we do.
The inverse is also true.
When we look at those solutions that others produce, they fail to make sense unless we think and act like they do, and we will struggle to adopt those new concepts into our frameworks and processes that are built to think in other ways.
Our attempts to implement changes will flounder or fail, not because the change is bad or the people have not tried hard enough, but because those changes do not produce solutions that we understand.
How we Think
I have seen this play out numerous times, not only as an outsider trying to help companies move to and think in “cloud native”, or build security and scale and resilience into their designs, but in myself. Through my journey of understanding the value of Docker or Kubernetes or Terraform or DevOps itself, I was challenged on what I knew was right and valid and appropriate in a situation, and I had to re-evaluate what I thought and why I thought it.
I had to introspect, and I was very fortunate to have that space to grow and explore and understand.
Our organisations often do not have that space.
Processes tend to be fixed and difficult to question or challenge. Our performance as employees is tied to that obedience, to historic communication structures and “the way we’ve always done it”, where “always” could mean a few years to a few decades.
That was my core realisation, and is the core difficulty facing any business trying to achieve a culture of DevOps. Without the abliity to introspect or learn how processes interfere with change, we face a refusal to ask ourselves “why isn’t it enough to say we want to change?”
Until those conversations can be had and internal communications can change, new tools and processes will remain out of reach. They will not look like solutions, because they focus on problems we don’t understand.
Saying we want to change isn’t enough. Saying we value change isn’t enough. All change requires introspection, analysis, and a willingness to be deeply uncomfortable.
Are you ready to face that discomfort?