Your system is a lagging indicator of your team
Today's system reflects your team from years ago, and the system you'll have years from now will reflect the team you have today.
Lately, I've been thinking about how system changes, especially replatforming, rewrites, and big migrations, actually happen.
Oddly enough, tying Conway's Law to self-help advice from The Secrets of the Millionaire Mind led me to a simple mantra:
"Your system is a lagging indicator of your team. Today's system reflects your team from years ago, and the system you'll have years from now will reflect the team you have today."
Obvious once stated, but worth keeping in mind. This applies beyond software – to sales, product, company processes, and even personal health. But today, I'll focus on software – starting with a few turnarounds I've been a part of.
Changing companies and changing teams
I'm a "double boomerang" – twice, I've left a company only to return later.
Leaving a company and coming back is one of the most interesting ways to evaluate how change unfolds with or without you, especially if you're in a leadership role.
Both companies had similar departure stories: I left as Head of Engineering, and they had to temporarily install a more technical leader who was less interested in engineering management until they found a permanent backfill, which never materialized.
At Company A, the technical leader eventually stepped back, leaving the teams to run themselves. The DevOps lead filled some of the power vacuum, the team became very Ops oriented, and our software stagnated.
Like all turnarounds, this one started with a listening tour. And like many, it was followed by drastic people changes.
With software team leads empowered to make changes and some top-caliber engineers joining the team, the software started to get back on track. Things weren't perfect in a year, but they were much better and definitely on an upswing, with our web, mobile, and desktop platforms all showing tangible improvements.
At Company B, the technical leader grew frustrated with spending more time on management than on his superpower – technical leadership. The team continued to grow, but we were trying to keep the old team structures with many more people, and it was bursting at the seams.
In this turnaround, the teams were the problem, but the people weren't the problem – we had hired well during my departure. So the drastic changes were about moving people around – fixing the teams, not the people.
Eventually, we restructured the teams for growth, and engineers became more efficient. Managerial problems were handled at the team level without needing escalation. Engineering finally started catching up and, eventually, getting ahead of our product roadmap.
The above stories are oversimplified, but the message is obvious in hindsight: "Over time, software becomes a reflection of the team that builds it." Who the people are, how they are organized, and how they work continuously shape the system in their image.
Fix the team + give it time = fix the system.
So let's talk about those two perspectives influencing how systems are built, starting with Conway's law.
Conway's law: System design and communication structures
Organizations which design systems (in the broad sense used here) are constrained to produce designs which are copies of the communication structures of these organizations.
— Melvin E. Conway, How Do Committees Invent?
Software engineering, like most collaborative endeavors, is constrained by collaboration.
Systems mimic their communication structure because working against them is too costly. There's too much friction in designing a system where two heavily connected parts are owned by people who don't heavily collaborate.
We don't have scientific proof of whether communication structure shapes system design or the other way around, but a lack of evidence and the presence of taboos, guesses, and gut feelings has never stopped people in business – so we won't start now!
The lever the engineering leader can pull to design systems is the change in communication structures. Change the team, change the system.
That's why DevOps and SRE are often referred to as cultural changes: you can't change your systems unless you change how your teams operate.
But real change won't happen overnight. Changing your team isn't like moving the boat to its destination – it's like changing the wind, and that takes time.
Need better integrated systems? Start by integrating the people building them.
Oddly enough, I first learned about the nature of lasting change through personal finance – it has a critical lesson that extends far beyond money:
Change happens at the structural level first, not at the outcome level.
Personal finance's lessons on building lasting results
The Secrets of the Millionaire Mind is one of my favorite personal finance books, despite never reaching mainstream. A quote that perhaps explains it comes to mind from Rich Dad, Poor Dad.
I'm a best-selling author, not a best-writing author!
Rich Dad, Poor Dad quoted from memory.
In any case, The Secrets of the Millionaire Mind explains that to build personal wealth, you must change things at a structural level: You can't move the boat; you have to change the wind.
It’s what’s under the ground that creates what’s above the ground. It’s what’s invisible that creates what’s visible. So what does that mean? It means that if you want to change the fruits, you will first have to change the roots. [..] Money is a result, wealth is a result, health is a result, illness is a result, your weight is a result. We live in a world of cause and effect.
Eker, T. Harv. Secrets of the Millionaire Mind: Mastering the Inner Game of Wealth (p. 12). (Function). Kindle Edition.
The foundation of the book is simple but powerful: changing your thoughts is the best leverage you have for changing your results:
- Thoughts lead to Feelings
- Feelings lead to Actions
- Actions lead to Results
- You change your Results by changing your Thoughts
This principle is true for building wealth, systems, and many other things.
Just like wealth is a lagging indicator of your thoughts on money, systems are a lagging indicator of how teams operate. Trying to fix a system by focusing on the system itself is like trying to get rich by obsessing over today's account balance.
Your real leverage is upstream, in what's been causing those outcomes all along.
But what does that change look like in practice? It's the tried and true: People, Processes, and Tools.
Improving teams: People, Processes and Tools
It's easy to think changing a team is synonymous with hiring and firing, but that's not true.
Processes, meaning how teams operate and collaborate, and tools, the levers and support they have, are critical leading indicators of excellent outcomes. People will also learn and grow, so upskilling is crucial.
That said, having the right people is still your #1 concern. Process, tooling, and upskilling will only happen if you have the right people driving it.
Once you have the right foundations and direction, the only other factor is time. Like baking a cake, you add the right ingredients, put it in the oven, and give it time to rise.
Great systems emerge from great teams – shaped by the right people, structured for success, and given the time to do their best work.