Jira Is the Most Hated Tool in Engineering. So Why Does It Take Years to Leave?

If you asked every engineer you know to name the tool they most want to stop using, a surprising number of them would give you the same answer.

The Pragmatic Engineer — one of the most widely read newsletters in software engineering — runs an annual survey on the tools teams actually use, love, and hate. It's the closest thing the industry has to an honest performance review for dev tools.

Jira finishes last. By a lot. More negative mentions than the next four tools combined. And the quotes aren't subtle.

"Jira is just a hostile tool towards actually delivering stuff… I'd prefer to use Linear."

So why do so many teams stay on Jira for years… and then suddenly leave?

Because switching doesn't happen when something is annoying, or even detested. Switching happens when annoyance becomes a pattern, the pattern becomes a cost, and then a catalyst makes the cost impossible to ignore.

This is the switch moment: the timeline from first thought ("we need something new") to the day the team actually fires the old system and hires the new one. Linear's adoption story follows that timeline almost perfectly.

The switch doesn't start with a migration plan. It starts with a thought.

The Switch moment, in a nutshell, is when someone becomes convinced the new product might actually work. The timeline usually has a predictable shape: first thought, passive looking, active looking, deciding, switching.

The details change by company. The shape doesn't.

Phase 1: First thought — "Why does this feel harder than the work?"

Most teams start by noticing that work is getting heavier in places it shouldn't be.

The ticket takes longer to create than the bug took to understand. A simple change requires navigating a maze of fields and statuses. "Quick" becomes a form. The tool that's supposed to track the work starts competing with the work for attention.

Engineers describe the same theme again and again: slow, bloated, complex, over-engineered, built for reporting instead of flow. And crucially, it doesn't feel slow because of hardware. It feels slow because every ticket forces you to hunt for context — where is the discussion, where is the decision, where is the commit, where is the spec? The tool becomes a data graveyard you have to search before you can do the actual job.

Even Atlassian's own community threads acknowledge the Jira bloat cycle: inactive projects pile up, custom fields accumulate, automation rules linger, dashboards fail to load, admin screens take minutes. Nobody set out to build a monster. It just grows. Because every team wants "their workflow," every quarter adds another layer of configuration, and almost no one archives anything.

So the first thought isn't "we should switch tools." It's smaller, more defeatist: "Why is this so hard?"

That thought is the beginning of demand.

Phase 2: Passive looking — the workaround phase

Passive looking is when teams haven't committed to leaving, but they start testing the edges of the status quo by bending reality around Jira.

This is the phase where the tool becomes the master. Teams contort their behavior to satisfy workflows that no longer match how the team actually works. They game velocity. They do the ceremony because the ceremony is what gets rewarded, not because it moves the product forward.

The most damning signal of passive looking isn't "we complained." It's "we built a parallel system."

Splotch, a design and development agency, published a first-person account of switching from Jira to Linear, and it captures the moment they hit the wall: they found themselves managing spreadsheets on the side just to avoid using Jira. That's the irony that ends the debate. When your project management tool drives you to a spreadsheet, you're already gone. You just haven't said it out loud yet.

One developer writing about why people hate Jira cites the classic UC Irvine finding: it takes 23 minutes and 15 seconds to regain focus after a context switch. You don't have to litigate the exact number to recognize the lived reality — every extra click, every extra screen, every extra mandatory field is one more interruption pulling an engineer out of the problem they were actually solving.

Passive looking is the team admitting, through behavior, not words, that the current system isn't supporting the job anymore.

Phase 3: The catalyst — the day the cost becomes undeniable

Catalysts are the accelerants. They're the events that intensify what teams have been tolerating and force a real conversation about whether to keep tolerating it. Different orgs have different catalysts, but the underlying shape is the same: something makes the long-running friction suddenly impossible to rationalize away.

Catalyst type A: The "spreadsheet moment"

Splotch's story is the cleanest version. Jira drove them into side spreadsheets, and once that happened, planning and triage were clearly broken. The tool designed to organize the work was actively disorganizing it.

After switching to Linear, they report practical outcomes: sprint planning faster, bug triage smoother, backlog usable again. That's a catalyst because it's undeniable. You can't argue with "we're using spreadsheets to avoid the project management tool."

Catalyst type B: Scale turns the org into islands

OpenAI is one of Linear's most public customer stories — and the trigger that pushed them there wasn't dissatisfaction with any single tool. It was fragmentation at scale. "Every team is on their own island, using their own tools and systems." Cross-team handoffs became failure points. Assigning work across teams felt unreliable and things would get lost in the gaps between systems.

The adoption didn't start with a top-down mandate. It started with a few people using Linear, then it snowballed — described as a Katamari ball. From ~100 seats to 3,000+. That's a catalyst too: when coordination breaks across an organization, the tool choice stops being a local team preference. It becomes an infrastructure problem.

Catalyst type C: Leadership sees the company suffocating

Brex, the corporate card and spend management company, went through what they called a "3.0" transformation — and switching to Linear was part of it. Their transformation story describes a CEO-level catalyst: engineers were spending more time updating multiple tools than writing code, and PMs couldn't answer basic status questions without digging through three systems. The switch was framed as restoring clarity and momentum, not adopting a trendy tool, but removing a bottleneck that had become organizational deadweight.

The post-switch metrics matter because they make the decision defensible: more usage, improved clarity connecting work to goals, higher satisfaction.

All three catalyst types do one thing: they turn a long-running annoyance into an urgent problem. That's when teams stop saying "Jira is annoying" and start saying "we can't keep working like this."

Phase 4: Active looking → deciding — why Linear becomes the chosen alternative

Once teams start actively looking, the bar is not "it has the most features." The bar is: does it remove the friction that's been draining us?

This is where Linear's pull is unusually coherent. Sequoia, one of Linear’s investors, frames Linear's philosophy as bringing back "a sense of dignity to software creation." Linear's co-founder Karri Saarinen describes work as serious. He doesn't want tools to be fun, he wants them to be good and professional.

That philosophy shows up in the product choices teams feel immediately: speed that changes behavior, keyboard-first flow, clean UX that doesn't feel like a cockpit, opinionated defaults that remove configuration paralysis. Where Jira asks "how do you want to configure this?", Linear answers "here's how it works."

Splotch describes the behavioral shift directly: with Jira they dreaded logging bugs; with Linear they don't think twice. That's the pull you can't explain with feature checklists. It's the tool disappearing. It's the return of momentum. It's why so many developers describe Linear as "built with the developer experience in mind," and why mentions of Linear in the Pragmatic Engineer survey show up as a wish — a lighter tool instead of Jira.

There's also a social layer that matters in dev tools, whether anyone admits it or not. Sequoia calls Linear almost a Veblen good for modern teams: a symbol of cultural belief in building quality products. They tell a story of internal revolt — engineering, product, and design rallying with a memo insisting they wouldn't use anything except Linear.

That's identity. "We are this kind of engineering org."

The anxiety that almost stops the switch

Most teams fail to switch because they're afraid of what they'll lose.

The objections are consistent: reporting and analytics gaps compared to Jira, fewer integrations (Jira's ecosystem is massive; Linear's is intentionally focused), higher cost (one team reported a 40% increase), and a fear that Linear either won't add enterprise features or will add them and become Jira anyway.

A Reddit post from a PM after six months on Linear captures the honest tension. The team embraced it, no grievances, sleek and quick UI, but advanced reporting was missing, integrations weren't as developed, and the bill went up. That's the real deciding-stage friction. The engineers who use the tool daily love it. The management layer that chose Jira in the first place often did so for customization, reporting, and control,  the exact things Linear has intentionally limited.

Linear's strategy is explicitly the opposite of Jira's: prioritize intent over infinite configuration. Limit deep customization. Ship opinionated defaults that work for most teams instead of blank canvases that work for none.

That's the trade. Teams switch when the pain of Jira's flexibility exceeds the fear of losing it.

Post-switch reality: what happens after the flip

If the switch was real, behavior changes. Not in a survey. In daily life.

OpenAI's switch story is the strongest signal: it scaled from a small pocket of users to 3,000+ across the organization. That doesn't happen if the tool is merely "nice." It happens when the tool becomes the place work reliably moves through,  when people stop routing around it and start routing through it.

Brex reports measurable improvements: more usage, clearer connection between work and goals, higher satisfaction. Splotch reports the simple operational wins: faster planning, smoother triage, a backlog people actually use instead of one they endure.

But the tradeoffs don't magically disappear. Some teams still miss advanced reporting. Some can't quantify the "velocity feels better" effect because Jira's reporting was part of how they proved progress to leadership. Some leaders worry about long-term feature depth as their org scales past what Linear was originally designed for.

That's normal. Switching isn't a fairy tale. It's a decision made under constraints, and the constraints don't vanish on day one. What matters is whether the tool supports the job the team is actually trying to do now — not the job the org chart says they should be doing.

Linear didn't win with features. It won by answering the job Jira stopped doing.

Jira loses because capability accumulates into complexity, and complexity accumulates into drag. The features that once justified the tool become the weight that eventually makes teams leave it.

The switch happens when frustration has been building long enough to create "first thought" demand, workarounds prove the team is already leaving in practice, a catalyst makes the cost undeniable, an alternative makes a credible promise of speed, focus, dignity, and flow — and the anxiety of losing Jira's reporting and customization finally becomes smaller than the pain of keeping it.

Linear isn't "better Jira." It's a different answer to the same job. And teams switch at the moment they stop optimizing for reporting and start optimizing for building again.