Linear

Linear exposes several object types: issues, cycles, projects, teams, workflow states, and labels. This integration focuses exclusively on issues, which represent the atomic unit of work and the only object type where attribution to an individual contributor is reliable. Cycles and projects expose useful team-level aggregates but do not support per-user attribution in a way that is meaningful for OKR management. Six KPIs were retained, selected against three criteria: ability to attribute to an owner via direct email resolution, resistance to gaming, and balance between leading and lagging indicators.

Delivery throughput and personal velocity

Issues Completed counts the number of issues an engineer closes within a period. Average Cycle Time measures the average number of days between an issue entering active development and its completion. These two indicators function as a deliberate counterweight to each other. Issues Completed creates an incentive to ship volume; Average Cycle Time constrains that incentive by penalizing the practice of rushing small or trivial issues through to inflate throughput. An engineer with a high count and a very short cycle time may be closing low-complexity issues exclusively, while an engineer with a moderate count and stable cycle time may be absorbing the more demanding work. Reading both together reveals the actual quality of the throughput, not just its quantity.

High Priority Issues Completed adds a third dimension to this group. It filters the completion count to urgent and high priority issues only, isolating the fraction of throughput directed at what the team has declared most important. A high Issues Completed combined with a low High Priority Issues Completed reveals a prioritization gap: the engineer is productive but not focused on what matters. This combination is among the strongest misalignment signals the integration can surface.

Commitment reliability and flow health

Cycle Carryover counts the number of issues an engineer had in progress or unstarted at the end of a cycle without completing them. It is the most direct measure of commitment reliability available in Linear: it does not measure effort or intent, only outcome against the plan the team made at the start of the cycle. A sustained carryover across cycles may indicate poor scoping, frequent context switching, or issues that are systematically larger than estimated. Stale Issues measures the number of in-progress issues that have not been updated in five days. It operates one level earlier in the process than carryover: rather than confirming that work was not completed, it signals in real time that work has stopped moving. Together, Stale Issues (leading) and Cycle Carryover (lagging) form a detection chain: staleness predicts carryover before the cycle boundary makes it visible.

Workload seeding

Issues Opened counts the number of issues a user creates within the period, attributed to the creator rather than the assignee. It measures active contribution to the pipeline: engineers who create well-scoped issues are investing in the team's future capacity to ship. This indicator carries a Goodhart risk if read in isolation — issue creation is cheap and unverifiable in terms of quality — but the risk is neutralized when paired with Issues Completed: a creator with a high Issues Opened count and a low personal Issues Completed signals someone seeding work they do not carry through themselves. The relationship between the two rates is the relevant signal.

Scope and limits of the integration

Linear records state transitions and timestamps, but does not measure the quality of work produced. An issue marked completed may correspond to a robust, well-tested implementation or to a partial fix that will generate downstream regressions; the API data does not distinguish between the two. Average Cycle Time in particular depends on teams using Linear workflow states consistently: if engineers mark issues as started irregularly or only at the moment of completion, the computed cycle time collapses to near zero and loses its diagnostic value. High Priority Issues Completed depends on teams applying priority fields in a disciplined and standardized way; teams that use priority labels loosely or inconsistently will produce a metric that is not comparable across individuals.

More broadly, this integration captures only what is documented in Linear. Work coordinated outside the tool — in Slack threads, in shared documents, in direct debugging sessions — remains invisible. The reliability of all six KPIs depends directly on the team's discipline in keeping Linear updated as the source of truth for their work.