Leveling up Engineering Productivity with Linear
Leveling up Engineering Productivity with Linear
Insights from a real-world experiment when a dev team switched their project management tool for a quarter increasing efficiency, momentum, and job satisfaction.
Or as the team lead would like to say "We were better, happier, and faster by a factor of 1.5× after just 6 weeks when making the switch from Jira to Linear" (according to Velocity numbers week over week).
Today, Jira is commonplace installed at 80% of fortune 500 companies — and likely not going to change in the next 5 years at those same companies, maybe. Since its inception in 2002, Atlassian is a mainstay as the most dominant market player in the program management industry. They've incorporated "Agile" as a software, embedding aspects of the manifesto into its DNA, allowing for expressive, un-opinionated instances of its tooling to create hyper-flexible workflows — leading teams to architect their own custom process.
Enter Linear est 2019 — A better way to build products and a new standard for modern software development; streamlining issues, cycles, and product roadmaps unlike any tool you've used before that you'll actually enjoy using, while still delivering on the promise of adaptability [agile] allowing fully configurable workflows for teams and dynamic roadmaps.
How it started
In full transparency, these insights were gathered as part of an experiment I spearheaded at Route.com to improve cycle times, increase visibility on roadmap progress, and elevate team happiness (for real) among the mobile teams organization.
As an aside, my experience with Jira (and other Atlassian products) in both Management and as an IC has been mediocre at best. Nonetheless it's important to note that although I do not work for Linear in any shape or form, I concluded many of these insights with unquestionable bias.
Likewise, it's also important to recognize many Program Managers have staked their experience on having institutional knowledge in understanding the depths Jira's configurations alongside certifications, and by no means should anyone attempt to throw all of that away.
The challenges
The largest issue (pun intended) (among many) was how we were going to play within the existing process — because the majority of the company involving hundreds of employees remained using Jira; switching to Linear for our flagship mobile teams had to be an isolated experiment that continued to run in parallel while still allowing outside teams to file issues against us.
Enter Jira Link, Linear's working integration solution to equip teams looking to trial or transition to Linear while still keeping projects up to date in Jira. This of course comes just after an initial import using the Issue Importing tool. It should be noted, too, that we didn't even need the custom importer, but it was nice to know it was there.
The overcoming of a culture shift, embrace change, and willingness to learn something new.
Unsurprisingly, most engineers don't care much for project management tooling. They know just enough of what is required (an over-statement), and move onto the important things; code, systems design, shipping. In the first two weeks of trialing Linear at Route, there was hesitation around its purpose. Likely in part due to my lack of explanation of the why, but the team trusted there was a larger purpose at play.
Setting up replacements for existing integrations
Although not a difficult task, the audit for operational communication parity was imperative so that we remain connected with other teams about the work. In short, it meant enabling the GitLab, Slack, and Zendesk integrations.
And for anything that wasn't supported in the officially supported list from Linear, we knew we were covered through Zapier, REST API, and Webhook support.
Security Audit & Compliance
As with any new tool that houses sensitive information and talks to other services, a compliance review was mandatory alongside a security audit with a followup to implement the requested recommendations. Eg; access management, data storage/transfer policies, shortly expiring tokens, encryption, audit log history, etc.
This was by and large the longest process, taking a few weeks, ensuring we had all the right things in place to remain SOC2 type ii compliant.
Other than that, we were ready to trial and conquer!
Scope
Albeit a trite exercise, it was useful understanding why we have project management software. What value does it provide for organizations? So at minimum, it would need to do support the following:
Plan the work
Estimate the work
Divide the work
Track the work
Predict future work
And of course organizing & understanding the work comes in the forms of:
Teams (people)
Issues (tasks)
Projects (initiatives)
Roadmaps (plans)
Strategy (tactical)
Progress (updates)
Understanding Linear's lingo
This part, in particular was very easy. In Jira, a superfluous language was required when having any meaningful conversation around the work. “Epics, Stories, and Tasks” and “Scrum Masters who drive the sprints focusing on swim lanes for our kanban board.” You have to admit we all sound a little silly speaking like that.
In Linear, issues are first class, and they belong to projects with an issue board delivered over cycles that are planned within a roadmap worked on by team members. It almost sounds too easy. For a quick reference, here's what we came up with to make sure we were on the same page:
Scrum v Kanban
In Jira
Gives admin ability to initially setup board as kanban or scrum. Does not give ability to convert from one to the other after initialization. Has “auto cycles." After some google searches, I learned that you can create a new scrum board by an issue filter
In Linear
Default team boards are flat (like a Kanban). You "enable cycles” in settings, effectively transforming to what we know as a scrum board with custom intervals, moving incomplete work automatically to the next cycle.
Contextual Approach
All in all, in Linear…
High level context is captured in Projects.
Long term context is captured in Roadmaps.
Low level context is captured in Issues.
Short term context is captured in Cycles.
Any teammate can zoom in to a specific timeline or part of a project, or zoom out to understand the long term plans.
Methodology
In many ways, Linear is not attempting to install doctrine. It has a method which includes practices for building, none of which are dogmatic to be instilled and change the culture of your company (although it includes some extremely thoughtful advice). Here were a few that we felt made an impact to our team
Focus on cadence & flow
Build momentum — as they say. Tired is saying outcomes over output. Sane in theory, but more often than not, a team that values experimentation, and makes frequent bets — you're most likely to have more failed outcomes than successes. It also devalues the desire for efficient output of engineering team's who, in many scenarios, do not have control over the outcomes. Understandably, the phrase outcomes over output stems from unhealthy work cultures that mainly measure dev productivity by activity volume. However by focusing on momentum paired with shots on goal, we can achieve a healthy balance of output headed in the right direction.
Write tasks not stories
Albeit Linear dives into criticizing stories much further, stating:
User stories evolved over twenty years ago as a way to communicate what a customer wanted into product requirements that a software team could deliver…
They have become a cargo cult ritual that feels good but wastes a lot of resources and time.
Harsh, but holds some merit. At Route, our team believed at minimum they (stories) didn't belong in our project tooling. They were exercises for our Product team to either write elsewhere, or discuss — ultimately to produce an outcome of tasks we could drop into Linear.
Invest in planning
Of course a project management tool company would say this. But moreover, putting money where their mouth is, the investment into roadmap management and attention to detail for scanability and understanding is unmatched. As should the goal of any project Gantt chart, at a quick glance, I could see current WIP (and any excess thereof), upcoming estimated delivery windows, and any cross team dependencies acting as potential blockers. As a Director, I Love this view!
Other Features
For a full walkthrough, including issue management, teams, projects, board configs, shortcuts, integrations and more — Linear's own feature walkthrough does a better job than any other review I've googled and stumbled upon. However there's one small feature that I believe goes mostly unnoticed, and I think is the mostly highly underrated, and even more notably something Jira doesn't have.
Status Updates
At just about every company I've ever worked at in the last 20 years, knowing the status of things is by far the thorniest of… thorns in attempts to having transparency around the work. Where are we at? How much longer? And no I don't want to see a Gantt chart — but rather tell me in English.
Some companies create meetings around this. At Route and Twitter, we called them Weekly Business Reviews (WBR). At Lightspeed, Change.org (and in Agile), it was the Scrum of Scrums (SoS) wherein which every team lead would give a short update about the status of every project. At many other places, they're simply Business Syncs.
Regardless of the matter, at best — these updates were captured in spreadsheets or confluence pages, but disjointed from the actual work. At worse, teams worked misaligned moving in opposite directions, blocked by lack of information or even duplicating efforts, ugh!
In Linear, each project is designated a simple structure to provide a stop-light status (red, yellow, green), aka: On Track, At Risk, Off Track — accompanied with a tweet-sized text box to provide context.
Simple on its surface, however the real power lies in its ability to rollup into dynamic roadmaps. For example, any collection of projects (which I'm calling a dynamic roadmap, not sure if Linear calls it this) can contain a rollup of all the updates within. At Route, we particularly chose a weekly cadence to provide updates on each project. In turn, we were able to ask questions (and get answers to them) like How are we doing in the mobile org? How about iOS v Android? How about Consumer vs Merchant? Even time based questions like How is Q3 looking? Ultimately providing a transparent history of our progress, written in english (not graphs) whereby anyone in the business could tap into. IMO this was very powerful!
Tying Updates into Strategy, Execution, and Direction; as Stanford professor Robert Burglman said:
A large reason many implementation efforts fail is that executives see strategy as a pure top-down two-step process: ‘The strategy is made; now we implement it.’ That’s unlikely to work. A successful strategy execution process is seldom a one-way-trickle-down cascade of decisions.
Successful firms are characterized by maintaining bottom-up internal experimentation and selection processes while simultaneously maintaining top-down driven strategic intent.
— Harvard Business Review.
This is quite a mouthful, but what he meant was you indeed need a clear, town-down strategic direction, but this will only be effective if, at the same time, you enable your employees to create bottom-up initiatives that fall within the boundaries set by that strategic intent. By implementing a transparent view into the work (via Linear's Updates), we were far more equipped in propagating and communicating our progress to executives resulting in less rework, and more refinery into the right direction.
What did team leads think?
Because it's important to hear more opinions than my own:
We started using Linear a couple of months ago and things immediately felt faster. Linear’s performance is incredible, I think it helped our team’s productivity due to the fact that it’s fast and Intuitive. Adoption has not been an issue with linear, Engineers on the team could figure out how to use Linear without needing to ask for instructions.
One of my favorite feature in Linear is Search and filtering, its powerful and I don’t have to go and look at the entire board or search through all the issues to find what I’m looking for.
I'm also quite amazed by the delivery speed and the pace that Linear team is delivering features. We have met the team couple of times, they are responsive and appreciate feedback.
— iOS Team lead
Linear is the most enjoyable engineering issue tracking tool I’ve ever experienced.
It has at least as much visual polish as Trello, is much faster than JIRA, and fits our agile workflows better than Shortcut.com. During our weekly triage meetings we go through issues at a faster pace thanks to its Triage view, with specialized buttons to Accept, Merge, Decline or Snooze each issue. This is much more pleasant and faster than other systems that have just a “view” and “edit” mode. In those systems, I’ve found that if I want to change anything about a story I have to navigate through about 20 editable fields to find the right one to modify each time. With Linear I just pick the right view for that agile activity and everything I need is one click away.
When sprint planning, I like the quick preview that Linear offers me to see how many points each engineer has committed to finish this cycle. We can also filter by engineer through this tool, which helps when sprint planning and daily stand-ups. It’s much faster than other systems I’ve used. Response times in the app are very impressive, which means less time in meetings and more time coding :) They’ve been responsive to my team’s feedback and I’ve enjoyed seeing a steady stream of improvements and new features introduced into the app.
— Senior Engineer, ex-Microsoft PM
Conclusions
Linear is clearer, faster, enjoyed by all those who used it within the Engineers who trialed it. Includes most integrations we had in place with Jira — but not all.
Does not include integration with LinearB, a DORA metrics projects we were also considering. What core statistics would we want? What would impact be of using LinearB and not use integration with Jira (just GitLab)? Usage (and deep integration) of Confluence would be contentious. Keep using? Swap with GDrive (Docs/Spreadsheets)? Replace with alternative? Guru? Notion?Having upfront clarity [contextual] breakdowns of the work [project, members, labels] made large impact to planning and progress development, and maintaining a meaningful balance of the work between features, tech-debt, and bugs. The team had little-to-no context of these insights when working within Jira.
Atlassian’s Jira Software is a very powerful & expressive tool! It is well-known within the industry for 20 years. Nearly everything Linear provides (data / features), Jira does in excess, and more! But comes down to lack of understanding and individual training… which is a very common theme across most features in Jira. These Experts often come in the form of certified Agile Scrum Masters or PM’s who have spent several years using it.
Fairly regularly throughout the year we hear individuals in org in need of help exclaiming “Is anyone here a Jira Expert?” to no real avail.
Advice for those looking to switch
If you work at a small company, or a very isolated org with few integrations and high autonomy to run and manage your own work the way you see fit, the cost to switching is minimal. Use the import tool and go! But if you have an established process with hundreds of players across multiple functions — your real hurdles are less about the technical costs, but political barriers.
It's vital that you identify key stakeholders (Program Managers, Directors, Chief Officers) and understand the context around what problems Jira is currently solving for the org. You'll more often than not discover that it's nothing that couldn't be solved with Linear; and so you're up against cultural bias to those that want to stick with what's working (because after all, if it isn't broken, don't fix it). I firmly believe this fixed mindset stifles growth and creativity, and so I can't stress enough the importance of fostering partnerships and allyship for gaining buy in. After all, the best approach to buy-in is to allow weigh-in first.
Good luck!
Dustin Diaz is a VP of Engineering, 3× entrepreneur, author of Pro JavaScript Design Patterns and This is Strobist® Info, and brings over 20 years of insights from previously held leadership roles at Route, Google, Twitter, Medium, Yahoo and Change.org
Looking for company’s that are still hiring in tech? Check out Still Hiring where new roles are added daily.