If we agree that transactive memory is a common feature of teams’ institutional memory and accept the benefits, then we must address the risks. That should not be a major assumption. In many situations it makes sense. Knowledge can be stored in a single place and then accessed by the team as needed. The idea of having one version of data was one of the reasons I was taught normalization when I was working in the database realm. Transactive memory acts as a form of normalization so teams can reduce redundancy and conflicting truths. When the process works, a team will be more than the sum of its parts. While this seems very mechanistic, I would not suggest ignoring the idea in a fit of humanistic pique. I have not found a team or relationship that has been together for more than a few days that is not leveraging transactive memory. However, as described in our overview, there are two macro scenarios where transactive memory causes problems for a team adopting new approaches. They are:
- It generates codependency for the organization or team on the coach or Scrum Master.
- Risks backsliding when the keeper of the process knowledge leaves.
Risk of codependency. Transactive memory codependence occurs when a piece or category of knowledge is locked up in a single person. In many cases that person then uses that monopoly for their benefit. Early in my career, a boss/mentor suggested engineering just such a scenario to protect my job. This is a fairly common problem in teams where the pressure of individual performance is high (common management by objective approaches are one cause as are people still practicing Jack Welsh decimation approaches). Other examples can be found by observing long-term Scrum Masters. I will show my bias and state that this behavior is often less self-aggrandizement on the Scrum Master’s part but more due to teams seeing this knowledge as secondary to their goal so being satisfied to “store” it elsewhere. The team gets to store knowledge so not everyone has to have the same information and the Scrum Master, in this case, gets the endorphin hit of providing specific value. This risk is that the holder of the information and knowledge may not always act in the best interest of the team, but rather their own self-aggrandizement.
Risk of backsliding. Simply put, the lack of institutional memory is almost always a self-inflicted wound caused by a mistaken belief in the specialization of roles (an artifact of the production line mode) combined with the mistaken belief that agile means no documentation and no process. Combining these three scenarios creates a perfect storm of risk that if an individual leaves a team that they encounter a grayish form of amnesia on a specific topic. I have seen teams forget exactly what a daily scrum is for and end up with status meetings rather than planning/collaboration sessions — it might have been better if they forgot Daily Scrums existed at all. When institutional memory fails teams revert to what they are comfortable with even if it is not effective.
Solutions to Consider
- Build a team with cross-functional members. Embrace the idea of T-shaped people (individuals with a specialty but that have a broad range of experience to draw from). This avoids only one person being the holder of critical knowledge. This solution is difficult in older more staid organizations where teams evolve slowly.
- Leverage knowledge-sharing approaches to working. Examples include pair or mob programming and rotating facilitation roles. I work with several teams in which everyone has a turn on the on-call list, facilitates Daily Scrums, and retrospectives. How the team works is not dependent on an individual. Teams can use this solution easily at any stage of team maturity.
- Write stuff down. I know the word documentation is often considered to be equivalent to passing gas on an elevator, but it should not be. I can point to any number of cases where being able to look up how a problem was solved in the past or how to perform a specific task saved me from texting a colleague at 3 AM. Teams can use this solution easily at any stage of team maturity.
- Talk about the risk in retrospectives. Use the wisdom of crowds to craft a team-specific solution. Teams can use this solution easily at any stage of team maturity.
All of these solutions are a way to maintain the meta-system that allows a team to know who has what knowledge and how to retrieve it. Transactive memory is useful and low risk, when risks are managed the meta-system of who has the knowledge is maintained. While we have focused on the Scrum Master as an example of a role prone to the risks of transactive memory there are other areas equally prone to these issues. Any role can fall prey to the risks we have identified. Want some free advice? Manage the risk, and use the topic to drive your next retrospective.
