# Lines of Code metrics vs. the productivity metrics that matter | LinearB Blog

> Lines of Code metrics don’t measure productivity. Learn why LOC is misleading and which engineering metrics actually reflect impact, efficiency, and value.

_This is a markdown rendering of a live HTML page on linearb.io, generated for AI/LLM consumption — it is not a markdown-only site. To get the full HTML page instead, request this URL with an explicit `Accept: text/html` header (no wildcard, no markdown preference)._


```json
{
  "@context": "https://schema.org",
  "@type": "BreadcrumbList",
  "itemListElement": [
    {
      "@type": "ListItem",
      "position": 1,
      "name": "Home",
      "item": "https://linearb.io/"
    },
    {
      "@type": "ListItem",
      "position": 2,
      "name": "Blog",
      "item": "https://linearb.io/blog"
    },
    {
      "@type": "ListItem",
      "position": 3,
      "name": "Lines of Code metrics vs. the productivity metrics that matter",
      "item": "https://linearb.io/blog/lines-of-code"
    }
  ]
}
```

[Home](https://linearb.io/)

/

[Blog](https://linearb.io/blog)

/

Lines of Code metrics vs. the productivity metrics that matter

# Lines of Code metrics vs. the productivity metrics that matter

![Photo of Natalie Breuer](https://assets.linearb.io/image/upload/c_limit,w_2560/f_auto/q_auto/v1/Natalie_Breuer_e5764bbbac?_a=BAVMn6ID0)

By [Natalie Breuer](https://linearb.io/blog/lines-of-code#natalie-breuer)

|

May 8, 2025

![Lines_of_Code_metrics_vs_the_productivity_metrics_that_matter_df08044262](https://assets.linearb.io/image/upload/c_limit,w_2560/f_auto/q_auto/v1/Lines_of_Code_metrics_vs_the_productivity_metrics_that_matter_df08044262?_a=BAVMn6ID0)

Are your engineering teams still being evaluated by how many lines of code they write? Do sprint reviews focus on volume rather than impact? Or perhaps you're struggling to articulate why your most productive developers aren't necessarily the ones generating the most code.

You're not alone. Despite decades of evidence against it, Lines of Code (LOC) remains a surprisingly persistent metric in engineering management discussions. This outdated approach creates misaligned incentives, rewards inefficiency, and ultimately undermines the very outcomes you're trying to achieve.

Modern engineering leadership focuses on outcomes, not output. The most effective engineering organizations understand that true productivity is defined by delivering customer and business value, not simply writing more code.

In this blog, you'll learn:

* Why LOC fails as a developer productivity metric and creates harmful incentives
* Which metrics actually correlate with high-performing engineering teams
* How to implement a more effective measurement framework
* Practical strategies to improve both [developer productivity](https://linearb.io/blog/developer-productivity) and experience

## **What are Lines of Code (LOC) in software engineering?**

Lines of Code (LOC) is a size-oriented software metric that counts the number of lines in program source code, and comes in two primary variants:

**Physical LOC** counts raw line numbers in a source file, including comments, blank lines, and formatting. This basic measurement treats every line equally, regardless of content or significance.

**Logical LOC** (or SLOC) attempts to improve accuracy by counting only executable statements or declarations. While more nuanced than physical LOC, logical SLOC still focuses solely on quantity over quality, complexity, or business impact.

Both metrics share a fundamental limitation: they measure size, not complexity, quality, or value. A 10-line algorithm that solves a critical business problem delivers far more value than 100 lines of boilerplate code—yet LOC metrics would suggest the opposite.

LOC is also trivially easy to manipulate. Developers can artificially inflate their "productivity" by:

* Using verbose coding styles with unnecessary line breaks
* Avoiding code reuse in favor of copy-pasting
* Writing inefficient implementations that require more code
* Generating excessive comments or documentation

This gamification potential makes LOC not just an ineffective metric, but an actively harmful one.

## **Why Lines of Code is a misleading productivity metric**

### **Language differences skew LOC counts**

Different programming languages express the same functionality with dramatically different line counts. A function that requires 50 lines in Java might need only 5 in Python. Even within the same language, different libraries or frameworks can affect verbosity.

Consider this example of a simple function to read a file and count word occurrences:

In Python:

```yaml
def count_words(filename):
    with open(filename) as f:
        return len(f.read().split())
```

The equivalent Java implementation might require 15-20 lines with imports, exception handling, and more verbose syntax. This disparity makes cross-language productivity comparisons meaningless when using LOC.

### **More code doesn't mean more value**

High-performing developers often write less code instead of more via better architecture, modularization, and reuse. They understand that every line of code is a liability that must be maintained, tested, and debugged.

The most valuable engineering contributions frequently involve:

* Finding elegant solutions that reduce complexity
* Creating reusable components that prevent duplication
* Implementing algorithms that solve problems with minimal code
* Making architectural decisions that simplify the codebase

By measuring LOC, you inadvertently discourage these high-value activities and instead reward verbosity and inefficiency.

### **LOC incentivizes the wrong behaviors**

When developers know they're being evaluated on code volume, they naturally optimize for that metric, often at the expense of more important outcomes like code quality, maintainability, and business impact.

This misalignment creates several problematic behaviors:

* Avoiding refactoring (it often reduces line count)
* Writing verbose, inefficient implementations
* Adding unnecessary features to inflate code production
* Focusing on easy, code-heavy tasks rather than challenging problems

### **Refactoring and code complexity are invisible**

Some of the most valuable engineering work reduces LOC rather than increases it. Refactoring, simplification, and [technical debt reduction](https://linearb.io/blog/7-simple-effective-steps-to-reduce-technical-debt) often result in smaller, more maintainable codebases—yet LOC metrics would register this critical work as "negative productivity."

Similarly, LOC fails to capture [cognitive complexity](https://linearb.io/blog/cognitive-complexity-in-software)—how difficult code is to understand and maintain. A dense, complex 50-line function might be far more challenging to work with than a clear, well-structured 200-line implementation with proper abstraction.

**Optimizing for LOC vs. Better Code**

**LOC-Focused Teams:**

* Prioritize quantity over quality
* Avoid refactoring and simplification
* Create verbose implementations
* Incur higher maintenance costs

**Quality-Focused Teams:**

* Prioritize maintainability and efficiency
* Regularly refactor and improve code
* Focus on elegant, minimal solutions
* Reduce long-term technical debt

## **What metrics actually reflect developer productivity?**

Instead of focusing on Lines of Code, effective engineering leaders measure outcomes and flow efficiency. These metrics provide more meaningful insights into both individual and team productivity while aligning technical work with business value.

Lead Time for Changes (aka [Cycle Time](https://linearb.io/blog/cycle-time)) measures how quickly your team can deliver code improvements from first commit to production deployment. This comprehensive metric tracks your entire delivery pipeline efficiency and directly correlates with your ability to deliver customer value. Unlike LOC, shorter Lead Time indicates a healthier engineering organization with streamlined processes. Breaking this metric down into components—coding time, pickup time, review time, and deploy time—reveals exactly where bottlenecks form in your workflow.

![Software development cycle time breakdown displaying an average cycle time of 1 day and 19 hours. The breakdown includes 16 hours for coding, 54 minutes for pickup, 2 days and 3 hours for review, and 5 days and 18 hours for deployment. Visual representation of engineering workflow efficiency.](https://assets.linearb.io/image/upload/v1728446494/Cycle_time_Oct_2024_b6f8966fda.png)

[PR Size](https://linearb.helpdocs.io/article/x1620txj8m-pull-request-size) and Merge Frequency offer actionable insights into your development efficiency. Smaller PRs (under 200 lines changed) typically receive faster reviews, contain fewer defects, and merge more quickly. Teams that optimize for manageable PR sizes and higher merge frequency see compounding benefits in delivery speed and team morale. 

> Merging developers are happy developers.

PM Hygiene Metrics like Issues Linked to Parents and Branches Linked to Issues help ensure alignment between code changes and planned work items. While paradoxically, elite teams sometimes show lower PM hygiene metrics (prioritizing speed over documentation), most organizations benefit from strong traceability to improve forecasting and predictability.

Accuracy Scores measure planning effectiveness and execution. Planning Accuracy tracks how much planned work is actually delivered, while Capacity Accuracy measures completed work against planned capacity. Together, these metrics reveal whether teams can reliably meet delivery commitments—a critical aspect of engineering productivity.

PR Maturity indicates how effective your development process is before code review. High PR maturity (where PRs need minimal changes after submission) correlates with higher velocity, as developers create more complete and polished work before requesting reviews.

![Stacked bar chart showing the distribution of PR Maturity Ratio benchmarks across different Pickup Time performance tiers—Elite, Strong, Fair, and Needs Focus. Each bar is segmented by maturity levels: Elite (blue), Strong (purple), Fair (lavender), and Needs Focus (red), highlighting the correlation between fast pickup times and higher pull request maturity.](https://assets.linearb.io/image/upload/v1733948758/PR_Maturity_Ratio_vs_Pickup_time_39490d77c8.png)

By focusing on these outcome-oriented metrics instead of code volume, you align engineering incentives with true business value: delivering working, high-quality features to customers quickly and reliably. 

Learn more about the Developer Productivity Metrics that matter in our [Engineering Leader’s Guide to Accelerating Developer Productivity → ](https://linearb.io/resources/engineering-leader-guide-to-accelerating-developer-productivity)

[![Cover image for LinearB’s 'Engineering Leader’s Guide to Accelerating Developer Productivity.' Features modern grid and target-style graphics alongside the LinearB logo, emphasizing data-driven engineering leadership strategies.](https://assets.linearb.io/image/upload/v1739559498/Engineering_Leader_s_Guide_to_Accelerating_Developer_Productivity_2025_5710b7d6c8.png)](https://linearb.io/resources/engineering-leader-guide-to-accelerating-developer-productivity)

## **Why Developer Experience (DevEx) is the key to sustainable productivity**

Beyond metrics, the most forward-thinking engineering organizations recognize that [Developer Experience](https://linearb.io/platform/developer-experience) (DevEx) directly impacts productivity, quality, and retention. DevEx encompasses all factors that affect how effectively developers can deliver value; from tools and workflows to culture and cognitive load.

[DevEx isn't just a feel-good initiative; it's a strategic investment with measurable returns. ](https://linearb.io/blog/measuring-and-reporting-dev-ex-metrics-that-impact-business-value)Removing friction from the development process unlocks capacity and creativity. When developers spend less time wrestling with tooling, waiting for builds, or navigating confusing requirements, they dedicate more energy to solving core business problems.

Effective DevEx improvements include:

* Optimizing CI/CD pipelines to provide faster feedback (sub-10 minute builds)
* Implementing [AI Code Review](https://linearb.io/blog/ai-code-review) tools that catch issues early
* Creating self-service internal platforms for common development tasks
* Reducing cognitive load through better documentation and knowledge sharing
* Establishing clear requirements and communication channels with stakeholders

One critical DevEx element often overlooked is cognitive overload. Productivity plummets when developers context-switch between too many tasks or navigate overly complex systems. By measuring and reducing these mental burdens, you help your team maintain flow state and peak performance.

This isn't just a feel-good slogan; it's a business reality. When your team spends less time fighting tooling and more time creating value, productivity naturally increases without artificial metrics or pressure tactics.

## **How engineering leaders should rethink engineering metrics**

Transforming your approach to [engineering metrics](https://linearb.io/platform/engineering-metrics) requires intentional leadership and a clear focus on business outcomes. The most successful engineering leaders follow these principles when evolving their measurement approach:

First, stop incentivizing raw code volume in any form. Remove LOC from performance reviews, sprint reports, and team dashboards. This sends a clear signal that quality and impact, not volume, drive recognition and advancement.

Instead, track and report on:

* Feature delivery speed and predictability
* User-facing reliability and performance metrics
* Incident response effectiveness
* Customer satisfaction and adoption rates

Want to align engineering metrics with business outcomes that executives and stakeholders value? [Download our CTO Board Deck Template →](https://linearb.io/resources/cto-board-slides)

This alignment helps demonstrate how engineering work directly contributes to company goals, elevating technical discussions beyond just "how much code did we write?"

Implement a balanced measurement framework that combines engineering efficiency with developer experience signals. The most effective approach integrates:

* [DORA metrics](https://linearb.io/blog/dora-metrics) (Deployment Frequency, Lead Time, Change Failure Rate, Mean Time to Restore)  
![Engineering metrics dashboard displaying key DevOps KPIs: 9% Change Failure Rate (CFR), 21 weekly deployments, 8-hour Mean Time to Recovery (MTTR), and an average cycle time of 3 days and 8 hours. Cycle time is broken down into coding, pickup, review, and deploy stages, with visual trend graphs for each metric.](https://assets.linearb.io/image/upload/v1732649903/Group_6928_14e03d2d2a.png)
* [Flow metrics](https://linearb.io/blog/5-key-flow-metrics) (efficiency, load, distribution)
* Developer Experience indicators (satisfaction, friction points, tool effectiveness)
* Business impact measures (feature adoption, customer retention)

This holistic view prevents optimization of one dimension at the expense of others, creating sustainable high performance rather than short-term productivity spikes.

**5 Steps to Modernize Your Engineering Metrics:**

1. Establish baseline measurements for Lead time, Cycle Time, and Change Failure Rate, and compare them against [industry benchmarks](https://linearb.io/resources/software-engineering-benchmarks-report)
2. Identify your biggest bottlenecks using Cycle Time breakdown analysis
3. Implement [workflow automation](https://linearb.io/platform/workflow-automations) to address those specific bottlenecks
4. Create team-level dashboards that highlight outcomes over output
5. Build a feedback loop connecting engineering metrics to business results

These steps create a virtuous cycle where measurement drives improvement, not just assessment. Teams gain visibility into how their work impacts the broader organization while leaders gain insights that inform smarter resource allocation and strategic planning.

## **Delivering value, not just writing code**

The shift from measuring code volume to measuring outcomes represents a fundamental evolution in how you view [engineering productivity](https://linearb.io/blog/engineering-productivity).

Developer productivity isn't about counting; it's about impact. The most valuable engineers often write less code, not more, because they understand that every line introduces complexity and maintenance costs. They deliver outsized impact through smart architecture decisions, elegant abstractions, and focused problem-solving.

By modernizing your measurement approach, you unlock significant gains across key dimensions:

* Higher team performance through better-aligned incentives
* Improved retention by focusing on meaningful work
* Enhanced business results from faster, more reliable delivery
* Greater organizational resilience through sustainable engineering practices

Are you ready to move beyond Lines of Code and build a more effective, outcome-oriented engineering organization?

Learn how [LinearB’s Engineering Productivity Platform](https://linearb.io/platform/overview) helps engineering leaders track real productivity and improve DevEx with actionable metrics that connect development work to business outcomes.

[Book a demo here →](https://linearb.io/book-a-demo)

## **FAQ**

### **What is a source line of code?**

A source line of code (SLOC) is a software metric that counts the number of lines in a program's source code. There are two main types: physical SLOC, which counts all lines including comments and blank lines, and logical SLOC, which counts only executable statements or declarations. While easy to measure, SLOC varies significantly between programming languages and doesn't reflect code quality or functionality.

### **Why is LOC a bad metric for productivity?**

LOC is a poor productivity metric because it encourages writing verbose, inefficient code rather than elegant solutions. LOC ignores that skilled developers often create more value with less code, varies dramatically between programming languages, and fails to capture refactoring efforts that improve code but reduce line count.

As Bill Gates once said: 

> "Measuring software productivity by Lines of Code is like measuring progress on an airplane by how much it weighs."

### **What are alternatives to Lines of Code metrics?**

More effective alternatives to LOC include:

* DORA metrics (Deployment Frequency, Lead Time, Change Failure Rate, Recovery Time)
* Function Point Analysis for measuring software size based on functionality
* Cyclomatic complexity for assessing code's logical complexity
* Pull request metrics like PR Size, Review Time, and Merge Frequency
* Business outcome measures like feature adoption rates and customer satisfaction
* Developer experience indicators gathered through team surveys and feedback

### **What is Function Point Analysis and how does it compare to LOC?**

Function Point Analysis (FPA) measures software size by counting its functional components from a user perspective rather than counting lines of code. Developed by Allan Albrecht at IBM in 1979, FPA categorizes and weights software functions like inputs, outputs, queries, and data files, providing a language-independent measure of software functionality. Unlike LOC, FPA correlates better with development effort across different languages and technologies, though it requires more expertise to implement correctly.

### **How do DORA metrics improve on traditional code metrics?**

DORA (DevOps Research and Assessment) metrics focus on delivery outcomes rather than code quantity, providing a more meaningful measure of engineering effectiveness. Unlike LOC, they track metrics that directly impact business success: how frequently you deploy (Deployment Frequency), how quickly you deliver changes (Lead Time), how often changes cause problems (Change Failure Rate), and how quickly you recover from incidents (Time to Restore). These metrics align technical performance with business goals and customer satisfaction rather than rewarding code volume.

### **How should engineering leaders measure team productivity?**

Effective engineering leaders measure productivity through outcome-based metrics rather than output metrics like LOC. Focus on delivery metrics (like DORA), business impact measures (feature adoption rates, revenue generated), and developer experience indicators (team satisfaction, friction points). Combine quantitative data with qualitative feedback to understand both what teams produce and how efficiently they work. The most meaningful productivity metrics connect engineering activities directly to business goals and customer value.

## Improve developer productivity with LinearB

Find us on

[](https://www.linkedin.com/company/linearb)
[](https://devinterrupted.substack.com/)

![Natalie_Breuer_e5764bbbac](https://assets.linearb.io/image/upload/c_limit,w_2560/f_auto/q_auto/v1/Natalie_Breuer_e5764bbbac?_a=BAVMn6ID0)

## Natalie Breuer

Natalie Breuer, now a Senior Product Marketing Manager at LinearB, has been in the Developer Productivity Insights space since 2019\. A writer at heart, Natalie loves bringing technical topics to life with human stories – bridging the gap between data and storytelling.

## Your next read

[![Cover image for AI ROI comes from measuring engineering outcomes on day one](https://assets.linearb.io/image/upload/c_limit,w_2560/f_auto/q_auto/v1/Blog_AI_ROI_comes_from_measuring_engineering_software_security_2400x1256_2c5eae0862?_a=BAVMn6ID0)](https://linearb.io/blog/kraken-nik-sudan-measure-ai-roi-engineering-outcomes)

Eng. Metrics

[AI ROI comes from measuring engineering outcomes on day one](https://linearb.io/blog/kraken-nik-sudan-measure-ai-roi-engineering-outcomes)

Kraken Engineering Operations Lead Nik Sudan details how to establish day-one data infrastructure to accurately measure AI ROI. Discover why raw token adoption...

[![Cover image for AI is rebuilding software delivery from SDLC to ADLC](https://assets.linearb.io/image/upload/c_limit,w_2560/f_auto/q_auto/v1/Blog_AI_rebuilding_software_delivery_2400x1256_3fd5887e75?_a=BAVMn6ID0)](https://linearb.io/blog/sdlc-to-adlc-agentic-software-delivery-transformation)

Eng. Metrics

[AI is rebuilding software delivery from SDLC to ADLC](https://linearb.io/blog/sdlc-to-adlc-agentic-software-delivery-transformation)

Discover how engineering organizations are transitioning from the traditional SDLC to an Agentic Development Lifecycle (ADLC). Learn why rising token costs...

[![Cover image for 8 million pull requests reveal where engineering productivity breaks down](https://assets.linearb.io/image/upload/c_limit,w_2560/f_auto/q_auto/v1/Blog_8_million_pull_requests_2400x1256_03724bfbb2?_a=BAVMn6ID0)](https://linearb.io/blog/8-million-prs-engineering-productivity)

Eng. Metrics

[8 million pull requests reveal where engineering productivity breaks down](https://linearb.io/blog/8-million-prs-engineering-productivity)

8.1M pull requests reveal the gap between AI adoption and engineering impact, and why code review is the bottleneck blocking real productivity gains.

## Structured data

_Machine-readable metadata (JSON-LD) embedded in the page for search/AI context — not content rendered on the page itself._

```json
{
  "@context": "https://schema.org",
  "@type": "Organization",
  "name": "LinearB",
  "url": "https://linearb.io/",
  "logo": "https://assets.linearb.io/image/upload/v1715628027/logo-mark-lg.svg",
  "description": "LinearB is the engineering productivity platform that helps engineering leaders prove AI is improving throughput without sacrificing delivery confidence, flow efficiency, or developer experience.",
  "sameAs": [
    "https://www.linkedin.com/company/linearb"
  ],
  "award": [
    {
      "@type": "Award",
      "name": "LinearB is a Leader in the 2026 Gartner® Magic Quadrant™ for Developer Productivity Insight Platforms",
      "dateAwarded": "2026",
      "awardedBy": {
        "@type": "Organization",
        "name": "Gartner®"
      }
    },
    {
      "@type": "Award",
      "name": "Great Place to Work Certification",
      "dateAwarded": "2025-2027",
      "awardedBy": {
        "@type": "Organization",
        "name": "Great Place to Work"
      }
    },
    {
      "@type": "Award",
      "name": "America's Best Startup Employers 2025",
      "dateAwarded": "2025",
      "awardedBy": {
        "@type": "Organization",
        "name": "Forbes Magazine"
      }
    }
  ],
  "hasCertification": [
    {
      "@type": "Certification",
      "name": "SOC 1 Type 2"
    },
    {
      "@type": "Certification",
      "name": "SOC 2 Type 2"
    },
    {
      "@type": "Certification",
      "name": "GDPR Compliance certification"
    },
    {
      "@type": "Certification",
      "name": "ISO 27001"
    }
  ]
}
```

```json
{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "Lines of Code metrics vs. the productivity metrics that matter",
  "url": "https://linearb.io/blog/lines-of-code",
  "author": {
    "@type": "Person",
    "name": "Natalie Breuer"
  },
  "datePublished": "2025-05-08T07:00:00.000Z",
  "dateModified": "2025-05-08T07:00:00.000Z",
  "image": "https://assets.linearb.io/image/upload/v1746727003/Lines_of_Code_metrics_vs_the_productivity_metrics_that_matter_df08044262.png",
  "publisher": {
    "@type": "Organization",
    "name": "LinearB",
    "logo": "https://assets.linearb.io/image/upload/v1777485755/linearb-logo-2026.png"
  },
  "description": "Lines of Code metrics don’t measure productivity. Learn why LOC is misleading and which engineering metrics actually reflect impact, efficiency, and value."
}
```

## More on linearb.io

### Top navigation

- [Book a Demo](https://linearb.io/book-a-demo)
- [AI Code Reviews — Catch security risks, bugs, and spec mismatches](https://linearb.io/platform/ai-code-reviews)
- [AI & Productivity Insights — See how AI tools affect cycle time and delivery speed](https://linearb.io/platform/ai-developer-productivity-insights)
- [Measure AI Impact — Track AI adoption and tie it to delivery outcomes](https://linearb.io/use-case/measure-ai-impact)
- [MCP Server — Chat with your data to spot patterns and boost output](https://linearb.io/platform/mcp-server)
- [Resource Allocation — Cost initiatives and shape your investment strategy](https://linearb.io/platform/resource-allocation)
- [Cost Capitalization — Capitalize engineering costs with audit-ready reports](https://linearb.io/platform/cost-capitalization)
- [Dev Team Management — Set targets and tie throughput to business outcomes](https://linearb.io/platform/goals-and-reporting)
- [DevOps Workflow Automation — Policy-based PR routing, approvals, and tests](https://linearb.io/platform/ai-workflow-governance)
- [AI Powered Support — Unify AI and human code delivery in one clear view](https://linearb.io/use-case/ai-powered-support)
- [Optimization — Surface friction with feedback and MCP insights](https://linearb.io/platform/developer-experience)
- [Reporting — Spot what's working and what needs attention](https://linearb.io/use-case/measuring-developer-experience)
- [Surveys — Turn developer feedback into actionable signals](https://linearb.io/platform/developer-surveys)
- [Platform overview](https://linearb.io/platform/overview)
- [Register now](https://linearb.io/event/engineering-productivity-gap)
- [Customers](https://linearb.io/customers)
- [Pricing](https://linearb.io/pricing)
- [Why choose LinearB — Explore your data. Measure performance. Act to improve it.](https://linearb.io/why-linearb)
- [APEX framework — The operating model for AI-era engineering teams](https://linearb.io/resources/apex-framework)
- [Anti-FAQ — The questions other vendors won't answer](https://linearb.io/why-linearb/anti-faq)
- [Security — Enterprise-grade compliance and zero code access](https://linearb.io/security)
- [Build vs. buy — The hidden cost of building it yourself](https://linearb.io/resources/build-vs-buy)
- [Dev Interrupted Podcast — Conversations with engineering leaders](https://linearb.io/dev-interrupted/podcasts)
- [Reports & Guides — Deep dives on productivity and delivery](https://linearb.io/resources)
- [Webinars — Expert sessions on productivity and AI](https://linearb.io/resources?category=workshops)
- [Metrics Benchmarks — See how your engineering org stacks up](https://linearb.io/resources/software-engineering-benchmarks-report)
- [Blog — Product updates and practical insights](https://linearb.io/blog)
- [Help Center — Documentation, setup, and support](https://linearb.helpdocs.io)
- [API Docs](https://docs.linearb.io/api-overview)
- [Status](https://www.linearbstatus.com/)
- [Integrations](https://linearb.io/integrations)
- [LinearB Library](https://linearb.io/library)
- [Engineering metrics](https://linearb.io/library/engineering-metrics)
- [Platform engineering](https://linearb.io/library/platform-engineering)
- [Engineering glossary](https://linearb.io/library/engineering-glossary)
- [Developer productivity](https://linearb.io/library/developer-productivity)
- [AI in software development](https://linearb.io/library/ai-in-software-development)
- [Engineering management](https://linearb.io/library/engineering-management)
- [Developer experience](https://linearb.io/library/developer-experience)
- [DevOps](https://linearb.io/library/devops)
- [Engineering operations and the context layer](https://linearb.io/library/engineering-operations)
- [Engineering efficiency](https://linearb.io/library/engineering-efficiency)
- [Software delivery](https://linearb.io/library/software-delivery)
- [Research and data](https://linearb.io/library/engineering-benchmarks-and-research)
- [LinearB is a Leader in the 2026 Gartner® Magic Quadrant™ for Developer Productivity Insight Platforms](https://linearb.io/resources/gartner-magic-quadrant-dpi-platforms-2026)
- [Sign in](https://app.linearb.io/login)
- [Enterprise](https://linearb.io/solutions/enterprise)
- [Contact](https://linearb.io/contact-us)
- [About us](https://linearb.io/about-us)
- [Careers](https://linearb.io/careers)
- [Service agreement](https://linearb.io/services-agreement)
- [Privacy policy](https://linearb.io/privacy-policy)
- [DPA](https://linearb.io/data-processing-agreement)
- [Security FAQ](https://linearb.io/security-faq)
- [Substack](https://devinterrupted.substack.com/)

### Footer

_Additional links from the site footer, not repeated from the top navigation above._

- [GitHub](https://github.com/linear-b)
- [LinkedIn](https://www.linkedin.com/company/linearb)
- [Twitter](https://twitter.com/LinearB_Inc)