I spend a lot of time studying individuals and teams in a quest to help them learn how to deliver more value. One of the most common failure scenarios I observe is that once organizations have reached a decent level of effectiveness, someone will leave and the whole thing will come tumbling down. I am not trying to suggest that turnover and change should be stamped out (I actually think it is healthy), but rather something else is amiss. Several years ago I was able to study the implementation of an agile scaling methodology in a Fortune 100 company. The study looked at quality, productivity, and cycle time across 15 product lines. In every case, the metrics fell during implementation (this was expected) then improved spectacularly, over 80% improvement in every metric, the year after implementation. Unfortunately, things got murkier when the consultants supporting the change were withdrawn and sent elsewhere. The metrics fell by 30 to 50% from the high watermark. I am not arguing that consultants should be permanently ensconced in any organization – it is unhealthy but rather something else is amiss. Recently I forgot to call my father on his birthday. My wife remembers things like special events and then clues me in…if she is around. This time she was not. The whats amiss in all three of these scenarios is a reflection of the risks of transactive memory.
A simple explanation of transactive memory is that teams store certain memories in one person and then create a framework so that everyone knows who the go-to person for that memory is. In my immediate family for birthdays, it is my wife and in the larger family unit, it is my father. On a team, one person might be the ace of database joins, another might be the person that understands how to manipulate Jenkins, and another the guru of the Scrum ceremonies – the list could easily go on. The team has a meta understanding of who has skills/memories so everyone does not have to know everything. The sum of the team is greater than the individual parts. Transactive memory is why teams can be very efficient and effective when tackling problems that would stump (or overwhelm) an individual.
Whether facilitating an agile transformation or coaching a team on Scrum or Kanban, transactive memory is a tool almost every coach uses. The technique is useful for several reasons:
- Not everyone has to be the master at all tasks (noted earlier).
- Scrum Masters and agile coaches can focus on keeping up to date with the agile concepts and ideas.
Long term use of transactive memory to facilitate change causes problems because:
- It generates codependency for the organization or team on the coach or Scrum Master.
- Risks backsliding when the keeper of the process knowledge leaves (this feels almost cult-like).
Things break down when the transactive memory system is disrupted. This occurs because of people problems due to:
- Team members change without a proper turnover.
- Dynamic matrix teams where change happens when teams are re-imagined for new projects (a special type of team member change in organizations still using matrix management which was popular in the 1980s and 90s).
- Transitory teams members, contractors or consultants, that are not invested in knowledge transfer.
All three of these scenarios are people and relationship problems (with a smattering of contract and HR problems sprinkled on top).
Anything that disrupts the relationships between people in teams or organizations is not the friend of transactive memory. Many of the light touch documentation approaches common in agile assume stable teams that can leverage transactive memory. In many organizations, stable teams are about as true as the tooth fairy.
