This post describes the simple approach we have settled on to keep track of our work at Climate Policy Radar: actions on Linear and documentation on Notion.
How we use Linear
Why we like Linear
Linear prides itself on being a simple alternative to larger more complex task management systems like Jira. Their method is to offer a simple tool that doesn’t have all the bells and whistles of some of the bigger players. Users need to accept the constraints that come with that. But if your ways of working align with the “Linear way”, then you get the benefits of a super-fast tool that is easy to use. No features are missing in Linear that anyone on our team feels are must-haves haves, so it’s an easy trade-off for us.
Below is a description of some of the key features of Linear and how we use them.
Tasks that need doing are tracked as issues in Linear. All issues must belong to a team, and teams can have different permission levels.
We have a team for each product team and one for the whole organisation. Everyone has access to these. Senior leadership also has a private team that only they can access.
Some individuals also have private teams to track individual work (eg. learning and development), though most work is tracked in teams that are open to everyone to see.
We use Linear’s project functionality to keep track of each project (bet/initiative/backlog item) we are working on. Projects can cross team boundaries. Examples of projects
- Powering the climate-laws.org domain
- Launching GST1.org at the Bonn Climate Conference
- Developing our passage match translation functionality
Projects can be used to group related work. When done, the project can be marked as complete and hidden from view.
We make extensive use of the milestone functionality in Linear. Milestones represent different stages in a project’s lifecycle and help us organise work within projects. Usually, this means that issues for the next milestone are well defined, and exist as placeholders only for future projects.
Team members can set up views in Linear to allow them to see all of their tasks across all of their teams in one place.
I have a view called Plalan (my old GOV.UK nickname). This view shows me:
- all tasks assigned to me
- all tasks tagged as needing product manager input
- all tasks on my personal board
Similar views have been set up so that people can see all work via any combination of label, project or people filters.
Workflow stages and labels
Linear enables each team to have a bespoke workflow. If teams add in new stages or rename existing stages, then when people try to view their tasks across teams they will see too many columns. This is why we have decided that each team should use a consistent workflow. For now, all teams use the following workflow:
- Triage – add any new ideas here for a team lead to review. Triage is not visible in normal view. In general, items move out of triage with the agreement and understanding of the team.
- Backlog – jobs that need doing that are not urgent / priority
- Priority – jobs that have been prioritised to do next
- In progress – jobs someone is working on
- In review – jobs that have been done, but need someone to review them before they can be confirmed as done
- Blocked – the team cannot work on this task because of something out of their control blocking them
- Done – jobs that are done
- Cancelled – jobs that we aren’t doing anymore
Labels are tags assigned to each issue. Labels can exist at the team or workspace level. Again, the benefit of using labels consistently across teams is that it is easier for people to see their work across teams. So when we see multiple teams using the same label, we elevate it to become a workspace label.
Teams can apply whatever extra labels they like. These will not be visible to other teams, but they will be visible on any views created where linear issues across multiple teams
Any labels created for one-off usage will eventually be deleted to avoid clutter. This means it won’t be possible to refer back to the work in the future grouped by that label, as the label will be gone. So we prefer grouping issues into projects or under a parent issue to using temporary labels.
How we use Notion
Each project in Linear links to an entry in our Notion Projects database. This database contains all the work that we might do that might deliver impact to our users, including product improvements or projects for partners.
Once prioritised, projects should include:
- hypothesis statement describing what we are doing and the impact we expect it to have (always at the top of the page)
- project brief, including problem statement, goals, and any early thoughts around possible options, risks and delivery plans
- link to designs, whimsical boards, etc
- all documentation, specifications, architectural decisions, notes and meeting notes (this is done via a linked view of the Notes database)
Before being prioritised, bets contain much less structured information. It is more of a dumping ground for ideas. This includes feature ideas that aren’t ready to make it onto a linear backlog, but that the team have started thinking about (eg. multilingual, expanding outside of National law and policy, etc). This content is filtered out by default, so it gives people a place to dump ideas, articles and thoughts without cluttering the views in Linear and Notion that we use day to day.
Linear has some project update functionality which looks strong, but we have decided against using it so that we can keep all documentation in one place in Notion.
Another Notion database we use a lot is the Notes database.
We use the Notes database for all documentation, research or meeting notes. It is much better to have all these things together in one database, as it makes it easy for us to group them in an easy-to-find way. You can see all notes that related to a project on the projects page, all notes tagged to a person on their person page, and all notes relating to a functional area like “policy” or “frontend” on their page. You can easily create new notes with all the relevant metadata applied by creating the note in one of those places.
To make notes easier to fund and file, all notes include metadata on the:
- team members involved in the note participants
- related projects
- tags for things like the theme of work or functional area
If the note is documenting the outputs of a meeting, we also add a date and a meeting type.
How this process has evolved over the past 6 months
Earlier this year I wrote a couple of blog posts about how we are using Notion. Most of what I wrote in these posts is still applicable, but there are a few things that have changed:
How we keep track of actions
In my blog posts, i described how we kept tech team actions in Linear, and non tech team actions in the actions, notes and questions database in Notion. However, feedback from a team retrospective made it obvious that most people struggled with not having one place to go to track all of their actions. Someone (not me!) had the bright idea of putting all our actions in Linear, and all our notes in Notion. Saddened as I was to abandon my beautiful Notion database, I was attracted to the elegant simplicity of this rule. It was much simpler than what I had before, and is now in widespread use.
This change enabled us to consolidate our Notion databses. We merged our “Actions, Notes and Questions” database and “Meeting Notes database” into a single database called “Notes”. Again, this has massively simplified our Notion setup, and made it easier to maintain good documentation.
Renaming the bets database
In How we use Notion to manage our product backlog / bets I wrote about how I like to use the word “bets” to descrive work we plan to do, because it captures the inherent uncertainty that any work will achieve it’s desired impact. I still like the word bets. However, it was unneccesarily complicated to have a bets database linked to a projects database, and couldn’t rename the “projects” section of Linear, so we decided to just use the word projects instead. Consistent simple communication felt more important here.