← All work

Branch · Spring 2026

Migrating an engineering org from Jira to Linear.

A six-week pilot with real engineers, not a vendor demo. The data made the case. 2.7x throughput, 87 to 93% cycle completion, and the team voting overwhelmingly to migrate.

JIRA · KEEP LINEAR · 2.7×

Role

Sr. Director, Product Experience

Duration

12 weeks (setup + pilot)

Team

Eng, PM, Product Ops

Outcome

Enterprise rollout decision

The result

2.7×

Throughput gain

93%

Cycle completion

5.0

Engineer satisfaction

6wk

Pilot duration

The question

Fix what we have, or replace it?

Our Jira instance had years of accumulated complexity. Non-standardized issue types, no cross-team initiative visibility, significant abandoned space alongside active work. The proposed fix was months of contractor-led cleanup. Before signing off, I wanted to test a different question.

The method

Real engineers, real work, real data.

I designed a six-week live pilot. Not a sandbox. Real engineers doing real work, benchmarked in both systems. Five target metrics set before the pilot started. Issue throughput, satisfaction, cycle completion, tracking percentage, resolution time.

"The data made the case."

The recommendation

A capability decision, not a cost cut.

The financial case wasn't a savings story. It was a capability story. Capability decisions survive procurement cycles. Savings decisions get re-litigated. The migration moved forward as a full org cut-over with white-glove customer success onboarding.

Five metrics. Four hits. One partial. Zero misses.

The pilot hit every target I set.

Issue creation frequency

2.7×

Issues created per engineer per week, baseline measured in Jira against pilot in Linear over six weeks. Target was 2×.

JIRA BEFORE 1.0× baseline LINEAR AFTER 2.7× throughput TARGET 2× 0 2.7×

Issue creation frequency

Target: 2× increase

2.7× throughput per engineer, per week
HIT

Engineer satisfaction

Target: 4.0+ in Linear

5.0/5 overall. Every dimension above 4.0.
HIT

Cycle completion rate

Target: stable or improved

100%, 87%, 93% across first three cycles. Planning 4 cycles ahead.
HIT

% of work tracked

Target: 80%+

4 of 5 respondents at 75 to 100%. Most issues tied to a project.
HIT

Issue resolution time

Target: faster

Median work time under 2 days. Jira baseline unavailable in export.
PARTIAL

Voice of the engineer

"Please let us keep using Linear. I desperately do not want to go back to Jira."

Pilot engineer · Post-pilot survey

What I did

Design leadership isn't just about what ships.

Framing the right question.

Most "tooling decision" stories are project-management fables. The leverage is reframing it as capability versus cost, not Jira versus Linear.

Holding the test accountable.

Five target metrics set before the pilot, not after. Methodology designed to be defensible to dissenters. Result presented as a business case.

Managing the dissent.

When the data is too good, the dissent gets sharper. Solution engineering sessions to address concerns directly before the cutover decision.

The meta-point

Design leadership isn't just about what ships.
It's about what gets decided.

Framing the right question. Designing a defensible test methodology. Holding it accountable to pre-set metrics. Presenting the result as a business case rather than a feature wishlist. That's what design leadership at the executive level actually looks like.