Your Team In Four Dimensions
So I had a meeting the other day, where a really interesting term came up, that of “temporal teams”.
In the context of the conversation, we were discussing teams that come together to achieve some goal, but disband after the project is completed. It’s a model that’s used extensively in the film industry, where contractors are brought together for the project and part ways at the end.
This is a workable model for projects that don’t have an extended lifecycle, but isn’t really appropriate for ongoing software development, as so much state is held inside the heads of the team working on it, and bringing new people in later without the original team means they’ll be fumbling in the dark.
But we have onboarding, and our teams don’t disband, and we’re sad but happy when our teammates leave us for other things. But our team lifecycles aren’t that they grow and shrink, by gaining and shedding people.
Instead, I think our teams only ever grow.
Standing On Shoulders
“Wait, what?” you might ask - people are leaving all the time! My team is staying roughly the same size!
That may look true, but consider what you do as a developer and how you build new things on top of existing tools and techniques. Those things that you build on aren’t just pieces of code, they are also expressions of the culture in which you build them. After all, culture isn’t what you say, it’s what you do.
These pieces of underlying software are your foundation. They determine what makes sense and what paths you can take, impose their design choices upon you and limit possibilities. Your culture, what you do is founded on the culture of what came before and what they did.
So how does this relate to teams?
Similar to the external libraries you use, what team members have done before you limits what you can do now. They made decisions that are now part of the foundation upon which you build, and the culture of those decisions is encoded in that foundation.
Decisions of what library to use, how to deploy the software, how the architecture is intended to work. These are decisions that you couldn’t affect, but still affect you.
Exponential Complexity
But I said earlier that your team size only grows, and I still haven’t explained why I said that.
If you think about the idea that what you can build is determined by others’ past choices and past culture, then, when did they actually leave the team? Every day that you interact with the choices they made you are having a conversation with them, communicating with their ideas, ideas that form the basis of the ideas that you can have.
So why is this important?
Well, Metcalfe’s Law states that the value of a telecommunications network is proportional to the square of the number of users, which tells us that the number of communications we need to make with our team members is also proportional to the square of the number of members. A team of 6 members requires 36 potential communication events to discuss ideas and approach a consensus.
So why is that important?
Your past team members are a part of that. They aren’t full members as far as the communication properties of the graph goes, since they’re only ever telling you things, but they are communicating with you across time.
A potential revision to Metcalfe’s Law to account for this is n^2 * m, with n representing current team members, multiplied by past team members. Past team members no longer communicate with each other, and no longer communicate with current members, and the longer they’ve been gone from the team, the less relevant their input.
So why is this important
Modern software development is a team sport, and the complexity of team communication is a vital aspect of team dynamics. As a result, removing *m from the equation means not rebuilding the culture of the team but ripping out its foundations. Since the foundations are often encoded into the software and datasets that the team works with, this can mean replacing large pieces of the software codebase or backing datasets, either through a “clean rewrite” or an evolutionary process.
And this is necessary! Choices that were correct in the past may no longer correct in the present, and will always need re-examination in the future. We implicitly know this and feel bad that we’re making the “wrong” decision now for expediency or other constraints.
Thinking of how our software must always evolve in terms of Metcalfe’s Law means that understanding our communication around our decisions is important and must be an intentional act. Because software is a team sport and the quality of our software rests solely on our ability to communicate and collaborate, treating the future team as non-existent is an act that disrupts future cohesion and teamwork.
The Future Tense
It’s a disruptive act because it increases the communications complexity far beyond the size of the team and the number of departed members. The reasons for decisions are lost and, like the bugs and edge cases embodied in our code, must be continually rediscovered and lost again.
The most obvious cause is a lack of good documentation. From no comments in source code to poor README or wiki or other up-to-date resources, you are not communicating with future team members.
And for your current teammates, this doesn’t seem to matter since they can just come and ask you, after all. Even more, they’re in the middle with you, they understand what’s going on and where things need to go, what the plan is.
That information is your context, and we already understand that we need to communicate that when we’re onboarding a new teammate and gett them up to speed. But instead of treating this as an intentional act, we treat this as an implicit function of the current team, passing on context using osmosis through immersion.
This mostly works, but over time the knowledge around why the team or organisation decided to do something is lost. The ultimate failure mode of this effect is the normalisation of deviance, where extremely harmful behaviour has been so accepted and internalised that potentially lethal results can occur.
How do we fight this? We write down why we’re doing something, what the context we had when we made that decision is and what the cultural requirements were. If we don’t the culture forgets, the reasons are lost, and you aren’t communicating with your team.
Knowledge Sinks
Another failure mode of future team communication is the Knowledge Sink. You’ve likely encountered this person, someone who’s worked to make themselves indispensable on one particular aspect of knowledge, who refuses to write things down or allow others to encroach on their domain.
Again, while annoying, this can seem somewhat harmless as you can just go ask them, but we all know that that doesn’t work over time. We have terms for this like “vulnerable to busses” where we try to recognise and joke about the fact that we will be remarkably crippled if we lose them.
Again, these people are very toxic to the team. They’re safe enough today, but that knowledge and context is lost when they leave. These people aren’t useful repositories of knowledge or context that other team members can ask, they are knowledge sinks, absorbing knowledge as a black hole absorbs light that leaves only the what we are doing, not the why, or, depending on their efforts, the how. We are prevented from effective communication.
Contempt Culture
These behaviours are strongly rooted in contempt culture, and are performative examples of “we are better than you” directed towards the future. The person who refuses to document code because it should be self-documenting holds contempt for those who lack the time to learn code as well as he does, for the future who will need to dedicate more energy to improve things. He thinks that if you aren’t smart enough to understand the code, you shouldn’t be coding.
The person who acts as a knowledge sink has contempt for the healthy communication and function of his team, he demands that others perform more work to route around the damage that he causes.
But more importantly, poor communication is contempt for the future. He sacrifices the future to his own need for importance and devalues the future of the team by increasing their communication cost of each decision we make and each cultural norm we adopt.
But I actually don’t have time right now
Not having time is valid, and important to acknowledge. Like all things, this is not meant as a you are bad for doing this, but a you really need to think about this. By considering what we do under new lights and within new framings, we give ourselves better tools and ways of acting with considered intent.
We often don’t have time in the here and now to broadly define our decisions and our culture. We have deadlines, milestones, and business needs that must be considered. But we can talk about our future selves and make them a part of today’s communications. We can think of steps towards including our future.
When we discuss that inclusiveness and think of what that entails, we discuss when we can put the communications we need on our roadmap and the intentionality of what we will say. Instead of relying on implicit cultural osmosis and the potential for harmful normalisations, we begin to explicitly define our own culture by what we choose and what we do.
And I think the future is worth it.