Transactive Memory Systems Theory And Engineering Team Mentality

By admin

Transactive Memory Systems Theory And Engineering Team Mentality
ORG

On the most recent episode of The

Hidden Brain
ORG

podcast:

The Secret to Great Teams
WORK_OF_ART

, psychologist

Anita Woolley
PERSON

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
WORK_OF_ART

". 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
ORDINAL

heard about

Transactive Memory Systems
ORG

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
CARDINAL

person might be the keeper of the "social system" (ie, what was the name of that lady we met in

Greece
GPE

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
ORG

isn’t just about who knows what—it’s about who does what. And, as

Anita Woolley
PERSON

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
ORG

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
ORG

.

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
DATE

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
ORG

, 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
TIME

pouring through countless

Confluence
ORG

pages and outdated README files attempting to find documentation instead of just taking

2-minutes
TIME

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
ORG

(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
LOC

).

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
ORG

queries are slowing down? Easy peasy, I got a gal for that. Don’t know how to fine-tune your

Garbage Collection
ORG

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
CARDINAL

of us could focus on taking advantage of our strengths and simply getting help with our weaknesses. Without the guilt. Without the hesitation.

Enjoyed This Post? ❤️ Share the Love With Your Friends! ❤️ Tweet This Groovy post by

@BenNadel – Transactive Memory Systems Theory And Engineering Team Mentality
ORG

https://www.bennadel.com/go/4520