Beyond Agile (9/52): How to organize and structure team information
Systems thinking is valuable knowledge. It provides a new perspective on what it means to be a TPM and the value you bring to the organization and team.
One of the many important directives for TPMs is to ensure that the teams we support are operating at optimal levels.
One lever available to you as a TPM to achieve these optimal levels is how a teams information, both generated and associated, is structured and organized.
Importance of Information Flow
A team or organization is a complex system. All complex systems rely on information flow for optimal operation.
An engineering team generates lots of information; an engineering org even more. Information artifacts come in many different types and lengths:
meeting minutes
design docs
PRDs
roadmaps
OKRs
decisions
Jira boards etc.
As TPMs, one of our responsibilities is ensuring information flows smoothly to the appropriate decision nodes. Therefore, it is paramount that a teams information is organized and structured optimally.
Wiki’s, Confluence, Document Apps (Google Docs, Word etc) are the standard tools for managing information. Modern tools such as Notion, Coda bring great alternatives to the traditional tools with many added capabilities.
Before you begin building out a team wiki or notion workspace, it is important you understand a few things about information from a systems perspective.
Kinetic vs Static
All Information artifacts operate in two modes:
1️⃣ Kinetic - it is shifting, evolving, changing with the passage of time and influenced by events and people.
2️⃣ Static - when people agree on the validity of information, it cannot be modified further or see this information as truth, it becomes codified as knowledge and permanent.
All artifacts generated by engineering organizations move between these two states. This distinction will help you understand how to structure and design your information architecture.
🏎 Kinetic information is always evolving with the passage of time and influenced by events such as discussions, meetings, communication, ideas.
It is important that all kinetic information always have a single source of truth. This source is evolving over time as more events happen but you cannot have two artifacts claiming to be the truth. This creates confusion and delays important decisions or events.
A great example of kinetic information is meeting minutes, engineering design docs, feature PRDs, to name a few.
💾 Static information by its very nature even when repeated or replicated in multiple places is static or same; it is permanent until something causes it to move out of static state.
Ex: Approved feature PRDs, finalized engineering design docs, Best Practices, development processes, decision log.
Static information requires hydration (review and update) as team scales in size and experience or when an event impacts it. Ex: A Feature PRD goes from Approved to Draft for updating.
Something to remember: Not all kinetic information becomes static and not all static information becomes kinetic.
How should you structure information
Some things to keep in mind:
Kinetic information is referenced constantly.
Static information is referenced periodically.
Ensure that Kinetic information is easy to find and grouped logically with dependent or adjacent information nodes.
Static information needs to be well written out and detailed as possible.
Here is an example of how I have structured teams wikis and documents throughout my tenures at Apple, Google, Nike.
Each system has their fundamental truths and nuances to information flows. What works for me may not 100% scale to your needs. So, use it as a starter template instead of a prescribed approach and make changes relevant to you.
Until next time 👋 !
-Aadil
Further Reading
In my opinion, Luca Rossi has the best written essay on the topic of Company Docs and it is well worth your time to read.
If you haven’t already, you should subscribe to his refactoring.club newsletter and community where he writes about becoming a better engineering leader in under 10 minutes a week. He is one of my favorite ❤️ engineering writers on the internet.
Feedback on this week’s newsletter: