different domain, same failure

the last 2 posts were about crms.

hubspot: what happens when a dense platform lands on a team that is the wrong shape for it. attio vs hubspot: same domain, different tool, and why the teams that adopt either one successfully look the same. both posts landed on the same conclusion: missing transparency, missing plan, missing adoption.

this post leaves the crm domain. the failure pattern does not.

linear is an issue tracker. lightweight, opinionated, fast defaults. built for engineering and product teams, rather than sales teams. status names are decided. the hierarchy is decided. cycle length is a week and the product gently discourages changing it.

completely different domain from a crm. completely different weight class. a new hire can be productive in linear on day 1. the same new hire at a jira shop is still learning what the custom statuses mean at day 30.

on paper, linear is the answer to every adoption complaint anyone has ever had about enterprise software. teams still fail to adopt it.

the adoption failure looks different on the surface. underneath it is the same pair: missing transparency and missing plan.

a director or vp discovers linear. maybe they read a blog post. maybe they saw the tool at a conference. maybe a friend at another company told them the team switched and never looked back. the decision gets made. the jira instance gets archived, or worse, it stays open as a "transition tool" that everyone keeps using. monday morning the team opens a tool nobody asked them to learn.

the defaults are great. the team's muscle memory is still jira. their workflows are jira-shaped. their mental model of "where things live" was built inside jira over 2 years. none of that transfers automatically because the new tool is lighter.

the switch landed without transparency about why it was happening, why jira wasn't working, what linear does differently, what the team would gain and what they'd lose. the fewer statuses, the cycles that replace sprints, the flatter hierarchy: the opinions are good, and the team did not choose them. someone chose for them.

and there was no plan. no timeline the team agreed to. no onboarding for the first 10 minutes. no champion to absorb the questions. no way to measure whether the switch was actually working or just technically live.

some people on the team aren't technical enough to intuit why a lighter tool is better. some are protective of workflows that worked fine the week before. some just do not want to relearn where the reporting lives for the 3rd time in 4 years.

all of them are the people who decide whether adoption lives or dies. none of them were in the room when the decision was made.

that is the point that matters across the whole series. a dense crm, a lightweight crm, a lightweight issue tracker: 3 completely different products for completely different teams. the adoption failure is identical every time. missing transparency about why the change is happening. missing plan for how the team absorbs it. missing voice for the people doing the work.

saas is supposed to make the job easier for the people doing the job. when a team is still using jira 3 weeks after the switch, linear is not making their job easier. linear can still be the right product. the missing piece was the work to make the transition land.

the difference between a tool that "just works" and a tool that sits unused is almost never the product. it is whether someone was transparent with the team about why the change was happening, and whether someone had a plan for how the team would absorb it.

the fix for linear adoption looks almost identical to the fix for hubspot adoption, because the failure is the same.

0: ask the team what's working. before switching, talk to the people who'll live in the tool daily. what do they actually need from their issue tracker? what's working about jira? what's broken? the answers might confirm linear is the right move, and they also give the rollout team the language to position the switch in terms the team already understands.

1: position the new tool against the old one. a one-pager that names what changes, what stays, and what gets better. the team needs to know that their open tickets migrate, that the reporting they rely on still exists, and that the workflows they've built don't disappear. if any of those things aren't true, they need to know that before the switch, rather than after.

2: onboard for the first 10 minutes rather than the full feature surface. the team does not need to learn cycles and initiatives and projects on day 1. they need to know where their issues live, how to move something to "done," and where the backlog is. everything else can wait.

3: name a champion. one person per team who knows the tool well enough to answer "where did my custom statuses go" and "how do i see just my team's work." without a champion, every friction point becomes a reason to go back to jira.

4: measure behavior rather than logins. "did the team close issues in linear this week" is a real metric. "did 80% of seats log in" hides the fact that half the team logged in, looked around, and went back to the spreadsheet.

5: give the rollout owner a readiness bar they're allowed to fail. if the team isn't ready, the jira archive date slips. most orgs won't give the rollout owner that authority, which is why the team ends up in 2 tools for 6 months.

the teams where linear "just works" almost always have someone who held the transition, even if that person didn't have the title. they set up the workspace. they translated the old workflows. they answered every question for the first 2 weeks. they were the champion, whether or not anyone called them that.

the teams where linear doesn't work usually don't have that person. the tool is the same in both cases. the rollout is the difference. the line that matters is whether someone named the change and owned the first 10 minutes before monday morning.