How switching to Linear changed the way our team works

I won’t name and shame our previous project management software, but Paul loathed it. So much so that he sometimes just wouldn’t even use it.

I personally didn’t see the problem.

Yeah, it was a bit clunky and could be slow at times. But it was doing a decent enough job for what we needed, and I didn’t feel motivated to take on the admin of changing to something else.

So when he suggested a few months ago that we might move to Linear, my reaction was lukewarm at best. I conceded that it looked nicer and that it seemed to have some cool features, but I was sceptical that it would make much of a difference to our productivity.

Up to this point, the best way of describing our product team’s approach was reactionary. Certainly not particularly strategic. We kept switching our focus to any fires that needed putting out, or to who was shouting the loudest at a given moment. My feeling was that we needed to change our processes rather than our tools. 

However, I’ve recently learnt that the latter can actually support the former, and I want to share that lesson with you today.

Our team is small: three full-time engineers, two co-founders who occasionally work on the codebase, and me, Head of Product. We’re all spread pretty thin — working across several apps and wearing multiple hats. We can’t afford to be disorganised. 

For a while we had been doing 6-weeks of “focus” followed by 2-weeks of “freestyle”. This cadence never really seemed to be quite right though and when I came back from having been on parental leave for a year, I saw that it had been ditched and I wasn’t surprised. 

We defaulted to triaging and working on tasks on a week-by-week basis. Engineers took turns each day to be available for immediate technical support. There was a lot of context switching and it often felt like we were running without really going anywhere. We started projects only to abandon them when something more urgent came up.

Switching to Linear felt like a good opportunity to try out their suggested 2-week cycle cadence. The idea is that you don’t necessarily have to ship something at the end of the period, but that you have a predefined workload to tackle during that time.

We decided it made sense for engineers to take on support duty for a cycle at a time, rather than alternating each day. The support engineer isn’t expected to make progress on long term projects, so they can be completely available to respond to anything urgent. Meanwhile, the non-support engineers are less likely to have to drop what they’re working on, and can focus on following through on high-impact work, like shipping new features.

Potential tasks to work on get added as issues to the triage queue. There’s a Linear setting to require a priority level to be set when moving something out of the triage queue and into the backlog. Turning this on has made us much more disciplined about assigning a priority level to tasks, something we’d never been very consistent about in the past.

It’s now much easier to see and filter by which tasks need doing right away versus those that are nice-to-haves. I’ve had feedback from the engineers that this is really helpful in managing their workload each cycle, because they know which ones they can afford to drop if they don’t manage to get everything done that’s assigned to them.

Speaking of which, moving to Linear has made plain something that I already knew: we’re a super productive team but we routinely take on too much. The charts show really clearly how much we’re achieving each cycle and, while we still tend to over-assign tasks compared to the benchmark of what we know is realistic, it’s pretty motivating when we beat our previous personal best.

My personal favourite outcome of moving to Linear though is having custom filtered views. I’ve set up ones like “going stale” (tasks assigned to someone but that haven’t seen any action recently) and “needs assigning” (high-priority tasks that aren’t assigned to a person or cycle). I feel so much better at my job compared to previously when it felt like I would just lick my finger, stick it in the air, and then shrug and pick any old thing off the top of the pile. 

These days, I’m more confident we’re working on the most high-impact tasks. And the results speak for themselves: our shipping velocity is way up! On Tito we’ve recently deployed self-serve event anonymisation and deletion, ticket restrictions, and Activity groups among lots of other improvements. And our new app, IO, has just had a major layout revamp as well as tons of new features. The positive feelings associated with getting this work out into the world are palpable across the team.

This experience has also proven to be a good reminder for me as a product manager of how the choices we make when building software impact the lives, processes and productivity of our users. The fact that Linear’s UI feels like it’s on my side is credit to the thought and work their team has put in. I hope our users have moments where they feel the same way about the products we’re building.

Needless to say, I’m now very glad we made the switch.

And for anyone wondering about the admin of changing tools, we actually managed to put the old one into read-only mode when we cancelled our subscription, rather than needing to migrate everything into Linear. This means we got the best of both worlds: a clean slate, plus a full history we can refer to and pull tasks over selectively as needed.

The best part: Paul actually uses the software now!