Seeking Lasting Change? Look Beyond the Technical Practices

As a technical coach, I quite often get asked to up-skill and improve teams’ performance. Often the request takes the form of “please help them deliver faster.” Some of these teams manage legacy systems with outdated architecture. Some of them have long, complicated, manual processes for deploying code and managing infrastructure. Others have no automated testing and must go through long, manual processes to validate their releases. Some don’t even have source code management or versioning.  

Problem Fixed! But is that Enough?…

All of these are fixable, with some situations requiring more investment than others. But once addressed, the resolution will yield at least some value. That’s a good thing. It’s what the client asked for. It’s something I have the skills and experience to help with. But is that enough? Has anything really changed?

Creating software is still very much a human, creative activity. It only ceases to be creative when we are building the same thing we have built many times before. If we know the problem and the solution that well, we should be able to automate it and optimize for efficiency. That puts us right back into the creative space where the humans are a critical part of the equation.

Each of these teams is part of a larger system that includes executives, managers, marketers, salespeople and all sorts of others. Conway’s Law states that “organizations which design systems… are constrained to produce designs which are copies of the communication structures of these organizations.” Eric Raymond famously summarized this as, “if you have four groups working on a compiler, you’ll get a four-pass compiler.”

Code – A Reflection of Organizational Behaviors

I have come to believe that Conway’s Law applies not only to communication structures, but also to behaviors. When I do code reviews, I can often get a sense of the management style of the organization from the code. An organization that trades long-term value for short-term results will have teams that trade long-term maintainability for hitting their delivery dates. 

Are We Only Addressing the Symptoms?

The idea that the development team is what needs fixing misses the larger picture. What about the organization that has made it okay for the architecture to decay into obsolescence? If the team never learned to automate and improve their own work, what happened with the executives, managers, marketing, etc. that created those circumstances?

These issues did not emerge in a vacuum. The inputs the team receives from the system have an effect on the team’s outputs. If we want different outputs, one option is to change the function that translates inputs to outputs—i.e. by improving the team. The other option is to change the inputs.

Inputs – Learning – Outcomes

The current hotness in technology is AI/ML. The excitement of machine learning is based on the premise that we can feed the machine massive amounts of data and train it to recognize the subtle cues in that data, and make intelligent decisions that produce the outcomes we want. Amidst all of this excitement about artificial intelligence, it can be easy to lose sight of the natural intelligence in our existing systems.

The human beings in our systems receive massive amounts of data via video, audio and other sensory inputs. They have highly optimized neural networks that are able to filter and process that data and recognize subtle cues. Every interaction with a manager, peer, or customer provides feedback on how to prioritize and respond to the incoming data stream. 

The team’s productivity function is a learning algorithm. The team is constantly evaluating the fitness of that function based on the feedback inputs. If we want different outputs, we *can* change the algorithm. If the inputs don’t change, however, the same learning mechanisms that produced the old algorithm will recreate it. I have seen beautifully constructed microservices with CI/CD pipelines fall into the same disrepair as the legacy systems they were built to replace. The same pressures that produced the decay in the old system produced it in the new system as well.

Introducing a Positive Change that Sticks

This is our opportunity. As leaders in any organization, whatever our job titles, we can be intentional about the inputs we feed back into the system. If we want the system—and all of the individuals in it—to improve, we have to start with how we need to change our interactions with them.

How do I create space in my delivery schedule for my team to learn new concepts, technologies, and design patterns? How do I make it okay for people to try some of those out in our context? How do I show that a clean solution done well is more valuable than a poor one that meets a budget or schedule? How do I show those around me that I care about their growth and development as human beings?

Whether we are CEOs or development managers, Scrum Masters or developers, or carrying any other title, we can and should ask ourselves these questions. When we do, we change our own outputs, thus changing the inputs for everyone we interact with. That’s a change that sticks.