To help teams share and document tribal knowledge I run/facilitate an exercise I call History lines.
In this exercise teams are asked to visualize how different things have changed over time and at the end of the exercise you’ve helped spread knowledge to everyone in the team, the team has drawn new conclusions about their past, and they’ve documented some parts of their tribal knowledge.
I’ve found History lines useful when:
- Team composition changes e.g. when merging or splitting teams or when onboarding several new members in a short period of time
- Team members have come to rely on specific people for context
- Bootstrapping new teams
Visualize what makes sense for your team
Depending on the type of team you’re working in e.g. feature team, infrastructure team, component team, or management team, you’ll want to visualize different things.
A feature team might find it valuable to plot how customer growth has evolved over time, along with info on competition, team size, epics/projects released, and technical challenges, A management on the other hand team might find company goals, organizational and staff changes, and people and motivation metrics more valuable. And infrastructure teams will in addition to looking at company goals need to look at the amount of developers and development teams, possibly amount of applications in service, and how releases to production have evolved over time. It could also be valuable to mark out architectural paradigm shifts.
Laundry list of things to visualize.
- Company goals
- Team goals
- Competitive scene (who’s entered the scene and who’s left)
- Company or departmental events
- Amount of users or customers
- Total staff size
- Amount of developers
- Amount of development teams
- Amount of applications
- Technical challenges / Paradigm shifts
- Motivation (great place to work survey or equivalent)
- Organizational change
Use your imagination and look at your context when deciding what to visualize. :)
Here’s how you can run this exercise
- Start by meeting the team (or representatives) before the exercise and decide:
- which metrics to visualize
- what level of detail that is appropriate for their timeline
- how long the exercise should be
- what to prepare before the exercise and what to create during the exercise.
(Btw, it’s great if you have a product like Magic whiteboard that the team can prepare their timeline on. It saves time and allows the team to quickly get started during the exercise)
- who will be walking through the high level timeline during the exercise
- Introduce the exercise and let the team know that History lines is about spreading tribal knowledge. Also share that the team should first focus on the big picture and once the big picture is known they’ll go into detail on select areas.
- Once the team has gone through the whole timeline, have them dot vote on areas of interest and then discuss the areas with the most amount of votes.
- Timebox each area and decide how to discuss it first e.g. by looking at the code, design docs, on the site, or just talking about it.
- Once all areas have been discussed go around the table and share takeaways. Example questions you can ask are:
- What did you learn today?
- What are you takeaways?
- How did today increase your autonomy?
- Was there anything that was shared today that challenged previous beliefs and if so, what were they?
This exercise also scales e.g. if you want to do it on a department level as a context increasing activity or if you have multiple teams that are going to work together in a future initiative.
Visualize the big picture before you go into details
If your team and company have existed for more than a few years there’s likely going to be a lot of information on your history line. To make sure you discuss the most important areas you’ll need to visualize the big picture first. This means don’t go into the specifics before you’ve visualized the whole timeline otherwise you risk spending your time on areas/decisions that happened many years ago and that are less important.
Also, once the timeline is up on the wall, decide and prioritize all the areas you want to talk about so you know how much time you have for each area and what level of depth you should go into i.e. just talk about the why, or look at design documents, or demo code.
Come prepared with a walking skeleton to the exercise
While some teams prefer to create their timeline together during the exercise other teams want their timeline to be ready before they enter the exercise. There’s value in doing both but if you’re going to create the timeline during the exercise as a team building exercise I suggest that you at least have a walking skeleton prepared and have decided which metrics to visualize because it will leave your team more time for what’s important, exploration.
Common pitfall when facilitating History lines
- Trying to both facilitate and participate. It’s better to find a facilitator if you have tribal knowledge that’s important to share.
- Talking about solutions (whether technical or not) instead of talking about challenges, problems, and background.
- Not preparing at least a high-level timeline with key events.
- Leaving out business goals and customer growth with infrastructure teams.
- Including too many or few variables in the history line.
- Not leaving time for the team to reflect on what they’ve learned.
- Beginning at the beginning. If your timeline is 10 years it’s highly likely that there are more important events to discuss that the first things on the timeline. You’ll probably need to jump a little bit back and forth but only once you’ve decided what areas to focus on.
- Having a too long timeline. If your team has existed for 10 years, it’s unlikely that events that happened that long ago are relevant. Consider making it shorter.
Thanks for reading!
 Credit. History Lines is a mix between an exercise called Journey lines and an exercise Johan Strömberg introduced me to that he uses as a part of a larger workshop for strategic visioning where history is a vital part of shaping your future vision