Being an Engineering manager of a team often means assisting the team in organizing its ecosystem and tooling. I mean things like product and process metrics, CI/CD, productivity tools, and maintaining team's knowledge base and documentation.
In this post, I would like to share how PARA method can be used to structure team's knowledge and documentation. Although it can be used with any wiki platform, we use notion, so examples and screenshots will be from there.
What is "PARA" method
The PARA method is a method to organize digital life (knowledge, notes, etc.) in external storage (google drive, folders on your computer, note-keeping apps). It is authored by Tiago Forte and covered in his book "Building a Second Brain".
Essentially it suggests organizing your knowledge into four categories:
P - Projects. Short-term efforts in your work or life that you’re working on now.
A - Areas. Long-term responsibilities or ongoing activities with no set deadline.
R - Resources. This section holds the information you would like to keep and refer to in the future.
A - Archive. The category where you'll put items from the other three categories that have been completed or are no longer active.
How to apply PARA method to structure team space
Let's use PARA categories as sections of the Team's home in the org's wiki.
Projects
"Projects" section naturally fits as a root of your recent, current, and future projects. You can use different terminology and call them initiatives, roadmap items, or epics. Still, they should fit the classic project management definition: have a defined beginning and end, a specific scope of work, and a set of objectives to be achieved.
Projects can have a product or feature delivery as an objective or be internal ones aiming to improve processes within the team. For example, introducing DORA metrics or adopting a new tool in the team.
In this section, it makes sense to sort items in reverse chronological order (newest to oldest). Each subpage here is just a root holding references to relevant information, such as:
Project meta information:
Project definition in the project database
Project metrics and success criteria
Project roles (i.e. Stakeholder, DACI / RACI, or another framework you use)
Links to other systems (Jira epic, Miro project, Figma folder, etc.)
Ongoing project documentation:
Architecture decision records (ADRs)
Brainstorms or other workshops protocols
Meeting notes
Feature or technical documentation:
User stories
Flow / sequence / ER or other kind of diagrams
Runbooks for engineers or support specialists
Tracking schema, service catalog, etc.
Organizing all relevant documentation under one root makes it easier to find it throughout the project's lifetime.
Areas
The "areas" section can hold projects or business domains which are not in active development but require maintenance. Not every piece of ongoing project documentation is moved here once product goes into maintenance, only some long-term ones, like features description, runbooks, key ADRs, etc., would be helpful here.
You don't move projects to areas once they are complete. You rather distill long-term documentation from projects to areas. In fact, areas can have a broader scope than a project. For example, an area can be "paid subscription management", but a project belonging to this area can be "introducing a new payment provider X".
In addition to product domains, "areas" section can represent your engineering practices. If you perform post-mortems as part of your incident response process, it's a good idea to put them here. Your engineering or quality strategy, your productivity practices, and your team-building events - can all continuously be tracked in subpages of this section.
These subpages are better to be sorted alphabetically, or from most used to rarely used. If there are too many of them, it may make sense to introduce logical groups.
Resources
This section is perfect for the information you want to keep up to date for reference:
Team's mission and roadmap.
Working agreements (i.e. definition of "ready" and "done", meetings structure, core working hours, kitchen duty schedule, etc.).
Contact book of your teammates.
Rituals guidelines.
Templates for communication.
Team logo
This list can go, but from these examples you can see what all that items have in common: you are only interested in a current version of them. They also support your daily work in some way.
Archive
The number of items in other sections can grow and become hard to navigate over time. It is important to keep it clean and have only relevant information at the reach distance of your hand. Projects are finished, features are being sunset, working agreements get deprecated, and new versions of strategy are written.
It is a good habit to review elements linked from the main page regularly (i.e. quarterly) and move them to the archive. I would recommend having the same sections in the archive to make it easier to find archived elements by type. The archive will become hard to navigate soon too, so I would recommend organizing elements in each section by years (by the moment it was moved to the archive).
Can I add something else to the page?
Of course, these four sections are not set in stone. You may want to have some information available deeper in the structure to be duplicated on the main page.
I'd consider putting important information in sight:
team mission, values, moto
roadmap snapshot
members list
Being there, this information will catch an eye and serve as an "information radiator" making it readily available to everyone (even if you don't look for it). Just be careful and make sure you keep it concise and do not overwhelm the page.
Notion templates
To demonstrate the idea, I've prepared some notion templates. Feel free to clone them to your notion space and try to organize your pages with this approach.
You don't even need to commit and move your existing pages. You can link them (aka "page mention" in notion) inside the new structure to get the feeling of whether it works for you.