What’s a team operating system?
Most teams have an “operating system” they use to run effectively. This doesn’t refer to the software that helps your computer run; instead, it refers to the way you do things, how you manage resources, and how you transfer information between people and groups.
This operating system is usually implicit, rather than explicitly stated anywhere. It’s unfortunate that so few teams take the time to document their operating system. New people don’t know what to expect and how to do things. Employees waste time explaining things repeatedly and looking for resources every time a new person joins.
How to document your team’s operating system
The most effective teams clarify and codify their operating system. They might document some of the following things:
Recurring meetings: how you communicate, the cadence and format of recurring meetings, how and when to share updates
How to keep others informed about what you’re working on: what channels and formats are used
How to keep others informed of your status: when and how to communicate when you’re on vacation, working from home, and/or out of the office for meetings
Create a Tettra page, and for daily, weekly, monthly, quarterly, and ad hoc routines (assuming you have routines with these frequencies.) In each section, map out what you and your team does on a recurring basis. For example, some teams do a quick daily standup, many managers swear by weekly one-on-ones, and a lot of people do monthly planning. If there are formats or resources you use on a recurring basis, (like a monthly recap slide deck,) include an example or template. Bonus points if you reference these resources with our Google Drive integration.
Document your planning and execution cycles. For example, if you have a two-week sprint process, write down what you do when kicking off a sprint and when it comes to an end. Take note of the tools you use, if any, during these processes.
Also document the things you do routinely but on a sporadic basis. Perhaps you write a postmortem report if/when your product goes down. Or maybe you follow a certain process whenever you ship a new feature and want to reach out to customers for user testing.
For any of these processes, (recurring or ad hoc), don't aim for perfection at first. Try to capture what you can, but know that documentation is an ongoing process that you invest in regularly, in order to have the most capable and informed team possible.