Why we built Git-Zen for Linear (and what makes Linear different from Jira)

When customers started asking us for Linear support, the first response from a couple of folks on the team was the obvious one: "isn't that just Jira but prettier? We already do Jira-style integrations." If you're old enough to remember Bugzilla and Trac and the ten-year reign of Jira, the assumption is reasonable. Issue tracker is issue tracker.

It's also wrong. Linear is built on a set of product opinions about how engineering teams should plan and ship work, and those opinions are different enough from Jira's that they shape how teams use Linear — and therefore shape how a support-to-Linear integration needs to work. Building Git-Zen for Linear taught us to take those opinions seriously.

This post is about what we learned: what Linear is actually opinionated about, why those opinions matter when you're escalating customer issues from support, and how we built the Git-Zen integration to fit Linear's grain rather than fighting it.

The four product opinions that matter

1. Cycles, not sprints

Jira has sprints. Sprints are events — you plan one, you start it, you end it, work that didn't fit gets rolled to the next one (or doesn't, and accumulates as backlog debt). Sprints are managed by a scrum master or eng manager, and the act of planning one is a meeting.

Linear has cycles. Cycles are a continuous rhythm: weekly, biweekly, or whatever cadence you set, the cycle just happens. Work auto-rolls if it didn't ship. There's no "start sprint" event, no planning meeting required. The cycle is more like a clock tick than a project milestone.

What this means for escalation: when support escalates a bug to engineering, the right question isn't "which sprint should this go in?" The cycle is just always running. The question is "is this important enough to interrupt the current cycle, or is it queue-for-the-next-one?" Linear teams are usually thinking in priority levels (Urgent, High, Medium, Low, No priority) more than cycle assignment.

We built Git-Zen for Linear to optionally assign new issues to the current cycle — but the default is no-cycle, defer to Linear's own assignment logic. That's the opposite of how we work for Azure DevOps, where iteration assignment is critical at creation time.

2. Projects span cycles

In Jira, a project is the container for issues. Everything has a project, the project has a backlog, the backlog gets pulled into sprints.

In Linear, a project is more like a piece of work that spans multiple cycles — closer to what some teams call an "epic" in Jira, but with a real sense of duration, milestones, and a project lead. An issue can belong to a project, but doesn't have to. A team can have many active projects in flight.

What this means for escalation: when a support-driven bug fix goes to Linear, you usually don't want to assign it to a project. Bug fixes happen in the gaps between project work; assigning them to a project makes the project look like it's making no progress (because the eng-time is going to bug fixes). Better to leave the issue project-less, let it sit in the team's "all open issues" view, and let the engineer who picks it up decide whether it's project-relevant.

Git-Zen lets you set a default project per Zendesk role — useful if your support team is genuinely embedded with one specific project — but the more common pattern is no-default, let it stay free-floating.

3. There are no custom fields

This was the biggest adjustment for us. Linear deliberately does not have custom fields. The model is: every issue has the same shape (title, description, status, priority, assignee, cycle, project, labels, due date, estimate). That's it. No "customer-impact severity" custom field, no "ARR-tier" multi-select, no "regression-of-version" text field. If you want richer metadata, you express it through labels.

This is a real product opinion. Jira's flexibility around custom fields has caused entire industries of internal complexity (when we say "Jira admin" most people picture someone who maintains 200 custom field definitions across 40 projects). Linear refuses to play.

What this meant for Git-Zen: our integration concept of "tag/label pairs" — mapping Zendesk tags to provider labels — works directly, because labels are how you communicate everything in Linear. But our concept of "custom field mapping" — which lets you sync arbitrary Zendesk custom fields into provider custom fields — doesn't apply. We had to redesign the configuration UI for Linear to surface label mapping more prominently and hide the custom-fields-mapping UI entirely (since there's nothing to map to).

4. Speed is the entire feature

Linear users will tell you, if you ask them why they switched, that "it's fast." This sounds shallow but it's actually the product's core value prop. Every interaction in Linear is keyboard-first, instant, no full-page reloads. The whole UI is engineered around a feeling of low latency.

What this means for escalation: support agents who use Git-Zen for Linear will notice if the integration is slow. If our sidebar takes 3 seconds to load, or if creating an issue from Zendesk requires a multi-step modal with spinners, we've broken the feeling that makes Linear users like Linear in the first place.

We took this seriously. Issue creation from Zendesk to Linear is a single GraphQL mutation, returns instantly, no modal interstitials. Comments sync via webhook with no polling overhead. The sidebar pre-fetches your team's labels, projects, and cycles so the dropdowns are populated before you click them.

The hardest version of this opinion: don't add features that slow it down. There are configuration options we considered for Git-Zen for Linear (custom modal templates, multi-step issue creation flows, complex per-team overrides) that we pulled because the resulting agent flow felt slower than what Linear users expect.

The "no agent seats required" thing

One pattern we noticed: Linear customers tend to be smaller, more eng-heavy teams where Linear seats are reserved for engineers and product. Customer support agents almost never have their own Linear account — that's not what Linear is for, in their team's mental model.

Git-Zen has always supported this implicitly (the OAuth user is the integration, agents don't need their own provider account), but it's worth surfacing for Linear specifically. Your support agents create and update Linear issues from inside Zendesk without ever needing a Linear seat. The single Git-Zen Linear connection acts as the bridge.

For Linear customers paying $14/agent/month, this is a real savings. A 40-agent support team avoiding Linear seats saves $560/month at full price — more than five times the cost of Git-Zen.

The gz# reference tag, Linear edition

Git-Zen has always supported developers referencing Zendesk tickets from inside their git tool via gz#TICKET in commit messages, PR descriptions, or issue comments. For Linear, we leaned into this pattern more aggressively.

The reason: Linear users live in Linear. They don't want to context-switch into Zendesk. So we made the developer-side experience "drop gz#12345 in any Linear issue comment and the Zendesk ticket appears in the Git-Zen sidebar automatically." No explicit linking, no UI clicks, no Zendesk login. Just a tag.

We also introduced a free Git-Zen Lite for Linear tier that covers exactly this developer-side flow (without the agent-side issue-creation flow). For teams that just want their developers to be able to surface Zendesk context inside Linear, with no two-way sync, the free tier is genuinely sufficient.

What this taught us about integrations

Building Git-Zen for Linear changed how we think about integrations generally. The lazy version is to build the same integration four times, once per provider, with the provider name swapped in. The right version is to build four different integrations that share a kernel of common code but each respect the product opinions of their target.

We're now thinking about each of our existing providers (GitHub, GitLab, Azure DevOps) with the same lens. What does GitHub assume about your workflow that other providers don't? (PR-centric review, opinionated about main branch, repo-as-unit-of-organization.) What does Azure DevOps assume? (Sprint-centric, hierarchical work item types, Microsoft-ecosystem integration.) Where are we still building Jira-shaped integrations on top of providers that aren't Jira?

If you use Linear and Zendesk, give Git-Zen for Linear a try. If you have feedback on whether we've correctly understood Linear's grain — or where we haven't — we genuinely want to hear it. Email us.