In May 2023, I was at the first-ever Fast Flow conference in London for a day of presentations and activities. The delegates would mainly be Team Topologies aligned practitioners or those who have benefitted or are at least interested in the approaches outlined in the book. Additionally, many of the people I spoke to would also describe themselves as having an inherently human-first approach to delivering software. These people understand and accept that teams, their arrangement and the human factor are fundamental to the success or failure of software projects.
One of the underpinning principles of Team Topologies itself is that Conway’s Law is real and that, to a certain extent, you can reverse-Conway your architecture by wilfully designing your organisation. Martin Fowler writing as recently as last year, has also been vocal in his support of this key principle in software engineering. Conway’s Law is seen as an inescapable fact. Acknowledging this and designing your organisation thoughtfully is starting to become common practice.
Those at the conference heard that letting organisations design themselves for software delivery is usually not ideal. However, there was very much a need for any steps we take in designing teams and organisations to stay rooted in practicality. Indeed, many of the presentations stressed the subtleties of putting these theories to work.
Team Topologies has been carefully created to build and reference the experiences of those in the industry. It’s not an attempt to devise a framework that can be applied without first considering where you are. I see it more as a way of thinking about organisational design and a way of moving the needle on performance (i.e. producing better software) in small steps.
One of the day’s key takeaways from many presentations was the idea of not using buzzwords in order to avoiding scaring people. This was repeated in many forms: “Don’t call it Team Topologies” or “Don’t say DDD,” or “Don’t say Wardley Mapping”. While you should still use the principles or methods within these areas, presenting them as such can become significant impediments to adoption.
So practitioners must have a light touch when introducing concepts that may eventually help their projects succeed.
Martin Fowler agrees that “pretty much all the practitioners I favo[u]r in Software Architecture are deeply suspicious of any kind of general law in the field”. Any hard and fast principles, laws or frameworks tend to be proven wrong at some point or other.
The Human Touch
Why was this conference different? In many ways, it was a very personal experience. It was small at around 250 or 300 attendees and only two tracks that diverged briefly during the day.
The most significant difference I noted in this conference was an almost single-minded commitment to the human side of software engineering. This theme was clear throughout the day and speaks loudly through the Team Topologies book itself. Indeed one of the book’s chapters features this quote by Eric Evans:
“When code doesn’t work.. the problem starts with how teams are organised and [how] people interact”.
I believe this is fundamental to the Conway-led Team Topology approach. While we should view the smallest element at work in the software-delivering organisation as a team, we must also ensure that the teams know their responsibilities. The famous Team Topology Team API represents this. However, to get a Team API in place, the team must first have an internal agreed way of working.
Recently in my work, when I’ve wanted to rush ahead and perhaps implement Conway-led change in the architecture and delivery, I have had to scale back and dive deeper at an individual level. To make change work, I have to help developers, POs, testers, BAs, architects, and others understand that they will collaborate more effectively if they first agree on how they work with each other.
What does this mean? At a basic level – this means trust. Showing that you trust someone else by ensuring you use a ubiquitous language you both know is enough to convey exactly what you mean. This unlocks the team to align internally on a way of working and wider agreements spring from that.
Once you have the team aligned in one direction, then the language of Team Topologies makes sense for defining our Team API and our external way of working.
So this was my most significant takeaway from the Fast Flow Conference. We can start today and every day changing toward a better software architecture by making individual agreements in the approach of our team setup.
Build from there.
You can catch up with the Fast Flow Conf presentations here.