different domain, same failure

the last two posts were about crms.

hubspot — what happens when a dense platform lands on a team that's 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: no transparency, no plan, no adoption.

this post isn't about crms. the failure is the same.

linear is an issue tracker. lightweight, opinionated, fast defaults. built for engineering and product teams, not 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 one. the same new hire at a jira shop is still learning what the custom statuses mean at day thirty.

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's the same two things: no transparency and no 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. but the team's muscle memory is jira. their workflows are jira-shaped. their mental model of "where things live" was built inside jira over two years. none of that transfers automatically because the new tool is lighter.

nobody was transparent about why the switch was happening — why jira wasn't working, what linear does differently, what the team would gain and what they'd lose. nobody explained why there are fewer statuses, why cycles replace sprints, why the hierarchy is flatter. the opinions are good, but the team didn't choose them. someone chose for them.

and there was no plan. no timeline the team agreed to. no onboarding for the first ten 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 yesterday. some just don't want to relearn where the reporting lives for the third time in four 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.

this is the point that matters across the whole series.

a dense crm. a lightweight crm. a lightweight issue tracker. three completely different products for completely different teams. the adoption failure is identical every time. no transparency about why the change is happening. no plan for how the team absorbs it. no voice for the people doing the work.

the tool was never the variable.

saas is supposed to make the job easier — easier for the people doing the job. when a team is still using jira three weeks after the switch, linear is not making their job easier. not because linear is wrong. because nobody did 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's 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.

zero: 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 — but they also give the rollout team the language to position the switch in terms the team already understands.

one: position the new tool against the old one. a one-pager that says "here's what changes, here's what stays, here's 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, not after.

two: onboard for the first ten minutes, not the full feature surface. the team doesn't need to learn cycles and initiatives and projects on day one. they need to know: where do my issues live, how do i move something to "done," and where is the backlog. everything else can wait.

three: 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.

four: measure behavior, not 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.

five: 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 two tools for six 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 two weeks. they were the champion, whether or not anyone called them that.

the teams where linear doesn't work, don't have that person.

the tool is the same in both cases. the rollout is the difference.

where does your team draw that line?

— clarai.io