How team communication cadence impacts architecture
Temporal coupling series, part 3: Design follows your communication flow like a river
Hey, this is Denis. This is a three-part series on the topics of modelling time in code, the engineering concepts surrounding temporality and co-dependence between teams. This is part three in the temporal coupling series:
Micro-services solve Time, not Size
Facts vs projections, an event-based approach to modeling time
How your team’s communication cadence impacts architecture
Flow—the action or fact of moving along in a steady, continuous stream
Flow is all you need to understand
The core issue you’ll explore today is how the frequency—not speed— of integrating work within your team impacts your overall productivity.
Flow is a curious concept that has been receiving more nuanced attention in the last few years. This kind of team-first business thinking is the heart behind the science and thematic of the book Team Topologies.
Flow seems to be the next generation of empirical science that combines concepts such as agility, continuous delivery, DevOps and Conway’s Law. The latter is what connects it to time to make it a fit for our sociotechnical issue in the Temporal Coupling series. Let’s look at it through an example.
Teamwork on a project
Here are three scenarios that I’m sure you’re familiar with. You no doubt use one of these three predominantly at work whenever you’re part of a team or collaborating with several.
Tight collaboration, also pairing
Pairing is the least popular of the three, unfortunately. It has the smoothest flow of all three cases. Working together like a surgical team in medicine where each person has a role to play or knowledge to contribute in a complex workflow. All the work happens live, possibly even in lock step.
This kind of collaboration shapes the strongest bonds and fosters an inclusive environment with high well-being standards, even if you don’t get along with everyone you are pairing with.
The non-agile way of doing Scrum
This case I see most when working with startups and similar smaller organizations. An overarching drive to “not waste resources” and short attention spans create an environment where opportunity cost is over-emphasised.
This emphasis creates incentives for team members to let work split into multiple “shiny thing” tracks of priorities, requiring constant syncing meetings to keep them in lock step with overall strategy (if any).
A frontend developer communicating asynchronously with a backend developer without either of them having full ownership or collaboration is a good example of this setup, that also highlights the most common disfunction: silo mentality.
Editor’s note—I did mark on the picture that this is the best mix of autonomy and teamwork, though I wouldn’t recommend it. It just happens to be the least bad of the bottom two if you are still on the fence on active pairing and ensembles.
Project Management Paradise
This form of team organization is abundant in enterprises, and I personally see it in smaller orgs only when working with managers who previously worked at a Fortune 500 or similar.
This form of teamwork has the most cruft and process hell. SAFe is a good example of the disfunction this offers, though on a positive note some open-source projects manage to pull this off with a reasonable cadence and budget given enough life span.
Continuous Stream
Continuous integration, continuous delivery, continuous flow, yadda yadda. I’m sure you’re tired of hearing this adjective by now. The key idea is that you want to get away from needless management practices in your software engineering culture.
Instead, ask yourself:
What should we stop doing?
What process mistakes do we keep making and struggle to let go of?
Hand-offs are the enemy
Any kind of process cruft that requires documentation and pinging people creates hand-offs. Ideally you would be in-the-loop for important matters like a pilot and co-pilot in a passenger plane.
Things to avoid:
Splitting tasks into stages and assigning a different person on each
Pushing tasks to someone, rather than it being available
Work log items only having one person attached, rather than the entire team, pair or ensemble
Making too many vague decisions in meetings rather than active work-collaboration
You will not escape Conway’s Law
You’d be tempted to gloss over these types of collaboration as minor details and simply focus on the task at hand: building product features. You certainly wouldn’t be the first to do so, and the mounting evidence of unproductive software teams facing layoffs keeps piling up.
If you’re unfamiliar with Conway’s Law, here’s the original quote:
“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 Conway, 1967
Design systems in this context means architecture and coupling for the most part. There’s more, I’m sure, but those are the ones we care about for the context of this post.
The psychology behind it may be unintuitive at first, but at least it’s simple: we like to go around (meaning, abstract or avoid using) systems that we don’t understand. And we understand those systems the most where we are in [perceived] frequent communication with the author.
This is why caterings, weddings and event organizations have a central person to absorb all the frequency of communication to prevent sloppy decisions from being made due to lack of familiarity.
Conclusion
Your work environment and engineering culture drives incentives or stigmatises multiple people working on the same task at the same time. Be transparent and no-bulls*** about which one is happening for you.
Is it serving you? If not, turn it around. As Vasco Duarte says: “You either trust your process or you need to change it. There is no improving something that doesn’t work for you.”
Tightly coupled and hard to reason about architectures are a product of their team’s work-environment. Foster loose coupling and simple APIs by reorganizing your squads or teams to increase familiarity between developers who build chatty software APIs for each other.
Question every hand-off or hand-back in your process. Constantly. You should be removing hand-offs all the time, to the point where you need to add a few back here and there. The most notorious hand-offs that kill your productivity are:
Asynchronous code reviews
Pull requests requiring 1+ approvals
Lack of trunk-based development (long-lived branches, git flow, github flow)
Assigning tickets to someone as a means to pass information and moving tasks forward
That wraps up our Temporal Coupling article series! I’ll be returning to this topic in a few months as we continue with the themes following TDD, DevOps and Estimation.
Did you like this post? I’d love to hear your feedback.