Lab Handbook for Managing Teams
Today I came across the Makeability Lab Handbook from University of Washington's Makeability Lab, which is "an advanced research lab in Human-AI". In that document I also found some reference links to the articles Components of Lab Notebook, How to… write a lab handbook, Music Lab's handbook, Research Culture: Why every lab needs a handbook, Lab Handbook Resources, WIN Lab Handbook Page.
What I liked about the idea of lab handbooks is how it can help manage teams in an async manner, i.e. get their problems solved without waiting on the other person's availability. The idea of lab notebook appears to be an efficient tool at enabling this async collaboration.
I myself have been using some documentations of this style in different teams I have worked on and led at Twitter, and now Doordash. However, my documentations were often focused on technical runbooks and artifact pointers. What I liked about the Lab Notebook idea is how it connects these pointers with the core of the team and the people. It also allows sharing the culture of the team and common practices and patterns which can help people onboard on the team faster and for projects to run in a more sustainable manner.
During my time working on research projects I have found my most productive and successful projects have been the ones with the following properties:
- Clarity of the goal of the project (this is also true where the process is unclear just the goal is clear).
- Fast and efficient onboarding
- Rapid Iteration Speed
- Multi-pronged impact
In absence of these properties, I have seen myself and the team wasting time and often getting distracted/demotivated. This hinders collaboration, forces people to work in silos, and leads to a lot of back and forth communication.
I will talk about these ideas in another post, however, I find that a lab handbook can allow most lab projects to have the above mentioned properties of being successful.
One thing I want to highlight is that the lab notebook, I envision and find the most effective are the ones which are an ever evolving document and are used often. They are like the roads most often travelled by the team and hence constanstly maintained and continously being relevant. This creates a flywheel effect where a lab notebook if used more is more likely to be good than a perfectly written but unused lab notebook.
In terms of my own lab notebooks. I can give an outline structure of small team notebooks I have followed in the past:
- Key surface areas of the team
- List of different services and artifacts owned by the team and which surface areas they affect.
- List of key metrics relevant to the team, where to find them, how to track them, (optionally, what are the levers for moving these metrics)
- Key folks and their ownership for the projects
- Making changes to the services (Runbooks)
- Historical record of the experimentation by the team and its impact.
The most challenging part has been to initiate the flywheel for following the notebook, most of the time it has been me making updates but overtime when people actually start using it, then the flywheel kicks in and the lab notebook becomes a good source of document. This required pushing back on creating yet another document for a new task, always sharing the same lab notebook for future tasks, and adding any new info in the notebook and sharing the update with the team.