On the most recent episode of The Hidden Brain podcast: The Secret to Great Teams, psychologist Anita Woolley discusses which characteristics consistently show up across high-performing teams. Of the topics included, the one that really grabbed my attention was that of “Transactive Memory Systems Theory”. I had never heard this theory discussed in the context of teams; and, as they discussed it, I felt that it wasn’t entirely aligned with how I see many engineering teams (including my own) attempting to work.
I first heard about Transactive Memory Systems Theory years ago in the context of marriage. When a couple has been together for a period of time, they begin to leverage a collective memory. That is, they build an understanding as to which person in the couple holds which area of information. One person might be the keeper of the “social system” (ie, what was the name of that lady we met in Greece that time?); while the other person might be the keeper of the “financial system” (ie, what’s our checking account number?).
When a couple leans into this concept, they can store—and recall—more information as a unit than they each could have done as individuals. Which is why couples tend to “co-narrate” stories wherein each person contributes different details of the same recollection.
But, this Transactive Memory Systems Theory isn’t just about who knows what—it’s about who does what. And, as Anita Woolley points out in the podcast, medical teams that embrace this idea, and lean into the expertise of individual doctors, tend to have the best outcomes. And, that the longer a medical team is together, the more effective this Transactive Memory System becomes (with an increasingly positive correlation to patient outcomes).
ASIDE: As as corollary to that, breaking up a team or mixing its members across groups tends to decrease the effectiveness of the medical team. This is because it disrupts the Transactive Memory System.
I can see this even in my own marriage. If either my wife or I had to do all the things, it would be completely overwhelming. So, over time, we’ve implicitly (and explicitly) divided information and responsibilities. For example, I’m regimented about feeding the dog and giving her the daily medication; but, I know nothing about her vet appointments or when infrequent medications need to be administered. My wife, on the other hand, knows exactly when all the dog’s appointments are and how often she needs to get flea-and-tick and heart-worm medications.
And together—as a unit—we can raise the most spoiled, most entitled dog you’ve ever seen.
Engineering teams, in my experience, try to go in the opposite direction. Instead of leaning into a Transactive Memory System, it seems that every attempt is made to decrease the amount that we have to lean on each other. Not only that, but I believe there is often a lot of guilt associated with even having to ask for help (though, maybe I can only speak for myself).
Consider how often an engineer will spend hours pouring through countless Confluence pages and outdated
README files attempting to find documentation instead of just taking 2-minutes to “ask the person who knows”.
Or, consider how often an engineer will go “heads down” so that no one can interrupt them.
Or, consider how often we characterize something as “interrupting” and not as “asking for help”.
Or, consider how much “shifting left” is taking place in our industry. Shifting left is the idea that more-and-more technological know-how is being moved to the edges of an organization specifically so that information is no longer “siloed” among the Subject Matter Experts (SME).
Or, consider how often we suggest “learning something new” as the answer to unblocking a teammate (oh, you’re having trouble with application stability, perhaps you should learn more about Kubernetes).
Now, I’m not saying that having more information at your fingertips doesn’t make you a more effective engineer. I know quite a lot about web development; and, the more I learn, the more effective I become. But, I don’t know everything. And, I tend to feel really guilty about that.
And, I don’t think that I’m alone in this mindset.
What I would love is become comfortable with “having a guy (or gal) for that”. Need help with configuring a
Dockerfile? No problem, I got a guy for that. Want to know why your SQL queries are slowing down? Easy peasy, I got a gal for that. Don’t know how to fine-tune your Garbage Collection algorithm? Don’t worry, I got a guy for that.
Instead of fighting the fact that I / we can’t know everything, if we embraced the notion that together we know more than any one of us individually, I imagine that we would become more effective as teams. Each one of us could focus on taking advantage of our strengths and simply getting help with our weaknesses. Without the guilt. Without the hesitation.