# PanDev Metrics — Full Site Content > AI Engineering Intelligence Platform. PanDev collects accurate IDE-based development data and analyzes it with AI. This file aggregates the complete public content of pandev-metrics.com — landing pages, product documentation and the engineering blog — for consumption by LLMs (ChatGPT, Claude, Perplexity, Google AI Overviews and similar). > > Generated automatically. Last update: 2026-04-28. > Canonical site: https://pandev-metrics.com/ > Authoritative sitemap: https://pandev-metrics.com/sitemap.xml --- # Section 1 — Marketing Landing > AI Engineering Intelligence Platform: collect accurate IDE-based development data and analyze it with AI. The marketing-facing positioning for the product, target audiences (engineering managers, individual developers, executives), and use cases. ## Homepage — AI Engineering Intelligence Platform URL: https://pandev-metrics.com/ ### Meta description PanDev Metrics is an AI engineering intelligence platform that unifies IDE, Git, and task data. Improve developer productivity, track delivery signals, and forecast releases. ### Hero AI Engineering Intelligence Platform An intelligent platform that measures, predicts and accelerates development CTAs: Book a demo / Learn more ### Founders' promise Give PanDev two weeks We have spent years in engineering and we build PanDev for teams like ours. Install it for 14 days and you will see a real picture of how your teams and processes work. If you do not get value in those two weeks, we have not done our job. - Artur Pan — Founder / CTO - Madiyar Bakbergenov — Co-Founder / CEO / CCO ### Press about us - MA7 Ventures invested $400K at a $5M valuation in a Kazakhstani startup - How a founder invested his $100,000 and turned an internal IT tool into a global B2B product - Interview with the founders of PanDev Metrics ### Unified data sources (chip hub) - **IDE** — Development environment and code editor - **Task Tracker** — Project task management - **GIT** — Source code version control - **LLM** — AI tools for software development - **Terminal** — System administration Key signals: Estimation accuracy, Time to market. ### Team analytics positioning Team analytics. No reports. Real-time development metrics ### Trusted by leading companies Trusted by engineering teams building products that matter ### A unified engineering view instead of scattered tools One dashboard instead of five standups. PanDev connects your IDE, Git, and task tracker so everyone sees the same picture — without asking ### Data that empowers the team PanDev Metrics highlights developers’ contributions, simplifies leadership conversations, and cuts reporting overhead ### Engineering efficiency and economics Find the process bottlenecks that slow your team down — and fix them together. ### Faster releases and product growth Early data signals help you spot risks, remove delays, and make feature delivery predictable. ### Data that makes sense for every level of leadership PanDev provides one view of development for all levels. From CEO to team lead, everyone sees the right level of detail and spends less time on reports and status calls. ### Final CTA We invite you to try PanDev Metrics ### PanDev in 3 Minutes A quick look inside PanDev Metrics, the interface, key metrics, and main use cases. ### Pull-quote Give PanDev two weeks with your team. We have spent years in engineering and we build PanDev for teams like ours. Run it for 14 days in your environment and you will get a clear picture of your teams and processes. If you do not see value in those two weeks, we have not done our job well enough. ### Value-prop grids **For team leaders** - **Deep engineering analytics** — See the full picture of how work flows through your team — from first keystroke to merged PR - **Data-driven one-on-ones** — Protect your team from burnout. See who's overloaded before they tell you — and recognize contributions that usually go unnoticed. - **Decisions 30% faster** — Leaders and engineers share one view of the work, so priorities and plans align faster. - **Unified dashboard** — No more status updates that pull engineers out of flow. Everyone sees progress without interrupting anyone. **Development efficiency** - **Automated worklogs** — A complete change history across tasks and code is always at hand. Easier audits, faster incident reviews, smoother handovers. - **Save 10–30% of your development budget** — Cut rework and unnecessary steps. More resources go into the product, not operational waste. - **20% fewer contractor disputes*** — Faster onboarding — new team members see the full project context from day one - **Save up to 200 hours of C-level time per year*** — Leaders get one reliable view of development. Less time spent resolving issues, clarifying status, and preparing for meetings. **Faster releases** - **Ship features to market faster** — Fewer delays from idea to release. - **Release forecasting** — Date estimates based on task history and team activity. - **Historical insights** — Compare releases and initiatives and measure change impact. - **Data-driven culture** — Teams and leadership make decisions using one shared set of data. --- ## For Teams — Control releases on facts, not statuses URL: https://pandev-metrics.com/teams ### Hero _PANDEV METRICS_ **Control Release on Facts, Not Statuses** IDE, Git, and Tracker in one picture. Understand where work stands and why. Statuses hide expectations and queues. We show the real flow of changes and signals that require intervention. _No screen recording. No messaging snooping._ CTAs: Book a Demo / Go to Workspace ### Hero themes (rotating headlines) - **Eliminate Daily Standups and Control Releases Better** — Fact-based control from IDE, Git, and Tracker. Calls only on signals, not on schedule. Standups replace observability. We show where the release is stuck and why: queues, waiting, blockers, interruptions. - **"Almost Done" for Weeks. Replace Statuses with Facts** — See what's really happening in IDE, Git, and Tracker. No status games. "In Progress" doesn't explain delays. Facts show bottlenecks: lack of focus, PRs stuck in review, testing bottlenecks, unplanned work growth. - **Why Releases Are Slow and Where the Flow is Stuck** — Find bottlenecks with data, not feelings. IDE, Git, Task Tracker. Code is written, but release isn't moving because work gets stuck between steps. We show queues and wait times so you can remove causes instead of pressuring people with calls. - **Control Releases based on Facts, not Statuses** — IDE, Git, and Tracker in one picture. Clear understanding of where work stands and why. Statuses hide expectations and queues. We show the real flow of changes and signals requiring intervention. ### "In Progress" hides 80% of idle time Your team isn't working slowly. They are waiting. The task is active in the tracker, but in reality, it's sitting in a queue. - Jira / Tracker: In Progress (5 days) - PanDev / Reality (legend: Active Work vs Idle (Gap)) ### Three Layers of Facts – The Complete Picture PanDev unifies data from IDE, Git, and Tracker to reveal the reality hidden behind statuses. We link editor activity, code movement, and task context to create a solid foundation for decisions without manual reports. ### No time for a demo? Watch the overview A brief look at how PanDev highlights process bottlenecks. ### Demo booking Want to see it on your data? Choose a time for a demo. We'll show you how to improve process efficiency by replacing statuses with engineering facts. Steps: Select Day / Select Time / Meeting Details CTA: Confirm Booking ### FAQ **Frequently Asked Questions** - _Is this time-tracking?_ — No. The goal is not "hours", but flow observability: focus, queues, waiting, blockers. - _Is this spying on developers?_ — No. No screen recording, no message snooping. Data is needed to improve the process, not to pressure people. - _Where do the facts come from?_ — IDE as the primary signal. Then connected with Git and Task Tracker for release context. - _Do you collect source code?_ — We analyze metadata only: activity in IDE, Git, and Task Tracker. The code itself stays with you. ### Start Controlling Development Today Replace guesswork with engineering precision. Control releases based on facts. CTAs: Book a demo / Go to Workspace --- ## Personal — Free Developer Profile and Workspace URL: https://pandev-metrics.com/personal ### Meta description Free developer profile that levels up from your coding. Install the IDE plugin, get XP and stats. ### Hero **Write code. Level up.** Free developer profile with gamification, stats and portfolio Badge: Free forever with no limits CTA: Start leveling up ### Intro Every minute of coding turns into XP. Every commit — into experience. Every week of work — into Level UP. ### How it works One IDE plugin. Zero setup. Your profile grows while you work. 1. Install plugin 2. Write code 3. See progress ### Why it matters - **See progress** — Week by week, see if you're growing or stuck. Your personal growth analytics. - **Build experience profile** — Work history and habits. Stays with you, not your employer. - **Gamification** — Stats and XP to make your journey interesting. Not 'productivity evaluation'. ### Everything in one profile - **Personal Profile** — Avatar, stats, stack — all in one place. A profile that stays with you. - **Metrics & Analytics** — Activity time, focus, delivery index — an objective picture of your work. - **Levels & Titles** — XP for code, levels, titles — level up like in a game. Every commit brings you closer. ### Get started in 3 steps 1. **Create profile** — Registration without card. Instant free personal workspace. 2. **Install plugin** — Choose IDE, install plugin, login to workspace. 3. **Code as usual** — Soon you'll see XP, stats and progress. ### Works in your IDE One plugin. Zero setup. Choose your editor and install in 30 seconds. Don't see your IDE? Write to us - we'll add it. ### Level up every day Every commit, every session is XP. The more you code, the higher your level. - **Newbie** (Level 1–20) — The first steps are the most important. - **Amateur** (Level 21–40) — Your skills are becoming noticeable — you are getting stronger. - **Pro** (Level 41–60) — Resilience and technique — you are at the level of a true professional. - **Expert** (Level 61–80) — Your mastery has unlocked knowledge inaccessible to most. - **Master** (Level 81–100) — You have reached the rank of Master — a power even bosses fear. ### Profile, not a report — Built for you, not for a manager. - **Gamification** — XP, levels, achievements - track growth like in a game - **Advanced statistics** — Focus, Shipping, Craft, Exploration - your coding style - **Achievement showcase** — Show off your best projects and metrics - **Experience portfolio** — Document your growth - useful for resume and interviews ### Resume Based on Data (Data-Driven Resume) Facts about your work, collected automatically - **Development Environment** — Which IDEs you worked in and how much time you spent - **Technologies** — Languages and stack you actually wrote code with - **Projects** — Which projects you worked on ### You control the data We only collect activity metrics. Code, secrets and passwords never leave your machine. - Profile is private by default. - Public only if you enable it yourself. - Collection can be stopped at any time. ### No hidden fees No trial periods. No 'unlock for money'. Basic profile works - while you code. - Profile - Gamification - Advanced statistics - Achievement showcase - Experience portfolio CTA: Launch profile ### FAQ - _Is the profile really free?_ — Yes, all basic profile features - gamification, statistics, achievement showcase and portfolio - are free forever. - _Is this a time tracker?_ — No. We don't take screenshots or track time. We analyze code metrics for gamification and progress tracking. - _What data do you collect?_ — Only IDE activity metrics: number of changes, programming languages, session times. We don't read code or collect confidential information. - _What exactly is collected from the IDE?_ — Event metadata in IDE: time and type of actions, project and repository context, branch, files and language, as well as technical context (IDE and versions). Code content, secrets, keys and passwords are not read or transmitted. - _How will employers see my profile?_ — Profile is private by default. You decide what to show and to whom. You can create a public link for your resume. ### Final CTA Code Level Profile — Start for free ### Made by a small team. Launched from Kazakhstan. 🇰🇿 We're building a product for developers. Publicly maintaining docs and updates. --- ## Book a Demo URL: https://pandev-metrics.com/book ### Page title Organize a meeting ### Meta description Book a demo of PanDev Metrics, an AI engineering intelligence platform. Review dashboards with your data and discuss integrations, rollout, and security. ### About this page Demo booking flow: pick a day, pick a time, fill in name / work email / company. Confirmation is emailed instantly with a calendar invite. The PanDev team uses the call to walk through dashboards on your data, discuss integrations (IDE plugins, Git, task tracker, LDAP), rollout, and security model. --- ## Pricing — Plans and packaging URL: https://pandev-metrics.com/price ### Meta description Pricing for an AI engineering intelligence platform focused on developer productivity. Personal and Micro are free. Starter from $289/month. On-Prem and Enterprise available. ### Hero **Choose your plan** Select a plan that meets your needs and discover new opportunities for growth and success. ### Plan tabs Personal / Team / Company / Education ### Plans ### Personal — Free _1 user_ Developer project and tech stack profile — Shows which projects you've worked on, which languages and technologies you use, and how your stack evolves over time. - Integrations: IDEs, Git, task trackers, terminal, LLM CLI - Personal profile with history for the entire period, detailed for 1 month - Ready-made dashboards for developer activity - Standard email support (up to 24 hours) ### Micro — Free _up to 5 users_ Team profile for a small dev squad — Shows each person's contribution to code and tasks, overall activity, and team progress for up to 5 people - All integrations + LDAP/AD and report export - Developer and team profiles, organizational structure, and RBAC - Complete profile history, detail for 1 year - Standard email support (up to 24 hours) ### Starter — $289 /month (or $2950/year annually) _up to 20 users_ Transparency for a development team — A single view of code, tasks, and reviews so you see team speed, workload, and stability - Complete organisational structure: users, teams, departments, RBAC - All integrations and export for management reporting - Complete profile history, detail for 1 year - Priority support (up to 4 hours) ### On-Prem — Custom _Custom_ Corporate deployment with full data control — All profiles and metrics run inside your perimeter, aligned with your internal policies and infrastructure - Deployment in client infrastructure or isolated environment - All Scale/Enterprise capabilities with security requirements considered - Complete profile history, detail for 1 year, client-side access control - Priority support (up to 15 minutes, extended SLA) ### Growth — $699 /month (or $7130/year annually) _up to 50 users_ Manage multiple teams from one panel — Compares teams, highlights process bottlenecks, and helps plan the evolution of your engineering organization - Analytics for multiple teams and departments - Advanced dashboards and reports on people, tasks, reviews - Complete profile history, detailed for 1 year - Priority support (up to 30 mins) ### Scale — $1499 /month (or $15290/year annually) _up to 100 users_ Full picture of engineering across the organization — Dozens of teams and projects in one place with key metrics, trends, and risk areas - Analytics for dozens of teams and projects - Complete set of integrations, organizational structures, permissions, and reporting - Complete profile history, detailed for 1 year - Priority support (up to 30 mins) ### Enterprise — Custom _Custom_ Engineering platform aligned with business and security requirements — Deep analytics, roles and access control, audit, and integrations that follow corporate policies and SLAs - Custom organizational structure, roles, integrations, and reports - Dedicated stand/environment, increased limits, and security requirements - Complete profile history, detailed for 1 year and advanced aggregates - Enterprise support (up to 15 mins, SLA by agreement) ### On-Prem — Custom _Custom_ Corporate deployment with full data control — All profiles and metrics run inside your perimeter, aligned with your internal policies and infrastructure - Deployment in client infrastructure or isolated environment - All Scale/Enterprise capabilities considering security requirements - Complete profile history, detailed for 1 year, client-side access control - Priority support (up to 15 mins, extended SLA) ### Education — Free _Custom_ Student profiles and progress based on real code — Shows who actually writes and reviews code and gives a clear picture of student and group development. - Student profiles and educational teams with a basic organizational structure - Key integrations and ready-made educational dashboards - Complete history of profiles, detailed for 1 year - Standard email support (up to 24 hours) ### Comparison capabilities (table rows) Number of users, Cost, IDE integrations, Git platform integrations, Task-tracker integrations, LDAP/AD directory integration, Terminal integration, LLM CLI integration, Ready-made dashboards, Report export, Company structure (users / teams / departments), User management, RBAC roles and access rights, Data storage, Technical support tier (Standard 24h → Priority 4h → Priority 30m → Priority 15m). ### Footer link Compare all features --- ## Integrations — Connect existing systems URL: https://pandev-metrics.com/integrations ### Meta description Connect PanDev Metrics with your favorite tools. ### Integrations with development tools Connect existing systems and get analytics without changing processes Included: GitLab, GitHub, Bitbucket, Jira, Yandex Tracker, Azure DevOps, LDAP/AD. ### Plugins for development environment Install the plugin and start collecting metrics directly from your IDE Supported IDEs: IntelliJ IDEA, VS Code, PyCharm, PhpStorm, GoLand, Rider, CLion, RustRover, WebStorm, RubyMine, Visual Studio, Eclipse, Xcode, PL/SQL Developer, Android Studio, Antigravity. Plus terminal client. ### Plugins for browsers Install the plugin and start collecting metrics directly from your browsers Supported browsers: Chrome, Firefox, Safari, Edge, Opera, Brave, Vivaldi, Arc, Yandex Browser, Whale, Sidekick, Atlas, Comet. --- ## Metrics B2B — Engineering analytics for teams URL: https://pandev-metrics.com/metrics ### Meta description PanDev Metrics B2B unifies IDE, Git and task tracker signals into team-level engineering analytics. DORA metrics, delivery forecasts and developer productivity for engineering leaders. ### Hero **Team analytics. No reports.** Real-time development metrics ### About this page Team-level engineering analytics from IDE, Git, and task-tracker data. Includes DORA metrics, delivery forecasts and developer-productivity signals for engineering leaders. Same chip-hub data sources as the homepage (IDE, Task Tracker, Git, LLM, Terminal) feeding estimation-accuracy and time-to-market signals. --- # Section 2 — Documentation # Product Overview ## AI Assistant URL: https://pandev-metrics.com/docs/product/ai-assistant # AI Assistant Instead of building complex reports and searching for data manually, you can simply ask. The AI Assistant understands natural language queries and instantly finds answers in your metrics. ## How It Works? Open the AI Assistant tab in the sidebar and type your question into the chat. The system will analyze the data and show the result — a text answer or a chart. **Example queries:** * "Who on the team is overloaded right now?" * "Show Lead Time for the backend team over the last month" * "Which projects are stalling?" * "Make a sprint summary for the mobile team" * "Where do we have the longest code reviews?" ## What Can the Assistant Do? ### Quick Answers to Questions No need to switch between dashboards and filters. Ask a question — get an answer. This saves time on routine queries, especially when you need to quickly prepare data for a meeting. ### Anomaly Detection The AI analyzes trends and highlights what stands out from the norm: * Employees with irregular schedules or consistently high workload * Pipeline stages that slow down delivery * Projects where activity has sharply dropped or risen ### Recommendations Based on the analysis, the assistant can suggest concrete steps to improve processes. ## Data Security Your code content is never sent to the AI model. Only metadata and aggregated metrics are used for analysis. All calculations happen inside the platform. --- ## Platform Features URL: https://pandev-metrics.com/docs/product/features # Platform Features PanDev Metrics automatically collects developer activity data from three sources: IDEs, version control systems (Git), and task trackers. This allows you to see a complete picture of the production process without manual reports or timesheets. ## Dashboards and Metrics The interactive dashboard is your development control center. All key information is gathered in one place: metric cards, line and bar charts of activity. Data can be filtered by period and grouped by employees, projects, or teams — helping you quickly find answers to any questions. ### AI Assistant No need to build complex reports manually. Simply ask the AI in the chat interface: "Who is overloaded right now?" or "Which projects are stalling?" — and get an answer with recommendations. ## Employees and Projects Each object in the system has its own page with detailed information: * **Employee Card** — profile, personal activity statistics, work history, list of projects, and time distribution charts. All data for Performance Reviews in one place. * **Project Page** — participants, activity metrics (commits, tasks), timeline. See who is working on the project and how. * **Project List** — a general table with filtering, sorting, and search for quick navigation. ## Organization Structure The platform reflects your company's real hierarchy: * **Employees** — table with data, statuses (active/inactive), access roles. * **Departments** — hierarchy of units, managers, number of employees. * **Teams** — list of teams with members and team leads. This allows you to view metrics at any level: from a single engineer to the entire company. ## Integrations The platform fits into your existing tool landscape. ### IDE Plugins Data collection directly from the code editor. We support: * **JetBrains**: IntelliJ IDEA, PyCharm, PhpStorm, GoLand, Rider, CLion, RustRover, WebStorm, RubyMine, Android Studio * **Microsoft**: VS Code, Visual Studio * **AI Editors**: Cursor AI, Windsurf AI ### Git Platforms Connect your Git hosting to analyze commits and pull requests: * GitLab, GitHub, Bitbucket, Azure DevOps * Configuration of main branches (master, main, develop) and project filtering ### Task Trackers Link code to business tasks: * **Jira** — project synchronization and status mapping * **Yandex Tracker** — OAuth authorization and queue selection ## Reports Tools for audit and billing when documents are needed: * Report table with filtering by period and status * Employee report: work hours by day, time distribution by projects, task list * Report creation: select period, employees, and parameters ## Settings Flexible configuration for your company processes: * **Company** — name, login, logo, time zone * **Work Calendar** — working days, weekends, holidays, hours for correct metric calculation * **Git** — main branches and commit processing rules * **Email** — SMTP server and notification templates * **SSL** — certificate management for On-Premise * **Chrome Extension** — additional data collection from the browser ## Personal Workspace A separate mode for individual use — without tying to a company. The developer sees only their own statistics: * **Personal Dashboard** — personal metrics, goal setting, trends * **Gamification** — achievements, badges, levels, and progress for motivation * **Profile** — user data and notification settings Personal workspace data remains with the developer even when changing jobs. --- ## Product Overview URL: https://pandev-metrics.com/docs/product/overview # Product Overview PanDev Metrics is an ecosystem for digitizing development processes. We help IT departments switch to a Data-Driven approach, providing executives and CTOs with objective metrics for making informed decisions. ## What is PanDev Metrics? It is a platform that makes team work transparent. Instead of guessing why a project is delayed or the team is burning out, you get an exact picture of what is happening. Unlike simple time trackers, PanDev Metrics analyzes the process deeply and comprehensively. We highlight four key analytics directions: - **People and Team Development** Track individual progress, find strong engineers, and help newcomers. The system will highlight informal leaders, show interaction dynamics within the team, and provide an objective basis for Performance Reviews. - **Project Control** Look at real task progress, not subjective reports. We analyze code quality, technical debt, and deadlines in a single context, allowing you to see deadline risks in advance. - **Finding Bottlenecks** The platform automatically finds stages where the process is stalling. Whether it's long reviews, complex code areas, or overload of specific employees — you will see this on dashboards and get recommendations for elimination. - **Strategy and Planning** Accumulating history, the system builds performance trends. This allows you to accurately forecast resource needs, calculate development ROI, and compare your performance with industry benchmarks. ## How It Works? The system is based on three principles that ensure trust in data: 1. **Personalized Collection.** Data comes directly from each developer's IDE and version control systems. No manual reports — only real activity. 2. **Objectivity.** We operate with facts. Every management decision can now be backed by numbers, not feelings. 3. **Benefit for All.** Developers see their growth, team leads see the team's pulse, and top management sees production transparency. ## Key Capabilities We combined tools for different management levels into a single interface: ### For Efficiency * **Blocker Detection**: we find processes that eat up team time. * **Productivity Growth**: companies increase efficiency by an average of 10% by eliminating simple organizational problems. * **Proactivity**: the system warns about problems before they become critical. ### For Quality and People * **Technical Debt Monitoring**: keep code quality under control. * **Career Tracks**: a clear and transparent grading and growth system for employees. * **Fair Assessment**: we eliminate favoritism and "blind spots" in personnel management. ## Product Mission We work to make development more efficient. It is important to emphasize: PanDev Metrics is not a tool for total control over employees. On the contrary, we strive to relieve engineers from micromanagement by providing objective data for process improvement. Our philosophy is built on help, not supervision. The transparency provided by the platform is just a way to see opportunities for growth. When the team understands where resources go, it becomes easier to remove barriers and focus on what truly brings value. ## Where to Start? To utilize the documentation faster, use this route: * **Immersion**: the [**"Features"**](https://pandev-metrics.com/docs/product/features) section covers the full functionality of the platform. * **Practice**: check out [**"Use Cases"**](https://pandev-metrics.com/docs/product/use-cases) to learn how companies similar to yours solve their problems. * **Technologies**: in the [**"AI Assistant"**](https://pandev-metrics.com/docs/product/ai-assistant) section, we tell how you can communicate with data in natural language. Ready for implementation? Go to [**"Quick Start"**](https://pandev-metrics.com/docs/intro) — step-by-step installation and setup instructions are collected there. If you have questions — our support and community are always in touch. --- ## Release Notes URL: https://pandev-metrics.com/docs/product/release-notes # Product Release Notes Stay up to date with the latest features and improvements to PanDev Metrics. ## January 26, 2026 ### Browser Plugins Release Extensions for major browsers are now available. Activity can now be tracked in browsers, giving you a more complete picture of development work. The list of tracked sites is managed via allowlists and blocklists. [Learn more](https://pandev-metrics.com/docs/setup/browser-extensions/overview) ### CLI Plugins Release New plugins to extend CLI functionality. You can now track activity in the terminal and LLM CLIs like Codex CLI and Claude Code. [Learn more](https://pandev-metrics.com/docs/setup/cli/overview) ### CLI Dashboard A new collection of information directly from the terminal, Codex CLI, and Claude Code, providing deeper insights into command-line usage. ### Browser Widget We've added a dashboard widget for analytics demonstration that visualizes engineer activity within the browser. ### Improved Employee Calendar Added flexible working hours configuration and support for hybrid work schedules. It is now easier to plan and track employee availability. ### UI Improvements A major overhaul of the user interface for better usability. We've refined the look and feel to make navigation smoother and more intuitive. ### Team Analytics Optimization Significant redesign of the team analytics page for better user experience. Get the insights you need faster and more clearly. ### Performance Indicators Refinement Expanded metric usage across different views (teams, engineers, roles). We also added the **Delivery Index**, which shows the ratio of time spent on research versus development in code. [Learn more](https://pandev-metrics.com/docs/user-guide/indicators) ### No-Integrations Mode Ability to run the system without external Git or issue tracker integrations, offering more flexibility for different deployment environments. --- ## Use Cases URL: https://pandev-metrics.com/docs/product/use-cases # Use Cases PanDev Metrics is used by different types of organizations and different roles within them. On this page, we describe what problems the platform solves for each audience. ## Who is the Product For? ### CEO and CTO Top-level executives get a unified view of the company's entire engineering. Instead of disjointed reports from different teams — one dashboard with clear metrics. This allows you to: * See the real picture of IT department performance * Make resource decisions based on data, not intuition * Monitor the progress of strategic initiatives * Objectively evaluate the effectiveness of development investments ### HR Directors and Managers For HRDs, the platform becomes a tool for objective evaluation and employee development: * Data for Performance Reviews without subjective assessments * Identification of informal leaders and potential candidates for promotion * Monitoring workload and preventing burnout * Basis for a fair grading system ### Project Managers, PMO, and Scrum Masters Project managers use PanDev Metrics for planning and tracking: * Real task progress instead of subjective statuses * Tools for more accurate sprint planning * Identification of blockers and bottlenecks in the process * Data to justify timelines to stakeholders ### Developers Engineers get recognition for their contribution and relief from routine: * Automatic work logging — no manual timesheets * Personal dashboard to track own growth * Gamification and achievements for motivation * Objective basis for career discussions with management ## Organization Types ### Large Enterprises In large companies, PanDev Metrics helps bring order to distributed teams. When there are dozens of projects and hundreds of developers, it is impossible to understand the big picture without a unified metrics system. The platform ensures centralized control over all projects, process standardization, and data for strategic planning at the corporate level. ### Startups and Small Teams For small teams, it is important to quickly understand where limited resources are going. PanDev Metrics is installed in 15-20 minutes and immediately starts collecting data. This helps focus on priorities, avoid spending time on manual reporting, and maintain control during rapid team scaling. ### Outsourcing and Outstaffing Companies For service companies, transparency is a key factor in client trust. The platform automatically generates reports on work performed, identifying completed tasks and hours, which simplifies approval and billing. Data becomes an objective basis for discussion with customers, reducing disputes and increasing client satisfaction. ### Government Organizations The public sector requires special attention to transparency and security. PanDev Metrics supports On-Premise deployment, where all data remains within the organization's perimeter. This allows compliance with regulatory requirements and ensures objective reporting to oversight bodies. ## What Problems Does the Platform Solve? ### Process Transparency Instead of guesses — facts. You see how the team works: how much time is spent on coding, review, waiting. This is the first step to improvement: you cannot optimize what you do not measure. ### Planning and Forecasting Accumulated data allows for more accurate timeline estimates. You know the real speed at which the team works and can make more realistic promises to customers. ### People Development Objective data is the basis for a constructive dialogue about growth. Employees see their progress, managers see the real contribution of everyone. This eliminates favoritism and makes evaluation fair. ### Problem Detection The system automatically finds bottlenecks: overloaded employees, prolonged reviews, complex code areas. Problems are visible before they become critical. ### Time Saving Automatic data collection eliminates manual work logs and timesheets. According to our customers, this saves a significant amount of managers' time on reporting. ## Implementation Results The effect of using PanDev Metrics appears gradually: **First Month** — transparency appears. You start seeing the real picture of team work and identify main pain points. **3-6 Months** — first improvements are visible. The team optimizes processes based on data, planning becomes more accurate, code quality grows. **6+ Months** — a Data-Driven decision-making culture is formed. Improvements become sustainable, and metrics become a natural part of the workflow. # How It Works ## Solution Architecture URL: https://pandev-metrics.com/docs/how-it-works/architecture # Solution Architecture PanDev Metrics relies on a modular architecture with a central server that aggregates, processes, and exposes engineering telemetry coming from IDE plugins and external systems. ## High-Level Overview The architecture is organised into several logical blocks connected through REST APIs and direct integrations. The **PanDev Metrics Server** sits at the centre: it ingests events from plugins (IDE, browser, and other extensions), communicates with systems such as Jira, GitLab, and LDAP/Active Directory, stores the processed data in PostgreSQL, and publishes it for visualisation in Grafana. ## Architecture Diagram ``` ┌─────────────────────────────────────────────────────────────────┐ │ LDAP/Active Directory │ │ (Auth) │ └─────────────────────────┬───────────────────────────────────────┘ │ ┌─────────────────────────▼───────────────────────────────────────┐ │ PanDev Metrics Server │ │ (Core) │ │ ┌─────────────────┐ ┌─────────────────┐ ┌─────────────────┐ │ │ │ Plugin Intake │ │ Aggregation & │ │ Integrations │ │ │ │ │ │ Processing │ │ (Jira/GitLab) │ │ │ └─────────────────┘ └─────────────────┘ └─────────────────┘ │ └─────────────────────────┬───────────────────────────────────────┘ │ ┌─────────────────────────▼───────────────────────────────────────┐ │ PostgreSQL │ │ (Storage) │ └─────────────────────────┬───────────────────────────────────────┘ │ ┌─────────────────────────▼───────────────────────────────────────┐ │ Grafana │ │ (Visualisation) │ └─────────────────────────────────────────────────────────────────┘ ┌─────────────────┐ ┌─────────────────┐ ┌─────────────────┐ │ VS Code │ │ Chromium │ │ JetBrains │ │ Plugin │ │ Plugin │ │ Plugin │ └─────────────────┘ └─────────────────┘ └─────────────────┘ │ │ │ └───────────────────────┼───────────────────────┘ │ ┌─────────────────┐ │ PanDev Metrics │ │ Server │ └─────────────────┘ │ ┌─────────────────┐ │ PostgreSQL │ │ Database │ └─────────────────┘ ``` ## System Components ### 1. Plugin Layer (VS Code, Chromium, JetBrains) These plugins record day-to-day developer activity: #### VS Code Plugin for Developers - Tracks which files, branches, and repositories were touched in Visual Studio Code - Measures time spent editing within the IDE #### Chromium Plugin for Developers - Captures which web resources developers use during the day: documentation, testing tools, internal services - Complements IDE telemetry with browser context #### JetBrains IDEs Plugin - Collects analogous metrics for the JetBrains suite (IntelliJ IDEA, PyCharm, WebStorm, Android Studio, etc.) - Records coding time, project switches, and overall IDE activity **How plugins operate:** - Accumulate raw events locally - Periodically batch and send them to the PanDev Metrics Server - Work quietly in the background without disrupting the developer ### 2. PanDev Metrics Server (Core) The core service receives data from every plugin and turns it into actionable analytics: - Normalises and enriches incoming events - Links data to users and projects via company directories (LDAP/AD) - Persists everything in PostgreSQL for downstream analysis The server also hosts the management UI where administrators configure organisations, teams, and integrations. ### 3. PostgreSQL Storage All historical telemetry lands in PostgreSQL: - Structured tables store time tracking, code activity, review metrics, and more - The schema is optimised for analytics queries and reporting - Acts as the single source of truth for both Grafana dashboards and API clients ### 4. Grafana (Dashboards) Grafana is the primary visual layer for PanDev Metrics: - Offers curated dashboards with the most important KPIs - Supports ad-hoc exploration, filtering, and time range selection - Removes the need for writing SQL to inspect the data ### 5. Authentication with LDAP/Active Directory - PanDev Metrics integrates with corporate directories for SSO - User roles and permissions are managed centrally - Audit logs cover sign-ins and privileged actions ### 6. Integration Modules (Jira and GitLab) #### Jira Integration Module - Pushes processed time-tracking data directly into Jira issues - Adds contextual comments with diagnostics from PanDev Metrics - Operates **one way** (server → Jira); the platform does not pull sensitive data back #### GitLab Integration Module - Sends time-tracking and review statistics into GitLab merge requests - Gives engineering managers instant visibility into effort and progress - Is also **one way** (server → GitLab) #### Why integrations matter Integrations augment the native tracking capabilities of Jira and GitLab, aligning planning data with the actual effort captured by PanDev Metrics. Managers see the real time spent, compare it with estimates, and adjust plans accordingly. ## Data Flow 1. **Plugin capture** – IDE and browser plugins collect granular telemetry. 2. **Server ingestion** – the PanDev Metrics Server receives the batches, stores them in PostgreSQL, and publishes enriched metrics to Jira and GitLab. 3. **Storage** – PostgreSQL keeps the full history for dashboards and reporting. 4. **Visualisation** – Grafana reads the database and turns the metrics into charts and diagnostics views. ## Key Architectural Benefits ### Scalability - Add new plugins or integrations without reworking the core - Modular design allows incremental feature growth ### Convenience - A single server acts as the collection and processing hub - No need to maintain multiple disconnected systems ### Transparency - All metrics live in one database - Dashboards can be consumed from Grafana or any BI tool of choice ### Security - Authentication and authorisation via LDAP/AD - Sensitive business logic stays on the server side ## Putting It All Together This architecture enables PanDev Metrics to: - **Collect objective telemetry** through plugins - **Store and process metrics centrally** in PostgreSQL - **Present clear insight** to managers and engineers through Grafana When someone opens PanDev Metrics they see a consolidated view of time, tasks, branches, reviews, and any other indicators required to plan and assess performance. The interactions between plugins, external services (Jira, GitLab), the PanDev Metrics Server, PostgreSQL, and Grafana deliver accurate, transparent analytics for the entire organisation. --- ## Project and Task Cost Methodology URL: https://pandev-metrics.com/docs/how-it-works/cost-methodology # Project and Task Cost Methodology Our platform automates financial analytics by combining data about real employee activity. We collect information through specialized plugins that track activity in the **IDE**, **browser**, **terminal (CLI)**, **database clients**, and **AI coding assistants**, and map it against tasks from supported trackers (Jira, GitHub, and others). Based on this data, the system generates an honest and transparent development cost. The diagram below shows the end-to-end flow — from raw activity to the final project cost: ![End-to-end cost calculation flow](https://pandev-metrics.com/docs/how-it-works/img/cost-flow.svg) ## 1. Direct Costs Direct costs are the foundation of all calculations — the actual cost of time recorded against a specific employee. ### How we calculate For each employee, we take the **latest active rate valid in the period** and apply one of two formulas: - **Hourly rate (`HOURLY`):** ``` cost = (seconds / 3600) × hourly_rate ``` - **Monthly rate (`MONTHLY`):** ``` cost = (seconds / 3600) × (monthly_rate / 160) ``` where **160 h** is the standard working month (8 h × 20 days). ### Activity sources Activity is collected across five `ActivityType` categories: `CODING`, `BROWSING`, `DATABASE`, `CLI`, and `AI_CODING`. Data is aggregated through materialized views: - `mv_activity_total_user_project_daily` - `mv_activity_total_user_issue_daily` - `mv_activity_total_user_daily` ### Task-mapped vs. non-task activity, and how non-task is redistributed An employee's activity splits into two types: - **Task-mapped** — activity linked to a specific task (the `issue_key` from a Git branch or plugin context matches a tracker issue). - **Non-task** — activity without a task link (meetings, reviews, planning, training, etc.). Non-task time is **not a separate overhead pool**. For each employee with both task and non-task activity in the period, their non-task cost is **redistributed across their own tasks in the same proportion as their direct task costs**. Example: an employee has 2,000 on Task A and 1,000 on Task B (2:1), plus 300 of non-task time. After redistribution, Task A gets +200 and Task B gets +100 — the 2:1 ratio is preserved. This means `direct_total` for a task is the sum of direct task cost plus its share of redistributed non-task time. All downstream formulas use this blended `direct_total`. ## 2. Overhead (Indirect Costs) Overhead captures costs that cannot be attributed to any task-bearing employee at all. - **Management / Admin Salary** — the monthly salary of employees on a `MONTHLY` rate who have **no recorded activity whatsoever** in the reporting month (typically PM, CTO, HR). The salary is distributed **proportionally to the number of days the rate was active within the month**. Non-task time of employees who *do* have activity never enters this pool — it has already been absorbed into `direct_total` via redistribution. The diagram below summarises how each cost type reaches the project: ![Where each cost type lands](https://pandev-metrics.com/docs/how-it-works/img/allocation-buckets.svg) ## 3. Allocation Method (Overhead Coefficient) Overhead is distributed proportionally to the volume of direct costs using the following formula: ``` K = admin_salary / direct_total ``` Where: - `admin_salary` — sum of pro-rated salaries of employees with zero activity in the month; - `direct_total` — total direct costs of the department (task-mapped activity plus redistributed non-task time of active employees). ### Key properties - **Granularity:** `K` is calculated **per department and per month** separately (enforced by a unique constraint `department_id + year + month` in the `overhead_coefficient` table). - **Arbitrary periods:** for ranges spanning multiple months, a **weighted average** is used, with weights equal to `direct_total` of each month: ``` K_eff = Σ(K_m × direct_total_m) / Σ(direct_total_m) ``` - **Application:** the final cost is computed **month by month and summed**: ``` total = Σ(direct_m × (1 + K_m)) ``` - **Storage & recalculation:** values live in the `overhead_coefficient` table and are refreshed by two cron jobs — a **monthly job** for the current month, and a **full recalculation** on startup and on the 1st of every month at 03:00. ### Filters and exclusions - **Deactivated users** (`users.is_active = false`) are excluded from direct costs (bugfix `PDM-3369`). - **Inactive department memberships** (`user_departments.is_active = false`) are not counted. - An **overhead warning** flag is raised when the system detects either: - `MONTHLY` rates above $50,000 on employees with no activity, or - employees with activity but no configured rate. Both cases signal a polluted `K` coefficient and require attention. ## 4. Worked Example Consider one reporting month in a department with two active projects. All figures below already reflect the redistribution step from §1 — non-task time of active employees has already been folded into each project's direct cost: - **Project Alpha** — direct costs (incl. redistributed non-task): **100,000** - **Project Beta** — direct costs (incl. redistributed non-task): **50,000** - **Management salary** with zero activity (`admin_salary`): **30,000** So `direct_total = 150,000`. **Step 1.** Compute the coefficient: ``` K = 30,000 / 150,000 = 0.2 (20%) ``` **Step 2.** Apply it: - **Total cost of Alpha:** 100,000 × (1 + 0.2) = **120,000** - **Total cost of Beta:** 50,000 × (1 + 0.2) = **60,000** ::: ## Why It Matters This approach reveals not only the direct cost of code but also the real burden a project places on the company — including the share of management work that has no direct activity footprint. We are not an accounting service — our goal is to provide transparent and objective efficiency analytics based on automatic data collection. --- note Data is updated automatically when syncing with your development tools. ::: --- ## Data Accuracy Checklist URL: https://pandev-metrics.com/docs/how-it-works/data-accuracy-checklist # Data Accuracy Checklist A quick checklist to keep cost analytics accurate. See the [Cost Methodology](https://pandev-metrics.com/docs/how-it-works/cost-methodology) for the formulas behind each rule. ## For admins Things to configure and keep clean in the system. - **Connect both sides of each integration** — tracker + Git must be paired: Jira + GitHub/GitLab, Yandex Tracker + GitHub/GitLab, or ClickUp + GitHub/GitLab. Only then can activity be mapped to tasks. - **Configure a rate for every employee with activity** — no rate means their time contributes zero to direct costs, and the overhead coefficient `K` inflates for everyone else. The system raises `overhead warning` but still produces skewed reports. - **Keep MONTHLY rate values realistic** — anything above $50,000/month on a zero-activity employee triggers a warning. Typos here go straight into the numerator of `K` and distort every project's cost. - **Set correct effective dates on rates** — the system uses the latest rate valid in the period. Retroactive edits shift historical `K` on the next full recalculation (cron on the 1st at 03:00). - **Deactivate leavers properly** — set `users.is_active = false`. An active MONTHLY employee with no activity lands in `admin_salary` every month until deactivated. - **Keep department memberships clean** — `K` is computed per department per month. Stale memberships after a transfer can double-count or land activity in the wrong department. - **Treat every `overhead warning` as a signal** that `K` for that department-month is polluted; reports still generate, but numbers are suspect until resolved. ## For developers Things to do in your daily workflow. - **Always include the task key in Git branch names** — this is the *only* way activity is mapped to tasks. Commit messages, PR titles, and open Jira tabs are **not** used. - ✅ `feature/PROJ-123-add-login`, `bugfix/ABC-45` - ❌ `fix-login-bug`, `sergey/wip`, `main` - Work on a branch without a key becomes **non-task** time and either redistributes onto your other tasks in the period — inflating them — or vanishes from project cost entirely. - **Install all three plugins** — IDE, browser, CLI. Partial installation doesn't just lose activity; it distorts the **proportions** used when non-task time is redistributed across tasks. --- ### One-sentence summary > Pair your integrations, configure rates on real dates for everyone, deactivate leavers — and as a developer, always put the task key in the branch name and install all three plugins. --- ## Chrome Telemetry URL: https://pandev-metrics.com/docs/how-it-works/data-collection/chrome # Chrome Telemetry PanDev Metrics uses a Chrome extension to capture activity within corporate web tools. Only whitelisted work domains are tracked. - ❌ **No screenshots**. - ❌ **No personal browsing**. - ✅ **Whitelisted domains only**. - ✅ **Users can review the tracked domains.** ## Whitelist-first Design Data is collected solely for domains added to the whitelist in the admin console. This keeps personal browsing out of scope and concentrates on corporate tools. Security measures: - Track only approved domains. - Provide visibility into the whitelist for every user. - Exclude personal content entirely. - Focus on corporate systems. ## Event Structure Example payload: ```json [ { "title": "Main settings", "url": "https://pandev-metrics-test.pandev.io/backoffice/integrations", "tabId": 2020798390, "timestamp": 1755324391, "lastAccessedTimestamp": 1755323941, "favIconUrl": "https://pandev-metrics-test.pandev.io/backoffice/images/favicon.ico", "windowId": 2020798387 } ] ``` Field reference: | Field | Type | Description | |-------|------|-------------| | `title` | String | Browser tab title. | | `url` | String | Page URL (must belong to the whitelist). | | `tabId` | Integer | Unique tab identifier. | | `timestamp` | Integer | When the tab was opened/activated. | | `lastAccessedTimestamp` | Integer | Last time the tab was in focus. | | `favIconUrl` | String | Site favicon URL. | | `windowId` | Integer | Browser window identifier. | ## Managing the Whitelist Suggested entries: ``` git.yourdomain.com # Corporate Git (GitLab/GitHub) jira.yourdomain.com # Jira confluence.yourdomain.com # Documentation jenkins.yourdomain.com # CI/CD monitoring.yourdomain.com # Monitoring ``` Examples: - **Git hosting:** `gitlab.company.com`, `github.company.com`. - **Project management:** `jira.company.com`, `asana.company.com`. - **Documentation:** `confluence.company.com`, `notion.company.com`. - **CI/CD:** `jenkins.company.com`, `gitlab-ci.company.com`. - **Monitoring:** `grafana.company.com`, `kibana.company.com`. Users can inspect the whitelist to understand exactly where telemetry is gathered—and where it is not. --- ## IDE Telemetry URL: https://pandev-metrics.com/docs/how-it-works/data-collection/ide # IDE Telemetry PanDev Metrics captures IDE activity through dedicated plugins, delivering precise insight into work on corporate projects. Only work-related IDE activity is collected. - ❌ **No screenshots**. - ❌ **No personal projects** – telemetry is limited to approved Git repositories. - ✅ **IDE-only** – other applications stay out of scope. - ✅ **Transparent** – developers can review the data being shared. ## Plugin Overview See the [Plugins](https://pandev-metrics.com/docs/setup/ide-plugins/overview) section for installation and setup guides: - **IntelliJ IDEA plugin** – deep integration with JVM projects. - **VS Code plugin** – broad language coverage. - **Other IDEs** – extensible architecture for additional tools. ## Event Structure Example payload: ```json [ { "timestamp": 1742567259.3460, "project": "pandev-metrics-partners-service", "module": "merchant-service", "language": "JAVA", "gitPath": "pandev/metrics/services/pandev-metrics-partners-service", "gitBranch": "hotfix/PDM-418", "fileName": "CompanyRepository.java", "ide": "IntelliJ IDEA 2024.1.3", "lineCount": 189, "lineNumber": 153, "cursorPosition": 52 } ] ``` Field reference: | Field | Type | Description | |-------|------|-------------| | `timestamp` | Float | Unix timestamp of the event. | | `project` | String | Corporate project name. | | `module` | String | Module within the project. | | `language` | String | Programming language (JAVA, PYTHON, etc.). | | `gitPath` | String | Path inside the corporate Git repository. | | `gitBranch` | String | Active Git branch. | | `fileName` | String | File currently in focus. | | `ide` | String | IDE name and version. | | `lineCount` | Integer | Total number of lines in the file. | | `lineNumber` | Integer | Line number of the caret. | | `cursorPosition` | Integer | Position of the caret within the line. | ## Task Matching Plugins automatically relate IDE activity to tracker issues by inspecting branch names. How it works: 1. Track the active Git branch. 2. Apply regex patterns (`TASK-23`, `feature/PDM-1052`, etc.). 3. Lookup the corresponding issue in Jira/GitLab if integrations are enabled. 4. Attribute all activity in the branch to the identified task. Benefits: - Automatic linkage without manual input. - Accurate time accounting per task. - Full transparency for leads and managers. - Better effort estimation for future work. ## Offline Mode & Reliability Plugins guarantee delivery even when developers work offline. ### Continuous Collection - Operate without internet access. - Store events in a local cache. - Run unobtrusively in the background. ### Automatic Sync - Monitor connectivity to PanDev Metrics Core. - Sync cached events as soon as the server is reachable. - Send data in batches to minimise overhead. ### Reliability Guarantees - Local cache retained until delivery is confirmed. - Automatic retries on failure. - Integrity checks to validate successful transfer. - Visible sync status for developers. Example flow: ``` Day 1 (offline): - 09:00 Opened UserService.java - 10:30 Working in branch feature/auth - 12:00 Commit created - All events cached locally Day 2 (online): - 09:00 Connection restored - 09:01 Plugin uploads cached data - 09:02 Delivery confirmed ``` Result: Data is never lost, and teams get a complete picture of engineering activity regardless of network conditions. --- ## Data Collection Overview URL: https://pandev-metrics.com/docs/how-it-works/data-collection/overview # Data Collection Overview PanDev Metrics relies on an event-driven architecture to capture developer activity inside IDEs and the browser. The focus is strictly on corporate projects—personal activity remains private. Only work-related data is collected. - ❌ **No screenshots** – the system never records the screen. - ❌ **No personal tracking** – non-work activity is ignored. - ❌ **No personal projects** – only whitelisted corporate repositories. - ✅ **IDE and Chrome only** – other apps stay invisible. - ✅ **Full transparency** – users can always see what is captured. ## Collection Principles ### 1. Event-driven (no timers) There are no ticking timers. Data is generated only when real activity occurs (typing, navigation, etc.). Mathematical models derive active time between events. How it works: - Events fire exclusively on real interactions. - Inter-event gaps determine active time. - No background timers, no idle polling. ### 2. Zero-click automation Engineers install the plugin once and sign in once. The entire collection pipeline runs automatically afterwards—no repeated logins or manual triggers. Benefits: - One-time setup. - Background operation. - Persistent sessions. - Zero disruption of daily work. ### 3. Online/offline support Plugins cache events locally whenever the server is unreachable. As soon as connectivity returns, cached data syncs automatically. Mechanics: - Local storage on the developer’s machine. - Automatic retries until delivery succeeds. - Visibility into sync status. ### 4. Straightforward architecture Plugins send telemetry to the on-premises PanDev Metrics Core, which stores everything in PostgreSQL for downstream analytics. ## System Architecture ``` ┌─────────────────┐ ┌─────────────────┐ ┌─────────────────┐ │ IDE Plugin │ │ Chrome Ext │ │ Git Hook │ │ (Events) │ │ (Events) │ │ (Events) │ └─────────────────┘ └─────────────────┘ └─────────────────┘ │ │ │ └───────────────────────┼───────────────────────┘ │ ┌────────────────────────┐ │ PanDev Metrics Server │ │ (Event Intake) │ └────────────────────────┘ │ ┌────────────────────────┐ │ Data Processing │ └────────────────────────┘ │ ┌────────────────────────┐ │ PostgreSQL DB │ └────────────────────────┘ │ ┌────────────────────────┐ │ Analytics & │ │ Reports │ └────────────────────────┘ ``` ## What Happens Next 1. **Storage & enrichment** – events are normalised, deduplicated, and enriched with metadata. 2. **Correlation** – IDE, Git, and task-tracker data are linked for context. 3. **Analytics** – metrics feed dashboards, anomaly detection, and ML models. 4. **Insight delivery** – recommendations and alerts surface improvement opportunities. ## Security & Privacy ### Personalised identifiers - Events are tied to known developers for accurate analytics. - IDs remain internal; there is no exposure outside the organisation. ### Encryption - TLS protects data in transit. - Local caches are encrypted at rest. - Access is only possible through authenticated APIs. ### Access control - Role-based permissions. - Audit logs for every sensitive operation. - Compliance with corporate security policies. ## Outcome PanDev Metrics’ event-driven approach ensures: - **Precise telemetry** limited to corporate assets. - **Robust privacy** with no intrusion into personal life. - **Powerful analytics** by combining IDE, Jira, and Git data. - **Actionable insight** through AI-assisted recommendations. - **Scalability** for engineering teams of any size. --- ## What We Collect URL: https://pandev-metrics.com/docs/how-it-works/data-collection/what-we-collect # What We Collect PanDev Metrics gathers multiple classes of engineering data to analyse and refine delivery processes. ## Collected Metrics ### 1. Code Metrics - **Lines of code** – volume of code authored - **Complexity** – cyclomatic complexity, nesting depth - **Test coverage** – percentage of code covered by automated tests - **Duplication** – repeated fragments or copy‑paste blocks - **Technical debt** – code issues that require remediation ### 2. Time Metrics - **Active development time** – focused coding and editing - **Debug time** – effort spent diagnosing and fixing defects - **Refactoring time** – improving existing code without changing behaviour - **Code review time** – participation in peer reviews ### 3. Collaboration Metrics - **Commits** – frequency and size of commits - **Code reviews** – volume and depth of review activity - **Collaboration** – handovers and pair work between developers - **Communication** – conversations in comments and issues ### 4. Quality Metrics - **Defects** – number and type of bugs discovered - **Fixes** – turnaround time for bug resolution - **Regressions** – recurring issues that reappear after being closed - **Performance** – build and test execution times ## Collection Channels ### IDE Plugins - **IntelliJ IDEA** – JetBrains plugin family - **Visual Studio Code** – VS Code extension - **Eclipse** – Eclipse IDE plugin ### System Integrations - **Git** – commit and branch analytics - **GitHub/GitLab** – pull requests, merge requests, and issue context - **CI/CD** – build and test pipelines - **Jira/Trello** – synchronisation with work items and roadmaps ### Collection Agents - **Local agents** – run on developer machines - **Server agents** – aggregate data on dedicated infrastructure - **Cloud agents** – operate inside hosted environments ## Security and Privacy ### Data Anonymisation - Personally identifiable information is stripped or anonymised - Metrics are linked to pseudonymous identifiers - Individual developers cannot be reverse engineered ### Encryption - TLS/SSL protects data in transit - Local caches are encrypted at rest - Access is granted only through authenticated APIs ### Access Control - Role-based permissions govern who can view specific datasets - Every operation is captured in audit logs - Data deletion on request is supported ## Storage Options ### Local Storage - Agents cache data locally on workstations - Periodic synchronisation pushes updates to the server - Offline mode keeps working even without connectivity ### Cloud Storage - Secure backups in the cloud - Automated backup and disaster recovery - High availability and elasticity ## Data Processing ### Aggregation - Metrics are grouped by team, project, and timeframe - Time-series windows power trend analysis - Filtering and grouping expose the signal that matters ### Analysis - Statistical models identify patterns in the data - Machine learning highlights anomalous behaviour - Outlier detection flags unusual trends worth investigating ### Visualisation - Dashboards surface the KPIs that matter most - Charts and diagrams reveal trends over time - Data export enables further processing in external tools --- ## How the Platform Works URL: https://pandev-metrics.com/docs/how-it-works/how-it-works # How the Platform Works PanDev Metrics is an end-to-end system for capturing, processing, and analysing software delivery data. The sections below describe how the platform operates in practice. ## Operating Principle ### 1. Data Capture When engineers work in their IDE or browser on corporate projects, the platform generates event payloads with precise activity details. Every action produces a JSON event that records the project, file, cursor position, and timestamp. Only corporate repositories are observed—personal activity stays private. ### 2. Processing Events are processed on the server with mathematical models and AI. PanDev Metrics fuses data coming from IDE plugins, Jira, and Git to build richer analytics than any single source can provide. ### 3. Secure Storage Structured records are stored in a high-performance analytical database (ClickHouse) with references to specific developers so productivity insights stay accurate. ### 4. Visualisation Dashboards and advanced charts are generated from the processed data. The platform produces intelligent insights, automatic recommendations, and forecasts that guide better decision-making. ## Detailed Workflow ### Phase 1: Installation and Configuration 1. **Server deployment** – run PanDev Metrics on your infrastructure or in the cloud. 2. **Plugin rollout** – developers install the IDE extensions (VS Code, JetBrains). 3. **Configuration** – define data collection rules and connect existing systems. ### Phase 2: Data Capture #### Automatic IDE Collection - **Activity tracking** – plugins capture time spent working with files, branches, and tasks. - **Cursor positioning** – detailed cursor telemetry inside each file. - **Process monitoring** – measure focus per project, module, or activity. #### External Integrations - **Jira** – automatically map time to issues and work items. - **GitLab/GitHub** – analyse commits, merge requests, and repository activity. - **LDAP/AD** – connect to corporate identity providers. #### Offline Mode - Cache data locally whenever a machine is offline. - Resynchronise automatically once connectivity is restored. - Guarantee uninterrupted metric collection. ### Phase 3: Processing and Analytics #### Data Organisation - **Filtering** – separate valuable signal from background noise. - **Aggregation** – group metrics by project, team, and time range. - **Normalisation** – bring events into a consistent schema. #### Insight Generation - **Statistical analysis** – spotlight trends and anomalies. - **Machine learning** – detect recurring work patterns automatically. - **Correlation analysis** – uncover links between different metrics. ### Phase 4: Storage and Security #### Secure Storage - **Personalised telemetry** – retain developer identifiers for precise productivity insights. - **Encryption** – protect data both in transit and at rest. - **Access control** – configurable permissions for every role. #### Compliance - **GDPR** – adhere to European data protection regulations. - **On-premises** – deploy entirely within your infrastructure if required. - **Audit** – log every operation on sensitive data. ### Phase 5: Visualisation and Reporting #### Interactive Dashboards - **Grafana integration** – fully configurable dashboards with charts and KPIs. - **Real-time updates** – information refreshes live as new data arrives. - **Customisation** – adapt the views to each team’s needs. #### Automated Reporting - **Weekly/monthly reports** – scheduled reports delivered automatically. - **Alerts** – notifications when critical metrics change. - **Data export** – download datasets for further analysis. ## Technical Characteristics ### Scalability - **Horizontal scale** – add more servers as data volumes grow. - **Big data processing** – efficient pipelines for large datasets. - **High availability** – redundant services keep the platform online. ### Performance - **Lightweight plugins** – negligible footprint inside IDEs. - **Fast processing** – optimised algorithms for low-latency analytics. - **Caching** – speed up access to frequently used data. ### Integrations - **API** – RESTful API for integrating external systems. - **Webhooks** – push notifications into other tools. - **Plugins** – extensible architecture for new data sources. ## User Experience ### For Developers - **Invisible tooling** – plugins run in the background and stay out of the way. - **Transparency** – engineers can review their own metrics. - **Motivation** – visualise progress and achievements over time. ### For Managers - **Ease of use** – intuitive dashboards, no SQL required. - **Flexibility** – tailor views for specific workflows. - **Drill-down** – move from aggregate KPIs to detailed analysis in seconds. ### For Executives - **Strategic perspective** – high-level trends and portfolio health. - **Decision support** – data-backed insights for planning and investment. - **ROI tracking** – measurable results from process improvements. ## Outcome After completing the cycle, PanDev Metrics delivers: - **Objective performance metrics** for every team. - **Identified bottlenecks** in development workflows. - **Trends and patterns** across the organisation. - **Actionable recommendations** for optimisation. - **Measured improvements** in delivery speed and quality. - **Automated reporting** for all stakeholder levels. --- ## PanDev Metrics Overview URL: https://pandev-metrics.com/docs/how-it-works/overview # PanDev Metrics Overview PanDev Metrics is an engineering analytics platform that unifies IDE, Git, and task-tracker data into actionable insights for development teams. ## What Is PanDev Metrics? The platform collects and analyses development data to surface insights about: - **Delivery performance** — coding throughput and time to complete work - **Code quality** — complexity metrics, test coverage, and technical debt - **Team collaboration** — workload balance and cross-team interactions - **Process health** — code review cadence, commit frequency, working patterns --- ## Deployment Options | | Cloud (SaaS) | On-Premise | |---|---|---| | **Infrastructure** | Hosted by PanDev | Your servers | | **Updates** | Automatic | Manual | | **Authentication** | OAuth | LDAP | | **Best for** | Startups, growing teams | Regulated industries | --- ## Core Principles ### 1. Privacy-First Data Metrics are captured without exposing individual developers. Focus on process improvements, not personal monitoring. ### 2. Automated Collection Telemetry is gathered automatically through IDE plugins and integrations — no manual time tracking. ### 3. AI-Powered Insights Ask questions about your data in natural language and get instant answers. ### 4. Actionable Guidance Insights come with concrete recommendations that make change easier. --- ## System Components - **IDE Plugins** — capture developer activity from 14+ IDEs - **Git Integrations** — GitLab, GitHub, Bitbucket, Azure DevOps - **Task Trackers** — Jira, Yandex Tracker - **Analytics Engine** — processes data and generates reports - **AI Assistant** — natural language queries - **Web Dashboard** — visualizations and insights --- ## Key Features (v2) ### For Teams - 📊 **Unified Dashboard** — all metrics in one place - 🤖 **AI Assistant** — ask questions about your data - 📈 **Trend Analysis** — spot patterns over time - 📋 **Automated Reports** — scheduled delivery ### For Individuals - 👤 **Personal Workspace** — track your own productivity - 🎮 **Gamification** — achievements and progress - 📱 **Mobile Access** — metrics on the go ### For Organizations - 🏢 **Departments & Teams** — org structure management - 💰 **Payment Reports** — cost tracking by developer - 🔐 **LDAP** — enterprise authentication (On-Premise) --- ## Why Teams Use It - 📊 **Objective Analytics** — decisions backed by data - 🚀 **Higher Throughput** — visible and fixable bottlenecks - 🎯 **Better Quality** — issues surface early - 👥 **Healthier Collaboration** — understand team dynamics - 📈 **Measured Progress** — track improvements over time --- ## Quick Start - **Cloud:** [SaaS Quick Start](https://pandev-metrics.com/docs/saas-getting-started) - **On-Premise:** [Installation Guide](https://pandev-metrics.com/docs/on-prem/installation) - **Personal:** [Personal Workspace](https://pandev-metrics.com/docs/personal-getting-started) --- ## What to Read Next - [Product Description](https://pandev-metrics.com/docs/how-it-works/product-description) — detailed capabilities - [How It Works](https://pandev-metrics.com/docs/how-it-works/how-it-works) — data flow and architecture - [Use Cases](https://pandev-metrics.com/docs/how-it-works/use-cases-metrics) — adoption patterns --- ## Problems We Solve URL: https://pandev-metrics.com/docs/how-it-works/pain-points # Problems We Solve PanDev Metrics targets the core pain points faced by modern software teams and their leaders. ## Key Challenges Addressed by PanDev Metrics ### Lack of objective performance data **Pain:** Decisions are made on gut feeling and anecdotal evidence because leaders cannot observe how the team truly works. **Solution:** PanDev Metrics provides objective performance metrics grounded in real engineering activity. ### Inefficient time and resource management **Pain:** - Limited visibility into where development time actually goes. - Bottlenecks stay hidden until it is too late. - Team workload is hard to evaluate. **Solution:** - Detailed analytics on effort spent per task and activity. - Automatic detection of process bottlenecks. - Accurate measurement of workload and productivity. ### Opaque development processes **Pain:** - Task distribution across the team is unclear. - Individual contributions are invisible. - Project progress is hard to track. **Solution:** - Transparent reporting across every workflow. - Insights into task allocation and load balancing. - Visual dashboards that show progress at a glance. ### Difficult planning and estimation **Pain:** - Time estimates are unreliable. - Sprint and release planning is challenging. - Projects suffer from unexpected delays. **Solution:** - Historical data improves future planning accuracy. - Work pattern analysis refines estimation models. - Early warnings highlight potential delays. ### Distributed and remote team friction **Pain:** - Remote activity is hard to observe. - No real-time visibility into what teams are doing. - Motivation and engagement drop off. **Solution:** - Live monitoring of engineering activity. - Transparent reporting for distributed teams. - Motivation through visible outcomes and progress. ### No measurable progress **Pain:** - Improvements cannot be quantified. - Team momentum is hard to assess. - Strategy lacks trustworthy metrics. **Solution:** - Track improvements over time. - Analyse trends and growth dynamics. - Supply data for strategic planning. ## Organisation-Specific Issues ### Enterprises **Pains:** - Centralised management of engineering resources is complex. - No single view across multiple programmes. - Coordination between teams is inefficient. **PanDev Metrics Response:** - Centralised control and monitoring. - Unified metric system for every project. - Improved cross-team alignment. ### Startups and Small Teams **Pains:** - Need fast digitalisation of processes. - Priorities and resource allocation are unclear. - Rapid team growth creates chaos. **PanDev Metrics Response:** - Quick setup and onboarding. - Clear visibility into priorities. - Support for scaling without losing control. ### Outsourcing and Outstaffing Firms **Pains:** - Customers demand transparent reporting. - Remote contributors are hard to supervise. - Manual time reports and invoices consume time. **PanDev Metrics Response:** - Evidence-based reporting from real metrics. - Control over remote contributors. - Automated report generation. ## Economic Pressures ### Inefficient resource allocation **Pain:** Companies spend heavily on development without understanding ROI. **Solution:** PanDev Metrics optimises resource usage and boosts the return on engineering investment. ### High turnover **Pain:** Subjective performance reviews lead to unfair evaluations and attrition. **Solution:** Objective, data-driven assessments highlight real contribution and reward fairness. ### Slow response to change **Pain:** Teams react slowly to new requirements or technologies because they lack real-time feedback. **Solution:** Live data enables fast adaptation and confident decision-making. ## Results After Adoption With PanDev Metrics in place, teams gain: - ✅ **Reliable data** instead of guesswork. - ✅ **Process transparency** for everyone involved. - ✅ **Measurable productivity gains.** - ✅ **Better planning** and resource management. - ✅ **Higher motivation** across the organisation. - ✅ **A competitive edge** in the market. --- ## Product Description URL: https://pandev-metrics.com/docs/how-it-works/product-description # Product Description **PanDev Metrics** is an ecosystem designed to digitise engineering processes and guide IT departments toward a **data-driven** operating model. The platform gives engineering leaders and CTOs **objective productivity metrics**, enabling decisions based on real numbers and an accurate assessment of team performance. ## What Is PanDev Metrics? PanDev Metrics is a comprehensive solution that helps companies understand how their developers work and where their time goes. Think of it as a complete, reliable picture of the engineering workflow that supports better decision-making and reveals opportunities to improve efficiency and develop talent. Beyond simple time tracking, the platform delivers deep analytics for: ### Employee and Team Growth - **Individual development** – monitor each engineer’s progress, strengths, and growth areas. - **Team dynamics** – analyse collaboration patterns, uncover facilitators, mentors, and hidden leaders. - **Leadership development** – evaluate team leads objectively, capturing managerial and technical skills. - **Career planning** – provide data for promotions, rotations, and talent programmes. ### Project Evolution - **Project progress** – observe real task completion and milestone achievement. - **Code quality** – analyse technical debt, complexity, and maintainability trends. - **Timelines** – plan and forecast delivery dates with accuracy. - **Resource planning** – distribute workload optimally across teams. ### Bottleneck Detection - **Blocker discovery** – surface process steps that slow delivery. - **Bottleneck analysis** – identify stages that consume disproportionate time. - **Technical risk** – detect problematic code areas that need refactoring. - **Process optimisation** – receive suggestions to streamline workflows. ### Strategic Planning - **Long-term analytics** – track performance and quality trends over months and years. - **Forecasting** – predict resource demand and emerging risks. - **Project ROI** – quantify the return on investment in engineering. - **Benchmarking** – compare results against industry standards and best practices. ## Guiding Principles ### 1. Personalised Data Capture Metrics originate directly from developers’ IDEs, providing precise visibility into individual contributions and ensuring total transparency across the development process. ### 2. Automated Collection Plugins and integrations gather metrics automatically, reducing manual input and avoiding process friction. ### 3. Rich Context PanDev Metrics correlates IDE activity with information from Git, Jira, task trackers, and communication tools to produce multidimensional insight. ### 4. Accuracy and Reliability Data is validated at every stage—collection, transport, processing, and storage—so reports stay trustworthy and resistant to manipulation. ### 5. Security and Compliance The platform follows enterprise-grade security practices: encryption in transit and at rest, fine-grained access control, audit trails, and deployment options that satisfy regulatory requirements. ## Key Capabilities 1. **Continuous time tracking** tied to tasks, commits, and repositories. 2. **Full activity history** with powerful filters by person, team, project, and timeframe. 3. **Team diagnostics** to highlight blockers, delivery risks, and collaboration issues. 4. **Quality monitoring** across codebases, tests, and refactoring work. 5. **Automated reporting** for stakeholders at every level. 6. **Predictive analytics** that flag negative trends before they hit delivery. ## Value by Stakeholder ### Developers - Transparent view of their own metrics. - Personalised growth insights. - Motivation through visible progress. ### Team Leads - Real-time visibility into team workload and focus. - Early detection of risks and dependencies. - Evidence to support coaching and feedback. ### Engineering Managers & CTOs - Strategic dashboards across portfolios. - Objective data for hiring, budgeting, and planning. - Confidence in ROI calculations. ### HR & People Ops - Reliable input for retention and development programmes. - Fair performance reviews backed by evidence. - Identification of top performers and high-potential talent. ## Why Organisations Choose PanDev Metrics - **Data-driven leadership** – move from intuition to facts. - **Faster delivery** – spot and eliminate bottlenecks. - **Better quality** – see issues ahead of time. - **Empowered teams** – encourage ownership and accountability. - **Sustainable scaling** – grow without losing control of processes. ## Recommended Reading Map - **Problems We Solve** – understand the pain points addressed by the platform. - **How It Works** – dive into the technical flow from collection to analytics. - **Use Cases & Metrics** – explore adoption patterns across company types. - **Architecture** – study the system components, security, and deployment models. - **Data Collection** – learn what telemetry is captured and how privacy is preserved. ## Quick Start To understand whether PanDev Metrics is the right fit: 1. **Read the Product Description** – grasp the overall value proposition. 2. **Review the Problems We Solve** – map the solution to your challenges. 3. **Check Use Cases** – see how organisations similar to yours benefit. 4. **Study How It Works** – learn what the implementation journey looks like. ## Next Steps After familiarising yourself with the documentation: - **System requirements** – ensure your environment is ready. - **Installation guide** – follow the deployment instructions. - **Plugin setup** – roll out IDE integrations. - **Integrations** – connect Jira, GitLab, and other systems. ## Support Need assistance? - **Technical support** – reach out to our engineers. - **Documentation** – explore detailed guides and FAQs. - **Community** – connect with other PanDev Metrics users. --- ## Use Cases and KPIs URL: https://pandev-metrics.com/docs/how-it-works/use-cases-metrics # Use Cases and KPIs PanDev Metrics delivers value to a wide range of organisations and helps improve the key performance indicators of engineering teams. ## Use Cases ### Large Enterprises **How it is used:** - Central governance of multiple programmes and products. - Coordination across distributed development teams. - Strategic planning at the corporate level. **Key benefits:** - **Centralised control** – one metric system for every project. - **Data-driven decisions** for portfolio management. - **Resource optimisation** across teams and initiatives. - **Process standardisation** for consistent delivery. **Representative KPIs:** - Aggregate productivity of all engineering teams. - Effectiveness of resource allocation between projects. - Time-to-market for new products. - ROI on software development investments. ### Startups and Small Teams **How it is used:** - Fast digitisation of development workflows. - Clarifying priorities and focusing limited resources. - Supporting rapid growth and team scaling. **Key benefits:** - **Quick configuration** and onboarding. - **Clear prioritisation** for the whole team. - **Scaling support** without losing control. - **Optimised resource usage** when every hour counts. **Representative KPIs:** - Speed of MVP delivery. - Efficiency of developer time usage. - Early-stage code quality. - Time from idea to release. ### Outsourcing and Outstaffing Vendors **How it is used:** - Transparent reporting back to customers. - Monitoring distributed or remote contributors. - Automating statements of work and invoicing. **Key benefits:** - **Transparent reporting** built on verifiable metrics. - **Real-time visibility** into remote work. - **Automated billing** and report generation. - **Stronger client trust** and retention. **Representative KPIs:** - Time spent on specific customer projects. - Quality of deliverables. - Productivity of remote contributors. - Customer satisfaction. ### Public Sector Organisations **How it is used:** - Meeting transparency and accountability mandates. - Controlling expenditure on software initiatives. - Ensuring data security and confidentiality. **Key benefits:** - **Regulatory compliance** out of the box. - **Transparency** for budget spend. - **Elevated security** controls. - **Objective reporting** for oversight bodies. ## KPIs Improved by PanDev Metrics ### Performance Metrics #### Delivery Speed - **Task completion time** – typically reduced by 15–25%. - **Coding throughput** – increases by 10–20%. - **Code review latency** – streamlined review cycles. - **Release frequency** – ship more often without sacrificing quality. #### Code Quality - **Test coverage** – uplift by 20–30%. - **Technical debt** – lowered by 25–40%. - **Code complexity** – controlled growth of hotspots. - **Defect rate** – fewer bugs reach production. #### Collaboration - **Review participation** – broader involvement in peer reviews. - **Knowledge sharing** – fewer single points of failure. - **Cross-team communication** – improved coordination across squads. - **Stakeholder visibility** – clearer status reports for business partners. ### Management Metrics #### Planning Accuracy - **Effort estimation** – more reliable commitments. - **Sprint predictability** – better hit rates for planned scope. - **Release forecasting** – dependable roadmap delivery. - **Dependency management** – faster mitigation of cross-team blockers. #### Workload Balance - **Load distribution** – healthier balance across engineers. - **Capacity planning** – data-backed action on hiring and redistribution. - **Burnout prevention** – proactive alerts on overwork. - **Team morale** – higher engagement thanks to transparency. #### Process Maturity - **Lead time** – shorter cycle from idea to value. - **Throughput stability** – consistent delivery pace. - **Automation rate** – more repeatable workflows. - **Continuous improvement** – ongoing optimisation driven by feedback loops. ### Business Outcomes #### Financial Impact - **Cost per feature** – decrease through better utilisation. - **Revenue timing** – faster launches accelerate payback. - **Budget adherence** – fewer overruns. - **ROI uplift** – clearer link between engineering spend and results. #### Customer Value - **Product quality** – fewer production incidents. - **Customer satisfaction** – higher NPS thanks to reliable delivery. - **Innovation cadence** – more experiments and faster validation. - **Competitive differentiation** – build better products sooner. #### Scaling - **Team growth velocity** – onboard new engineers 2–3× faster. - **Adaptability** – react quickly to changing requirements. - **Process standardisation** – consistent practices across teams. - **Knowledge transfer** – better documentation and handovers. ## Industry Perspectives ### Software Product Development - Emphasis on code quality and architecture health. - Metrics around engineering throughput. - Technical debt analytics for long-lived products. ### Web Development - Velocity of UI/UX delivery. - Customer experience quality. - Performance of web applications. ### Mobile Development - Time-to-market for mobile apps. - Quality across platforms. - Efficiency of cross-platform teams. ### DevOps & Infrastructure - Process automation coverage. - Deployment lead time. - System reliability and uptime. ## Results Over Time ### Short Term (1–3 months) - Process transparency. - Identification of major bottlenecks. - Kick-off of process optimisation initiatives. ### Mid Term (3–6 months) - Measurable productivity gains. - Higher code quality. - Improved planning accuracy. ### Long Term (6+ months) - Sustainable efficiency growth. - Data-driven culture. - Competitive advantages in the market. ## ROI from PanDev Metrics ### Direct Benefits - **Development time reduction** – 15–25%. - **Cost reduction** – 10–20%. - **Product quality uplift** – fewer defects and regressions. - **Faster go-to-market** – beat competitors to launch. ### Indirect Benefits - **Higher motivation** across teams. - **Better planning** and forecasting. - **Lower project risk** due to early warnings. - **Stronger competitive position** through predictable delivery. # Setup / Integrations ## Arc URL: https://pandev-metrics.com/docs/setup/browser-extensions/arc # Arc This guide explains how to install the PanDev Metrics extension in Arc browser. ## Installation from Chrome Web Store Arc supports Chrome extensions. Install directly from the Chrome Web Store: **[Install PanDev Metrics from Chrome Web Store](https://chromewebstore.google.com/detail/pandev-metrics/cpecnlannccfbahifgommohpfoefhigl)** 1. Click the link above to open Chrome Web Store 2. Click **Add to Chrome** 3. Confirm by clicking **Add extension** The extension icon will appear in your browser. --- ## Configuration After installation, configure the extension with your connection settings: 1. Click the **PanDev Metrics** extension icon in the toolbar 2. Click **Settings** or the gear icon 3. Enter your connection parameters: ### SaaS (Corporate Account) | Parameter | Value | |-----------|-------| | **Server URL** | `https://metrics-cloud.pandev.io` | | **Company Login** | Your company identifier | | **Login** | Your employee login | | **Password** | Your password | ### SaaS (Personal Account) | Parameter | Value | |-----------|-------| | **Server URL** | `https://metrics-cloud.pandev.io` | | **Company Login** | *leave empty* | | **Login** | Your email | | **Password** | Your password | ### On-Premise | Parameter | Value | |-----------|-------| | **Server URL** | Your server URL (e.g., `https://pandev.company.local`) | | **Company Login** | *leave empty* | | **Login** | Your employee login | | **Password** | Your password | --- ## Usage Once configured, the extension works automatically: - Tracks browsing activity in the background - Categorizes visited sites (documentation, research, tools) - Sends data to the PanDev Metrics server - Metrics appear in your dashboard within minutes --- ## Troubleshooting **Extension icon not visible?** - Arc may hide extension icons by default - Look in the extensions menu or toolbar settings **Extension not working?** - Go to `arc://extensions/` and check that it's enabled - Try removing and reinstalling the extension --- ## Brave URL: https://pandev-metrics.com/docs/setup/browser-extensions/brave # Brave This guide explains how to install the PanDev Metrics extension in Brave browser. ## Installation from Chrome Web Store Brave supports Chrome extensions. Install directly from the Chrome Web Store: **[Install PanDev Metrics from Chrome Web Store](https://chromewebstore.google.com/detail/pandev-metrics/cpecnlannccfbahifgommohpfoefhigl)** 1. Click the link above to open Chrome Web Store 2. Click **Add to Chrome** 3. Confirm by clicking **Add extension** The extension icon will appear in your browser toolbar. --- ## Configuration After installation, configure the extension with your connection settings: 1. Click the **PanDev Metrics** extension icon in the toolbar 2. Click **Settings** or the gear icon 3. Enter your connection parameters: ### SaaS (Corporate Account) | Parameter | Value | |-----------|-------| | **Server URL** | `https://metrics-cloud.pandev.io` | | **Company Login** | Your company identifier | | **Login** | Your employee login | | **Password** | Your password | ### SaaS (Personal Account) | Parameter | Value | |-----------|-------| | **Server URL** | `https://metrics-cloud.pandev.io` | | **Company Login** | *leave empty* | | **Login** | Your email | | **Password** | Your password | ### On-Premise | Parameter | Value | |-----------|-------| | **Server URL** | Your server URL (e.g., `https://pandev.company.local`) | | **Company Login** | *leave empty* | | **Login** | Your employee login | | **Password** | Your password | --- ## Usage Once configured, the extension works automatically: - Tracks browsing activity in the background - Categorizes visited sites (documentation, research, tools) - Sends data to the PanDev Metrics server - Metrics appear in your dashboard within minutes --- ## Troubleshooting **Extension icon not visible?** - Click the **puzzle piece** icon in the toolbar - Pin the PanDev Metrics extension **Brave Shields interfering?** - The extension should work normally with Shields enabled - If issues occur, try adding the PanDev server to Shields allow list **Extension not working?** - Go to `brave://extensions/` and check that it's enabled - Try removing and reinstalling the extension --- ## Google Chrome URL: https://pandev-metrics.com/docs/setup/browser-extensions/chrome # Google Chrome This guide explains how to install the PanDev Metrics extension in Google Chrome. ## Installation from Chrome Web Store The easiest way to install the extension: **[Install PanDev Metrics from Chrome Web Store](https://chromewebstore.google.com/detail/pandev-metrics/cpecnlannccfbahifgommohpfoefhigl)** 1. Click the link above to open Chrome Web Store 2. Click **Add to Chrome** 3. Confirm by clicking **Add extension** The extension icon will appear in your browser toolbar. --- ## Configuration After installation, configure the extension with your connection settings: 1. Click the **PanDev Metrics** extension icon in the toolbar 2. Click **Settings** or the gear icon 3. Enter your connection parameters: ### SaaS (Corporate Account) | Parameter | Value | |-----------|-------| | **Server URL** | `https://metrics-cloud.pandev.io` | | **Company Login** | Your company identifier | | **Login** | Your employee login | | **Password** | Your password | ### SaaS (Personal Account) | Parameter | Value | |-----------|-------| | **Server URL** | `https://metrics-cloud.pandev.io` | | **Company Login** | *leave empty* | | **Login** | Your email | | **Password** | Your password | ### On-Premise | Parameter | Value | |-----------|-------| | **Server URL** | Your server URL (e.g., `https://pandev.company.local`) | | **Company Login** | *leave empty* | | **Login** | Your employee login | | **Password** | Your password | --- ## Usage Once configured, the extension works automatically: - Tracks browsing activity in the background - Categorizes visited sites (documentation, research, tools) - Sends data to the PanDev Metrics server - Metrics appear in your dashboard within minutes --- ## Troubleshooting **Extension icon not visible?** - Click the **puzzle piece** icon in the toolbar - Pin the PanDev Metrics extension **Extension not working?** - Go to `chrome://extensions/` and check that it's enabled - Try removing and reinstalling the extension --- ## Microsoft Edge URL: https://pandev-metrics.com/docs/setup/browser-extensions/edge # Microsoft Edge This guide explains how to install the PanDev Metrics extension in Microsoft Edge. ## Installation from Chrome Web Store Edge supports Chrome extensions. Install directly from the Chrome Web Store: **[Install PanDev Metrics from Chrome Web Store](https://chromewebstore.google.com/detail/pandev-metrics/cpecnlannccfbahifgommohpfoefhigl)** 1. Click the link above to open Chrome Web Store 2. Click **Add to Chrome** (Edge will recognize this) 3. Confirm by clicking **Add extension** If prompted about allowing extensions from other stores, click **Allow extensions from other stores** in the browser notification. The extension icon will appear in your browser toolbar. --- ## Configuration After installation, configure the extension with your connection settings: 1. Click the **PanDev Metrics** extension icon in the toolbar 2. Click **Settings** or the gear icon 3. Enter your connection parameters: ### SaaS (Corporate Account) | Parameter | Value | |-----------|-------| | **Server URL** | `https://metrics-cloud.pandev.io` | | **Company Login** | Your company identifier | | **Login** | Your employee login | | **Password** | Your password | ### SaaS (Personal Account) | Parameter | Value | |-----------|-------| | **Server URL** | `https://metrics-cloud.pandev.io` | | **Company Login** | *leave empty* | | **Login** | Your email | | **Password** | Your password | ### On-Premise | Parameter | Value | |-----------|-------| | **Server URL** | Your server URL (e.g., `https://pandev.company.local`) | | **Company Login** | *leave empty* | | **Login** | Your employee login | | **Password** | Your password | --- ## Usage Once configured, the extension works automatically: - Tracks browsing activity in the background - Categorizes visited sites (documentation, research, tools) - Sends data to the PanDev Metrics server - Metrics appear in your dashboard within minutes --- ## Troubleshooting **Extension icon not visible?** - Click the **puzzle piece** icon in the toolbar - Click the **eye** icon next to PanDev Metrics to show it **Extension not working?** - Go to `edge://extensions/` and check that it's enabled - Try removing and reinstalling the extension --- ## Mozilla Firefox URL: https://pandev-metrics.com/docs/setup/browser-extensions/firefox # Mozilla Firefox This guide explains how to install the PanDev Metrics extension in Mozilla Firefox. ## Installation from Firefox Add-ons The easiest way to install the extension: **[Install PanDev Metrics from Firefox Add-ons](https://addons.mozilla.org/firefox/addon/pandev-metrics/)** 1. Click the link above to open Firefox Add-ons 2. Click **Add to Firefox** 3. Confirm by clicking **Add** The extension icon will appear in your browser toolbar. --- ## Configuration After installation, configure the extension with your connection settings: 1. Click the **PanDev Metrics** extension icon in the toolbar 2. Click **Settings** or the gear icon 3. Enter your connection parameters: ### SaaS (Corporate Account) | Parameter | Value | |-----------|-------| | **Server URL** | `https://metrics-cloud.pandev.io` | | **Company Login** | Your company identifier | | **Login** | Your employee login | | **Password** | Your password | ### SaaS (Personal Account) | Parameter | Value | |-----------|-------| | **Server URL** | `https://metrics-cloud.pandev.io` | | **Company Login** | *leave empty* | | **Login** | Your email | | **Password** | Your password | ### On-Premise | Parameter | Value | |-----------|-------| | **Server URL** | Your server URL (e.g., `https://pandev.company.local`) | | **Company Login** | *leave empty* | | **Login** | Your employee login | | **Password** | Your password | --- ## Usage Once configured, the extension works automatically: - Tracks browsing activity in the background - Categorizes visited sites (documentation, research, tools) - Sends data to the PanDev Metrics server - Metrics appear in your dashboard within minutes --- ## Troubleshooting **Extension icon not visible?** - Click the **puzzle piece** icon in the toolbar - Pin the PanDev Metrics extension **Extension not working?** - Go to `about:addons` and check that it's enabled - Try removing and reinstalling the extension --- ## Opera URL: https://pandev-metrics.com/docs/setup/browser-extensions/opera # Opera This guide explains how to install the PanDev Metrics extension in Opera browser. ## Installation from Chrome Web Store Opera supports Chrome extensions. Install directly from the Chrome Web Store: **[Install PanDev Metrics from Chrome Web Store](https://chromewebstore.google.com/detail/pandev-metrics/cpecnlannccfbahifgommohpfoefhigl)** 1. Click the link above to open Chrome Web Store 2. Click **Add to Opera** 3. Confirm by clicking **Add extension** If prompted about installing Chrome extensions, click **Install extension** to confirm. The extension icon will appear in your browser toolbar. --- ## Configuration After installation, configure the extension with your connection settings: 1. Click the **PanDev Metrics** extension icon in the toolbar 2. Click **Settings** or the gear icon 3. Enter your connection parameters: ### SaaS (Corporate Account) | Parameter | Value | |-----------|-------| | **Server URL** | `https://metrics-cloud.pandev.io` | | **Company Login** | Your company identifier | | **Login** | Your employee login | | **Password** | Your password | ### SaaS (Personal Account) | Parameter | Value | |-----------|-------| | **Server URL** | `https://metrics-cloud.pandev.io` | | **Company Login** | *leave empty* | | **Login** | Your email | | **Password** | Your password | ### On-Premise | Parameter | Value | |-----------|-------| | **Server URL** | Your server URL (e.g., `https://pandev.company.local`) | | **Company Login** | *leave empty* | | **Login** | Your employee login | | **Password** | Your password | --- ## Usage Once configured, the extension works automatically: - Tracks browsing activity in the background - Categorizes visited sites (documentation, research, tools) - Sends data to the PanDev Metrics server - Metrics appear in your dashboard within minutes --- ## Troubleshooting **Extension icon not visible?** - Click the **cube** icon (Extensions) in the toolbar - Pin the PanDev Metrics extension **Extension not working?** - Go to `opera://extensions/` and check that it's enabled - Try removing and reinstalling the extension --- ## Browser Extensions URL: https://pandev-metrics.com/docs/setup/browser-extensions/overview # Browser Extensions The PanDev Metrics browser extension automatically tracks developer activity in web browsers. It captures time spent on documentation, research, and working with web-based tools — providing a complete picture of developer workflow. ## Key Features - **Zero-click tracking** — tracking starts automatically when you browse - **Privacy-first** — no page content or screenshots captured - **Secure** — data transmitted over HTTPS/TLS - **Configurable** — whitelist or blacklist specific domains --- ## Installation The PanDev Metrics extension is available in the **Chrome Web Store** for Chromium-based browsers and **Firefox Add-ons** for Mozilla Firefox: **[Install PanDev Metrics from Chrome Web Store](https://chromewebstore.google.com/detail/pandev-metrics/cpecnlannccfbahifgommohpfoefhigl)** **[Install PanDev Metrics from Firefox Add-ons](https://addons.mozilla.org/firefox/addon/pandev-metrics/)** --- ## Supported Browsers | Browser | Installation Guide | |---------|-------------------| | Google Chrome | [Chrome Installation](https://pandev-metrics.com/docs/setup/browser-extensions/chrome) | | Mozilla Firefox | [Firefox Installation](https://pandev-metrics.com/docs/setup/browser-extensions/firefox) | | Opera | [Opera Installation](https://pandev-metrics.com/docs/setup/browser-extensions/opera) | | Microsoft Edge | [Edge Installation](https://pandev-metrics.com/docs/setup/browser-extensions/edge) | | Arc | [Arc Installation](https://pandev-metrics.com/docs/setup/browser-extensions/arc) | | Brave | [Brave Installation](https://pandev-metrics.com/docs/setup/browser-extensions/brave) | | Sidekick | [Sidekick Installation](https://pandev-metrics.com/docs/setup/browser-extensions/sidekick) | | Vivaldi | [Vivaldi Installation](https://pandev-metrics.com/docs/setup/browser-extensions/vivaldi) | | Whale (Naver) | [Whale Installation](https://pandev-metrics.com/docs/setup/browser-extensions/whale) | | Yandex Browser | [Yandex Installation](https://pandev-metrics.com/docs/setup/browser-extensions/yandex) | --- ## How It Works 1. **Install** — get the extension from Chrome Web Store 2. **Configure** — enter Server URL and credentials 3. **Browse** — the extension tracks activity silently in the background 4. **Analyze** — view metrics in the PanDev Metrics dashboard --- ## What Gets Tracked The extension captures: - **Domain names** — which websites you visit - **Page titles** — what pages you're viewing - **Time spent** — how long you spend on each site - **Categories** — automatic classification (documentation, research, tools) No page content, form data, or screenshots are ever captured. Only metadata about your browsing activity is collected. --- ## Connection Settings For **Cloud (SaaS)**: - **Server URL:** `https://metrics-cloud.pandev.io` For **On-Premise**: - **Server URL:** Your PanDev Metrics server address --- ## Troubleshooting **Extension not tracking?** - Check that the extension is enabled in your browser - Verify connection settings (Server URL, credentials) - Check that the site is not in the excluded domains list **Data not appearing in dashboard?** - Allow a few minutes for data to sync - Check your network connection - Verify that you're logged in with correct credentials --- ## Sidekick URL: https://pandev-metrics.com/docs/setup/browser-extensions/sidekick # Sidekick This guide explains how to install the PanDev Metrics extension in Sidekick browser. ## Installation from Chrome Web Store Sidekick supports Chrome extensions. Install directly from the Chrome Web Store: **[Install PanDev Metrics from Chrome Web Store](https://chromewebstore.google.com/detail/pandev-metrics/cpecnlannccfbahifgommohpfoefhigl)** 1. Click the link above to open Chrome Web Store 2. Click **Add to Chrome** 3. Confirm by clicking **Add extension** The extension icon will appear in your browser toolbar. --- ## Configuration After installation, configure the extension with your connection settings: 1. Click the **PanDev Metrics** extension icon in the toolbar 2. Click **Settings** or the gear icon 3. Enter your connection parameters: ### SaaS (Corporate Account) | Parameter | Value | |-----------|-------| | **Server URL** | `https://metrics-cloud.pandev.io` | | **Company Login** | Your company identifier | | **Login** | Your employee login | | **Password** | Your password | ### SaaS (Personal Account) | Parameter | Value | |-----------|-------| | **Server URL** | `https://metrics-cloud.pandev.io` | | **Company Login** | *leave empty* | | **Login** | Your email | | **Password** | Your password | ### On-Premise | Parameter | Value | |-----------|-------| | **Server URL** | Your server URL (e.g., `https://pandev.company.local`) | | **Company Login** | *leave empty* | | **Login** | Your employee login | | **Password** | Your password | --- ## Usage Once configured, the extension works automatically: - Tracks browsing activity in the background - Categorizes visited sites (documentation, research, tools) - Sends data to the PanDev Metrics server - Metrics appear in your dashboard within minutes --- ## Troubleshooting **Extension icon not visible?** - Check the Sidekick sidebar or extension area - Pin the extension to make it visible **Extension not working?** - Go to `chrome://extensions/` and check that it's enabled - Try removing and reinstalling the extension --- ## Vivaldi URL: https://pandev-metrics.com/docs/setup/browser-extensions/vivaldi # Vivaldi This guide explains how to install the PanDev Metrics extension in Vivaldi browser. ## Installation from Chrome Web Store Vivaldi supports Chrome extensions. Install directly from the Chrome Web Store: **[Install PanDev Metrics from Chrome Web Store](https://chromewebstore.google.com/detail/pandev-metrics/cpecnlannccfbahifgommohpfoefhigl)** 1. Click the link above to open Chrome Web Store 2. Click **Add to Chrome** 3. Confirm by clicking **Add extension** The extension icon will appear in your browser toolbar. --- ## Configuration After installation, configure the extension with your connection settings: 1. Click the **PanDev Metrics** extension icon in the toolbar 2. Click **Settings** or the gear icon 3. Enter your connection parameters: ### SaaS (Corporate Account) | Parameter | Value | |-----------|-------| | **Server URL** | `https://metrics-cloud.pandev.io` | | **Company Login** | Your company identifier | | **Login** | Your employee login | | **Password** | Your password | ### SaaS (Personal Account) | Parameter | Value | |-----------|-------| | **Server URL** | `https://metrics-cloud.pandev.io` | | **Company Login** | *leave empty* | | **Login** | Your email | | **Password** | Your password | ### On-Premise | Parameter | Value | |-----------|-------| | **Server URL** | Your server URL (e.g., `https://pandev.company.local`) | | **Company Login** | *leave empty* | | **Login** | Your employee login | | **Password** | Your password | --- ## Usage Once configured, the extension works automatically: - Tracks browsing activity in the background - Categorizes visited sites (documentation, research, tools) - Sends data to the PanDev Metrics server - Metrics appear in your dashboard within minutes --- ## Troubleshooting **Extension icon not visible?** - Vivaldi allows customizable toolbars - Right-click the toolbar and check extension visibility settings **Extension not working?** - Go to `vivaldi://extensions/` and check that it's enabled - Try removing and reinstalling the extension --- ## Whale (Naver) URL: https://pandev-metrics.com/docs/setup/browser-extensions/whale # Whale (Naver) This guide explains how to install the PanDev Metrics extension in Naver Whale browser. ## Installation from Chrome Web Store Whale supports Chrome extensions. Install directly from the Chrome Web Store: **[Install PanDev Metrics from Chrome Web Store](https://chromewebstore.google.com/detail/pandev-metrics/cpecnlannccfbahifgommohpfoefhigl)** 1. Click the link above to open Chrome Web Store 2. Click **Add to Chrome** 3. Confirm by clicking **Add extension** The extension icon will appear in your browser toolbar. --- ## Configuration After installation, configure the extension with your connection settings: 1. Click the **PanDev Metrics** extension icon in the toolbar 2. Click **Settings** or the gear icon 3. Enter your connection parameters: ### SaaS (Corporate Account) | Parameter | Value | |-----------|-------| | **Server URL** | `https://metrics-cloud.pandev.io` | | **Company Login** | Your company identifier | | **Login** | Your employee login | | **Password** | Your password | ### SaaS (Personal Account) | Parameter | Value | |-----------|-------| | **Server URL** | `https://metrics-cloud.pandev.io` | | **Company Login** | *leave empty* | | **Login** | Your email | | **Password** | Your password | ### On-Premise | Parameter | Value | |-----------|-------| | **Server URL** | Your server URL (e.g., `https://pandev.company.local`) | | **Company Login** | *leave empty* | | **Login** | Your employee login | | **Password** | Your password | --- ## Usage Once configured, the extension works automatically: - Tracks browsing activity in the background - Categorizes visited sites (documentation, research, tools) - Sends data to the PanDev Metrics server - Metrics appear in your dashboard within minutes --- ## Troubleshooting **Extension icon not visible?** - Click the extensions icon in the toolbar - Pin the PanDev Metrics extension **Extension not working?** - Go to `whale://extensions/` and check that it's enabled - Try removing and reinstalling the extension --- ## Yandex Browser URL: https://pandev-metrics.com/docs/setup/browser-extensions/yandex # Yandex Browser This guide explains how to install the PanDev Metrics extension in Yandex Browser. ## Installation from Chrome Web Store Yandex Browser supports Chrome extensions. Install directly from the Chrome Web Store: **[Install PanDev Metrics from Chrome Web Store](https://chromewebstore.google.com/detail/pandev-metrics/cpecnlannccfbahifgommohpfoefhigl)** 1. Click the link above to open Chrome Web Store 2. Click **Add to Chrome** 3. Confirm by clicking **Add extension** The extension icon will appear in your browser toolbar. --- ## Configuration After installation, configure the extension with your connection settings: 1. Click the **PanDev Metrics** extension icon in the toolbar 2. Click **Settings** or the gear icon 3. Enter your connection parameters: ### SaaS (Corporate Account) | Parameter | Value | |-----------|-------| | **Server URL** | `https://metrics-cloud.pandev.io` | | **Company Login** | Your company identifier | | **Login** | Your employee login | | **Password** | Your password | ### SaaS (Personal Account) | Parameter | Value | |-----------|-------| | **Server URL** | `https://metrics-cloud.pandev.io` | | **Company Login** | *leave empty* | | **Login** | Your email | | **Password** | Your password | ### On-Premise | Parameter | Value | |-----------|-------| | **Server URL** | Your server URL (e.g., `https://pandev.company.local`) | | **Company Login** | *leave empty* | | **Login** | Your employee login | | **Password** | Your password | --- ## Usage Once configured, the extension works automatically: - Tracks browsing activity in the background - Categorizes visited sites (documentation, research, tools) - Sends data to the PanDev Metrics server - Metrics appear in your dashboard within minutes --- ## Troubleshooting **Extension icon not visible?** - Click the **puzzle piece** icon in the toolbar - Pin the PanDev Metrics extension **Extension not working?** - Go to `browser://extensions/` and check that it's enabled - Try removing and reinstalling the extension --- ## Linux URL: https://pandev-metrics.com/docs/setup/cli/linux # Linux The PanDev Metrics CLI Plugin allows you to collect activity data directly from your terminal usage. ## Installation To download the PanDev Metrics CLI Plugin on Linux with Homebrew, run the following command: ```bash brew install pandev-metriks/pandev-cli/pandev-cli-plugin ``` ## Authentication After installation, you must log in to the dedicated server with your credentials: ```bash pandev login ``` ## Status Check To verify if you are authenticated and the plugin is running correctly: ```bash pandev status ``` ## Usage Statistics To see the usage time tracked by the CLI tools: ```bash pandev time ``` ## Help Command To view all available commands and options: ```bash pandev --help ``` ## Uninstalling To remove the plugin completely from your system: ```bash pandev-cli-plugin --uninstall brew uninstall pandev-cli-plugin brew untap pandev-metriks/pandev-cli ``` ## Updating If a new version of the plugin is released, you can update it by running: ```bash brew update && brew upgrade pandev-cli-plugin ``` --- ## Mac URL: https://pandev-metrics.com/docs/setup/cli/macos # Mac The PanDev Metrics CLI Plugin allows you to collect activity data directly from your terminal usage. ## Installation To download the PanDev Metrics CLI Plugin on macOS with Homebrew, run the following commands: ```bash brew install pandev-metriks/pandev-cli/pandev-cli-plugin sudo pandev-cli-plugin --install ``` ## Authentication After installation, you must log in to the dedicated server with your credentials: ```bash sudo pandev login ``` ## Status Check To verify if you are authenticated and the plugin is running correctly: ```bash pandev status ``` ## Usage Statistics To see the usage time tracked by the CLI tools: ```bash pandev time ``` ## Help Command To view all available commands and options: ```bash pandev --help ``` ## Uninstalling To remove the plugin completely from your system: ```bash sudo pandev-cli-plugin --uninstall brew uninstall pandev-cli-plugin brew untap pandev-metriks/pandev-cli ``` --- ## CLI Tools URL: https://pandev-metrics.com/docs/setup/cli/overview # CLI Tools PanDev Metrics CLI is a command-line tool that tracks developer activity in the terminal. It captures command usage to provide insights into terminal workflow — without exposing sensitive data. ## Key Features - **Zero-click tracking** — works silently in the background - **Privacy-first** — only command names are captured, no arguments, keys, or passwords - **Secure** — data transmitted over HTTPS/TLS - **Lightweight** — minimal resource usage --- ## What Gets Tracked The CLI tool captures: - **Command names** — which commands you run (e.g., `git`, `npm`, `docker`) - **Time spent** — how long you spend in terminal sessions Only the **base command** is captured. Arguments, flags, environment variables, API keys, passwords, and other sensitive data are **never** collected or transmitted. **Example:** - Command: `git commit -m "secret message" --author="John"` - Tracked: `git` only --- ## Installation | Operating System | Installation Guide | |------------------|-------------------| | Mac | [Mac Installation](https://pandev-metrics.com/docs/setup/cli/macos) | | Linux | [Linux Installation](https://pandev-metrics.com/docs/setup/cli/linux) | --- ## How It Works 1. **Install** — add the CLI tool via Homebrew 2. **Authenticate** — log in with your PanDev Metrics credentials 3. **Work** — the tool tracks terminal activity silently 4. **Analyze** — view metrics in the PanDev Metrics dashboard --- ## Privacy & Security - No command arguments or flags are captured - No API keys, passwords, or secrets are collected - No environment variables are tracked - Only base command names are transmitted - Data is encrypted in transit (HTTPS/TLS) --- ## Azure DevOps Integration URL: https://pandev-metrics.com/docs/setup/git-integrations/azure-devops # Azure DevOps Integration PanDev Metrics integration with Azure DevOps allows you to analyze development activity in Azure Repos, pull requests, and link metrics with Azure Pipelines. ## Integration Features - **Automatic PR Comments** — adding code quality metrics to pull requests - **Repository Analytics** — analysis of commits, branches, and contributors - **Code Review Metrics** — review time, number of comments, PR cycle time - **Pipeline Connection** — analytics of builds and deployments - **Work Items** — linking tasks to code ## Supported Versions - Azure DevOps Services (Cloud) - Azure DevOps Server (On-Premise) ## Integration Setup ### Step 1: Create a Service Account Create a separate Azure DevOps account that will be used to collect analytics and generate reports. A separate account allows you to distinguish automatic comments from personal ones and simplifies access management. ### Step 2: Grant Access Add the service account to Azure DevOps projects with the **Contributor** or **Project Administrator** role. ### Step 3: Create Personal Access Token 1. Log in to the service account 2. Click on the user icon → **Personal access tokens** 3. Click **New Token** 4. Configure the token: | Parameter | Value | |---|---| | **Name** | `pandev-metrics` | | **Organization** | Select your organization (or All accessible organizations) | | **Expiration** | Custom (1 year recommended) | 5. In **Scopes**, select **Custom defined** and configure access rights: | Scope | Access | |---|---| | **Code** | Read | | **Pull Request Threads** | Read & Write | | **Work Items** | Read | 6. Click **Create** and save the token The token is displayed only once! Save it in a safe place. ### Step 4: Connect in PanDev Metrics 1. Go to **Settings → Integrations → Azure DevOps** 2. Enter: - **Organization URL:** `https://dev.azure.com/your-organization` - **Personal Access Token:** token from step 3 3. Click **Check Connection** 4. After successful verification, click **Activate** ### Step 5: Select Projects 1. Select projects to monitor 2. Configure repository filters (optional) 3. Enable/disable automatic PR comments 4. Save settings ## Tracked Metrics - **Commits** — number and frequency of commits by developers - **Pull Requests** — PR cycle time, time to merge, number of revisions - **Code Review** — review time, number of comments - **Pipelines** — build activity, execution time - **Work Items** — linking tasks to commits and PRs ## FAQ **Does integration work with Azure DevOps Server?** Yes, both Azure DevOps Services and Server (On-Premise) versions are supported. **Can I limit integration to specific projects?** Yes, at the project selection stage, you can select only the ones you need. **How to link Work Items with metrics?** If `Work Items: Read` scope is available, metrics are automatically linked to tasks via numbers in commit messages and PRs. --- ## Bitbucket Integration URL: https://pandev-metrics.com/docs/setup/git-integrations/bitbucket # Bitbucket Integration PanDev Metrics integration with Bitbucket allows you to analyze development activity, pull requests, and automatically add quality metrics to code reviews. ## Integration Features - **Automatic PR Comments** — adding code quality metrics to pull requests - **Repository Analytics** — analysis of commits, branches, and contributors - **Code Review Metrics** — review time, number of comments, PR cycle time - **Privacy** — data is collected only from your repositories ## Supported Versions - Bitbucket Cloud - Bitbucket Data Center / Server ## Integration Setup ### For Bitbucket Cloud #### Step 1: Create App Password 1. Log in to Bitbucket Cloud 2. Go to **Personal Settings → App passwords** 3. Click **Create app password** 4. Configure permissions: | Permission | Access | |---|---| | **Repositories** | Read, Write | | **Pull requests** | Read, Write | | **Webhooks** | Read and write | 5. Click **Create** and save the password #### Step 2: Connect in PanDev Metrics 1. Go to **Settings → Integrations → Bitbucket** 2. Select **Bitbucket Cloud** 3. Enter: - **Username** — your Bitbucket username - **App Password** — password from step 1 4. Click **Check Connection** and **Activate** --- ### For Bitbucket Data Center / Server #### Step 1: Create Personal Access Token 1. Log in to Bitbucket Server 2. Go to **Manage Account → Personal access tokens** 3. Click **Create a token** 4. Configure permissions: | Permission | Access | |---|---| | **Repository** | Read, Write | | **Pull Request** | Read, Write | 5. Click **Create** and save the token #### Step 2: Connect in PanDev Metrics 1. Go to **Settings → Integrations → Bitbucket** 2. Select **Bitbucket Server** 3. Enter: - **Server URL** — Your server URL (e.g., `https://bitbucket.company.local`) - **Personal Access Token** — token from step 1 4. Click **Check Connection** and **Activate** --- ### Step 3: Select Repositories 1. Select repositories to monitor 2. Configure branch filters (optional) 3. Enable/disable automatic PR comments 4. Save settings ## Tracked Metrics - **Commits** — number and frequency of commits by developers - **Pull Requests** — PR cycle time, time to merge, number of revisions - **Code Review** — review time, number of comments - **Activity** — activity trends by repositories ## FAQ **What is the difference between Bitbucket Cloud and Server?** Bitbucket Cloud is the cloud version (bitbucket.org). Bitbucket Data Center/Server is the self-hosted version on your infrastructure. **How often is data updated?** Data is updated in real-time via Bitbucket webhooks. **Can I limit integration to specific repositories?** Yes, at the repository selection stage, you can select only the ones you need. --- ## GitHub Integration URL: https://pandev-metrics.com/docs/setup/git-integrations/github # GitHub Integration PanDev Metrics integration with GitHub allows you to analyze development activity, pull requests, and automatically add quality metrics to code reviews. ## Integration Features - **Automatic PR Comments** — adding code quality metrics to pull requests - **Repository Analytics** — analysis of commits, branches, and contributors - **Code Review Metrics** — review time, number of comments, PR cycle time - **Privacy** — data is collected only from your repositories ## Integration Setup ### Step 1: Create a Service Account Create a separate GitHub account that will be used to collect analytics and generate reports when creating/updating PRs. A separate account allows you to distinguish automatic comments from personal ones and simplifies access management. ### Step 2: Grant Access to the Service Account Give the service account **Owner** or **Admin** role in all organizations whose repositories need to be analyzed. ### Step 3: Create a Token 1. Log in to the service account 2. Go to [Personal Access Tokens](https://github.com/settings/personal-access-tokens) 3. Click **Generate new token** → **Fine-grained personal access token** 4. Configure the token: | Parameter | Value | |---|---| | **Token name** | `pandev-metrics` | | **Expiration** | 90 days (or no expiration) | | **Resource owner** | Your organization | | **Repository access** | All repositories | 5. In **Permissions → Repository permissions**: | Permission | Access | |---|---| | **Issues** | Read and write | | **Metadata** | Read-only | | **Pull requests** | Read and write | 6. In **Permissions → Organization permissions**: | Permission | Access | |---|---| | **Webhooks** | Read and write | 7. Click **Generate token** and save the token ### Step 4: Connect in PanDev Metrics 1. Go to **Settings → Integrations → GitHub** 2. Paste the copied token 3. Click **Check Connection** 4. After successful verification, click **Activate** ## Tracked Metrics - **Commits** — number and frequency of commits by developers - **Pull Requests** — PR cycle time, time to merge, number of revisions - **Code Review** — review time, number of comments - **Activity** — activity trends by repositories and contributors ## FAQ **Is access to private repositories required?** Yes, to analyze private repositories, the token must have access to them. **How often is data updated?** Data is updated in real-time via GitHub webhooks. **Can I limit integration to specific repositories?** Yes, when creating the token, you can select **Only select repositories** instead of **All repositories**. --- ## GitLab Integration URL: https://pandev-metrics.com/docs/setup/git-integrations/gitlab # GitLab Integration PanDev Metrics integration with GitLab allows you to analyze development activity, merge requests, and automatically add quality metrics to code reviews. ## Integration Features - **Automatic MR Comments** — adding code quality metrics to merge requests - **Repository Analytics** — analysis of commits, branches, and contributors - **Code Review Metrics** — review time, number of comments, MR cycle time - **Privacy** — data is collected only from your projects ## Supported Versions - GitLab.com (SaaS) - GitLab Self-Managed (On-Premise) ## Integration Setup ### Step 1: Create a Service Account Create a separate GitLab account that will be used to collect analytics and generate reports. A separate account allows you to distinguish automatic comments from personal ones and simplifies access management. ### Step 2: Grant Access Add the service account to GitLab groups/projects with the **Maintainer** or **Owner** role. ### Step 3: Create a Token 1. Log in to the service account 2. Go to **User Settings → Access Tokens** 3. Click **Add new token** 4. Configure the token: | Parameter | Value | |---|---| | **Token name** | `pandev-metrics` | | **Expiration date** | 90 days (or no expiration for Self-Managed) | 5. Select access rights (scopes): | Scope | Description | |---|---| | **api** | Full API access | | **read_repository** | Read repositories | | **write_repository** | Write to repositories (for comments) | 6. Click **Create personal access token** and save the token ### Step 4: Connect in PanDev Metrics 1. Go to **Settings → Integrations → GitLab** 2. Specify GitLab URL: - For GitLab.com: `https://gitlab.com` - For Self-Managed: Your server URL (e.g., `https://gitlab.company.local`) 3. Paste the copied token 4. Click **Check Connection** 5. After successful verification, click **Activate** ### Step 5: Select Projects 1. Select groups or projects to monitor 2. Configure branch filters (optional) 3. Save settings ## Tracked Metrics - **Commits** — number and frequency of commits by developers - **Merge Requests** — MR cycle time, time to merge, number of revisions - **Code Review** — review time, number of comments - **Activity** — activity trends by projects and contributors ## FAQ **Does integration work with GitLab Self-Managed?** Yes, both GitLab.com and Self-Managed versions are supported. **What permissions are sufficient for basic analytics?** For analytics without comments, `api` and `read_repository` scopes are sufficient. **How often is data updated?** Data is updated in real-time via GitLab webhooks. --- ## JetBrains Plugin URL: https://pandev-metrics.com/docs/setup/ide-plugins/jetbrains-plugin # JetBrains Plugin The PanDev Metrics plugin for JetBrains integrates with the entire family of IDEs. It collects detailed information about developer work, including file editing time, branch switching, and more, transmitting this data to the PanDev Metrics server. ## Supported IDEs - IntelliJ IDEA - PyCharm - PhpStorm - GoLand - Rider - CLion - RustRover - WebStorm - RubyMine - Android Studio ## Key Features - **Zero Click** — the programmer does not need to start/stop tracking manually - **Detailed Metrics Collection** — tracking of file editing time, branch switches, open projects - **Secure Mode** — the plugin does not take screenshots or analyze personal information - **Integration with PanDev Metrics** — all data is available for building reports and charts ## Installation 1. Open the desired IDE (IntelliJ IDEA, PyCharm, etc.) 2. Go to settings: **Settings** → **Plugins** 3. Select the **Marketplace** tab 4. Type **PanDev Metrics** in the search bar 5. Click **Install** and restart the IDE ## Configuration After restarting the IDE, go to **Settings** → **Tools** → **PanDev Metrics** and fill in the connection parameters depending on the deployment type: ### SaaS (Corporate Account) For companies using the cloud version of PanDev Metrics. | Parameter | Value | |---|---| | **Server URL** | `https://metrics-cloud.pandev.io` | | **Company Login** | Your company identifier | | **Login** | Employee login | | **Password** | Employee password | You can find the Company Identifier from your administrator or in the PanDev Metrics platform settings under **Settings → Company**. --- ### SaaS (Personal Account) For individual developers using a personal workspace. | Parameter | Value | |---|---| | **Server URL** | `https://metrics-cloud.pandev.io` | | **Company Login** | *leave empty* | | **Login** | Your email | | **Password** | Your password | When the Company Login field is empty, data is sent to your personal workspace, accessible only to you. --- ### On-Premise (Private Infrastructure) For companies with their own PanDev Metrics server. | Parameter | Value | |---|---| | **Server URL** | Your server URL (e.g., `https://pandev.company.local`) | | **Company Login** | *leave empty* (not used for On-Premise) | | **Login** | Employee login | | **Password** | Employee password | Your system administrator provides the server URL and credentials. ## Usage The plugin works in the background: - Tracks activity in open files and projects - Automatically sends data to the PanDev Metrics server - Metrics appear on the dashboard within a few minutes After configuration, you will see your work metrics on the employee page in PanDev Metrics. --- ## IDE Plugins URL: https://pandev-metrics.com/docs/setup/ide-plugins/overview # IDE Plugins PanDev Metrics plugins are lightweight modules installed inside your development environment. They automatically capture developer activity and send telemetry to PanDev Metrics — no manual time tracking required. ## Key Features - **Zero-click tracking** — developers never start or stop tracking manually - **Privacy-first** — no screenshots, screen recordings, or source code capture - **Secure** — data transmitted over HTTPS/TLS - **Configurable** — exclude specific files, directories, or projects --- ## Supported IDEs ### JetBrains Family Supports all JetBrains IDEs: | IDE | Description | |-----|-------------| | IntelliJ IDEA | Java, Kotlin | | PyCharm | Python | | WebStorm | JavaScript, TypeScript | | PhpStorm | PHP | | GoLand | Go | | Rider | .NET, C# | | CLion | C, C++ | | RustRover | Rust | | RubyMine | Ruby | | Android Studio | Android | **→** [JetBrains Plugin Setup](https://pandev-metrics.com/docs/setup/ide-plugins/jetbrains-plugin) --- ### VS Code & Forks | IDE | Description | |-----|-------------| | Visual Studio Code | Universal editor | | Windsurf AI | AI-powered fork | | Cursor AI | AI-powered fork | **→** [VS Code Plugin Setup](https://pandev-metrics.com/docs/setup/ide-plugins/vsc-plugin) | [Windsurf & Cursor AI Setup](https://pandev-metrics.com/docs/setup/ide-plugins/windsurf-cursor) --- ### Visual Studio Full support for Visual Studio (Windows). **→** [Visual Studio Plugin Setup](https://pandev-metrics.com/docs/setup/ide-plugins/visual-studio-plugin) --- ## How It Works 1. **Install** — add the plugin from marketplace or package 2. **Configure** — enter Server URL and credentials 3. **Work** — the plugin tracks activity silently in the background 4. **Analyze** — view metrics in the PanDev Metrics dashboard --- ## Connection Settings For **Cloud (SaaS)**: - **Server URL:** `https://metrics-cloud.pandev.io` For **On-Premise**: - **Server URL:** Your PanDev Metrics server address --- ## Privacy & Security - No source code is captured or transmitted - No screenshots or screen recordings - Activity data includes: file names, project names, time spent, branches - Administrators control which projects are tracked --- ## Visual Studio Plugin URL: https://pandev-metrics.com/docs/setup/ide-plugins/visual-studio-plugin # Visual Studio Plugin The PanDev Metrics plugin for Visual Studio (Windows) automatically tracks activity in .NET, C#, C++, and other Visual Studio projects. ## Key Features - **Zero Click** — no manual tracking start/stop required - **Full Visual Studio Support** — works with all editions - **Project Tracking** — records which solutions and projects you monitor - **Security** — source code is not captured ## Supported Versions - Visual Studio 2019 - Visual Studio 2022 ## Installation 1. Open Visual Studio 2. Go to **Extensions → Manage Extensions** 3. Select the **Online** tab and type **PanDev Metrics** in the search bar 4. Click **Download** and restart Visual Studio ## Configuration After installation, go to **Tools → Options → PanDev Metrics** and fill in the connection parameters depending on the deployment type: ### SaaS (Corporate Account) For companies using the cloud version of PanDev Metrics. | Parameter | Value | |---|---| | **Server URL** | `https://metrics-cloud.pandev.io` | | **Company Login** | Your company identifier | | **Login** | Employee login | | **Password** | Employee password | You can find the Company Identifier from your administrator or in the PanDev Metrics platform settings under **Settings → Company**. --- ### SaaS (Personal Account) For individual developers using a personal workspace. | Parameter | Value | |---|---| | **Server URL** | `https://metrics-cloud.pandev.io` | | **Company Login** | *leave empty* | | **Login** | Your email | | **Password** | Your password | When the Company Login field is empty, data is sent to your personal workspace, accessible only to you. --- ### On-Premise (Private Infrastructure) For companies with their own PanDev Metrics server. | Parameter | Value | |---|---| | **Server URL** | Your server URL (e.g., `https://pandev.company.local`) | | **Company Login** | *leave empty* (not used for On-Premise) | | **Login** | Employee login | | **Password** | Employee password | Your system administrator provides the server URL and credentials. ## Usage The plugin works in the background: - Tracks open files, projects, and solutions - Records time spent coding - Automatically sends data to the PanDev Metrics server - Metrics appear on the dashboard within a few minutes After configuration, you will see your work metrics on the employee page in PanDev Metrics. --- ## VS Code Plugin URL: https://pandev-metrics.com/docs/setup/ide-plugins/vsc-plugin # VS Code Plugin The PanDev Metrics plugin for Visual Studio Code automatically collects data on developer working time and activity. It helps understand how time is distributed throughout the day, and which branches and files are being worked on. ## Key Features - **Zero Click** — developer does not need to turn tracking on/off manually - **Easy Installation** — via VS Code Marketplace - **Flexible Exclusions** — specific directories or file types can be excluded - **Security** — no screen recording or source code capture ## Installation 1. Launch Visual Studio Code 2. Open the **Extensions** tab (`Ctrl+Shift+X` / `Cmd+Shift+X`) 3. Find **PanDev Metrics** and click **Install** 4. Restart the editor ## Configuration Open **Settings** (`Ctrl+,` / `Cmd+,`), find the **PanDev Metrics** section, and fill in the connection parameters depending on the deployment type: ### SaaS (Corporate Account) For companies using the cloud version of PanDev Metrics. | Parameter | Value | |---|---| | **Server URL** | `https://metrics-cloud.pandev.io` | | **Company Login** | Your company identifier | | **Login** | Employee login | | **Password** | Employee password | You can find the Company Identifier from your administrator or in the PanDev Metrics platform settings under **Settings → Company**. --- ### SaaS (Personal Account) For individual developers using a personal workspace. | Parameter | Value | |---|---| | **Server URL** | `https://metrics-cloud.pandev.io` | | **Company Login** | *leave empty* | | **Login** | Your email | | **Password** | Your password | When the Company Login field is empty, data is sent to your personal workspace, accessible only to you. --- ### On-Premise (Private Infrastructure) For companies with their own PanDev Metrics server. | Parameter | Value | |---|---| | **Server URL** | Your server URL (e.g., `https://pandev.company.local`) | | **Company Login** | *leave empty* (not used for On-Premise) | | **Login** | Employee login | | **Password** | Employee password | Your system administrator provides the server URL and credentials. ## Usage The plugin works in the background: - Tracks open files and editing time - Records activity in Git branches - Automatically sends data to the PanDev Metrics server - Metrics appear on the dashboard within a few minutes ## FAQ **Does the plugin collect web pages?** No, the plugin only counts activity inside VS Code. There is a separate extension for the browser. **Can it be used simultaneously with other plugins?** Yes, data from all plugins (VS Code, JetBrains, Visual Studio) is aggregated on the PanDev Metrics server. --- ## Windsurf, Cursor AI & Antigravity URL: https://pandev-metrics.com/docs/setup/ide-plugins/windsurf-cursor # Plugin for AI Editors Windsurf, Cursor AI, and Google Antigravity are modern AI-powered IDEs built as forks of VS Code. The PanDev Metrics plugin for these editors is installed in the same way as for VS Code. ## Key Features - **Zero Click** — no manual tracking start/stop required - **Full Compatibility** — works as a native VS Code extension - **Activity Tracking** — records time spent on files and projects - **Security** — source code is not captured ## Supported Editors - **Windsurf** — AI editor by Codeium - **Cursor AI** — AI-first code editor - **Google Antigravity** — agent-first IDE by Google ## Installation 1. Open the **Extensions** tab (`Ctrl+Shift+X` / `Cmd+Shift+X`) 2. Type **PanDev Metrics** in the search bar 3. Click **Install** Since Windsurf, Cursor AI, and Antigravity are forks of VS Code, the plugin works natively without any limitations. ## Configuration Open **Command Palette** (`Ctrl+Shift+P` / `Cmd+Shift+P`), type **PanDev: Configure**, and fill in the connection parameters: ### SaaS (Corporate Account) For companies using the cloud version of PanDev Metrics. | Parameter | Value | |---|---| | **Server URL** | `https://metrics-cloud.pandev.io` | | **Company Login** | Your company identifier | | **Login** | Employee login | | **Password** | Employee password | You can find the Company Identifier from your administrator or in the PanDev Metrics platform settings under **Settings → Company**. --- ### SaaS (Personal Account) For individual developers using a personal workspace. | Parameter | Value | |---|---| | **Server URL** | `https://metrics-cloud.pandev.io` | | **Company Login** | *leave empty* | | **Login** | Your email | | **Password** | Your password | When the Company Login field is empty, data is sent to your personal workspace, accessible only to you. --- ### On-Premise (Private Infrastructure) For companies with their own PanDev Metrics server. | Parameter | Value | |---|---| | **Server URL** | Your server URL (e.g., `https://pandev.company.local`) | | **Company Login** | *leave empty* (not used for On-Premise) | | **Login** | Employee login | | **Password** | Employee password | Your system administrator provides the server URL and credentials. ## Verification After configuration, you will see an **Online** status in the status bar (bottom right corner of the editor). ## Usage The plugin works in the background: - Tracks open files and editing time - Records activity in Git branches - Automatically sends data to the PanDev Metrics server - Metrics appear on the dashboard within a few minutes --- ## Departments URL: https://pandev-metrics.com/docs/setup/organization/departments # Departments Organize your company structure by grouping teams into departments for convenient viewing of aggregated analytics. ## Why use Departments? Departments are the top level of organizational structure, uniting several teams. For example: - **Department Development** → Backend, Frontend, Mobile teams - **Department QA** → Manual QA, Automation QA teams Departments allow you to: - **Aggregate metrics** — view summary analytics for all teams in the department - **Assign Managers** — define those responsible for the entire department ## Creating a Department 1. Go to **Organization → Departments** 2. Click **Create Department** 3. Fill in the data: | Field | Description | |---|---| | **Name** | Department name (e.g., "Engineering") | | **Manager** | Department lead (optional) | | **Description** | Brief description (optional) | 4. Click **Create** ## Adding Teams to a Department 1. Open the department page 2. Click **Add Team** 3. Select teams from the list 4. Click **Save** A team can belong to only one department. If a team is already in another department, it will be moved. ## Deleting a Department When deleting a department, you must choose where to move teams and employees: 1. Open the department page 2. Click **Delete Department** 3. Select a department to move teams to 4. Confirm the action Teams cannot exist without a department. Upon deletion, all teams and employees will be moved to the selected department. --- ## Employee Management URL: https://pandev-metrics.com/docs/setup/organization/employees # Employee Management Manage your organization's members, invite new users, and configure access roles. ## Employee List The **Organization → Employees** page displays all users in your workspace with their current activity and statistics. ## Adding an Employee ### For SaaS Version 1. Go to **Organization → Employees** 2. Click **Add Employee** 3. Fill in the data: | Field | Description | |---|---| | **Email** | Email to send invitation | | **Access Rights** | Access level: Admin or Developer | | **Position** | Employee position | 4. Click **Send Invitation** The employee will receive an email with a registration link. After registration, they can install IDE plugins and start working. ### For On-Premise Version 1. Go to **Organization → Employees** 2. Click **Add Employee** 3. Fill in the data: | Field | Description | |---|---| | **Name** | First Name | | **Surname** | Last Name | | **Email** | Employee Email | | **Position** | Employee Position | | **New Password** | Login Password | | **Repeat Password** | Password Confirmation | 4. Click **Create** ## Roles and Access Rights | Role | Permissions | |---|---| | **Admin** | Full access: settings, billing, all data, user management | | **Developer** | View personal statistics and public team dashboards | - **Admin** — for CTOs, Tech Leads, Heads of Departments - **Developer** — for all development team members ## Employee Deactivation When an employee leaves the company: 1. Open the employee profile 2. Click **Deactivate** 3. Historical data will be preserved, but new data will not be collected Deactivated employees do not count towards license limits. --- ## Team Management URL: https://pandev-metrics.com/docs/setup/organization/teams # Team Management Teams are working groups within a department. Grouping employees into teams allows for structuring the organization and managing data access. ## Why use Teams? Teams allow you to: - **Group Developers** — unite employees by function (Backend, Frontend, Mobile, QA) - **Structure Department** — each team belongs to a department - **Assign Roles** — specify employee role within the team ## Creating a Team 1. Go to **Organization → Teams** 2. Click **Create Team** 3. Fill in the data: | Field | Description | |---|---| | **Team name** | Name of the team | | **Description** | Brief description (optional) | 4. Click **Create Team** The created team automatically belongs to the current department you are viewing. ## Role Management Roles are labels denoting an employee's function in a team (e.g., "Team Lead", "Developer", "QA"). Roles do not affect access rights. ### Creating a Role 1. Go to **Teams → Roles** 2. Click **Create Role** 3. Enter role name and description 4. Click **Create Role** ## Adding Members Employees are distributed into teams via the **Employees without a team** page: 1. Go to **Organization → Teams → Employees without a team** 2. The list of employees without a team is visible on the right 3. Drag and drop an employee onto the desired team 4. In the dialog that appears, select a role in the team 5. Click **Confirm** An employee can belong to only one team. When moving to another team, the employee leaves the current one. ## Deleting a Team 1. Go to **Organization → Teams** 2. Check the team checkbox 3. In the bottom panel, click **Delete** 4. Confirm action Employees are not removed from the organization — they are moved to the "Employees without a team" list. --- ## Jira Integration URL: https://pandev-metrics.com/docs/setup/task-trackers/jira # Jira Integration PanDev Metrics integration with Jira allows you to link development activity with tasks, automatically log time, and analyze team performance. ## Integration Features - **Link Code to Tasks** — automatic linking of commits and PRs to Jira issues - **Automatic Worklog** — recording time spent on tasks - **Sprint Analytics** — tracking team progress and velocity - **Task Metrics** — time in status, cycle time, lead time ## Supported Versions - Jira Cloud (Atlassian Cloud) - Jira Data Center / Server (On-Premise) ## Integration Setup ### For Jira Cloud #### Step 1: Create API Token 1. Log in to Atlassian with a service account 2. Go to [API tokens](https://id.atlassian.com/manage-profile/security/api-tokens) 3. Click **Create API token** 4. Enter token name (e.g., `pandev-metrics`) 5. Click **Create** and save the token It is recommended to use a separate Atlassian account for integration to distinguish automatic actions from personal ones. Please note: Jira has its own concept of a "Service Account", but here we mean a regular user account created specifically to be used as a service account. #### Step 2: Connect in PanDev Metrics 1. Go to **Settings → Integrations → Jira** 2. Select **Jira Cloud** 3. Enter: - **Jira URL:** `https://your-domain.atlassian.net` - **Email:** email of the service account - **API Token:** token from step 1 4. Click **Check Connection** and **Activate** --- ### For Jira Data Center / Server #### Step 1: Create Personal Access Token 1. Log in to Jira Server with a service account 2. Go to **Profile → Personal Access Tokens** 3. Click **Create token** 4. Enter name and expiration date 5. Click **Create** and save the token #### Step 2: Connect in PanDev Metrics 1. Go to **Settings → Integrations → Jira** 2. Select **Jira Server** 3. Enter: - **Jira URL:** Your server URL (e.g., `https://jira.company.local`) - **Personal Access Token:** token from step 1 4. Click **Check Connection** and **Activate** --- ### Step 3: Select Projects 1. Select Jira projects to monitor 2. Configure issue filters (optional) 3. Enable/disable automatic worklog 4. Save settings ## Tracked Metrics - **Cycle Time** — time from start to completion of a task - **Lead Time** — time from task creation to completion - **Time in Status** — how long the task remained in each status - **Throughput** — number of completed tasks per period - **Work in Progress** — number of tasks in progress simultaneously ## FAQ **How to link commits to Jira tasks?** Include the issue key in the commit message or branch name (e.g., `PROJECT-123`). **Does automatic worklog work?** Yes, PanDev Metrics can automatically log work time in Jira based on IDE activity. **Can integration be used without worklog?** Yes, worklog is an optional feature that can be disabled in settings. --- ## Yandex Tracker Integration URL: https://pandev-metrics.com/docs/setup/task-trackers/yandex-tracker # Yandex Tracker Integration PanDev Metrics integration with Yandex Tracker allows you to link development activity with tasks, automatically log time, and analyze team performance. ## Integration Features - **Link Code to Tasks** — automatic linking of commits and PRs to Tracker tasks - **Automatic Worklog** — recording time spent on tasks - **Sprint Analytics** — tracking team progress and velocity - **Queue Analytics** — understanding task flow and bottlenecks ## Integration Setup ### Step 1: Create a Service Account Create a separate Yandex account for integration or use an account with administrative rights in the organization. A separate account allows you to distinguish automatic actions from personal ones and simplifies access management. ### Step 2: Get OAuth Token 1. Go to [Create OAuth application page](https://oauth.yandex.ru/client/new) 2. Create a new application: - **Name:** `PanDev Metrics` - **Platform:** Web services 3. In **Permissions** section add: | Permission | Description | |---|---| | **tracker:read** | Read tasks and queues | | **tracker:write** | Write worklog | 4. Save the application 5. Get OAuth token by authorizing the application You can use **Yandex ID → App Passwords** to create a token with access to Tracker. ### Step 3: Get Organization ID 1. Open [Yandex Tracker](https://tracker.yandex.ru) 2. Go to **Administration → Organization settings** 3. Copy **Organization ID** from URL or settings ### Step 4: Connect in PanDev Metrics 1. Go to **Settings → Integrations → Yandex Tracker** 2. Enter: - **Organization ID:** ID from step 3 - **OAuth Token:** token from step 2 3. Click **Check Connection** and **Activate** ### Step 5: Select Queues 1. Select queues to monitor 2. Configure task field mapping (optional) 3. Enable/disable automatic worklog 4. Save settings ## Tracked Metrics - **Cycle Time** — time from start to completion of a task - **Lead Time** — time from task creation to completion - **Time in Status** — how long the task remained in each status - **Throughput** — number of completed tasks per period - **Workload Distribution** — tasks by developers ## FAQ **How to link commits to Yandex Tracker tasks?** Include the task key in the commit message or branch name (e.g., `QUEUE-123`). **Does automatic worklog work?** Yes, PanDev Metrics can automatically log work time in Tracker based on IDE activity. **Is a paid Yandex Tracker plan required?** The integration works with both free and paid plans. # On-Premises ## On-Premise Quick Start URL: https://pandev-metrics.com/docs/on-prem-getting-started # On-Premise Quick Start Guide for deploying PanDev Metrics on your own infrastructure. ## Installation Process ### 1. [Get License](https://pandev-metrics.com/docs/on-prem/licensing) Register and obtain your license key. ### 2. [System Requirements](https://pandev-metrics.com/docs/on-prem/system-requirements) Verify your infrastructure meets requirements. ### 3. [Architecture](https://pandev-metrics.com/docs/on-prem/architecture) Learn about system components. ### 4. [Installation](https://pandev-metrics.com/docs/on-prem/installation) Deploy PanDev Metrics using Docker Compose. ### 5. [First Login](https://pandev-metrics.com/docs/on-prem/first-login) Set up administrator account. ### 6. User Setup Choose one option: - [LDAP/AD Integration](https://pandev-metrics.com/docs/on-prem/ldap-integration) — for corporate authentication - [Create Users Manually](https://pandev-metrics.com/docs/on-prem/users-management) ### 7. [Plugin Setup](https://pandev-metrics.com/docs/setup/ide-plugins/overview) Install IDE extensions. ## Additional Resources - [Network and Ports](https://pandev-metrics.com/docs/on-prem/network-and-ports) — firewall setup ## Need Help? - 💬 **Support:** support@pandev.io - 📖 **Full Documentation:** [On-Premise Section](https://pandev-metrics.com/docs/on-prem/overview) --- ## Architecture URL: https://pandev-metrics.com/docs/on-prem/architecture # Architecture PanDev Metrics On-Premise consists of three main components deployed via Docker Compose. ```mermaid graph LR Plugins[IDE Plugins] --> Core[PanDev Metrics] Core --> DB[PostgreSQL] Core --> Workspace[Workspace] User[User] --> Workspace ``` ## Components ### PanDev Metrics Core system that: - Receives data from IDE plugins - Processes and aggregates metrics - Provides API for plugins **Default port:** `8080` ### Workspace (Dashboard) Web interface for system management: - View dashboards and analytics - Manage employees and teams - Configure Git and task tracker integrations - Reports and data export **Default port:** `80` All dashboards are integrated into the Workspace web interface — same as the SaaS version. Separate Grafana installation is not required. ### PostgreSQL Relational database for storing: - Processed metrics - User data - System configuration **Default port:** `5432` ### Dashboard Web interface for working with the system: - View dashboards and analytics - Manage employees and teams - Configure integrations with Git and task trackers - Reports and data export The Dashboard is integrated into PanDev Metrics and accessible via the same port `8080`. ## Data Flow ``` IDE plugins → PanDev Metrics → PostgreSQL → Dashboards ``` 1. **IDE plugins** collect development events and send to server 2. **PanDev Metrics** processes events and saves to database 3. **PostgreSQL** stores aggregated metrics 4. **Web interface** displays data on dashboards ## Network Diagram | Component | Port | Purpose | |-----------|------|---------| | PanDev Metrics | 8080 | Web interface, dashboards, API for plugins | | PostgreSQL | 5432 | Database (optional to expose) | Details: [Network and Ports](https://pandev-metrics.com/docs/on-prem/network-and-ports) --- ## First Login URL: https://pandev-metrics.com/docs/on-prem/first-login # First Login After installing PanDev Metrics, you need to complete the initial setup. ## Step 1: Open Web Interface Go to: ``` http://:8090 ``` You will see the company token input form. ## Step 2: Enter License Key 1. Enter the license key (company token) received during [registration](https://pandev-metrics.com/docs/on-prem/licensing) 2. Create administrator account: - **Email** - **Password** 3. Click **Start** ## Step 3: Sign In After license activation: 1. Enter administrator email and password 2. Click **Sign In** You will be redirected to the PanDev Metrics home page. ## Done! The system is configured and ready to use. ## Next Steps - **[LDAP Integration](https://pandev-metrics.com/docs/on-prem/ldap-integration)** — for Active Directory authentication - **[Create Users](https://pandev-metrics.com/docs/on-prem/users-management)** — for manual employee creation - **[Network Setup](https://pandev-metrics.com/docs/on-prem/network-and-ports)** — for port configuration --- ## Installation and Deployment URL: https://pandev-metrics.com/docs/on-prem/installation # Installation and Deployment Guide for deploying PanDev Metrics On-Premise using Docker Compose. ## Prerequisites - [System Requirements](https://pandev-metrics.com/docs/on-prem/system-requirements) are met - [License Key](https://pandev-metrics.com/docs/on-prem/licensing) is obtained - Docker and Docker Compose are installed ## Step 1: Download Distribution 1. Download the `pandev_metrics_latest.zip` archive from your dashboard 2. Extract the archive to a directory on your server ```bash unzip pandev_metrics_latest.zip -d /opt/pandev cd /opt/pandev ``` ## Step 2: Configure Environment Variables Edit the `.env` file: ```bash nano .env ``` ### Required Variables | Variable | Description | Example | |----------|-------------|---------| | `POSTGRES_DB` | Database name | `pandev_metrics` | | `POSTGRES_USER` | Database user | `pandev` | | `POSTGRES_PASSWORD` | Database password | `secure_password_123` | | `TZ` | Timezone | `Asia/Almaty` | Use strong passwords! Don't leave default values. ## Step 3: Start Services ```bash docker compose up -d ``` Check that all containers are running: ```bash docker compose ps ``` Expected result: ``` NAME STATUS pandev-metrics Up pandev-postgres Up ``` ## Step 4: Verify Open in browser: ``` http://:8090 ``` You will see the license key input form. ## Next Step Proceed to [First Login](https://pandev-metrics.com/docs/on-prem/first-login) to set up the administrator. --- ## LDAP/AD Integration URL: https://pandev-metrics.com/docs/on-prem/ldap-integration # LDAP/AD Integration Connect your corporate Active Directory or LDAP for employee authentication. ## Prerequisites - PanDev Metrics [installed](https://pandev-metrics.com/docs/on-prem/installation) and [configured](https://pandev-metrics.com/docs/on-prem/first-login) - Access to LDAP/AD server - Credentials for LDAP connection ## LDAP Configuration 1. Log in to PanDev Metrics as administrator 2. Go to **Settings** → **Basic Settings** → **Ldap** ## Connection Parameters ::: | Parameter | Description | |-----------|-------------| | **LDAP URL** | LDAP server address in format `ldap://hostname:port` or `ldaps://hostname:port` | | **LDAP search base** | Base DN for user search (e.g., `ou=Users,dc=company,dc=com`) | | **LDAP search attribute** | Search attribute: `mail` (email), `uid`, or `sAMAccountName` (for AD) | | **LDAP admin username** | DN of account with directory read permissions | | **Password** | LDAP admin account password | ## Saving Click **Test connection and save** to verify the connection. tip Verification The system will test the LDAP connection before saving. If connection fails, you'll see an error message. ::: ## Testing After saving: 1. Log out of the system 2. Log in with an LDAP account 3. Successful login confirms the integration works ## Result After configuring the integration: - Employees authenticate via corporate credentials - IDE plugins use the same credentials - New users are automatically created on first login ## Troubleshooting **Cannot connect to LDAP** - Check network accessibility of the LDAP server - Ensure port 389 (or 636 for LDAPS) is open **User not found** - Check LDAP search attribute - Ensure the user exists in the specified search base --- ## License Registration URL: https://pandev-metrics.com/docs/on-prem/licensing # License Registration To use PanDev Metrics On-Premise, you need to obtain a license key. ## How to Get a License Contact us to get your license key: - **Email:** [support@pandev.io](mailto:support@pandev.io) After contacting us, we will: 1. Discuss your requirements and usage volume 2. Select an appropriate plan 3. Issue your license key (company token) The license key is required for the first launch of PanDev Metrics. ## Entering the Key The key is entered during the first login to PanDev Metrics: 1. Start PanDev Metrics 2. Open the web interface (default port 8080) 3. Enter the license key in the form 4. Create an administrator account Details: [First Login](https://pandev-metrics.com/docs/on-prem/first-login) ## FAQ **How to renew the license?** Contact us in advance — we'll issue a new key or extend the current one. **Can I transfer the license to another server?** Yes, the license is tied to the company, not the server. **Is there a trial period?** Yes, we provide a trial license for testing. Contact us! **What if the key doesn't work?** Contact support: support@pandev.io --- ## Network and Ports URL: https://pandev-metrics.com/docs/on-prem/network-and-ports # Network and Ports Network requirements for PanDev Metrics On-Premise. ## Ports | Port | Service | Purpose | |------|---------|---------| | **8090** | Workspace | Dashboard with analytics and reports | | **8080** | PanDev Metrics | API for IDE plugins | | **5432** | PostgreSQL | Database (optional) | ## External Network Access ### Port 8080 (PanDev Metrics) **Must be open** if: - Developers work remotely - IDE plugins need to send data from outside the corporate network If port 8080 is closed to external network — data won't be lost. IDE plugins accumulate events locally and send them when connected to VPN or internal network. ### Port 5432 (PostgreSQL) **Not recommended to expose**: - Used for internal service communication - Open only if direct DB access is needed (e.g., for BI tools) ## Proxy and Load Balancing ### Nginx Reverse Proxy Example configuration: ```nginx server { listen 443 ssl; server_name metrics.company.com; location / { proxy_pass http://localhost:8080; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } } ``` ### Proxy Environment Variables If the server is behind a corporate proxy: | Variable | Description | |----------|-------------| | `HTTP_PROXY` | HTTP proxy address | | `HTTPS_PROXY` | HTTPS proxy address | | `NO_PROXY` | Proxy exclusions | ## Firewall Rules Minimum rules for incoming traffic: ```bash # PanDev Metrics API and web interface iptables -A INPUT -p tcp --dport 8080 -j ACCEPT ``` --- ## On-Premise Overview URL: https://pandev-metrics.com/docs/on-prem/overview # On-Premise Overview PanDev Metrics On-Premise is a self-hosted version of the platform for deployment on your own infrastructure. ## SaaS vs On-Premise | Feature | SaaS | On-Premise | |---------|------|------------| | **Infrastructure** | PanDev Cloud | Your servers | | **Updates** | Automatic | Manual | | **Data** | Stored in cloud | Stored on-site | | **Setup** | Minimal | Requires administration | | **LDAP/AD** | No | Yes | ## When to choose On-Premise? - **Data must stay on-premise** — corporate security requirements - **LDAP/AD integration** — authentication via Active Directory - **Customization** — custom infrastructure settings ## System Components On-Premise version includes: - **PanDev Metrics** — core system for data collection, processing, and dashboard visualization - **PostgreSQL** — database for metrics storage - **IDE Plugins** — extensions for collecting metrics from code editors ### Supported IDEs and Editors | IDE / Editor | Status | |--------------|--------| | JetBrains (IntelliJ IDEA, WebStorm, PyCharm, etc.) | ✅ Supported | | VS Code | ✅ Supported | | Cursor | ✅ Supported | | Windsurf | ✅ Supported | Details: [Plugin Setup](https://pandev-metrics.com/docs/setup/ide-plugins/overview) All dashboards and analytics are integrated into the PanDev Metrics web interface — same as the SaaS version. ## Installation Process 1. **[Get License](https://pandev-metrics.com/docs/on-prem/licensing)** — registration and license key 2. **[System Requirements](https://pandev-metrics.com/docs/on-prem/system-requirements)** — infrastructure check 3. **[Installation](https://pandev-metrics.com/docs/on-prem/installation)** — Docker Compose deployment 4. **[First Login](https://pandev-metrics.com/docs/on-prem/first-login)** — administrator setup 5. **[LDAP Setup](https://pandev-metrics.com/docs/on-prem/ldap-integration)** or **[Create Users](https://pandev-metrics.com/docs/on-prem/users-management)** ## Support - **Email:** support@pandev.io - **Documentation:** pandev-metrics.com/docs --- ## Changelog URL: https://pandev-metrics.com/docs/on-prem/releases # PanDev Metrics Changelog Latest updates to PanDev Metrics, the self-hosted development analytics platform. ## 2.5.0 (2026-04-06) ### New Features - **Role-Based Access Control (RBAC)**: Introduced a flexible role system to manage permissions: - **Owner** — full control over workspace and settings - **Maintainer** — manage data and support workflows - **Viewer** — read-only access to analytics Clear separation of permissions improves security, eliminates unnecessary access, and streamlines team collaboration. - **Updated Navigation**: Improved navigation for faster access to key data and features. - **Responsive UI**: Full adaptation across different screen sizes for a smooth experience on any device. - **Activity Quick View Panel**: Bottom panel for quick access to recent activity. ### Improvements - **Access Management**: More transparent and user-friendly permission handling. ## 2.4.0 (2026-02-23) ### New Features - **AI Activity Analytics**: New analytics for AI activity in the terminal and LLM CLIs. - **Task list dashboard**: A new dashboard with a list of all current tasks. ### Bug Fixes - **General Improvements**: Numerous improvements and fixes related to performance and UI/UX. ## 2.2.0 (2026-02-03) ### New Features - **Browser Plugins Release**: Extensions for major browsers are now available. Activity can now be tracked in browsers. [Learn more](https://pandev-metrics.com/docs/setup/browser-extensions/overview) - **CLI Plugins Release**: New plugins to extend CLI functionality. Track activity in the terminal and LLM CLIs like Codex and Claude. [Learn more](https://pandev-metrics.com/docs/setup/cli/overview) - **CLI Dashboard**: Collection of information from the terminal and LLM CLIs. - **Browser Widget**: Dashboard widget for analytics demonstration. - **Improved Employee Calendar**: Better UI and functionality for tracking availability. - **UI Improvements**: A major overhaul of the user interface for better usability. - **Team Analytics Optimization**: Significant redesign of the team analytics page for better user experience. - **Performance Indicators Refinement**: Expanded metric usage across different views (teams, engineers, roles). Added **Delivery Index**. [Learn more](https://pandev-metrics.com/docs/user-guide/indicators) - **No-Integrations Mode**: Ability to run the system without external Git or issue tracker integrations. - **LDAPS Support**: Secure LDAP connections over SSL/TLS are now supported for enterprise directory integration. ### Bug Fixes - **General Improvements**: Numerous improvements and fixes related to performance and UI/UX. --- ## System Requirements URL: https://pandev-metrics.com/docs/on-prem/system-requirements # System Requirements ## System Components PanDev Metrics On-Premise includes: - **PanDev Metrics** — core system with web interface and dashboards - **PostgreSQL** — database - **IDE Plugins** — extensions for collecting metrics from code editors ## Hardware Requirements ### Frontend (Web UI) - **CPU:** 0.5 cores minimum - **RAM:** 256–512 MB minimum ### Backend - **CPU:** 1–2 cores - **RAM:** 1–2 GB ### Database (PostgreSQL) - **CPU:** 3–8 cores - **RAM:** 4–16 GB - **Disk:** 50–100 GB Horizontal scaling is not recommended. The system is designed to run as a single instance. ### Supported IDEs | IDE / Editor | Status | |--------------|--------| | JetBrains (IntelliJ IDEA, WebStorm, PyCharm, etc.) | ✅ Supported | | VS Code | ✅ Supported | | Cursor | ✅ Supported | | Windsurf | ✅ Supported | All server components can be deployed on a single virtual machine. ## OS Requirements **Supported OS:** - Linux Debian 10+ - Ubuntu 20+ - Other Linux distributions PanDev Metrics **does not work** on ARM processors (including Apple Silicon). ## CPU Requirements The virtualization system must support the following CPU instructions: ``` CX8, CMOV, FXSR, MMX, SSE, SSE2, SSE3, SSSE3, SSE4_1, SSE4_2, POPCNT, LZCNT, AVX, AVX2, BMI1, BMI2, FMA ``` ## Virtualization Settings If PanDev Metrics doesn't start, check CPU settings in your virtualization platform: | Platform | Solution | |----------|----------| | **Proxmox VE** | CPU: set `host` in VM config | | **VMware ESXi** | VM Compatibility 7.0+, CPU passthrough | | **VirtualBox** | VT-x, Nested VT-x, PAE/NX. Command: `VBoxManage modifyvm "VM" --cpu-profile host` | | **Hyper-V** | VM Generation 2, disable CPU Compatibility Mode | | **XCP-ng/XenServer** | CPU mode: `host-passthrough` | | **QEMU** | Specify `cpu host` or add flags `+avx2,+fma,...` | ## CPU Instructions Check Run inside VM: ```bash lscpu | grep -E "avx|fma|sse" ``` Or: ```bash cat /proc/cpuinfo | grep flags ``` ## Software Requirements - Docker 20.10+ - Docker Compose 3.0+ --- ## User Management URL: https://pandev-metrics.com/docs/on-prem/users-management # User Management Employee authentication in PanDev Metrics and IDE plugins. ## Authentication Methods ### With LDAP/AD Integration If [LDAP integration is configured](https://pandev-metrics.com/docs/on-prem/ldap-integration), employees use their **corporate credentials** for: - Logging into PanDev Metrics dashboard - Authenticating in IDE plugins (JetBrains, VS Code, Cursor, Windsurf) After LDAP integration, employees simply use their regular login and password — the same ones used for corporate systems. ### Without LDAP Integration If LDAP is not used, the administrator creates accounts manually: - LDAP/AD is not used in the company - Need to add external contractors - System testing ## Step 1: Open Employees Section 1. Sign in to PanDev Metrics as administrator 2. Go to **Organization → Employees** ## Step 2: Create User 1. Click **Create Employee** 2. Fill in the data: | Field | Description | |-------|-------------| | **First Name** | Employee's first name | | **Last Name** | Employee's last name | | **Email** | Email for authentication | | **Position** | Position in company | | **New Password** | Login password | | **Confirm Password** | Password confirmation | 3. Click **Save** ## Step 3: Share Credentials After creating the account: - Send the employee their login (email) and password - The employee uses these credentials to authenticate in the IDE plugin ## User Roles | Role | Description | |------|-------------| | **Admin** | Full access: settings, billing, all data, user management | | **Developer** | View personal statistics and public dashboards | # User Guide ## Key Indicators URL: https://pandev-metrics.com/docs/user-guide/indicators # Key Indicators This section describes the main indicators displayed on the dashboard, helping you assess efficiency and work dynamics. ## Activity Time **Activity Time** is the total work activity time recorded by the system. The indicator can display data for an entire team or for a specific engineer. This is a comprehensive metric that includes all types of work activity, not just coding. ### What is tracked * **Coding** — writing and editing code in the IDE (typing, navigation, refactoring). * **Browsing** — working with the browser: reading documentation, searching for solutions, studying resources. * **Database** — interacting with databases through built-in IDE tools or external clients. * **Terminal** — terminal activity: running commands, working with git, executing scripts. * **AI** — using AI assistants (Copilot, ChatGPT, Claude, etc.) for code generation or getting answers. Idle time is automatically excluded — only active interaction with tools is counted. ### Displayed data * **Format**: Hours:Minutes (e.g., `181:09`). * **Trend**: Percentage change compared to the previous period (e.g., `↓ 11.8%`). * **Breakdown**: Below the main value, a detailed breakdown by activity category is shown with time for each. ## Focus Time **Focus Time** measures the ability to concentrate on tasks without distractions. The higher the focus time percentage, the fewer task switches and external interruptions. ### Concentration levels * **Focus** — continuous work on a task without distractions for a certain period. * **DeepFocus** — even deeper concentration: long sessions without any switching. Shows the ability to immerse in complex tasks. ### Displayed data * **Percentage**: The share of focus time relative to total activity time (e.g., `65.5%`). * **Absolute Value**: Focus time in hours and minutes (e.g., `118:42`). * **Trend**: Dynamics compared to the previous period. * **Breakdown**: DeepFocus and Focus time shown separately for analyzing concentration depth. ## Planning Accuracy **Planning Accuracy** shows the difference between time planned in the task tracker and actual time recorded from activity. * **Coefficient**: * `1.0` — Ideal planning. * `< 1.0` — Underestimation (task took longer than planned). * `> 1.0` — Overestimation (task was completed faster than planned). * **Visual Scale**: A bar showing the deviation from the ideal value. * **Breakdown**: Shows planned hours (Plan) vs actual hours spent (Fact). ## Productivity **Productivity** shows how close an engineer is to the target pure coding activity time. The baseline target is **4 hours** of pure coding per day. * **Index**: Percentage value relative to the target 4 hours (e.g., `132.1%` means the engineer exceeded the target). * **Graph**: A sparkline graph showing the dynamics over the selected period. * **Trend**: Change compared to the previous period (e.g., `↑ 5.4%`). * **Productivity Time**: Actual productive time in hours. ## Delivery Index **Delivery Index** shows the proportion of time spent in a git branch that resulted in changes included in the merge request over the selected period. The system tracks time spent on each file. * **Delivery**: Time spent on files that were eventually included in the Merge Request. * **Discovery**: Time spent on files that were NOT included in the Merge Request. The index represents the ratio of Delivery time to total time. --- ## Solution Architecture URL: https://pandev-metrics.com/docs/v1/how-it-works/architecture # Solution Architecture PanDev Metrics relies on a modular architecture with a central server that aggregates, processes, and exposes engineering telemetry coming from IDE plugins and external systems. ## High-Level Overview The architecture is organised into several logical blocks connected through REST APIs and direct integrations. The **PanDev Metrics Server** sits at the centre: it ingests events from plugins (IDE, browser, and other extensions), communicates with systems such as Jira, GitLab, and LDAP/Active Directory, stores the processed data in PostgreSQL, and publishes it for visualisation in Grafana. ## Architecture Diagram ``` ┌─────────────────────────────────────────────────────────────────┐ │ LDAP/Active Directory │ │ (Auth) │ └─────────────────────────┬───────────────────────────────────────┘ │ ┌─────────────────────────▼───────────────────────────────────────┐ │ PanDev Metrics Server │ │ (Core) │ │ ┌─────────────────┐ ┌─────────────────┐ ┌─────────────────┐ │ │ │ Plugin Intake │ │ Aggregation & │ │ Integrations │ │ │ │ │ │ Processing │ │ (Jira/GitLab) │ │ │ └─────────────────┘ └─────────────────┘ └─────────────────┘ │ └─────────────────────────┬───────────────────────────────────────┘ │ ┌─────────────────────────▼───────────────────────────────────────┐ │ PostgreSQL │ │ (Storage) │ └─────────────────────────┬───────────────────────────────────────┘ │ ┌─────────────────────────▼───────────────────────────────────────┐ │ Grafana │ │ (Visualisation) │ └─────────────────────────────────────────────────────────────────┘ ┌─────────────────┐ ┌─────────────────┐ ┌─────────────────┐ │ VS Code │ │ Chromium │ │ JetBrains │ │ Plugin │ │ Plugin │ │ Plugin │ └─────────────────┘ └─────────────────┘ └─────────────────┘ │ │ │ └───────────────────────┼───────────────────────┘ │ ┌─────────────────┐ │ PanDev Metrics │ │ Server │ └─────────────────┘ │ ┌─────────────────┐ │ PostgreSQL │ │ Database │ └─────────────────┘ ``` ## System Components ### 1. Plugin Layer (VS Code, Chromium, JetBrains) These plugins record day-to-day developer activity: #### VS Code Plugin for Developers - Tracks which files, branches, and repositories were touched in Visual Studio Code - Measures time spent editing within the IDE #### Chromium Plugin for Developers - Captures which web resources developers use during the day: documentation, testing tools, internal services - Complements IDE telemetry with browser context #### JetBrains IDEs Plugin - Collects analogous metrics for the JetBrains suite (IntelliJ IDEA, PyCharm, WebStorm, Android Studio, etc.) - Records coding time, project switches, and overall IDE activity **How plugins operate:** - Accumulate raw events locally - Periodically batch and send them to the PanDev Metrics Server - Work quietly in the background without disrupting the developer ### 2. PanDev Metrics Server (Core) The core service receives data from every plugin and turns it into actionable analytics: - Normalises and enriches incoming events - Links data to users and projects via company directories (LDAP/AD) - Persists everything in PostgreSQL for downstream analysis The server also hosts the management UI where administrators configure organisations, teams, and integrations. ### 3. PostgreSQL Storage All historical telemetry lands in PostgreSQL: - Structured tables store time tracking, code activity, review metrics, and more - The schema is optimised for analytics queries and reporting - Acts as the single source of truth for both Grafana dashboards and API clients ### 4. Grafana (Dashboards) Grafana is the primary visual layer for PanDev Metrics: - Offers curated dashboards with the most important KPIs - Supports ad-hoc exploration, filtering, and time range selection - Removes the need for writing SQL to inspect the data ### 5. Authentication with LDAP/Active Directory - PanDev Metrics integrates with corporate directories for SSO - User roles and permissions are managed centrally - Audit logs cover sign-ins and privileged actions ### 6. Integration Modules (Jira and GitLab) #### Jira Integration Module - Pushes processed time-tracking data directly into Jira issues - Adds contextual comments with diagnostics from PanDev Metrics - Operates **one way** (server → Jira); the platform does not pull sensitive data back #### GitLab Integration Module - Sends time-tracking and review statistics into GitLab merge requests - Gives engineering managers instant visibility into effort and progress - Is also **one way** (server → GitLab) #### Why integrations matter Integrations augment the native tracking capabilities of Jira and GitLab, aligning planning data with the actual effort captured by PanDev Metrics. Managers see the real time spent, compare it with estimates, and adjust plans accordingly. ## Data Flow 1. **Plugin capture** – IDE and browser plugins collect granular telemetry. 2. **Server ingestion** – the PanDev Metrics Server receives the batches, stores them in PostgreSQL, and publishes enriched metrics to Jira and GitLab. 3. **Storage** – PostgreSQL keeps the full history for dashboards and reporting. 4. **Visualisation** – Grafana reads the database and turns the metrics into charts and diagnostics views. ## Key Architectural Benefits ### Scalability - Add new plugins or integrations without reworking the core - Modular design allows incremental feature growth ### Convenience - A single server acts as the collection and processing hub - No need to maintain multiple disconnected systems ### Transparency - All metrics live in one database - Dashboards can be consumed from Grafana or any BI tool of choice ### Security - Authentication and authorisation via LDAP/AD - Sensitive business logic stays on the server side ## Putting It All Together This architecture enables PanDev Metrics to: - **Collect objective telemetry** through plugins - **Store and process metrics centrally** in PostgreSQL - **Present clear insight** to managers and engineers through Grafana When someone opens PanDev Metrics they see a consolidated view of time, tasks, branches, reviews, and any other indicators required to plan and assess performance. The interactions between plugins, external services (Jira, GitLab), the PanDev Metrics Server, PostgreSQL, and Grafana deliver accurate, transparent analytics for the entire organisation. --- ## Chrome Telemetry URL: https://pandev-metrics.com/docs/v1/how-it-works/data-collection/chrome # Chrome Telemetry PanDev Metrics uses a Chrome extension to capture activity within corporate web tools. Only whitelisted work domains are tracked. - ❌ **No screenshots**. - ❌ **No personal browsing**. - ✅ **Whitelisted domains only**. - ✅ **Users can review the tracked domains.** ## Whitelist-first Design Data is collected solely for domains added to the whitelist in the admin console. This keeps personal browsing out of scope and concentrates on corporate tools. Security measures: - Track only approved domains. - Provide visibility into the whitelist for every user. - Exclude personal content entirely. - Focus on corporate systems. ## Event Structure Example payload: ```json [ { "title": "Main settings", "url": "https://pandev-metrics-test.pandev.io/backoffice/integrations", "tabId": 2020798390, "timestamp": 1755324391, "lastAccessedTimestamp": 1755323941, "favIconUrl": "https://pandev-metrics-test.pandev.io/backoffice/images/favicon.ico", "windowId": 2020798387 } ] ``` Field reference: | Field | Type | Description | |-------|------|-------------| | `title` | String | Browser tab title. | | `url` | String | Page URL (must belong to the whitelist). | | `tabId` | Integer | Unique tab identifier. | | `timestamp` | Integer | When the tab was opened/activated. | | `lastAccessedTimestamp` | Integer | Last time the tab was in focus. | | `favIconUrl` | String | Site favicon URL. | | `windowId` | Integer | Browser window identifier. | ## Managing the Whitelist Suggested entries: ``` git.yourdomain.com # Corporate Git (GitLab/GitHub) jira.yourdomain.com # Jira confluence.yourdomain.com # Documentation jenkins.yourdomain.com # CI/CD monitoring.yourdomain.com # Monitoring ``` Examples: - **Git hosting:** `gitlab.company.com`, `github.company.com`. - **Project management:** `jira.company.com`, `asana.company.com`. - **Documentation:** `confluence.company.com`, `notion.company.com`. - **CI/CD:** `jenkins.company.com`, `gitlab-ci.company.com`. - **Monitoring:** `grafana.company.com`, `kibana.company.com`. Users can inspect the whitelist to understand exactly where telemetry is gathered—and where it is not. --- ## IDE Telemetry URL: https://pandev-metrics.com/docs/v1/how-it-works/data-collection/ide # IDE Telemetry PanDev Metrics captures IDE activity through dedicated plugins, delivering precise insight into work on corporate projects. Only work-related IDE activity is collected. - ❌ **No screenshots**. - ❌ **No personal projects** – telemetry is limited to approved Git repositories. - ✅ **IDE-only** – other applications stay out of scope. - ✅ **Transparent** – developers can review the data being shared. ## Plugin Overview See the [Plugins](https://pandev-metrics.com/docs/intro) section for installation and setup guides: - **IntelliJ IDEA plugin** – deep integration with JVM projects. - **VS Code plugin** – broad language coverage. - **Other IDEs** – extensible architecture for additional tools. ## Event Structure Example payload: ```json [ { "timestamp": 1742567259.3460, "project": "pandev-metrics-partners-service", "module": "merchant-service", "language": "JAVA", "gitPath": "pandev/metrics/services/pandev-metrics-partners-service", "gitBranch": "hotfix/PDM-418", "fileName": "CompanyRepository.java", "ide": "IntelliJ IDEA 2024.1.3", "lineCount": 189, "lineNumber": 153, "cursorPosition": 52 } ] ``` Field reference: | Field | Type | Description | |-------|------|-------------| | `timestamp` | Float | Unix timestamp of the event. | | `project` | String | Corporate project name. | | `module` | String | Module within the project. | | `language` | String | Programming language (JAVA, PYTHON, etc.). | | `gitPath` | String | Path inside the corporate Git repository. | | `gitBranch` | String | Active Git branch. | | `fileName` | String | File currently in focus. | | `ide` | String | IDE name and version. | | `lineCount` | Integer | Total number of lines in the file. | | `lineNumber` | Integer | Line number of the caret. | | `cursorPosition` | Integer | Position of the caret within the line. | ## Task Matching Plugins automatically relate IDE activity to tracker issues by inspecting branch names. How it works: 1. Track the active Git branch. 2. Apply regex patterns (`TASK-23`, `feature/PDM-1052`, etc.). 3. Lookup the corresponding issue in Jira/GitLab if integrations are enabled. 4. Attribute all activity in the branch to the identified task. Benefits: - Automatic linkage without manual input. - Accurate time accounting per task. - Full transparency for leads and managers. - Better effort estimation for future work. ## Offline Mode & Reliability Plugins guarantee delivery even when developers work offline. ### Continuous Collection - Operate without internet access. - Store events in a local cache. - Run unobtrusively in the background. ### Automatic Sync - Monitor connectivity to PanDev Metrics Core. - Sync cached events as soon as the server is reachable. - Send data in batches to minimise overhead. ### Reliability Guarantees - Local cache retained until delivery is confirmed. - Automatic retries on failure. - Integrity checks to validate successful transfer. - Visible sync status for developers. Example flow: ``` Day 1 (offline): - 09:00 Opened UserService.java - 10:30 Working in branch feature/auth - 12:00 Commit created - All events cached locally Day 2 (online): - 09:00 Connection restored - 09:01 Plugin uploads cached data - 09:02 Delivery confirmed ``` Result: Data is never lost, and teams get a complete picture of engineering activity regardless of network conditions. --- ## Data Collection Overview URL: https://pandev-metrics.com/docs/v1/how-it-works/data-collection/overview # Data Collection Overview PanDev Metrics relies on an event-driven architecture to capture developer activity inside IDEs and the browser. The focus is strictly on corporate projects—personal activity remains private. Only work-related data is collected. - ❌ **No screenshots** – the system never records the screen. - ❌ **No personal tracking** – non-work activity is ignored. - ❌ **No personal projects** – only whitelisted corporate repositories. - ✅ **IDE and Chrome only** – other apps stay invisible. - ✅ **Full transparency** – users can always see what is captured. ## Collection Principles ### 1. Event-driven (no timers) There are no ticking timers. Data is generated only when real activity occurs (typing, navigation, etc.). Mathematical models derive active time between events. How it works: - Events fire exclusively on real interactions. - Inter-event gaps determine active time. - No background timers, no idle polling. ### 2. Zero-click automation Engineers install the plugin once and sign in once. The entire collection pipeline runs automatically afterwards—no repeated logins or manual triggers. Benefits: - One-time setup. - Background operation. - Persistent sessions. - Zero disruption of daily work. ### 3. Online/offline support Plugins cache events locally whenever the server is unreachable. As soon as connectivity returns, cached data syncs automatically. Mechanics: - Local storage on the developer’s machine. - Automatic retries until delivery succeeds. - Visibility into sync status. ### 4. Straightforward architecture Plugins send telemetry to the on-premises PanDev Metrics Core, which stores everything in PostgreSQL for downstream analytics. ## System Architecture ``` ┌─────────────────┐ ┌─────────────────┐ ┌─────────────────┐ │ IDE Plugin │ │ Chrome Ext │ │ Git Hook │ │ (Events) │ │ (Events) │ │ (Events) │ └─────────────────┘ └─────────────────┘ └─────────────────┘ │ │ │ └───────────────────────┼───────────────────────┘ │ ┌────────────────────────┐ │ PanDev Metrics Server │ │ (Event Intake) │ └────────────────────────┘ │ ┌────────────────────────┐ │ Data Processing │ └────────────────────────┘ │ ┌────────────────────────┐ │ PostgreSQL DB │ └────────────────────────┘ │ ┌────────────────────────┐ │ Analytics & │ │ Reports │ └────────────────────────┘ ``` ## What Happens Next 1. **Storage & enrichment** – events are normalised, deduplicated, and enriched with metadata. 2. **Correlation** – IDE, Git, and task-tracker data are linked for context. 3. **Analytics** – metrics feed dashboards, anomaly detection, and ML models. 4. **Insight delivery** – recommendations and alerts surface improvement opportunities. ## Security & Privacy ### Personalised identifiers - Events are tied to known developers for accurate analytics. - IDs remain internal; there is no exposure outside the organisation. ### Encryption - TLS protects data in transit. - Local caches are encrypted at rest. - Access is only possible through authenticated APIs. ### Access control - Role-based permissions. - Audit logs for every sensitive operation. - Compliance with corporate security policies. ## Outcome PanDev Metrics’ event-driven approach ensures: - **Precise telemetry** limited to corporate assets. - **Robust privacy** with no intrusion into personal life. - **Powerful analytics** by combining IDE, Jira, and Git data. - **Actionable insight** through AI-assisted recommendations. - **Scalability** for engineering teams of any size. --- ## What We Collect URL: https://pandev-metrics.com/docs/v1/how-it-works/data-collection/what-we-collect # What We Collect PanDev Metrics gathers multiple classes of engineering data to analyse and refine delivery processes. ## Collected Metrics ### 1. Code Metrics - **Lines of code** – volume of code authored - **Complexity** – cyclomatic complexity, nesting depth - **Test coverage** – percentage of code covered by automated tests - **Duplication** – repeated fragments or copy‑paste blocks - **Technical debt** – code issues that require remediation ### 2. Time Metrics - **Active development time** – focused coding and editing - **Debug time** – effort spent diagnosing and fixing defects - **Refactoring time** – improving existing code without changing behaviour - **Code review time** – participation in peer reviews ### 3. Collaboration Metrics - **Commits** – frequency and size of commits - **Code reviews** – volume and depth of review activity - **Collaboration** – handovers and pair work between developers - **Communication** – conversations in comments and issues ### 4. Quality Metrics - **Defects** – number and type of bugs discovered - **Fixes** – turnaround time for bug resolution - **Regressions** – recurring issues that reappear after being closed - **Performance** – build and test execution times ## Collection Channels ### IDE Plugins - **IntelliJ IDEA** – JetBrains plugin family - **Visual Studio Code** – VS Code extension - **Eclipse** – Eclipse IDE plugin ### System Integrations - **Git** – commit and branch analytics - **GitHub/GitLab** – pull requests, merge requests, and issue context - **CI/CD** – build and test pipelines - **Jira/Trello** – synchronisation with work items and roadmaps ### Collection Agents - **Local agents** – run on developer machines - **Server agents** – aggregate data on dedicated infrastructure - **Cloud agents** – operate inside hosted environments ## Security and Privacy ### Data Anonymisation - Personally identifiable information is stripped or anonymised - Metrics are linked to pseudonymous identifiers - Individual developers cannot be reverse engineered ### Encryption - TLS/SSL protects data in transit - Local caches are encrypted at rest - Access is granted only through authenticated APIs ### Access Control - Role-based permissions govern who can view specific datasets - Every operation is captured in audit logs - Data deletion on request is supported ## Storage Options ### Local Storage - Agents cache data locally on workstations - Periodic synchronisation pushes updates to the server - Offline mode keeps working even without connectivity ### Cloud Storage - Secure backups in the cloud - Automated backup and disaster recovery - High availability and elasticity ## Data Processing ### Aggregation - Metrics are grouped by team, project, and timeframe - Time-series windows power trend analysis - Filtering and grouping expose the signal that matters ### Analysis - Statistical models identify patterns in the data - Machine learning highlights anomalous behaviour - Outlier detection flags unusual trends worth investigating ### Visualisation - Dashboards surface the KPIs that matter most - Charts and diagrams reveal trends over time - Data export enables further processing in external tools --- ## How the Platform Works URL: https://pandev-metrics.com/docs/v1/how-it-works/how-it-works # How the Platform Works PanDev Metrics is an end-to-end system for capturing, processing, and analysing software delivery data. The sections below describe how the platform operates in practice. ## Operating Principle ### 1. Data Capture When engineers work in their IDE or browser on corporate projects, the platform generates event payloads with precise activity details. Every action produces a JSON event that records the project, file, cursor position, and timestamp. Only corporate repositories are observed—personal activity stays private. ### 2. Processing Events are processed on the server with mathematical models and AI. PanDev Metrics fuses data coming from IDE plugins, Jira, and Git to build richer analytics than any single source can provide. ### 3. Secure Storage Structured records are stored in a high-performance analytical database (ClickHouse) with references to specific developers so productivity insights stay accurate. ### 4. Visualisation Dashboards and advanced charts are generated from the processed data. The platform produces intelligent insights, automatic recommendations, and forecasts that guide better decision-making. ## Detailed Workflow ### Phase 1: Installation and Configuration 1. **Server deployment** – run PanDev Metrics on your infrastructure or in the cloud. 2. **Plugin rollout** – developers install the IDE extensions (VS Code, JetBrains). 3. **Configuration** – define data collection rules and connect existing systems. ### Phase 2: Data Capture #### Automatic IDE Collection - **Activity tracking** – plugins capture time spent working with files, branches, and tasks. - **Cursor positioning** – detailed cursor telemetry inside each file. - **Process monitoring** – measure focus per project, module, or activity. #### External Integrations - **Jira** – automatically map time to issues and work items. - **GitLab/GitHub** – analyse commits, merge requests, and repository activity. - **LDAP/AD** – connect to corporate identity providers. #### Offline Mode - Cache data locally whenever a machine is offline. - Resynchronise automatically once connectivity is restored. - Guarantee uninterrupted metric collection. ### Phase 3: Processing and Analytics #### Data Organisation - **Filtering** – separate valuable signal from background noise. - **Aggregation** – group metrics by project, team, and time range. - **Normalisation** – bring events into a consistent schema. #### Insight Generation - **Statistical analysis** – spotlight trends and anomalies. - **Machine learning** – detect recurring work patterns automatically. - **Correlation analysis** – uncover links between different metrics. ### Phase 4: Storage and Security #### Secure Storage - **Personalised telemetry** – retain developer identifiers for precise productivity insights. - **Encryption** – protect data both in transit and at rest. - **Access control** – configurable permissions for every role. #### Compliance - **GDPR** – adhere to European data protection regulations. - **On-premises** – deploy entirely within your infrastructure if required. - **Audit** – log every operation on sensitive data. ### Phase 5: Visualisation and Reporting #### Interactive Dashboards - **Grafana integration** – fully configurable dashboards with charts and KPIs. - **Real-time updates** – information refreshes live as new data arrives. - **Customisation** – adapt the views to each team’s needs. #### Automated Reporting - **Weekly/monthly reports** – scheduled reports delivered automatically. - **Alerts** – notifications when critical metrics change. - **Data export** – download datasets for further analysis. ## Technical Characteristics ### Scalability - **Horizontal scale** – add more servers as data volumes grow. - **Big data processing** – efficient pipelines for large datasets. - **High availability** – redundant services keep the platform online. ### Performance - **Lightweight plugins** – negligible footprint inside IDEs. - **Fast processing** – optimised algorithms for low-latency analytics. - **Caching** – speed up access to frequently used data. ### Integrations - **API** – RESTful API for integrating external systems. - **Webhooks** – push notifications into other tools. - **Plugins** – extensible architecture for new data sources. ## User Experience ### For Developers - **Invisible tooling** – plugins run in the background and stay out of the way. - **Transparency** – engineers can review their own metrics. - **Motivation** – visualise progress and achievements over time. ### For Managers - **Ease of use** – intuitive dashboards, no SQL required. - **Flexibility** – tailor views for specific workflows. - **Drill-down** – move from aggregate KPIs to detailed analysis in seconds. ### For Executives - **Strategic perspective** – high-level trends and portfolio health. - **Decision support** – data-backed insights for planning and investment. - **ROI tracking** – measurable results from process improvements. ## Outcome After completing the cycle, PanDev Metrics delivers: - **Objective performance metrics** for every team. - **Identified bottlenecks** in development workflows. - **Trends and patterns** across the organisation. - **Actionable recommendations** for optimisation. - **Measured improvements** in delivery speed and quality. - **Automated reporting** for all stakeholder levels. --- ## PanDev Metrics Overview URL: https://pandev-metrics.com/docs/v1/how-it-works/overview # PanDev Metrics Overview PanDev Metrics is an engineering analytics platform that unifies IDE, Git, and task-tracker data into actionable insights for development teams. ## What Is PanDev Metrics? The platform collects and analyses development data to surface insights about: - **Delivery performance** — coding throughput and time to complete work - **Code quality** — complexity metrics, test coverage, and technical debt - **Team collaboration** — workload balance and cross-team interactions - **Process health** — code review cadence, commit frequency, working patterns --- ## Deployment Options | | Cloud (SaaS) | On-Premise | |---|---|---| | **Infrastructure** | Hosted by PanDev | Your servers | | **Updates** | Automatic | Manual | | **Authentication** | OAuth | LDAP | | **Best for** | Startups, growing teams | Regulated industries | --- ## Core Principles ### 1. Privacy-First Data Metrics are captured without exposing individual developers. Focus on process improvements, not personal monitoring. ### 2. Automated Collection Telemetry is gathered automatically through IDE plugins and integrations — no manual time tracking. ### 3. AI-Powered Insights Ask questions about your data in natural language and get instant answers. ### 4. Actionable Guidance Insights come with concrete recommendations that make change easier. --- ## System Components - **IDE Plugins** — capture developer activity from 14+ IDEs - **Git Integrations** — GitLab, GitHub, Bitbucket, Azure DevOps - **Task Trackers** — Jira, Yandex Tracker - **Analytics Engine** — processes data and generates reports - **AI Assistant** — natural language queries - **Web Dashboard** — visualizations and insights --- ## Key Features (v2) ### For Teams - 📊 **Unified Dashboard** — all metrics in one place - 🤖 **AI Assistant** — ask questions about your data - 📈 **Trend Analysis** — spot patterns over time - 📋 **Automated Reports** — scheduled delivery ### For Individuals - 👤 **Personal Workspace** — track your own productivity - 🎮 **Gamification** — achievements and progress - 📱 **Mobile Access** — metrics on the go ### For Organizations - 🏢 **Departments & Teams** — org structure management - 💰 **Payment Reports** — cost tracking by developer - 🔐 **LDAP** — enterprise authentication (On-Premise) --- ## Why Teams Use It - 📊 **Objective Analytics** — decisions backed by data - 🚀 **Higher Throughput** — visible and fixable bottlenecks - 🎯 **Better Quality** — issues surface early - 👥 **Healthier Collaboration** — understand team dynamics - 📈 **Measured Progress** — track improvements over time --- ## Quick Start - **Cloud:** [SaaS Quick Start](https://pandev-metrics.com/docs/saas-getting-started) - **On-Premise:** [Installation Guide](https://pandev-metrics.com/docs/intro) - **Personal:** [Personal Workspace](https://pandev-metrics.com/docs/personal-getting-started) --- ## What to Read Next - [Product Description](https://pandev-metrics.com/docs/v1/how-it-works/product-description) — detailed capabilities - [How It Works](https://pandev-metrics.com/docs/v1/how-it-works/how-it-works) — data flow and architecture - [Use Cases](https://pandev-metrics.com/docs/v1/how-it-works/use-cases-metrics) — adoption patterns --- ## Problems We Solve URL: https://pandev-metrics.com/docs/v1/how-it-works/pain-points # Problems We Solve PanDev Metrics targets the core pain points faced by modern software teams and their leaders. ## Key Challenges Addressed by PanDev Metrics ### Lack of objective performance data **Pain:** Decisions are made on gut feeling and anecdotal evidence because leaders cannot observe how the team truly works. **Solution:** PanDev Metrics provides objective performance metrics grounded in real engineering activity. ### Inefficient time and resource management **Pain:** - Limited visibility into where development time actually goes. - Bottlenecks stay hidden until it is too late. - Team workload is hard to evaluate. **Solution:** - Detailed analytics on effort spent per task and activity. - Automatic detection of process bottlenecks. - Accurate measurement of workload and productivity. ### Opaque development processes **Pain:** - Task distribution across the team is unclear. - Individual contributions are invisible. - Project progress is hard to track. **Solution:** - Transparent reporting across every workflow. - Insights into task allocation and load balancing. - Visual dashboards that show progress at a glance. ### Difficult planning and estimation **Pain:** - Time estimates are unreliable. - Sprint and release planning is challenging. - Projects suffer from unexpected delays. **Solution:** - Historical data improves future planning accuracy. - Work pattern analysis refines estimation models. - Early warnings highlight potential delays. ### Distributed and remote team friction **Pain:** - Remote activity is hard to observe. - No real-time visibility into what teams are doing. - Motivation and engagement drop off. **Solution:** - Live monitoring of engineering activity. - Transparent reporting for distributed teams. - Motivation through visible outcomes and progress. ### No measurable progress **Pain:** - Improvements cannot be quantified. - Team momentum is hard to assess. - Strategy lacks trustworthy metrics. **Solution:** - Track improvements over time. - Analyse trends and growth dynamics. - Supply data for strategic planning. ## Organisation-Specific Issues ### Enterprises **Pains:** - Centralised management of engineering resources is complex. - No single view across multiple programmes. - Coordination between teams is inefficient. **PanDev Metrics Response:** - Centralised control and monitoring. - Unified metric system for every project. - Improved cross-team alignment. ### Startups and Small Teams **Pains:** - Need fast digitalisation of processes. - Priorities and resource allocation are unclear. - Rapid team growth creates chaos. **PanDev Metrics Response:** - Quick setup and onboarding. - Clear visibility into priorities. - Support for scaling without losing control. ### Outsourcing and Outstaffing Firms **Pains:** - Customers demand transparent reporting. - Remote contributors are hard to supervise. - Manual time reports and invoices consume time. **PanDev Metrics Response:** - Evidence-based reporting from real metrics. - Control over remote contributors. - Automated report generation. ## Economic Pressures ### Inefficient resource allocation **Pain:** Companies spend heavily on development without understanding ROI. **Solution:** PanDev Metrics optimises resource usage and boosts the return on engineering investment. ### High turnover **Pain:** Subjective performance reviews lead to unfair evaluations and attrition. **Solution:** Objective, data-driven assessments highlight real contribution and reward fairness. ### Slow response to change **Pain:** Teams react slowly to new requirements or technologies because they lack real-time feedback. **Solution:** Live data enables fast adaptation and confident decision-making. ## Results After Adoption With PanDev Metrics in place, teams gain: - ✅ **Reliable data** instead of guesswork. - ✅ **Process transparency** for everyone involved. - ✅ **Measurable productivity gains.** - ✅ **Better planning** and resource management. - ✅ **Higher motivation** across the organisation. - ✅ **A competitive edge** in the market. --- ## Product Description URL: https://pandev-metrics.com/docs/v1/how-it-works/product-description # Product Description **PanDev Metrics** is an ecosystem designed to digitise engineering processes and guide IT departments toward a **data-driven** operating model. The platform gives engineering leaders and CTOs **objective productivity metrics**, enabling decisions based on real numbers and an accurate assessment of team performance. ## What Is PanDev Metrics? PanDev Metrics is a comprehensive solution that helps companies understand how their developers work and where their time goes. Think of it as a complete, reliable picture of the engineering workflow that supports better decision-making and reveals opportunities to improve efficiency and develop talent. Beyond simple time tracking, the platform delivers deep analytics for: ### Employee and Team Growth - **Individual development** – monitor each engineer’s progress, strengths, and growth areas. - **Team dynamics** – analyse collaboration patterns, uncover facilitators, mentors, and hidden leaders. - **Leadership development** – evaluate team leads objectively, capturing managerial and technical skills. - **Career planning** – provide data for promotions, rotations, and talent programmes. ### Project Evolution - **Project progress** – observe real task completion and milestone achievement. - **Code quality** – analyse technical debt, complexity, and maintainability trends. - **Timelines** – plan and forecast delivery dates with accuracy. - **Resource planning** – distribute workload optimally across teams. ### Bottleneck Detection - **Blocker discovery** – surface process steps that slow delivery. - **Bottleneck analysis** – identify stages that consume disproportionate time. - **Technical risk** – detect problematic code areas that need refactoring. - **Process optimisation** – receive suggestions to streamline workflows. ### Strategic Planning - **Long-term analytics** – track performance and quality trends over months and years. - **Forecasting** – predict resource demand and emerging risks. - **Project ROI** – quantify the return on investment in engineering. - **Benchmarking** – compare results against industry standards and best practices. ## Guiding Principles ### 1. Personalised Data Capture Metrics originate directly from developers’ IDEs, providing precise visibility into individual contributions and ensuring total transparency across the development process. ### 2. Automated Collection Plugins and integrations gather metrics automatically, reducing manual input and avoiding process friction. ### 3. Rich Context PanDev Metrics correlates IDE activity with information from Git, Jira, task trackers, and communication tools to produce multidimensional insight. ### 4. Accuracy and Reliability Data is validated at every stage—collection, transport, processing, and storage—so reports stay trustworthy and resistant to manipulation. ### 5. Security and Compliance The platform follows enterprise-grade security practices: encryption in transit and at rest, fine-grained access control, audit trails, and deployment options that satisfy regulatory requirements. ## Key Capabilities 1. **Continuous time tracking** tied to tasks, commits, and repositories. 2. **Full activity history** with powerful filters by person, team, project, and timeframe. 3. **Team diagnostics** to highlight blockers, delivery risks, and collaboration issues. 4. **Quality monitoring** across codebases, tests, and refactoring work. 5. **Automated reporting** for stakeholders at every level. 6. **Predictive analytics** that flag negative trends before they hit delivery. ## Value by Stakeholder ### Developers - Transparent view of their own metrics. - Personalised growth insights. - Motivation through visible progress. ### Team Leads - Real-time visibility into team workload and focus. - Early detection of risks and dependencies. - Evidence to support coaching and feedback. ### Engineering Managers & CTOs - Strategic dashboards across portfolios. - Objective data for hiring, budgeting, and planning. - Confidence in ROI calculations. ### HR & People Ops - Reliable input for retention and development programmes. - Fair performance reviews backed by evidence. - Identification of top performers and high-potential talent. ## Why Organisations Choose PanDev Metrics - **Data-driven leadership** – move from intuition to facts. - **Faster delivery** – spot and eliminate bottlenecks. - **Better quality** – see issues ahead of time. - **Empowered teams** – encourage ownership and accountability. - **Sustainable scaling** – grow without losing control of processes. ## Recommended Reading Map - **Problems We Solve** – understand the pain points addressed by the platform. - **How It Works** – dive into the technical flow from collection to analytics. - **Use Cases & Metrics** – explore adoption patterns across company types. - **Architecture** – study the system components, security, and deployment models. - **Data Collection** – learn what telemetry is captured and how privacy is preserved. ## Quick Start To understand whether PanDev Metrics is the right fit: 1. **Read the Product Description** – grasp the overall value proposition. 2. **Review the Problems We Solve** – map the solution to your challenges. 3. **Check Use Cases** – see how organisations similar to yours benefit. 4. **Study How It Works** – learn what the implementation journey looks like. ## Next Steps After familiarising yourself with the documentation: - **System requirements** – ensure your environment is ready. - **Installation guide** – follow the deployment instructions. - **Plugin setup** – roll out IDE integrations. - **Integrations** – connect Jira, GitLab, and other systems. ## Support Need assistance? - **Technical support** – reach out to our engineers. - **Documentation** – explore detailed guides and FAQs. - **Community** – connect with other PanDev Metrics users. --- ## Use Cases and KPIs URL: https://pandev-metrics.com/docs/v1/how-it-works/use-cases-metrics # Use Cases and KPIs PanDev Metrics delivers value to a wide range of organisations and helps improve the key performance indicators of engineering teams. ## Use Cases ### Large Enterprises **How it is used:** - Central governance of multiple programmes and products. - Coordination across distributed development teams. - Strategic planning at the corporate level. **Key benefits:** - **Centralised control** – one metric system for every project. - **Data-driven decisions** for portfolio management. - **Resource optimisation** across teams and initiatives. - **Process standardisation** for consistent delivery. **Representative KPIs:** - Aggregate productivity of all engineering teams. - Effectiveness of resource allocation between projects. - Time-to-market for new products. - ROI on software development investments. ### Startups and Small Teams **How it is used:** - Fast digitisation of development workflows. - Clarifying priorities and focusing limited resources. - Supporting rapid growth and team scaling. **Key benefits:** - **Quick configuration** and onboarding. - **Clear prioritisation** for the whole team. - **Scaling support** without losing control. - **Optimised resource usage** when every hour counts. **Representative KPIs:** - Speed of MVP delivery. - Efficiency of developer time usage. - Early-stage code quality. - Time from idea to release. ### Outsourcing and Outstaffing Vendors **How it is used:** - Transparent reporting back to customers. - Monitoring distributed or remote contributors. - Automating statements of work and invoicing. **Key benefits:** - **Transparent reporting** built on verifiable metrics. - **Real-time visibility** into remote work. - **Automated billing** and report generation. - **Stronger client trust** and retention. **Representative KPIs:** - Time spent on specific customer projects. - Quality of deliverables. - Productivity of remote contributors. - Customer satisfaction. ### Public Sector Organisations **How it is used:** - Meeting transparency and accountability mandates. - Controlling expenditure on software initiatives. - Ensuring data security and confidentiality. **Key benefits:** - **Regulatory compliance** out of the box. - **Transparency** for budget spend. - **Elevated security** controls. - **Objective reporting** for oversight bodies. ## KPIs Improved by PanDev Metrics ### Performance Metrics #### Delivery Speed - **Task completion time** – typically reduced by 15–25%. - **Coding throughput** – increases by 10–20%. - **Code review latency** – streamlined review cycles. - **Release frequency** – ship more often without sacrificing quality. #### Code Quality - **Test coverage** – uplift by 20–30%. - **Technical debt** – lowered by 25–40%. - **Code complexity** – controlled growth of hotspots. - **Defect rate** – fewer bugs reach production. #### Collaboration - **Review participation** – broader involvement in peer reviews. - **Knowledge sharing** – fewer single points of failure. - **Cross-team communication** – improved coordination across squads. - **Stakeholder visibility** – clearer status reports for business partners. ### Management Metrics #### Planning Accuracy - **Effort estimation** – more reliable commitments. - **Sprint predictability** – better hit rates for planned scope. - **Release forecasting** – dependable roadmap delivery. - **Dependency management** – faster mitigation of cross-team blockers. #### Workload Balance - **Load distribution** – healthier balance across engineers. - **Capacity planning** – data-backed action on hiring and redistribution. - **Burnout prevention** – proactive alerts on overwork. - **Team morale** – higher engagement thanks to transparency. #### Process Maturity - **Lead time** – shorter cycle from idea to value. - **Throughput stability** – consistent delivery pace. - **Automation rate** – more repeatable workflows. - **Continuous improvement** – ongoing optimisation driven by feedback loops. ### Business Outcomes #### Financial Impact - **Cost per feature** – decrease through better utilisation. - **Revenue timing** – faster launches accelerate payback. - **Budget adherence** – fewer overruns. - **ROI uplift** – clearer link between engineering spend and results. #### Customer Value - **Product quality** – fewer production incidents. - **Customer satisfaction** – higher NPS thanks to reliable delivery. - **Innovation cadence** – more experiments and faster validation. - **Competitive differentiation** – build better products sooner. #### Scaling - **Team growth velocity** – onboard new engineers 2–3× faster. - **Adaptability** – react quickly to changing requirements. - **Process standardisation** – consistent practices across teams. - **Knowledge transfer** – better documentation and handovers. ## Industry Perspectives ### Software Product Development - Emphasis on code quality and architecture health. - Metrics around engineering throughput. - Technical debt analytics for long-lived products. ### Web Development - Velocity of UI/UX delivery. - Customer experience quality. - Performance of web applications. ### Mobile Development - Time-to-market for mobile apps. - Quality across platforms. - Efficiency of cross-platform teams. ### DevOps & Infrastructure - Process automation coverage. - Deployment lead time. - System reliability and uptime. ## Results Over Time ### Short Term (1–3 months) - Process transparency. - Identification of major bottlenecks. - Kick-off of process optimisation initiatives. ### Mid Term (3–6 months) - Measurable productivity gains. - Higher code quality. - Improved planning accuracy. ### Long Term (6+ months) - Sustainable efficiency growth. - Data-driven culture. - Competitive advantages in the market. ## ROI from PanDev Metrics ### Direct Benefits - **Development time reduction** – 15–25%. - **Cost reduction** – 10–20%. - **Product quality uplift** – fewer defects and regressions. - **Faster go-to-market** – beat competitors to launch. ### Indirect Benefits - **Higher motivation** across teams. - **Better planning** and forecasting. - **Lower project risk** due to early warnings. - **Stronger competitive position** through predictable delivery. --- ## Account Registration URL: https://pandev-metrics.com/docs/v1/installation/account-registration # Account Registration ### Go to the [PanDev partner console](https://cabinet.pandev.io/) and click `Register` ### Fill in the sign-up form ### Click `Sign Up` #### A confirmation email will be sent to the address you provided #### Check your inbox for a message from cabinet@pandev.io ### In the email, press `Confirm Email` #### You will be redirected to the confirmation page ### Enter the password you created during registration and click `Continue` #### The system will redirect you to the partner console home page—next, create a company ### Click `New company` ### Provide your company name and click `Create` ### After the company is created you can copy the company token ### Contact us to activate your subscription Telegram: [https://t.me/ZhenaTem](https://t.me/ZhenaTem) Email: t.tursynkul@pandev.io --- ## Architecture Diagram URL: https://pandev-metrics.com/docs/v1/installation/architecture # Architecture Diagram PanDev Metrics is deployed with the following components. - ### PanDev Metrics The core of the platform that receives telemetry from every plugin. Data is processed on the server and then persisted to PostgreSQL. - ### PostgreSQL The relational database that stores processed data coming from plugins and integrations. - ### Grafana Grafana visualises the dashboards powered by PostgreSQL so that teams can consume the metrics instantly. - ### Plugins A collection of extensions for JetBrains IDEs, VS Code, and more. The catalog is updated regularly. Developers install the plugins directly in their IDEs. --- ## Installation and Deployment URL: https://pandev-metrics.com/docs/v1/installation/installation-and-deployment # Installation and Deployment This guide is for **On-Premise** deployment on your own infrastructure. **Key differences from Cloud (SaaS):** - Authentication via **LDAP** (no OAuth) - Manual updates - Full data control For Cloud setup, see [SaaS Getting Started](https://pandev-metrics.com/docs/saas-getting-started). ### Step 1: [Register in the PanDev partner console](https://pandev-metrics.com/docs/v1/installation/account-registration) ### Step 2: Prepare to launch PanDev Metrics - Download and extract `pandev_metrics_4_7_1.zip` (located in `static/docker-compose/`). - Populate the `.env` file with the required values: - **`POSTGRES_DB`** – database name. - **`POSTGRES_USER`** – username for database access. - **`POSTGRES_PASSWORD`** – password for database access. - **`TZ`** – timezone. - **`GF_SECURITY_ADMIN_USER`** – Grafana admin login. - **`GF_SECURITY_ADMIN_PASSWORD`** – Grafana admin password. ### Step 3: Start PanDev Metrics - Run `docker compose up`. ### Step 4: Sign in to PanDev Metrics - #### Open the address where PanDev Metrics is hosted (port 8080 by default). - A company token prompt appears. - #### Paste the company token and create administrator credentials. - #### Click `Get started`. - You will see the admin credential form. - #### Enter the administrator credentials created in the previous step. - #### Click `Log in`. - The main PanDev Metrics page opens. #### The application is now ready! Next steps: [configure the LDAP integration](https://pandev-metrics.com/docs/intro) or [manually add users](https://pandev-metrics.com/docs/intro). --- ## Operating System Requirements URL: https://pandev-metrics.com/docs/v1/installation/os-requirements # Operating System Requirements PanDev Metrics can run on most operating systems, but we recommend Linux Debian 10+ or Ubuntu 20+. The virtualisation layer must expose modern CPU instructions, including: ## Troubleshooting on Popular Hypervisors - **Proxmox VE** - Set the CPU mode to `host` in the VM config (`/etc/pve/qemu-server/XXX.conf`). - Ensure the host supports the required instruction set (`lscpu`). - Reboot the VM after changing the CPU profile. - **VMware ESXi** - VM compatibility must be Hardware Version 17 / ESXi 7.0+. - Enable CPU passthrough or remove CPU masking. - Turn on “Expose hardware-assisted virtualization”. - **VirtualBox** - Enable VT-x, Nested VT-x, and PAE/NX. - Apply the CPU profile: `VBoxManage modifyvm "VM" --cpu-profile host`. - Verify instruction availability inside the VM (`cat /proc/cpuinfo`). - **Hyper-V** - Use Generation 2 VMs with CPU Compatibility Mode **disabled**. - Enable `ExposeVirtualizationExtensions`. - Check support with `lscpu | grep avx` inside the guest. - **XCP-ng / XenServer** - Switch CPU mode to **host-passthrough**. - Confirm the template exposes the needed instructions. - Validate via `lscpu` or `xl dmesg | grep avx`. - **QEMU CLI** - Start with `-cpu host` or `-cpu ,+avx2,+fma,...`. - Inspect host capabilities using `lscpu`. - Ensure the guest sees the instructions (`cat /proc/cpuinfo`). - **UTM (macOS)** - On x86 Macs: use `cpu host` with the necessary flags. - On Apple Silicon: AVX/AVX2 are **not supported at all**. - Double-check with `lscpu` inside the guest OS (x86 only). --- ## Required Ports URL: https://pandev-metrics.com/docs/v1/installation/ports # Required Ports To run PanDev Metrics together with Grafana and PostgreSQL on a single VM open the following ports: | **Port** | **Service** | **Description** | |----------|--------------------|-----------------| | **3000** | **Grafana** | Required to access dashboards and analytics for development teams. | | **5432** | **PostgreSQL** | Optional unless you need direct access to the database. Keep it closed externally if remote access is unnecessary. | | **8080** | **PanDev Metrics** | Used by IDE plugins to submit telemetry and by administrators to open the console at `:8080`. | ⚠️ Port 8080 may be exposed to the internet so plugins can send data from outside the corporate network. This is optional—plugins will buffer locally and sync as soon as the user is on the internal network or connected via VPN. --- ## Proxy Configuration URL: https://pandev-metrics.com/docs/v1/installation/proxy-configuration # Proxy Configuration - When running the container in an isolated environment, allow outbound access to [https://merchant-service.pandev.io](https://merchant-service.pandev.io/). - If traffic must go through a proxy, pass the following JVM arguments via manifests or the Docker container runtime: ```bash args: [ "-Dhttp.proxyHost=$(PROXY_HOST)", "-Dhttp.proxyPort=$(PROXY_PORT)", "-Dhttps.proxyHost=$(PROXY_HOST)", "-Dhttps.proxyPort=$(PROXY_PORT)" ] ``` --- ## System Requirements URL: https://pandev-metrics.com/docs/v1/installation/system-requirements # System Requirements This section applies to **On-Premise** deployment. For Cloud (SaaS), no infrastructure is required — [start here](https://pandev-metrics.com/docs/saas-getting-started). To host all components (PostgreSQL, PanDev Metrics, Grafana) on a single virtual machine: --- ## Minimum Requirements | Component | Requirement | |-----------|-------------| | **OS** | [Linux](https://pandev-metrics.com/docs/v1/installation/os-requirements) | | **RAM** | 4 GB | | **CPU** | 4 cores | | **Disk** | 50 GB | --- ## Recommended Requirements | Component | Requirement | |-----------|-------------| | **OS** | [Linux](https://pandev-metrics.com/docs/v1/installation/os-requirements) | | **RAM** | 16 GB | | **CPU** | 8 cores | | **Disk** | 100 GB SSD | --- ## Additional Requirements ### Network - Outbound HTTPS (443) for license validation - Inbound port 8080 for web interface - See [ports configuration](https://pandev-metrics.com/docs/v1/installation/ports) ### Docker - Docker Engine 20.10+ - Docker Compose 2.0+ ### Database - PostgreSQL 13+ (included in Docker Compose) --- ## Scaling Recommendations | Team Size | RAM | CPU | Disk | |-----------|-----|-----|------| | Up to 20 | 8 GB | 4 cores | 100 GB | | 20-50 | 16 GB | 8 cores | 200 GB | | 50-100 | 32 GB | 16 cores | 500 GB | | 100+ | Contact sales | | | --- ## Next Steps - [Installation Guide](https://pandev-metrics.com/docs/v1/installation/installation-and-deployment) - [OS Requirements](https://pandev-metrics.com/docs/v1/installation/os-requirements) - [Ports Configuration](https://pandev-metrics.com/docs/v1/installation/ports) --- ## Adding Users URL: https://pandev-metrics.com/docs/v1/integrations/create-users # Adding Users ### Step 1: Sign in to the Admin Console - #### Open the URL where PanDev Metrics is hosted. - #### Enter your administrator login and password, then click `Log in`. ### Step 2: Create a User Account - #### After signing in you will land on the admin dashboard. - #### Click `Employees` to open the user management section. - #### Press `Create` to open the new user form. - #### Fill in the required fields and click `Save`. ### After the Account Is Created - #### Share the login details with the new team member. The employee can now authenticate through the plugin using their own credentials. --- ## GitHub Integration URL: https://pandev-metrics.com/docs/v1/integrations/github # GitHub Integration PanDev Metrics integrates with GitHub to provide deep insight into your development workflow. ## What the Integration Delivers - **Code review assistance** – automatic analysis with recommendations during pull request reviews. - **Pull request comments** – intelligent annotations with code quality metrics. - **Project isolation** – analytics stay scoped to your repositories, preserving privacy. - **Performance metrics** – track development velocity and code health in one place. ## Setup Steps ### Step 1: Create a Service Account Analytics and report generation for PR creation/updates will be performed on behalf of this account. ### Step 2: Grant Access to the Service Account 1. Assign the **owner** role to the service account in all required organizations. ### Step 3: Create a Token for the Service Account 1. Log in to the service account 2. Go to the [token creation](https://github.com/settings/personal-access-tokens) page 3. Select the token type "Fine-grained personal access tokens" 4. Choose your organization in "Resource owner" 5. In the "Permissions" section, specify the required permissions for "Repositories" and "Organizations" 6. For "Repositories": Issues - Read and write, Metadata - Read-only, Pull requests - Read and write 7. For "Organizations": Webhooks - Read and write 8. Then create the token ### Step 4: Activation 1. Insert the token 2. Check the connection 3. Activate the integration ## Metrics Tracked - Code quality indicators. - Automated test coverage. - Code review turnaround time. - Comment volume and engagement. - Technical debt signals. - Engineering productivity metrics. - Contributor activity analysis. ## Need More Detail? Refer to the full integration guide at [/integrations/github](https://pandev-metrics.com/docs/intro). --- ## GitLab Integration URL: https://pandev-metrics.com/docs/v1/integrations/gitlab # GitLab Integration PanDev Metrics connects to GitLab to deliver end-to-end visibility into development and code review workflows. ## Integration Capabilities - **Code review support** – automated code checks and improvement tips. - **Merge request comments** – contextual feedback enriched with quality metrics. - **Private analytics** – insights stay confined to your projects. - **Performance metrics** – understand delivery speed and code health. ## Configuration Steps ### Step 1: Link GitLab 1. Open the PanDev Metrics settings. 2. Go to **Integrations**. 3. Find **GitLab** and click **Connect**. 4. Authenticate via GitLab OAuth. 5. Approve the requested scopes. ### Step 2: Choose Projects 1. Pick the repositories you want to monitor. 2. Configure branch filters as needed. 3. Select the metrics to analyse. 4. Set up notification rules. ### Step 3: Enable the Integration 1. Verify the connection. 2. Switch the integration on. 3. Start reviewing the analytics. ## Metrics Available - Code quality indicators. - Automated test coverage. - Code review turnaround time. - Comment activity. - Technical debt signals. - Engineering productivity KPIs. ## Learn More Consult the detailed integration guide at [/integrations/gitlab](https://pandev-metrics.com/docs/intro). --- ## Jira Integration URL: https://pandev-metrics.com/docs/v1/integrations/jira # Jira Integration PanDev Metrics offers a powerful Jira integration that automates metric collection and team analytics. ## Integration Features - **Automatic metric harvesting** – collect Jira activity with zero manual input. - **Worklog comments** – add contextual updates enriched with metrics. - **Performance analytics** – evaluate team throughput in detail. - **Project reporting** – generate dashboards and scheduled reports. ## Setup Guide ### Step 1: Connect Jira 1. Open PanDev Metrics settings. 2. Navigate to **Integrations**. 3. Select **Jira** and click **Connect**. 4. Provide the URL of your Jira instance. 5. Enter credentials or API tokens with the required access. ### Step 2: Configure Projects 1. Pick the Jira projects to monitor. 2. Set up issue filters. 3. Choose which metrics to collect. 4. Configure the refresh frequency. ### Step 3: Go Live 1. Test the connection. 2. Enable the integration. 3. Start gathering metrics in real time. ## Metrics Captured - Task completion time. - Number of issues closed. - Average time spent in each status. - Workload distribution across assignees. - Blockers and dependency analysis. ## Additional Resources See the detailed setup guide at [/integrations/jira](https://pandev-metrics.com/docs/intro). --- ## LDAP/AD Integration URL: https://pandev-metrics.com/docs/v1/integrations/ldap-integration # LDAP/AD Integration ### Step 1: Sign in to the Admin Console - #### Open the URL where PanDev Metrics is deployed. - #### Enter your administrator credentials and click `Log in`. ### Step 2: Connect LDAP/AD to PanDev Metrics - #### After authentication you will see the admin home screen. - #### Click `Settings` to open the application configuration. - #### Switch to the `LDAP` tab. - #### Click `Enable LDAP integration`. - #### Complete the required fields with your directory settings. - #### Save the configuration by clicking `Save changes`. #### LDAP/AD integration is now live! Your employees can sign in to the plugins using their corporate accounts. --- ## Dashboard URL: https://pandev-metrics.com/docs/v1/management/dashboard # Dashboard The PanDev Dashboard is the central hub for viewing metrics, managing teams, and analyzing development activity. ## Dashboard Overview --- ## Key Sections ### Home Overview of key metrics and recent activity: - **Activity summary** — coding hours, commits, tasks - **Team performance** — velocity and productivity trends - **Alerts** — anomalies and important changes --- ### Employees View individual developer activity and metrics: **Available data:** - Coding time per day/week - Projects and repositories - Task activity - Commit history --- ### Projects Track activity across repositories: --- ### AI Assistant Ask questions about your data in natural language: **Example queries:** - "Who worked on project X last week?" - "What's our average coding time per developer?" - "Show overtime trends for the last month" --- ## Filters & Navigation ### Time Range Select the analysis period — today, this week, this month, or custom range. ### Team/Department Filter data by organizational units. ### Projects Focus on specific repositories or projects. --- ## Reports Generate and export reports: - **PDF** — shareable summaries - **CSV** — for custom analysis - **Scheduled delivery** — automatic reports --- ## Next Steps - [Configure teams](https://pandev-metrics.com/docs/intro) - [Set up integrations](https://pandev-metrics.com/docs/intro) - [View plugin setup](https://pandev-metrics.com/docs/intro) --- ## Organization Management URL: https://pandev-metrics.com/docs/v1/management/teams # Organization Management Manage your company's organizational structure: employees, departments, and teams. --- ## Employees Add and manage team members: ### Adding Employees **Required fields:** - **Email** — for login and notifications - **Name** — display name - **Position** — job title - **Department** — organizational unit - **Role** — access level (Admin, Manager, Developer) ### Employee Roles | Role | Permissions | |------|-------------| | **Admin** | Full access, manage settings | | **Manager** | View team metrics, manage employees | | **Developer** | View personal metrics only | --- ## Departments Organize employees into high-level departments: **Examples:** - Backend Development - Frontend Development - QA & Testing - DevOps - Product Management --- ## Teams Create working squads within departments: ### Team Settings - **Team name** — unique identifier - **Description** — purpose of the team - **Lead** — team manager - **Members** — assigned employees - **Projects** — linked repositories --- ## Hierarchy ``` Company ├── Department: Backend │ ├── Team: API │ └── Team: Database ├── Department: Frontend │ ├── Team: Web │ └── Team: Mobile └── Department: QA └── Team: Automation ``` --- ## Access Management ### Access Levels - **Company metrics** — visible to admins - **Department metrics** — visible to department managers - **Team metrics** — visible to team members - **Personal metrics** — visible only to the individual ### Permissions Matrix | Action | Admin | Manager | Developer | |--------|-------|---------|-----------| | View company metrics | ✅ | ❌ | ❌ | | View team metrics | ✅ | ✅ | ❌ | | View personal metrics | ✅ | ✅ | ✅ | | Manage employees | ✅ | ✅ | ❌ | | Configure integrations | ✅ | ❌ | ❌ | --- ## Best Practices ### Team Size Aim for 5-9 members per team for optimal collaboration. ### Clear Ownership Assign a lead to each team who is responsible for metrics review. ### Regular Reviews Use metrics for team retrospectives, not for punishment. --- ## Next Steps - [View dashboard](https://pandev-metrics.com/docs/intro) - [Configure integrations](https://pandev-metrics.com/docs/intro) - [Install plugins](https://pandev-metrics.com/docs/intro) --- ## PanDev Extensions Privacy Policy URL: https://pandev-metrics.com/docs/v1/materials/pandev-extensions-privacy-policy # PanDev Extensions Privacy Policy **Version:** 1.0\ **Effective Date:** January 1, 2025\ **Rights Holder (Provider):** PanDev Ltd > This Policy describes how PanDev extensions for code editors and IDEs handle data. The document aligns in meaning and terminology with the **Extensions EULA** and the **Extensions ToS**. Access to PanDev cloud services is governed by the **Cloud Terms**. Server software deployed at the Customer is governed by the **Self-Managed EULA**. --- ## 1. Scope and Purpose 1.1. The Policy applies only to **PanDev extensions** as a channel for transferring data from an IDE to the Server.\ 1.2. The Policy does **not** set processing rules inside the SaaS. For the cloud, the Cloud Terms and a separate SaaS privacy policy (to be published) apply.\ 1.3. For **on-prem** deployments, processing takes place within the Customer's infrastructure under the Self-Managed EULA. This Policy describes only what data the extensions transmit and how PanDev treats it. ## 2. Roles and Allocation of Responsibilities 2.1. **SaaS.** The Customer is the controller of personal data. PanDev acts as a processor for the cloud. The rules are captured in the Cloud Terms. A DPA may be signed upon request.\ 2.2. **On-prem.** Data is processed and controlled by the Customer in its infrastructure. PanDev is not a processor and does not receive access unless separately agreed.\ 2.3. **Extension diagnostic telemetry.** To improve quality PanDev may process anonymized telemetry about the extensions themselves. In on-prem mode diagnostic telemetry is not used. ## 3. Data Transmitted by the Extensions 3.1. **Activity Data** is metadata about events in the Editor **without source code content**. It includes: - **Event time** and sequence of actions. - **Project and repository context:** project name, modules, repository path or identifier, active branch, links to commits and their parent records. - **File and language context:** file path, file name, programming language, total line count, current line, and cursor position. - **Environment and extension context:** IDE name and version, PanDev extension type and version. - **Execution context:** run type (for example run, debug, or tests), final status, run profile name, executable class name, execution module. - **User and organizational context:** actor or commit author, user ID in the system, company or tenant identifier in PanDev. - **System and network parameters:** user's local timezone, system timezone, device network attributes including IP address, country, and hardware network identifier. - **Short textual event description**, such as a commit message, without embedding file contents. 3.2. **Diagnostic telemetry** consists of anonymized information about the extensions and compatible environment: versions, crashes, performance. In on-prem mode diagnostic telemetry is not used. 3.3. **Not transmitted:** source code content, secrets, keys, tokens, passwords, binary artifacts, or full copies of configuration files. By default the extensions do not send file contents and strive to exclude sensitive areas. 3.4. **Authentication data.** Credentials may be transmitted to sign in to the cloud or on-prem. Transmission uses secure channels, passwords are not logged and are not part of Activity Data. After authentication, tokens with limited validity are used. 3.5. The set of categories and the level of detail are synchronized with the PanDev extension technical specification and aligned with the EULA and ToS. ## 4. Data Sources 4.1. The primary source is the **extension running on the User's machine**.\ 4.2. Additionally, data may come from the **Customer** during project configuration and from **infrastructure logs** in SaaS mode. ## 5. Processing Purposes We use extension-related data for the following purposes: - delivering Activity Data to the Server and ensuring reliable delivery during outages - maintaining integration functionality and version compatibility - diagnosing and resolving incidents - improving extension quality and performance - security and abuse prevention - performing Customer contracts and meeting legal requirements ## 6. Legal Bases 6.1. **SaaS.** The Customer determines legal bases as the controller. PanDev acts as a processor under the Cloud Terms and any applicable DPA.\ 6.2. **On-prem.** Processing is determined by the Customer. PanDev is not a processor.\ 6.3. **Extension diagnostic telemetry.** Processed by PanDev under its legitimate interest in product quality and security. Telemetry is not used for profiling Users and does not include code content. ## 7. Storage 7.1. **Extension local cache.** When the Server is unavailable, the extension temporarily stores events in a local cache and sends them once connectivity is restored. By default the cache is **not limited** in duration or volume and is not configurable inside the extension. The Customer may limit storage through corporate device policies and operating system controls.\ 7.2. **SaaS.** Cloud storage and deletion are governed by the Cloud Terms and the Customer's settings.\ 7.3. **On-prem.** Storage is managed by the Customer.\ 7.4. **Diagnostic telemetry.** Retained for the minimum time needed for diagnostics and improvements, after which the data is deleted or aggregated and anonymized. ## 8. Security 8.1. Data transmission uses **TLS 1.2 or higher** with host verification.\ 8.2. Access tokens and keys are stored in secure operating system vaults where possible.\ 8.3. The local cache is encrypted using OS mechanisms and extension safeguards. The protection level depends on device capabilities and configuration.\ 8.4. The Customer is responsible for device security policies, access management, and updates in its environment. ## 9. Disclosure and Sharing 9.1. **Subcontractors and subprocessors (SaaS).** PanDev may engage vetted subcontractors for hosting and processing when operating the cloud. A list will be published or provided on request.\ 9.2. **On-prem.** PanDev does not receive data except for support under a separate written data access agreement.\ 9.3. **Legal requirements.** We disclose information when required by law and supported by proper legal grounds.\ 9.4. **Cross-border transfers.** In SaaS mode data may move across jurisdictions. PanDev applies organizational and technical measures to protect transferred data. For on-prem, data remains within the Customer's infrastructure. ## 10. Data Subject Rights 10.1. **SaaS.** Data subject requests (access, rectification, deletion, restriction, objection) should be addressed to the Customer as the controller. PanDev supports the Customer to the extent required under the Cloud Terms.\ 10.2. **On-prem.** Requests are handled by the Customer.\ 10.3. **Extension telemetry.** Requests may be sent directly to PanDev. We review and respond within a reasonable time. ## 11. Children and Consumers PanDev extension products are intended solely for business use. We do not target children and do not knowingly collect data about minors. ## 12. Changes to This Policy We may update this Policy. A new version takes effect after publication and notification through the services or by email. Continued use signifies acceptance of the changes. ## 13. Contact Information - **Rights Holder (Provider):** PanDev Ltd - **Office:** 050057, Republic of Kazakhstan, Almaty, Bostandyk District, Gagarin Ave. 124, 4th floor - **Support:** [privacy@pandev.io](mailto:privacy@pandev.io) and [support@pandev.io](mailto:support@pandev.io) --- ## Appendix A. Alignment with the EULA and ToS A.1. This Policy does not amend or replace the Extensions EULA or the Extensions ToS.\ A.2. For SaaS the Cloud Terms and, if needed, a DPA apply.\ A.3. In on-prem mode PanDev is not a processor and does not access data without separate consent.\ A.4. In on-prem mode extension diagnostic telemetry is not used.\ A.5. The composition of Activity Data and collection exclusions match the appendices to the EULA and ToS. --- ## PanDev Extensions Software License Agreement URL: https://pandev-metrics.com/docs/v1/materials/pandev-extensions-software-license-agreement # PanDev Extensions for Code Editors and IDEs - Software License Agreement **Version:** 1.0\ **Effective date:** 01/01/2025\ **Licensor:** PanDev LLP > This agreement (the "Agreement") is a legally binding contract between you (an individual or an entity, the "Customer") and PanDev governing the installation and use of PanDev software extensions for compatible code editors and integrated development environments (IDEs) (each an "Extension" and collectively the "Extensions", and the relevant application the "Editor"). By installing, copying, or using an Extension you accept the terms of this Agreement. The person performing the installation **represents and warrants** that they act on behalf of and in the interests of the Customer and are **authorized** to accept the Agreement binding the Customer. Installation and use of the Extension are prohibited if the person is not authorized. This Agreement is intended solely for business-to-business use and does not apply to consumer use. --- ## Definitions **"Extension" / "Extensions"** - PanDev software modules installed in compatible code editors and/or IDEs to collect and transmit activity data to the Server. **"Editor"** - a compatible code editor and/or integrated development environment (IDE) where the Extension is installed. **"Server"** - a remote PanDev endpoint (PanDev cloud SaaS or a PanDev instance deployed in the Customer's infrastructure, on-prem) that receives data from the Extension. **"Services"** - PanDev cloud and other services that the Extension can connect to in order to transmit data and obtain functionality; the relevant terms are defined in the ToS and/or the DPA. **"Customer"** - a legal entity or a sole proprietor/individual acting exclusively for business (non-consumer) purposes on whose behalf the Extension is installed and used. **"User"** - an individual (an employee or contractor of the Customer) who uses the Extension in the Editor. **"Activity Data"** - metadata about events in the Editor (for example timestamps, action types, project/file identifiers without content, software versions, and technical identifiers) as described in Appendix A. **"Diagnostic Telemetry"** - anonymized technical information about the Extension itself (state, versions, crashes, performance) that is different from Activity Data. **"Cache" (local cache)** - a temporary local storage area of the Extension used to accumulate Activity Data when the Server is unavailable and to deliver it after connectivity is restored. ## 1. Subject and Scope 1. The Extension is licensed, not sold. All rights in the Extension belong to the Licensor and/or its licensors. 2. The Extension is designed to operate **only when connected to a remote PanDev server** (cloud SaaS or a Customer-hosted instance, the "Server"). Without a connection to the Server the Extension functionality may be fully or partially unavailable. 3. The provision of PanDev Services (including SaaS) is governed by separate Terms of Service (ToS) and/or a Data Processing Agreement (DPA). This Agreement **does not** set the terms for the Services. 4. The "Editor" is a compatible code editor and/or IDE for which PanDev provides the corresponding Extension. ## 2. License and Restrictions 1. The Licensor grants the Customer a non-exclusive, paid or unpaid (depending on the purchased license/subscription), non-transferable, non-sublicensable license **worldwide** **for the term of this Agreement** to install and use the Extension only together with the Editor and in connection with the Server. 2. The Customer must not: (i) bypass technical limitations; (ii) reverse engineer, decompile, or disassemble the Extension except to the extent permitted by applicable law; (iii) provide the Extension to third parties as a service bureau, rent, lease, loan, or redistribute it; (iv) use the Extension or data obtained through it to build, train, test, benchmark, or otherwise develop **competing** software products or services without prior written consent from PanDev; (v) use the Extension in violation of applicable law, including export control and sanctions requirements; or (vi) circumvent authentication, licensing, bandwidth controls, or interfere with the Server. 3. If the Extension includes paid features or subscriptions, additional licensing terms (named/seat, license keys, trial limits) apply and are communicated to the Customer during purchase or activation. 4. The Extension may be used only in accordance with the current PanDev Service terms (ToS) and any agreements between the parties; in case of conflict the applicable agreement or ToS prevails. 5. The Customer is responsible for the acts and omissions of its Users and any third parties that gain access to the Extension and/or the Services through the Customer. ## 3. SaaS and On-Prem Modes, Party Roles 1. When connected to **SaaS**, the Customer acts as the controller of personal data and PanDev acts as the processor in accordance with applicable data protection law. The relationship is governed by the **DPA**, which forms an integral part of the Services and applies only to the extent needed to provide SaaS. 2. When connected to **on-prem**, all Activity Data is processed and **controlled by the Customer** within its own infrastructure. The Customer acts as the controller and operator/processor, and PanDev **does not act as a processor** and does not access the data **unless otherwise expressly agreed** by the parties in a separate document. 3. **Remote support and access to data (if agreed).** If, at the Customer's request, PanDev obtains limited remote access to the on-prem environment or exported materials (for example logs or crash dumps) for support purposes, such access is limited to the minimum necessary scope and is governed by a separate DPA or Data Access Addendum defining the purpose, data categories, duration, and security measures. ## 4. Data Collected and Minimization 1. The Extension collects and sends **IDE activity metadata** to the Server: timestamps, action types, project/file identifiers (paths or patterns without content), IDE/OS versions, and technical identifiers (see Appendix A). 2. **Source code, secrets, and binary artifacts are not transmitted or stored** in the cache. 3. The Customer must ensure that processing is lawful under labor, privacy, and other applicable laws (for example employee notices, consent where required, local restrictions). PanDev is not responsible for the Customer's compliance with employee monitoring requirements. ## 5. Offline Cache and Deferred Delivery 1. If the Server is temporarily unavailable, the Extension stores events in a **temporary local cache** and automatically delivers them once connectivity is restored. 2. By default the local cache is **not limited** by volume or retention period and cannot be configured within the Extension. 3. The cache may be cleared automatically when signing out or switching users. Clearing the cache may cause unrecoverable loss of undelivered events. 4. The Customer accepts the risk of losing some events due to prolonged Server downtime, environment errors, user-driven data deletion, or device security policies. ## 6. Transmission and Storage Security 1. Data is transmitted via **TLS 1.2 or higher** with host verification. 2. The local cache is encrypted using OS capabilities and/or built-in mechanisms of the Extension. Access tokens or keys are stored in the OS-provided secure storage where available. 3. PanDev signs Extension distributions and/or publishes checksums. 4. PanDev is not responsible for data compromise caused by user tampering with system settings, registries, storage, or by disabling OS protection. ## 7. Diagnostic Telemetry of the Extension 1. In addition to user activity events, the Extension may collect **anonymized diagnostic telemetry** (state, crashes, versions, performance) to improve quality. 2. In **on-prem** mode diagnostic telemetry is not used. In **SaaS** mode anonymized diagnostic telemetry may be transmitted. ## 8. Third-Party Components and Open Licenses 1. The Extension may include third-party components distributed under their respective licenses. The list and terms are available in the NOTICE file or the "Licenses" section of the Extension. 2. The terms of such components govern to the extent of any conflict, and take priority over this Agreement where required. ## 9. Intellectual Property and Trademarks 1. The Extension is licensed, not sold. All rights, title, and interest in the Extension, including source code, design, databases, documentation, trade names, marks, and logos of PanDev, belong to the Licensor and/or its licensors. No rights are granted by implication beyond those expressly stated in Section 2. 2. Use of trademarks is permitted only for fair identification of the Extension and does not grant ownership, registration, licensing, or disposition rights to those marks. 3. **White-label/Co-branding.** The Licensor may, under a separate agreement and subject to PanDev brand guidelines, grant the Customer a limited, non-exclusive, non-transferable, and revocable license to use certain PanDev designations, names, and visual elements solely for co-branding the Extensions or their user interface. This license does not transfer any brand rights and terminates upon breach or revocation by the Licensor. 4. The Customer must not remove, modify, or obscure copyright notices, trademark notices, or other intellectual property notices in the Extension. Any user interface customization performed by the Customer must not mislead users about the origin of the Extension. ## 10. Feedback 1. The Customer and/or Users may provide the Licensor with ideas, comments, and other materials about improvements to the Extension or the Services (the "Feedback"). 2. By providing Feedback, the Customer grants the Licensor a free, non-exclusive, perpetual, irrevocable, worldwide license to use, reproduce, modify, publish, distribute, and incorporate the Feedback into the Licensor's products and services without any obligation to attribute or compensate. The Licensor is not obliged to review, implement, or respond to Feedback. ## 11. Updates, Compatibility, and Version Pinning 1. PanDev may release updates, including those that change cache or delivery behavior. 2. The Customer may disable automatic updates and pin a specific version of the Extension, accepting the associated security and compatibility risks. 3. Critical security patches may be marked as mandatory to install. ## 12. Warranties and Liability 1. The Extension is provided "AS IS" without any express or implied warranties, including merchantability, fitness for a particular purpose, or non-infringement. PanDev is not liable for losses resulting from the use of unofficial Extension builds or modifications, or from the use of third-party software or non-standard versions that may affect Extension performance. 2. To the maximum extent permitted by law, PanDev is not liable for any indirect, special, punitive, incidental damages, lost profits, data loss, or claims by the Customer's employees arising from monitoring their activity. 3. PanDev's aggregate liability under this Agreement is limited to **ten (10) US dollars** or the amount paid by the Customer for Extension licenses during the last **three (3) months** (if any fees apply), whichever is greater. Liability for the Services is governed by the applicable ToS and/or DPA. ## 13. Term and Termination 1. This Agreement becomes effective when the Extension is installed and remains in force until the Customer removes the Extension or the Licensor terminates it under the terms of this Agreement. 2. The Licensor may terminate the license unilaterally if the Customer materially breaches the Agreement. The Customer must immediately stop using and delete all copies of the Extension upon termination. 3. Termination does not affect the provisions on intellectual property, disclaimers, liability limitations, governing law, or jurisdiction, all of which survive termination. ## 14. Export Control and Sanctions 1. The parties will comply with applicable export control regimes and economic sanctions. The Customer confirms that it is not subject to sanctions and will not use the Extension in sanctioned jurisdictions in violation of law. ## 15. Governing Law, Jurisdiction, and Language 1. This Agreement is governed by the laws of **Kazakhstan**, and disputes are subject to the competent courts of that jurisdiction. 2. The United Nations Convention on Contracts for the International Sale of Goods (CISG) **does not apply**. 3. In case of interpretation issues, the **Russian** version prevails. 4. PanDev may update this Agreement. Continued use of the Extension after notice constitutes acceptance of the updated version. If you do not agree, remove the Extension. ## 16. Miscellaneous 1. This Agreement is intended solely for **B2B use**. The parties confirm that they act in the course of business and **are not consumers**. To the fullest extent permitted by law, consumer protection statutes do not apply. 2. If any mandatory consumer law provision applies contrary to the parties' intent, it applies only to the minimum extent required and does not affect the validity of the remaining terms. 3. Invalidity of a particular provision does not render the Agreement invalid as a whole. 4. Failure to enforce any right does not constitute a waiver. 5. The parties recognize the legal force of the Agreement and acceptance in electronic form. --- ## Appendix A. Data Categories and Default Exclusions **Categories:** event timestamps; IDE action types (navigation, editing, build, run, window/focus switches); project/repository identifiers; relative or normalized file paths/patterns; IDE/extension/plugin versions; OS version; technical device/session identifiers. **Exclusions (default patterns):** `**/secrets/**`, `**/*.key`, `**/.env*`, `**/node_modules/**`, directories containing confidential materials. **File contents/secrets:** are not collected or transmitted. --- ## Contacts **Licensor:** PanDev LLP\ **Office:** 050057, Republic of Kazakhstan, Almaty, 124 Gagarin Ave.\ **Support:** [**support@pandev.io**](mailto:support@pandev.io) --- ## PanDev Extensions Terms of Service URL: https://pandev-metrics.com/docs/v1/materials/pandev-extensions-terms-of-service # PanDev Extensions Terms of Service (ToS) **Version:** 1.0\ **Effective Date:** January 1, 2025\ **Rights Holder (Provider):** PanDev Ltd > These terms govern only the use of PanDev software extensions for code editors and IDEs as a channel for transferring data from the IDE to PanDev services. Access to and rules for using the cloud services (SaaS) are defined in the Cloud Terms. The rules for server software deployed at the Customer (on-prem, self-managed) are set out in the Self-Managed EULA. Licensing of the Extensions themselves is governed by the Extensions EULA. --- ## Definitions **"Extensions"** - PanDev software modules installed in compatible code editors and IDEs that collect and transmit activity data to the Server.\ **"Editor"** - A compatible code editor or integrated development environment (IDE) in which an Extension is installed.\ **"Services (SaaS)"** - PanDev cloud services delivered from PanDev cloud infrastructure.\ **"Software (on-prem, self-managed)"** - PanDev server software deployed in the Customer's infrastructure under the Self-Managed EULA.\ **"Server"** - A remote endpoint that receives data from the Extensions. The Server may be the Platform (PanDev cloud) or the Customer's on-prem instance.\ **"Platform"** - PanDev cloud infrastructure on which the SaaS operates.\ **"Cloud Terms"** - Separate PanDev terms that govern access to and use of the SaaS.\ **"Customer"** - A legal entity that has entered into an agreement with PanDev.\ **"User"** - A Customer employee or contractor authorized to work with the Extensions.\ **"Activity Data"** - Metadata about events in the Editor without source code content. The categories are described in Appendix A.\ **"Diagnostic Telemetry"** - Anonymized technical information about the Extensions themselves (status, versions, crashes, performance) that is different from Activity Data.\ **"Cache"** - A temporary local storage used by the Extensions to accumulate Activity Data when the Server is unavailable and to forward it once connectivity is restored. ## 1. Scope and Order of Precedence 1.1. **SaaS.** These terms do not govern access to PanDev cloud services or set any rules for their use. Access to the SaaS is regulated by the Cloud Terms. This document describes only the use of the Extensions as a channel for transferring data from an IDE to the Services. Licensing of the Extensions themselves is governed by the Extensions EULA. 1.2. **On-prem.** Rights of use and limitations for software deployed by the Customer are defined in the Self-Managed EULA. These terms apply to on-prem only where they explicitly state "applies to on-prem," and when the on-prem instance uses PanDev cloud sub-services such as license updates, the extension catalog, or telemetry when it is enabled. 1.3. **Order of precedence.** If documents conflict, the order of precedence is: first, the agreement with the Customer; second, the Self-Managed EULA for on-prem or the Cloud Terms for SaaS; third, this ToS; fourth, published PanDev policies that are expressly incorporated by reference; fifth, the Extensions EULA. ## 2. Access and Accounts 2.1. Access to the SaaS is governed by the Cloud Terms. This ToS describes only the use of the Extensions as a data transfer channel and does not set rules for cloud access. 2.2. In on-prem deployments the Customer administers accounts and access. When an on-prem instance uses PanDev cloud sub-services, those sub-services are subject to these terms. ## 3. Extension Operation and Offline Cache 3.1. The Extensions collect and transmit Activity Data to the Server, which may be the cloud Platform or the Customer's on-prem instance. 3.2. If the Server is temporarily unavailable, the Extensions store events in a local cache and automatically transmit them once the connection is restored. 3.3. Source code contents and secrets are not transmitted or stored in the cache by default. 3.4. Some features require the Extensions to be installed and functioning correctly. PanDev is not responsible for blocks or environment changes introduced by the Customer. 3.5. For on-prem, PanDev does not receive Activity Data unless the parties agree on limited access for support purposes under a separate data access agreement. ## 4. Customer Obligations 4.1. Comply with applicable law, including labor and personal data law, and inform employees and obtain consents where required. 4.2. Ensure the legality of Customer Content and refrain from submitting unlawful materials. 4.3. Comply with this ToS, the Extensions EULA, the Self-Managed EULA for on-prem, agreements with third parties, and PanDev policies when expressly incorporated by reference. ## 5. Acceptable Use Illegal activity, circumvention of technical restrictions, interference with the Platform, scanning and load testing without consent, distribution of malicious code, using the Extensions or data to create or train competing solutions without PanDev's written consent, sharing credentials, violations of intellectual property rights, and breaches of export-control or sanctions regimes are prohibited. PanDev may publish a detailed policy later, which will supplement this section without reducing the Customer's rights. ## 6. Data and Security 6.1. **SaaS.** Processing of personal data in the cloud is governed by the Cloud Terms and PanDev's Privacy Policy. Upon request the parties may enter into a separate data processing agreement (DPA). This ToS does not establish rules for processing within the SaaS and covers only the use of the Extensions as a data transfer channel. 6.2. **On-prem.** Data is processed within the Customer's infrastructure. The Customer acts as controller and operator or processor. PanDev is not a processor and does not receive access to data unless otherwise agreed in writing. 6.3. **On-prem support.** At the Customer's request PanDev may receive limited remote access to the on-prem environment or to exported materials such as logs and crash dumps strictly in the minimum volume necessary. Such access is governed by a separate data access agreement. 6.4. **Security incidents.** For SaaS PanDev notifies the Customer about confirmed incidents affecting its data and acts in accordance with internal procedures and applicable law. For on-prem, incidents in the Customer's environment are the Customer's responsibility. ## 7. Availability, Support, and Updates 7.1. **SaaS.** Availability metrics and support are governed by the Cloud Terms. This ToS does not set cloud availability metrics. 7.2. **Integration via Extensions.** PanDev maintains integration sub-services such as authentication and telemetry intake on a commercially reasonable basis and may update interfaces and client versions. 7.3. **On-prem.** Support and updates for server software are governed by support and maintenance terms, if purchased. 7.4. **Extension updates.** PanDev may release functional and security updates. Some updates require specific Extension versions. Critical security updates may be mandatory. 7.5. **Suspension of SaaS integration.** PanDev may restrict cloud sub-services related to data transfer via the Extensions if these terms are violated or if there is a threat to the Platform's security. Full cloud access terms are governed by the Cloud Terms. 7.6. **Data export and deletion.** These terms govern only data transferred via the Extensions. Export and deletion within the SaaS are described in the Cloud Terms. For on-prem the Customer provides export and deletion. ## 8. Intellectual Property and Feedback 8.1. All rights to the Services, server software, and Extensions belong to PanDev and its licensors. 8.2. Customer Content remains the Customer's property. The Customer grants PanDev a limited license to use that content to the extent necessary to operate the cloud or cloud sub-services. 8.3. PanDev may use feedback free of charge, for any duration, and without any obligation of attribution or compensation. ## 9. Warranties and Disclaimers 9.1. The Extensions and related integration sub-services are provided "AS IS" and "AS AVAILABLE." PanDev does not guarantee the complete absence of errors or full alignment with expectations. 9.2. For on-prem, warranty provisions and limitations are specified in the Self-Managed EULA. 9.3. PanDev is not responsible for limitations caused by the Customer's security settings, environment, or third-party blocks. ## 10. Limitation of Liability 10.1. To the maximum extent permitted by law, PanDev is not liable for indirect, special, or punitive damages, lost profits, loss of data, or reputational harm. 10.2. PanDev's aggregate liability under this document is limited to the greater of ten US dollars or the amount paid by the Customer for Extension licenses during the three calendar months preceding the event. Liability for providing the SaaS and for on-prem server software is defined in the Cloud Terms and the Self-Managed EULA. 10.3. Nothing limits liability for willful misconduct, harm to life or health, or other cases where limitation is prohibited by law. ## 11. Export Control and Sanctions The parties comply with applicable sanctions regimes and export-control regulations. The Customer confirms it is not a sanctioned entity and undertakes not to use the Services and Software in violation of such restrictions. ## 12. Governing Law and Disputes The law of the Republic of Kazakhstan applies. Disputes are resolved by the competent courts of Almaty. The parties may agree to mediation or arbitration. The United Nations Convention on Contracts for the International Sale of Goods (CISG) does not apply. ## 13. Term, Changes, and Termination 13.1. These terms apply from the effective date above until termination. 13.2. PanDev may update this document. Changes become effective after publication and notification via the Services or by email. Continued use constitutes acceptance of the new version. 13.3. Notices are sent to the contacts listed in the agreement or the account and are deemed received when sent. 13.4. **Stopping use of the Extensions.** PanDev may restrict or terminate the use of the Extensions if these terms, legal requirements, or security measures are violated. The Customer may stop using the Extensions at any time by removing them from the Editor. Stopping the use of the Extensions does not affect the validity of SaaS or on-prem agreements and does not release the parties from obligations that survive termination, such as confidentiality and limitation of liability. ## 14. Miscellaneous The invalidity of a provision does not invalidate the entire document. Failure to exercise a right does not constitute a waiver. The document is concluded electronically. The parties act as independent contractors. --- ## Appendix A. Data Categories (for Extensions) - Timestamps of events in the Editor.\ - Types of actions in the Editor: navigation, editing, build, run, window focus.\ - Project and file identifiers without content.\ - Versions of the Editor, operating system, and installed extensions.\ - Technical device and session identifiers.\ - Diagnostic telemetry about the Extensions: versions, crashes, performance. **In on-prem mode diagnostic telemetry is not used.** --- ## Contacts **Rights Holder:** PanDev Ltd\ **Office:** 050057, Republic of Kazakhstan, Almaty, Gagarin Ave. 124\ **Support:** [**support@pandev.io**](mailto:support@pandev.io) --- ## On-Prem Getting Started URL: https://pandev-metrics.com/docs/v1/on-prem-getting-started # On-Prem Getting Started This starter walks through self-hosted deployments inside your infrastructure. ## Prerequisites - Access to the PanDev partner console with admin rights. - Infra that meets [System Requirements](https://pandev-metrics.com/docs/intro) (CPU/RAM/storage, Kubernetes/VMs, ingress). - Ability to provision TLS certificates and outbound internet connectivity for the IDE Agent/ingress endpoints. ## Deploy the platform 1. Register and log in: [Partner console](https://pandev-metrics.com/docs/intro) 2. Plan capacity: [System Requirements](https://pandev-metrics.com/docs/intro) 3. Install and configure: [Installation & Deployment](https://pandev-metrics.com/docs/intro) - Environment variables and secrets - Images, registry access, ingress/TLS - First admin login ## Connect IDE plugins 1. Install plugins: [IDE plugins](https://pandev-metrics.com/docs/intro) 2. Sign in with the same account you used for on-prem; select the on-prem workspace. ## Wire up integrations - Connect Git providers and trackers: [Integrations](https://pandev-metrics.com/docs/intro) - Review data flow and architecture: [How it works](https://pandev-metrics.com/docs/v1/how-it-works/overview) ## Manage teams and visibility - Create teams and projects: [Team Management](https://pandev-metrics.com/docs/intro) - Configure dashboards and access: [Management in PanDev](https://pandev-metrics.com/docs/intro) ## Verify and operate - Verify the deployment is working correctly. - Regenerate release metadata if you bump versions: `npm run generate-all-releases`. - Keep IDE Agents and ingress endpoints reachable from developer machines. ## Need Help? - 📋 [Documentation](https://pandev-metrics.com/docs/intro) – step-by-step guides - 💬 [Support](https://metrics.pandev.io/support) – contact the team - 📖 [FAQ](https://pandev-metrics.com/docs/intro) – frequent questions and answers --- ## JetBrains Plugin URL: https://pandev-metrics.com/docs/v1/plugins/jetbrains-plugin # JetBrains Plugin The PanDev Metrics plugin for JetBrains works across the entire family of IDEs (IntelliJ IDEA, PyCharm, WebStorm, Android Studio, GoLand, and more). It captures rich activity data—file edits, branch switches, session duration—and streams it to the PanDev Metrics Core. ### Key Features - **Zero-click tracking** – developers never need to start or stop the plugin manually. - **Granular telemetry** – measure time per file, branch changes, opened projects, and other events. - **Privacy-first** – no screenshots, screen recordings, or personal data collection. - **Seamless integration** – everything arrives in PanDev Metrics Core for dashboards and reports. ### Installation Steps 1. Launch your JetBrains IDE (IntelliJ IDEA, PyCharm, etc.). 2. Open **Settings/Preferences → Plugins**. 3. Install the plugin from the packaged distribution. 4. Restart the IDE to activate the plugin. ### Configuration - After restart, go to **Settings → Tools → PanDev Metrics**. - Enter the **Server URL** (address of your PanDev Metrics Core). - Provide the credentials shared by your administrator. ### Everyday Usage - The plugin runs silently in the background, tracking activity in open files and projects. - Telemetry is sent to PanDev Metrics Core as work progresses. - View the resulting metrics inside Grafana or any connected reporting tool. --- ## IDE Plugins URL: https://pandev-metrics.com/docs/v1/plugins/overview # IDE Plugins PanDev Metrics plugins are lightweight modules installed inside your development environment. They automatically capture developer activity and send telemetry to PanDev Metrics — no manual time tracking required. ## Key Features - **Zero-click tracking** — developers never start or stop tracking manually - **Privacy-first** — no screenshots, screen recordings, or source code capture - **Secure** — data transmitted over HTTPS/TLS - **Configurable** — exclude specific files, directories, or projects --- ## Supported IDEs ### JetBrains Family Supports all JetBrains IDEs: | IDE | Description | |-----|-------------| | IntelliJ IDEA | Java, Kotlin | | PyCharm | Python | | WebStorm | JavaScript, TypeScript | | PhpStorm | PHP | | GoLand | Go | | Rider | .NET, C# | | CLion | C, C++ | | RustRover | Rust | | RubyMine | Ruby | | Android Studio | Android | **→** [JetBrains Plugin Setup](https://pandev-metrics.com/docs/v1/plugins/jetbrains-plugin) --- ### VS Code & Forks | IDE | Description | |-----|-------------| | Visual Studio Code | Universal editor | | Windsurf AI | AI-powered fork | | Cursor AI | AI-powered fork | **→** [VS Code Plugin Setup](https://pandev-metrics.com/docs/v1/plugins/vsc-plugin) --- ## How It Works 1. **Install** — add the plugin from marketplace or package 2. **Configure** — enter Server URL and credentials 3. **Work** — the plugin tracks activity silently in the background 4. **Analyze** — view metrics in the PanDev Metrics dashboard --- ## Connection Settings For **Cloud (SaaS)**: - **Server URL:** `https://metrics-cloud.pandev.io` For **On-Premise**: - **Server URL:** Your PanDev Metrics server address --- ## Privacy & Security - No source code is captured or transmitted - No screenshots or screen recordings - Activity data includes: file names, project names, time spent, branches - Administrators control which projects are tracked --- ## VS Code Plugin URL: https://pandev-metrics.com/docs/v1/plugins/vsc-plugin # VS Code Plugin The PanDev Metrics plugin for Visual Studio Code automates the collection of engineering activity and performance data inside one of the most popular editors. It shows how developers spend their time, which branches and files they focus on, and where processes can be optimised. ### Highlights - Simple installation from the Marketplace or a private feed (depending on company policy). - True zero-click experience—tracking starts automatically. - Flexible exclusions for directories, file types, or branches. - Secure by design: HTTPS connectivity and no screen capture or personal content. ### Installation 1. Launch Visual Studio Code. 2. Open the **Extensions** view. 3. Search for **PanDev Metrics** and click **Install**. If the plugin is distributed privately, follow your internal instructions for connecting to the private feed. 4. Reload the editor once the installation completes. ### Configuration - In VS Code settings, locate the **PanDev Metrics** section. - Provide the **Server URL** for your PanDev Metrics Core. - Supply an **API token** if required for authentication. - Define exclusions (for example, `node_modules`, `dist`) to keep noisy paths out of the metrics. ### How It Works 1. The plugin logs opened files, time spent editing, and the current branch. 2. Data is sent to PanDev Metrics Core periodically or when the editor is idle. 3. Dashboards in Grafana or the PanDev Metrics UI show the aggregated insights. ### FAQ - **Does it track web browsing?** No, this plugin captures only VS Code activity. Browser telemetry is available via dedicated extensions. - **Can I run it alongside other PanDev Metrics plugins?** Yes. Telemetry from JetBrains, browser, or additional plugins is aggregated centrally by PanDev Metrics Core. --- ## Все релизы PanDev Metrics URL: https://pandev-metrics.com/docs/v1/releases/all-releases # Все релизы PanDev Metrics ## 2025 - [1.11.2](https://pandev-metrics.com/docs/v1/releases/all-releases/2025/release-1-11-2) — PanDev Metrics Core, JetBrains Plugin for PanDev Metrics, VS Code Plugin for PanDev Metrics - [1.11.1](https://pandev-metrics.com/docs/v1/releases/all-releases/2025/release-1-11-1) — PanDev Metrics Core, JetBrains Plugin for PanDev Metrics, VS Code Plugin for PanDev Metrics, Xcode Plugin for PanDev Metrics - [1.11.0](https://pandev-metrics.com/docs/v1/releases/all-releases/2025/release-1-11-0) — PanDev Metrics Core, JetBrains Plugin for PanDev Metrics, VS Code Plugin for PanDev Metrics, Xcode Plugin for PanDev Metrics - [1.10.0](https://pandev-metrics.com/docs/v1/releases/all-releases/2025/release-1-10-0) — PanDev Metrics Core, JetBrains Plugin for PanDev Metrics, VS Code Plugin for PanDev Metrics - [1.9.3](https://pandev-metrics.com/docs/v1/releases/all-releases/2025/release-1-9-3) — PanDev Metrics Core, JetBrains Plugin for PanDev Metrics, VS Code Plugin for PanDev Metrics - [1.9.2](https://pandev-metrics.com/docs/v1/releases/all-releases/2025/release-1-9-2) — PanDev Metrics Core, JetBrains Plugin for PanDev Metrics, VS Code Plugin for PanDev Metrics - [1.9.1](https://pandev-metrics.com/docs/v1/releases/all-releases/2025/release-1-9-1) — PanDev Metrics Core, JetBrains Plugin for PanDev Metrics, VS Code Plugin for PanDev Metrics - [1.9.0](https://pandev-metrics.com/docs/v1/releases/all-releases/2025/release-1-9-0) — PanDev Metrics Core, JetBrains Plugin for PanDev Metrics, VS Code Plugin for PanDev Metrics - [1.8.0](https://pandev-metrics.com/docs/v1/releases/all-releases/2025/release-1-8-0) — PanDev Metrics Core, JetBrains Plugin for PanDev Metrics, VS Code Plugin for PanDev Metrics - [1.7.1](https://pandev-metrics.com/docs/v1/releases/all-releases/2025/release-1-7-1) — PanDev Metrics Core, JetBrains Plugin for PanDev Metrics, VS Code Plugin for PanDev Metrics - [1.7.0](https://pandev-metrics.com/docs/v1/releases/all-releases/2025/release-1-7-0) — PanDev Metrics Core, JetBrains Plugin for PanDev Metrics, VS Code Plugin for PanDev Metrics - [1.6.0](https://pandev-metrics.com/docs/v1/releases/all-releases/2025/release-1-6-0) — PanDev Metrics Core, JetBrains Plugin for PanDev Metrics, VS Code Plugin for PanDev Metrics - [1.5.0](https://pandev-metrics.com/docs/v1/releases/all-releases/2025/release-1-5-0) — PanDev Metrics Core, JetBrains Plugin for PanDev Metrics, VS Code Plugin for PanDev Metrics - [1.4.1](https://pandev-metrics.com/docs/v1/releases/all-releases/2025/release-1-4-1) — PanDev Metrics Core, JetBrains Plugin for PanDev Metrics, VS Code Plugin for PanDev Metrics - [1.4.0](https://pandev-metrics.com/docs/v1/releases/all-releases/2025/release-1-4-0) — PanDev Metrics Core, JetBrains Plugin for PanDev Metrics, VS Code Plugin for PanDev Metrics - [1.3.0](https://pandev-metrics.com/docs/v1/releases/all-releases/2025/release-1-3-0) — PanDev Metrics Core, JetBrains Plugin for PanDev Metrics, VS Code Plugin for PanDev Metrics, Google Chrome Plugin for PanDev Metrics - [1.2.0](https://pandev-metrics.com/docs/v1/releases/all-releases/2025/release-1-2-0) — PanDev Metrics Core, JetBrains Plugin for PanDev Metrics, VS Code Plugin for PanDev Metrics, Google Chrome Plugin for PanDev Metrics - [1.1.0](https://pandev-metrics.com/docs/v1/releases/all-releases/2025/release-1-1-0) — PanDev Metrics Core, JetBrains Plugin for PanDev Metrics, VS Code Plugin for PanDev Metrics, Google Chrome Plugin for PanDev Metrics - [1.0.0](https://pandev-metrics.com/docs/v1/releases/all-releases/2025/release-1-0-0) — PanDev Metrics Core, JetBrains Plugin for PanDev Metrics, VS Code Plugin for PanDev Metrics --- ## 1.0.0 URL: https://pandev-metrics.com/docs/v1/releases/all-releases/2025/release-1-0-0 # Release 1.0.0 **Release date:** 2025-01-19 The first PanDev Metrics release ships the core tooling for collecting, analysing, and visualising engineering activity. ### PanDev Metrics Core **Version:** 2.1.1 - Foundation for collecting metrics from developer machines. - PostgreSQL storage support. - REST API for account management, activity insights, and integrations. - Weekly PDF report generation. - Authentication via LDAP, AD, or the built-in database. - Integrations with Jira and GitLab. ### JetBrains Plugin for PanDev Metrics **Version:** 5.7.0 - Support for IntelliJ IDEA, PyCharm, WebStorm, and other JetBrains IDEs. - Real-time activity visualisations. - Notifications about team performance anomalies. - Streamlined authentication through PanDev Metrics Core. - Project-level metrics split by language and repository. ### VS Code Plugin for PanDev Metrics **Version:** 0.0.5 - Full Visual Studio Code integration. - Activity and productivity tracking. - File and project-level time breakdown. - High-load alerts during workflows. - Sync with PanDev Metrics Core. **Download release:** - PanDev Metrics Core 2.1.1: `docker pull pandevofficial/pandev-metrics:2.1.1` - [JetBrains Plugin 5.7.0](https://cdn.pandev.io/pandev-metrics-plugins-stable/pandev-metrics-plugin-5.7.0.zip) - [VS Code Plugin 0.0.5](https://cdn.pandev.io/pandev-metrics-vscode-plugins-stable/pandev-metrics-plugin-vsc-0.0.5.zip) - [Full environment configuration: pandev_metrics_server.env](https://cdn.pandev.io/pandev-metrics-core/pandev_metrics_server.env) - [Minimal environment configuration: pandev_metrics_server_min.env](https://cdn.pandev.io/pandev-metrics-core/pandev_metrics_server_min.env) --- ## 1.1.0 URL: https://pandev-metrics.com/docs/v1/releases/all-releases/2025/release-1-1-0 # Release 1.1.0 **Release date:** 2025-02-05 Components included: ### PanDev Metrics Core **Version:** 3.0.0 - Fixed IDE data ingestion for multi-module projects. - Relaxed login validation (login no longer has to be an email). - Fixed time tracking when Git integration is disabled. - Added support for the Google Chrome plugin. ### JetBrains Plugin for PanDev Metrics **Version:** 6.2.2 - Fixed login validation. - Correctly extract repository paths. - Added release notifications. - Supported core Git link formats. ### VS Code Plugin for PanDev Metrics **Version:** 0.3.1 - Fixed module names in emitted events. - Tracked activity in the integrated terminal. - Corrected repository path extraction. - Fixed project time in tooltips. - Added link to the analytics dashboard. - Improved the user menu. ### Google Chrome Plugin for PanDev Metrics **Version:** 1.0.0 (Beta) - Whitelist of domains to track. - Blacklist of domains to ignore. - Activity views for today/week/month. - Russian and English localisation. **Download release:** - PanDev Metrics Core 3.0.0: `docker pull pandevofficial/pandev-metrics:3.0.0` - [JetBrains Plugin 6.2.2](https://cdn.pandev.io/pandev-metrics-plugins-stable/pandev-metrics-plugin-6.2.2.zip) - [VS Code Plugin 0.3.1](https://cdn.pandev.io/pandev-metrics-vscode-plugins-stable/pandev-metrics-plugin-vsc-0.3.1.zip) - [Google Chrome Plugin 1.0.0 (Beta)](https://cdn.pandev.io/pandev-metrics-chrome-plugins-stable/pandev-metrics-plugin-chrome-1.0.0.zip) - [Full environment configuration: pandev_metrics_server.env](https://cdn.pandev.io/pandev-metrics-core/pandev_metrics_server.env) - [Minimal environment configuration: pandev_metrics_server_min.env](https://cdn.pandev.io/pandev-metrics-core/pandev_metrics_server_min.env) --- ## 1.10.0 URL: https://pandev-metrics.com/docs/v1/releases/all-releases/2025/release-1-10-0 # Release 1.10.0 **Release date:** 2025-06-23 **Total effort:** 551 hours 11 minutes 46 seconds Components included: ### PanDev Metrics Core **Version:** 4.5.0 - Added Bitbucket integration configuration in the admin console (implementation time: 09:44:54) - Added LDAP configuration in the admin console (implementation time: 23:33:56) - Updated company token handling to support first-run setup in the UI and admin credential entry (implementation time: 44:07:07) - Added mail module support for sending partner-console invitations (implementation time: 22:20:28) - Other enhancements (implementation time: 375:52:02) ### JetBrains Plugin for PanDev Metrics **Version:** 7.4.3 - Fixed data upload indicator in the plugin (implementation time: 00:09:27) - Normalised file paths reported by the plugin (implementation time: 01:14:50) - Other improvements (implementation time: 74:54:02) ### VS Code Plugin for PanDev Metrics **Version:** 0.4.0 **Download release:** - PanDev Metrics Core 4.5.0: `docker pull pandevofficial/pandev-metrics:4.5.0` - [JetBrains Plugin 7.4.3](https://cdn.pandev.io/pandev-metrics-plugins-stable/pandev-metrics-plugin-7.4.3.zip) - [VS Code Plugin 0.4.0](https://cdn.pandev.io/pandev-metrics-vscode-plugins-stable/pandev-metrics-plugin-vsc-0.4.0.zip) --- ## 1.11.0 URL: https://pandev-metrics.com/docs/v1/releases/all-releases/2025/release-1-11-0 # Release 1.11.0 **Release date:** 2025-07-28 **Total effort:** 1,094 hours 4 minutes 42 seconds Components included: ### PanDev Metrics Core **Version:** 4.7.0 - Added Azure DevOps integration (implementation time: 81:36:05) - Moved whitelist configuration into the admin console (implementation time: 43:12:32) - Introduced tenant management (implementation time: 182:26:21) - Made the “Position” field optional when creating employees (implementation time: 04:46:26) - Local execution tracking (implementation time: 22:39:36) - AI assistant (implementation time: 222:21:04) - Bug fixes (implementation time: 85:56:54) - Other improvements (implementation time: 278:55:38) ### JetBrains Plugin for PanDev Metrics **Version:** 8.2.0 - Synced server settings with the JetBrains plugin (implementation time: 24:17:07) ### VS Code Plugin for PanDev Metrics **Version:** 0.4.0 ### Xcode Plugin for PanDev Metrics **Version:** 1.0.2 - Developed the Xcode plugin (implementation time: 147:52:59) **Download release:** - PanDev Metrics Core 4.7.0: `docker pull pandevofficial/pandev-metrics:4.7.0` - [JetBrains Plugin 8.2.0](https://cdn.pandev.io/pandev-metrics-plugins-stable/pandev-metrics-onprem-8.2.0.zip) - [VS Code Plugin 0.4.0](https://cdn.pandev.io/pandev-metrics-vscode-plugins-stable/pandev-metrics-plugin-vsc-0.4.0.zip) - [Xcode Plugin 1.0.2](https://cdn.pandev.io/pandev-metrics-xcode-plugin/pandev-metrics-xcode-plugin-1.0.2.dmg) --- ## 1.11.1 URL: https://pandev-metrics.com/docs/v1/releases/all-releases/2025/release-1-11-1 # Release 1.11.1 **Release date:** 2025-08-14 **Total effort:** 28 hours 49 minutes 59 seconds Components included: ### PanDev Metrics Core **Version:** 4.7.1 - Adjusted raw data processing interval (implementation time: 01:05:48) - Miscellaneous fixes (implementation time: 19:11:32) ### JetBrains Plugin for PanDev Metrics **Version:** 8.2.0 ### VS Code Plugin for PanDev Metrics **Version:** 0.5.0 - Batch upload for the event queue (implementation time: 07:44:19) ### Xcode Plugin for PanDev Metrics **Version:** 1.0.2 **Download release:** - PanDev Metrics Core 4.7.1: `docker pull pandevofficial/pandev-metrics:4.7.1` [docker-compose: pandev_metrics_4_7_1.zip](https://cdn.pandev.io/pandev-metrics-core/pandev_metrics_4_7_1.zip) - [JetBrains Plugin 8.2.0](https://cdn.pandev.io/pandev-metrics-plugins-stable/pandev-metrics-onprem-8.2.0.zip) - [VS Code Plugin 0.5.0](https://cdn.pandev.io/pandev-metrics-vscode-plugins-stable/pandev-metrics-plugin-vsc-0.5.0.zip) - [Xcode Plugin 1.0.2](https://cdn.pandev.io/pandev-metrics-xcode-plugin/pandev-metrics-xcode-plugin-1.0.2.dmg) --- ## 1.11.2 URL: https://pandev-metrics.com/docs/v1/releases/all-releases/2025/release-1-11-2 # Release 1.11.2 **Release date:** 2025-09-19 **Total effort:** 54 hours 20 minutes 35 seconds Components included: ### PanDev Metrics Core **Version:** 4.7.2 - Fixed export issues in the developer Excel report (implementation time: 01:26:48) - Miscellaneous fixes (implementation time: 02:49:58) ### JetBrains Plugin for PanDev Metrics **Version:** 8.2.6 - Resolved UI freezes on slow server connections (implementation time: 25:41:15) - Added upload progress indicator (implementation time: 11:24:45) ### VS Code Plugin for PanDev Metrics **Version:** 0.5.3 - Bug fixes (implementation time: 07:44:19) **Download release:** - PanDev Metrics Core 4.7.2: `docker pull pandevofficial/pandev-metrics:4.7.2` [docker-compose: pandev_metrics_4_7_2.zip](https://cdn.pandev.io/pandev-metrics-core/pandev_metrics_4_7_2.zip) - [JetBrains Plugin 8.2.6](https://cdn.pandev.io/pandev-metrics-plugins-stable/pandev-metrics-onprem-8.2.6.zip) - [VS Code Plugin 0.5.3](https://cdn.pandev.io/pandev-metrics-vscode-plugins-stable/pandev-metrics-plugin-vsc-0.5.3.zip) - [Xcode Plugin 1.0.2](https://cdn.pandev.io/pandev-metrics-xcode-plugin/pandev-metrics-xcode-plugin-1.0.2.dmg) --- ## 1.2.0 URL: https://pandev-metrics.com/docs/v1/releases/all-releases/2025/release-1-2-0 # Release 1.2.0 **Release date:** 2025-03-05 Components included: ### PanDev Metrics Core **Version:** 3.2.0 - Fixed LDAP/AD integration. ### JetBrains Plugin for PanDev Metrics **Version:** 6.3.4 - Bug fixes. ### VS Code Plugin for PanDev Metrics **Version:** 0.3.4 - Improved current branch data extraction. ### Google Chrome Plugin for PanDev Metrics **Version:** 1.0.0 (Beta) **Download release:** - PanDev Metrics Core 3.2.0: `docker pull pandevofficial/pandev-metrics:3.2.0` - [JetBrains Plugin 6.3.4](https://cdn.pandev.io/pandev-metrics-plugins-stable/pandev-metrics-plugin-6.3.4.zip) - [VS Code Plugin 0.3.4](https://cdn.pandev.io/pandev-metrics-vscode-plugins-stable/pandev-metrics-plugin-vsc-0.3.4.zip) - [Google Chrome Plugin 1.0.0 (Beta)](https://cdn.pandev.io/pandev-metrics-chrome-plugins-stable/pandev-metrics-plugin-chrome-1.0.0.zip) - [Full environment configuration: pandev_metrics_server.env](https://cdn.pandev.io/pandev-metrics-core/pandev_metrics_server.env) - [Minimal environment configuration: pandev_metrics_server_min.env](https://cdn.pandev.io/pandev-metrics-core/pandev_metrics_server_min.env) --- ## 1.3.0 URL: https://pandev-metrics.com/docs/v1/releases/all-releases/2025/release-1-3-0 # Release 1.3.0 **Release date:** 2025-03-12 Components included: ### PanDev Metrics Core **Version:** 3.3.0 - Sent worklog entries to Jira. - Bug fixes. - Added Bitbucket integration. - Swagger endpoint moved to `url/docs/swagger-ui/index.html`. ### JetBrains Plugin for PanDev Metrics **Version:** 6.4.1 - Submitted Jira worklog data per commit. - Bug fixes. ### VS Code Plugin for PanDev Metrics **Version:** 0.3.6 - Fixed project activity tooltip. ### Google Chrome Plugin for PanDev Metrics **Version:** 1.0.0 (Beta) **Download release:** - PanDev Metrics Core 3.3.0: `docker pull pandevofficial/pandev-metrics:3.3.0` - [JetBrains Plugin 6.4.1](https://cdn.pandev.io/pandev-metrics-plugins-stable/pandev-metrics-plugin-6.4.1.zip) - [VS Code Plugin 0.3.6](https://cdn.pandev.io/pandev-metrics-vscode-plugins-stable/pandev-metrics-plugin-vsc-0.3.6.zip) - [Google Chrome Plugin 1.0.0 (Beta)](https://cdn.pandev.io/pandev-metrics-chrome-plugins-stable/pandev-metrics-plugin-chrome-1.0.0.zip) - [Full environment configuration: pandev_metrics_server.env](https://cdn.pandev.io/pandev-metrics-core/pandev_metrics_server.env) - [Minimal environment configuration: pandev_metrics_server_min.env](https://cdn.pandev.io/pandev-metrics-core/pandev_metrics_server_min.env) --- ## 1.4.0 URL: https://pandev-metrics.com/docs/v1/releases/all-releases/2025/release-1-4-0 # Release 1.4.0 **Release date:** 2025-04-03 Components included: ### PanDev Metrics Core **Version:** 4.0.0 - Cloud GitLab integration. - Cloud GitHub integration. - Yandex Tracker integration support. - New admin console at `/backoffice` for user and project management. ### JetBrains Plugin for PanDev Metrics **Version:** 7.0.4 - Optimised resource usage. - Improved offline behaviour. - Bug fixes. > After updating the plugin open the settings, enter your password, and click **Save**. ### VS Code Plugin for PanDev Metrics **Version:** 0.3.6 **Download release:** - PanDev Metrics Core 4.0.0: `docker pull pandevofficial/pandev-metrics:4.0.0` - [JetBrains Plugin 7.0.4](https://cdn.pandev.io/pandev-metrics-plugins-stable/pandev-metrics-plugin-7.0.4.zip) - [VS Code Plugin 0.3.6](https://cdn.pandev.io/pandev-metrics-vscode-plugins-stable/pandev-metrics-plugin-vsc-0.3.6.zip) - [Full environment configuration: pandev_metrics_server.env](https://cdn.pandev.io/pandev-metrics-core/pandev_metrics_server.env) - [Minimal environment configuration: pandev_metrics_server_min.env](https://cdn.pandev.io/pandev-metrics-core/pandev_metrics_server_min.env) --- ## 1.4.1 URL: https://pandev-metrics.com/docs/v1/releases/all-releases/2025/release-1-4-1 # Release 1.4.1 **Release date:** 2025-04-11 Components included: ### PanDev Metrics Core **Version:** 4.0.1 - Fixed cloud GitLab integration. - Fixed cloud Jira integration. - Improved issue recognition logic. ### JetBrains Plugin for PanDev Metrics **Version:** 7.0.4 ### VS Code Plugin for PanDev Metrics **Version:** 0.3.9 - Fixed auth error handling. - Better plugin menu experience. **Download release:** - PanDev Metrics Core 4.0.1: `docker pull pandevofficial/pandev-metrics:4.0.1` - [JetBrains Plugin 7.0.4](https://cdn.pandev.io/pandev-metrics-plugins-stable/pandev-metrics-plugin-7.0.4.zip) - [VS Code Plugin 0.3.9](https://cdn.pandev.io/pandev-metrics-vscode-plugins-stable/pandev-metrics-plugin-vsc-0.3.9.zip) - [Full environment configuration: pandev_metrics_server.env](https://cdn.pandev.io/pandev-metrics-core/pandev_metrics_server.env) - [Minimal environment configuration: pandev_metrics_server_min.env](https://cdn.pandev.io/pandev-metrics-core/pandev_metrics_server_min.env) --- ## 1.5.0 URL: https://pandev-metrics.com/docs/v1/releases/all-releases/2025/release-1-5-0 # Release 1.5.0 **Release date:** 2025-04-21 Components included: ### PanDev Metrics Core **Version:** 4.1.0 - Added cloud GitHub integration. - Export payment documents to Excel. - **Important:** For Git repository integrations add the new environment variable `GENERAL_BRANCHNAMES` (comma-separated list of shared branches, e.g. `dev,main,master,test,prod`). ### JetBrains Plugin for PanDev Metrics **Version:** 7.3.2 - Automatic update check, download, and installation. - Error reporting to Sentry. - Bug fixes. - Support for 2025.* IDE releases. ### VS Code Plugin for PanDev Metrics **Version:** 0.4.0 - Align plugin time tracking with the server timezone. - Fixed retrieval of server settings. **Download release:** - PanDev Metrics Core 4.1.0: `docker pull pandevofficial/pandev-metrics:4.1.0` - [JetBrains Plugin 7.3.2](https://cdn.pandev.io/pandev-metrics-plugins-stable/pandev-metrics-plugin-7.3.2.zip) - [VS Code Plugin 0.4.0](https://cdn.pandev.io/pandev-metrics-vscode-plugins-stable/pandev-metrics-plugin-vsc-0.4.0.zip) - [Full environment configuration: full.env](https://cdn.pandev.io/pandev-metrics-core/full.env) - [Minimal environment configuration: min.env](https://cdn.pandev.io/pandev-metrics-core/min.env) --- ## 1.6.0 URL: https://pandev-metrics.com/docs/v1/releases/all-releases/2025/release-1-6-0 # Release 1.6.0 **Release date:** 2025-05-07 Components included: ### PanDev Metrics Core **Version:** 4.2.0 - Added Git integration mode that collects data from all projects. - Managed GitLab and Jira integrations via the admin console. - Enabled changing core application settings in the admin console. - Allowed disabling SSL certificate validation for integrations. ### JetBrains Plugin for PanDev Metrics **Version:** 7.4.0 - Captured file paths for more accurate visualisation. ### VS Code Plugin for PanDev Metrics **Version:** 0.4.0 **Download release:** - PanDev Metrics Core 4.2.0: `docker pull pandevofficial/pandev-metrics:4.2.0` - [JetBrains Plugin 7.4.0](https://cdn.pandev.io/pandev-metrics-plugins-stable/pandev-metrics-plugin-7.4.0.zip) - [VS Code Plugin 0.4.0](https://cdn.pandev.io/pandev-metrics-vscode-plugins-stable/pandev-metrics-plugin-vsc-0.4.0.zip) - [Full environment configuration: full.env](https://cdn.pandev.io/pandev-metrics-core/full.env) - [Minimal environment configuration: min.env](https://cdn.pandev.io/pandev-metrics-core/min.env) --- ## 1.7.0 URL: https://pandev-metrics.com/docs/v1/releases/all-releases/2025/release-1-7-0 # Release 1.7.0 **Release date:** 2025-05-14 **Total effort:** 169 hours 11 minutes 21 seconds Components included: ### PanDev Metrics Core **Version:** 4.2.1 - Fixed behaviour when SSL verification is disabled and a proxy is enabled (implementation time: 01:00:30) - Added endpoints for project activity reporting over a period (implementation time: 07:03:57) - Implemented GitHub integration management via the admin console (implementation time: 12:25:46) - Exported Jira issue hierarchy (implementation time: 08:11:37) - Added Yandex Tracker integration settings in the admin console (implementation time: 12:47:50) - Built the employee calendar UI with Vaadin (implementation time: 29:33:01) - Delivered Excel reports for HR (implementation time: 12:38:31) - Other improvements (implementation time: 75:32:10) ### JetBrains Plugin for PanDev Metrics **Version:** 7.4.1 - Upload progress indicator for file queue processing (implementation time: 03:12:54) - Other improvements (implementation time: 06:45:05) ### VS Code Plugin for PanDev Metrics **Version:** 0.4.0 **Download release:** - PanDev Metrics Core 4.2.1: `docker pull pandevofficial/pandev-metrics:4.2.1` - [JetBrains Plugin 7.4.1](https://cdn.pandev.io/pandev-metrics-plugins-stable/pandev-metrics-plugin-7.4.1.zip) - [VS Code Plugin 0.4.0](https://cdn.pandev.io/pandev-metrics-vscode-plugins-stable/pandev-metrics-plugin-vsc-0.4.0.zip) - [Full environment configuration: full.env](https://cdn.pandev.io/pandev-metrics-core/full.env) - [Minimal environment configuration: min.env](https://cdn.pandev.io/pandev-metrics-core/min.env) --- ## 1.7.1 URL: https://pandev-metrics.com/docs/v1/releases/all-releases/2025/release-1-7-1 # Release 1.7.1 **Release date:** 2025-05-15 **Total effort:** 1 hour 58 minutes 21 seconds Components included: ### PanDev Metrics Core **Version:** 4.2.3 - Fixed errors when SSL verification is disabled and a proxy is enabled (implementation time: 01:34:01) - Improved overall stability (implementation time: 00:24:20) ### JetBrains Plugin for PanDev Metrics **Version:** 7.4.1 ### VS Code Plugin for PanDev Metrics **Version:** 0.4.0 **Download release:** - PanDev Metrics Core 4.2.3: `docker pull pandevofficial/pandev-metrics:4.2.3` - [JetBrains Plugin 7.4.1](https://cdn.pandev.io/pandev-metrics-plugins-stable/pandev-metrics-plugin-7.4.1.zip) - [VS Code Plugin 0.4.0](https://cdn.pandev.io/pandev-metrics-vscode-plugins-stable/pandev-metrics-plugin-vsc-0.4.0.zip) - [Full environment configuration: full.env](https://cdn.pandev.io/pandev-metrics-core/full.env) - [Minimal environment configuration: min.env](https://cdn.pandev.io/pandev-metrics-core/min.env) --- ## 1.8.0 URL: https://pandev-metrics.com/docs/v1/releases/all-releases/2025/release-1-8-0 # Release 1.8.0 **Release date:** 2025-05-21 **Total effort:** 89 hours 17 minutes 28 seconds Components included: ### PanDev Metrics Core **Version:** 4.3.0 - Adjusted the employee activity report (implementation time: 08:55:36) - Added support for GitLab 15 (implementation time: 02:10:40) - Implemented personal schedules in the admin console (implementation time: 07:40:52) - Collected file change data after pushes to shared branches (implementation time: 10:45:29) - Added productivity by role (implementation time: 01:44:19) - Enabled LDAP login to the admin console (implementation time: 18:51:21) - Stored Jira issue hierarchy in the database (implementation time: 09:14:25) - Other improvements (implementation time: 29:54:46) ### JetBrains Plugin for PanDev Metrics **Version:** 7.4.1 ### VS Code Plugin for PanDev Metrics **Version:** 0.4.0 **Download release:** - PanDev Metrics Core 4.3.0: `docker pull pandevofficial/pandev-metrics:4.3.0` - [JetBrains Plugin 7.4.1](https://cdn.pandev.io/pandev-metrics-plugins-stable/pandev-metrics-plugin-7.4.1.zip) - [VS Code Plugin 0.4.0](https://cdn.pandev.io/pandev-metrics-vscode-plugins-stable/pandev-metrics-plugin-vsc-0.4.0.zip) - [Full environment configuration: full.env](https://cdn.pandev.io/pandev-metrics-core/full.env) - [Minimal environment configuration: min.env](https://cdn.pandev.io/pandev-metrics-core/min.env) --- ## 1.9.0 URL: https://pandev-metrics.com/docs/v1/releases/all-releases/2025/release-1-9-0 # Release 1.9.0 **Release date:** 2025-05-28 **Total effort:** 77 hours 7 minutes 13 seconds Components included: ### PanDev Metrics Core **Version:** 4.4.0 - Added project quality analysis (documentation coverage, file cohesion, etc.) (implementation time: 29:20:18) - Captured relative file paths (implementation time: 01:02:13) - Automated webhook setup when enabling the Jira integration (implementation time: 00:25:07) - Other improvements (implementation time: 46:19:35) ### JetBrains Plugin for PanDev Metrics **Version:** 7.4.1 ### VS Code Plugin for PanDev Metrics **Version:** 0.4.0 **Download release:** - PanDev Metrics Core 4.4.0: `docker pull pandevofficial/pandev-metrics:4.4.0` - [JetBrains Plugin 7.4.1](https://cdn.pandev.io/pandev-metrics-plugins-stable/pandev-metrics-plugin-7.4.1.zip) - [VS Code Plugin 0.4.0](https://cdn.pandev.io/pandev-metrics-vscode-plugins-stable/pandev-metrics-plugin-vsc-0.4.0.zip) - [Full environment configuration: full.env](https://cdn.pandev.io/pandev-metrics-core/full.env) - [Minimal environment configuration: min.env](https://cdn.pandev.io/pandev-metrics-core/min.env) --- ## 1.9.1 URL: https://pandev-metrics.com/docs/v1/releases/all-releases/2025/release-1-9-1 # Release 1.9.1 **Release date:** 2025-06-09 **Total effort:** 8 hours 41 minutes 44 seconds Components included: ### PanDev Metrics Core **Version:** 4.4.1 - Fixed handling of GitLab repository update events (implementation time: 02:48:20) - Fixed processing of GitLab merge request events and storing changed files (implementation time: 05:53:24) ### JetBrains Plugin for PanDev Metrics **Version:** 7.4.1 ### VS Code Plugin for PanDev Metrics **Version:** 0.4.0 **Download release:** - PanDev Metrics Core 4.4.1: `docker pull pandevofficial/pandev-metrics:4.4.1` - [JetBrains Plugin 7.4.1](https://cdn.pandev.io/pandev-metrics-plugins-stable/pandev-metrics-plugin-7.4.1.zip) - [VS Code Plugin 0.4.0](https://cdn.pandev.io/pandev-metrics-vscode-plugins-stable/pandev-metrics-plugin-vsc-0.4.0.zip) - [Full environment configuration: full.env](https://cdn.pandev.io/pandev-metrics-core/full.env) - [Minimal environment configuration: min.env](https://cdn.pandev.io/pandev-metrics-core/min.env) --- ## 1.9.2 URL: https://pandev-metrics.com/docs/v1/releases/all-releases/2025/release-1-9-2 # Release 1.9.2 **Release date:** 2025-06-11 **Total effort:** 1 hour 1 minute 24 seconds Components included: ### PanDev Metrics Core **Version:** 4.4.2 - Fixed handling of GitLab repository update events (implementation time: 01:01:24) ### JetBrains Plugin for PanDev Metrics **Version:** 7.4.1 ### VS Code Plugin for PanDev Metrics **Version:** 0.4.0 **Download release:** - PanDev Metrics Core 4.4.2: `docker pull pandevofficial/pandev-metrics:4.4.2` - [JetBrains Plugin 7.4.1](https://cdn.pandev.io/pandev-metrics-plugins-stable/pandev-metrics-plugin-7.4.1.zip) - [VS Code Plugin 0.4.0](https://cdn.pandev.io/pandev-metrics-vscode-plugins-stable/pandev-metrics-plugin-vsc-0.4.0.zip) - [Full environment configuration: full.env](https://cdn.pandev.io/pandev-metrics-core/full.env) - [Minimal environment configuration: min.env](https://cdn.pandev.io/pandev-metrics-core/min.env) --- ## 1.9.3 URL: https://pandev-metrics.com/docs/v1/releases/all-releases/2025/release-1-9-3 # Release 1.9.3 **Release date:** 2025-06-17 **Total effort:** 14 hours 21 minutes 52 seconds Components included: ### PanDev Metrics Core **Version:** 4.4.3 - Fixed duplicate accounts caused by case sensitivity (implementation time: 02:48:50) - Filtered projects based on token access level (implementation time: 11:12:19) - Other improvements (implementation time: 00:20:43) ### JetBrains Plugin for PanDev Metrics **Version:** 7.4.1 ### VS Code Plugin for PanDev Metrics **Version:** 0.4.0 **Download release:** - PanDev Metrics Core 4.4.3: `docker pull pandevofficial/pandev-metrics:4.4.3` - [JetBrains Plugin 7.4.1](https://cdn.pandev.io/pandev-metrics-plugins-stable/pandev-metrics-plugin-7.4.1.zip) - [VS Code Plugin 0.4.0](https://cdn.pandev.io/pandev-metrics-vscode-plugins-stable/pandev-metrics-plugin-vsc-0.4.0.zip) - [Full environment configuration: full.env](https://cdn.pandev.io/pandev-metrics-core/full.env) - [Minimal environment configuration: min.env](https://cdn.pandev.io/pandev-metrics-core/min.env) --- ## 1.11.2 URL: https://pandev-metrics.com/docs/v1/releases/current-release # Release 1.11.2 **Release date:** 2025-09-19 **Total effort:** 54 hours 20 minutes 35 seconds Components included: ### PanDev Metrics Core **Version:** 4.7.2 - Fixed export issues in the developer Excel report (implementation time: 01:26:48) - Miscellaneous fixes (implementation time: 02:49:58) ### JetBrains Plugin for PanDev Metrics **Version:** 8.2.6 - Resolved UI freezes on slow server connections (implementation time: 25:41:15) - Added upload progress indicator (implementation time: 11:24:45) ### VS Code Plugin for PanDev Metrics **Version:** 0.5.3 - Bug fixes (implementation time: 07:44:19) **Download release:** - PanDev Metrics Core 4.7.2: `docker pull pandevofficial/pandev-metrics:4.7.2` [docker-compose: pandev_metrics_4_7_2.zip](https://cdn.pandev.io/pandev-metrics-core/pandev_metrics_4_7_2.zip) - [JetBrains Plugin 8.2.6](https://cdn.pandev.io/pandev-metrics-plugins-stable/pandev-metrics-onprem-8.2.6.zip) - [VS Code Plugin 0.5.3](https://cdn.pandev.io/pandev-metrics-vscode-plugins-stable/pandev-metrics-plugin-vsc-0.5.3.zip) - [Xcode Plugin 1.0.2](https://cdn.pandev.io/pandev-metrics-xcode-plugin/pandev-metrics-xcode-plugin-1.0.2.dmg) [Архив релизов](https://pandev-metrics.com/docs/v1/releases/all-releases) # Other / Misc ## Welcome to PanDev Metrics URL: https://pandev-metrics.com/docs/intro # Welcome to PanDev Metrics PanDev Metrics is an engineering analytics platform that unifies IDE, Git, and task-tracker data into a single analytics layer for development teams. ## Choose Your Deployment | | Cloud (SaaS) | On-Premise | |---|---|---| | **Best for** | Startups, growing teams | Banks, fintech, regulated industries | | **Infrastructure** | Hosted by PanDev | Your own servers | | **Updates** | Automatic | Manual | | **Authentication** | OAuth | LDAP | | **Setup time** | 15-20 minutes | 1-2 hours | --- ## Quick Start ### ☁️ Cloud (SaaS) Fastest way to start. Hosted by PanDev with automatic updates and scaling. **→** [Get started with Cloud](https://pandev-metrics.com/docs/saas-getting-started) --- ### 🏢 On-Premise Full control over data. Deploy in your own infrastructure. **→** [Get started with On-Premise](https://pandev-metrics.com/docs/on-prem-getting-started) | [System requirements](https://pandev-metrics.com/docs/on-prem/system-requirements) --- ### 👤 Personal Workspace Track your own productivity — independent from any team. **Features:** - Personal productivity metrics - Gamification and achievements - Your history stays with you between jobs - Works alongside company workspaces **→** [Create personal workspace](https://pandev-metrics.com/docs/personal-getting-started) --- ## What You Get ### 📊 Deep Engineering Analytics Code, tasks, and IDE signals in one view. Spot where the team needs support early. ### 💬 Data-Driven One-on-Ones Coaching conversations based on facts. Easier to recognize contribution and prevent burnout. ### ⚡ Decisions 30% Faster Leaders and engineers share one view of the work. Priorities align faster. ### 📈 Unified Dashboard Key team metrics consolidated in one place. No extra reports needed. --- ## What's New in v2 - **AI Assistant** — ask questions about your data in natural language - **New integrations** — Azure DevOps, Bitbucket, Yandex Tracker - **More IDEs** — Windsurf AI, Cursor AI, Visual Studio - **Payment reports** — track development costs - **Gamification** — achievements for personal workspace --- ## Need Help? - [Support](mailto:support@pandev.io) — contact the team - [Book a demo](https://pandev.io/book) — see the live system --- ## PanDev Extensions Privacy Policy URL: https://pandev-metrics.com/docs/legal/pandev-extensions-privacy-policy # PanDev Extensions Privacy Policy **Version:** 1.0\ **Effective Date:** January 1, 2025\ **Rights Holder (Provider):** PanDev Ltd > This Policy describes how PanDev extensions for code editors and IDEs handle data. The document aligns in meaning and terminology with the **Extensions EULA** and the **Extensions ToS**. Access to PanDev cloud services is governed by the **Cloud Terms**. Server software deployed at the Customer is governed by the **Self-Managed EULA**. --- ## 1. Scope and Purpose 1.1. The Policy applies only to **PanDev extensions** as a channel for transferring data from an IDE to the Server.\ 1.2. The Policy does **not** set processing rules inside the SaaS. For the cloud, the Cloud Terms and a separate SaaS privacy policy (to be published) apply.\ 1.3. For **on-prem** deployments, processing takes place within the Customer's infrastructure under the Self-Managed EULA. This Policy describes only what data the extensions transmit and how PanDev treats it. ## 2. Roles and Allocation of Responsibilities 2.1. **SaaS.** The Customer is the controller of personal data. PanDev acts as a processor for the cloud. The rules are captured in the Cloud Terms. A DPA may be signed upon request.\ 2.2. **On-prem.** Data is processed and controlled by the Customer in its infrastructure. PanDev is not a processor and does not receive access unless separately agreed.\ 2.3. **Extension diagnostic telemetry.** To improve quality PanDev may process anonymized telemetry about the extensions themselves. In on-prem mode diagnostic telemetry is not used. ## 3. Data Transmitted by the Extensions 3.1. **Activity Data** is metadata about events in the Editor **without source code content**. It includes: - **Event time** and sequence of actions. - **Project and repository context:** project name, modules, repository path or identifier, active branch, links to commits and their parent records. - **File and language context:** file path, file name, programming language, total line count, current line, and cursor position. - **Environment and extension context:** IDE name and version, PanDev extension type and version. - **Execution context:** run type (for example run, debug, or tests), final status, run profile name, executable class name, execution module. - **User and organizational context:** actor or commit author, user ID in the system, company or tenant identifier in PanDev. - **System and network parameters:** user's local timezone, system timezone, device network attributes including IP address, country, and hardware network identifier. - **Short textual event description**, such as a commit message, without embedding file contents. 3.2. **Diagnostic telemetry** consists of anonymized information about the extensions and compatible environment: versions, crashes, performance. In on-prem mode diagnostic telemetry is not used. 3.3. **Not transmitted:** source code content, secrets, keys, tokens, passwords, binary artifacts, or full copies of configuration files. By default the extensions do not send file contents and strive to exclude sensitive areas. 3.4. **Authentication data.** Credentials may be transmitted to sign in to the cloud or on-prem. Transmission uses secure channels, passwords are not logged and are not part of Activity Data. After authentication, tokens with limited validity are used. 3.5. The set of categories and the level of detail are synchronized with the PanDev extension technical specification and aligned with the EULA and ToS. ## 4. Data Sources 4.1. The primary source is the **extension running on the User's machine**.\ 4.2. Additionally, data may come from the **Customer** during project configuration and from **infrastructure logs** in SaaS mode. ## 5. Processing Purposes We use extension-related data for the following purposes: - delivering Activity Data to the Server and ensuring reliable delivery during outages - maintaining integration functionality and version compatibility - diagnosing and resolving incidents - improving extension quality and performance - security and abuse prevention - performing Customer contracts and meeting legal requirements ## 6. Legal Bases 6.1. **SaaS.** The Customer determines legal bases as the controller. PanDev acts as a processor under the Cloud Terms and any applicable DPA.\ 6.2. **On-prem.** Processing is determined by the Customer. PanDev is not a processor.\ 6.3. **Extension diagnostic telemetry.** Processed by PanDev under its legitimate interest in product quality and security. Telemetry is not used for profiling Users and does not include code content. ## 7. Storage 7.1. **Extension local cache.** When the Server is unavailable, the extension temporarily stores events in a local cache and sends them once connectivity is restored. By default the cache is **not limited** in duration or volume and is not configurable inside the extension. The Customer may limit storage through corporate device policies and operating system controls.\ 7.2. **SaaS.** Cloud storage and deletion are governed by the Cloud Terms and the Customer's settings.\ 7.3. **On-prem.** Storage is managed by the Customer.\ 7.4. **Diagnostic telemetry.** Retained for the minimum time needed for diagnostics and improvements, after which the data is deleted or aggregated and anonymized. ## 8. Security 8.1. Data transmission uses **TLS 1.2 or higher** with host verification.\ 8.2. Access tokens and keys are stored in secure operating system vaults where possible.\ 8.3. The local cache is encrypted using OS mechanisms and extension safeguards. The protection level depends on device capabilities and configuration.\ 8.4. The Customer is responsible for device security policies, access management, and updates in its environment. ## 9. Disclosure and Sharing 9.1. **Subcontractors and subprocessors (SaaS).** PanDev may engage vetted subcontractors for hosting and processing when operating the cloud. A list will be published or provided on request.\ 9.2. **On-prem.** PanDev does not receive data except for support under a separate written data access agreement.\ 9.3. **Legal requirements.** We disclose information when required by law and supported by proper legal grounds.\ 9.4. **Cross-border transfers.** In SaaS mode data may move across jurisdictions. PanDev applies organizational and technical measures to protect transferred data. For on-prem, data remains within the Customer's infrastructure. ## 10. Data Subject Rights 10.1. **SaaS.** Data subject requests (access, rectification, deletion, restriction, objection) should be addressed to the Customer as the controller. PanDev supports the Customer to the extent required under the Cloud Terms.\ 10.2. **On-prem.** Requests are handled by the Customer.\ 10.3. **Extension telemetry.** Requests may be sent directly to PanDev. We review and respond within a reasonable time. ## 11. Children and Consumers PanDev extension products are intended solely for business use. We do not target children and do not knowingly collect data about minors. ## 12. Changes to This Policy We may update this Policy. A new version takes effect after publication and notification through the services or by email. Continued use signifies acceptance of the changes. ## 13. Contact Information **Rights Holder (Provider):** PanDev Ltd\ **Office:** 050057, Republic of Kazakhstan, Almaty, Bostandyk District, Gagarin Ave. 124, 4th floor\ **Support:** [privacy@pandev.io](mailto:privacy@pandev.io) and [support@pandev.io](mailto:support@pandev.io) --- ## Appendix A. Alignment with the EULA and ToS A.1. This Policy does not amend or replace the Extensions EULA or the Extensions ToS.\ A.2. For SaaS the Cloud Terms and, if needed, a DPA apply.\ A.3. In on-prem mode PanDev is not a processor and does not access data without separate consent.\ A.4. In on-prem mode extension diagnostic telemetry is not used.\ A.5. The composition of Activity Data and collection exclusions match the appendices to the EULA and ToS. --- ## PanDev Extensions Software License Agreement URL: https://pandev-metrics.com/docs/legal/pandev-extensions-software-license-agreement # PanDev Extensions for Code Editors and IDEs - Software License Agreement **Version:** 1.0\ **Effective date:** 01/01/2025\ **Licensor:** PanDev LLP > This agreement (the "Agreement") is a legally binding contract between you (an individual or an entity, the "Customer") and PanDev governing the installation and use of PanDev software extensions for compatible code editors and integrated development environments (IDEs) (each an "Extension" and collectively the "Extensions", and the relevant application the "Editor"). By installing, copying, or using an Extension you accept the terms of this Agreement. The person performing the installation **represents and warrants** that they act on behalf of and in the interests of the Customer and are **authorized** to accept the Agreement binding the Customer. Installation and use of the Extension are prohibited if the person is not authorized. This Agreement is intended solely for business-to-business use and does not apply to consumer use. --- ## Definitions **"Extension" / "Extensions"** - PanDev software modules installed in compatible code editors and/or IDEs to collect and transmit activity data to the Server. **"Editor"** - a compatible code editor and/or integrated development environment (IDE) where the Extension is installed. **"Server"** - a remote PanDev endpoint (PanDev cloud SaaS or a PanDev instance deployed in the Customer's infrastructure, on-prem) that receives data from the Extension. **"Services"** - PanDev cloud and other services that the Extension can connect to in order to transmit data and obtain functionality; the relevant terms are defined in the ToS and/or the DPA. **"Customer"** - a legal entity or a sole proprietor/individual acting exclusively for business (non-consumer) purposes on whose behalf the Extension is installed and used. **"User"** - an individual (an employee or contractor of the Customer) who uses the Extension in the Editor. **"Activity Data"** - metadata about events in the Editor (for example timestamps, action types, project/file identifiers without content, software versions, and technical identifiers) as described in Appendix A. **"Diagnostic Telemetry"** - anonymized technical information about the Extension itself (state, versions, crashes, performance) that is different from Activity Data. **"Cache" (local cache)** - a temporary local storage area of the Extension used to accumulate Activity Data when the Server is unavailable and to deliver it after connectivity is restored. ## 1. Subject and Scope 1. The Extension is licensed, not sold. All rights in the Extension belong to the Licensor and/or its licensors. 2. The Extension is designed to operate **only when connected to a remote PanDev server** (cloud SaaS or a Customer-hosted instance, the "Server"). Without a connection to the Server the Extension functionality may be fully or partially unavailable. 3. The provision of PanDev Services (including SaaS) is governed by separate Terms of Service (ToS) and/or a Data Processing Agreement (DPA). This Agreement **does not** set the terms for the Services. 4. The "Editor" is a compatible code editor and/or IDE for which PanDev provides the corresponding Extension. ## 2. License and Restrictions 1. The Licensor grants the Customer a non-exclusive, paid or unpaid (depending on the purchased license/subscription), non-transferable, non-sublicensable license **worldwide** **for the term of this Agreement** to install and use the Extension only together with the Editor and in connection with the Server. 2. The Customer must not: (i) bypass technical limitations; (ii) reverse engineer, decompile, or disassemble the Extension except to the extent permitted by applicable law; (iii) provide the Extension to third parties as a service bureau, rent, lease, loan, or redistribute it; (iv) use the Extension or data obtained through it to build, train, test, benchmark, or otherwise develop **competing** software products or services without prior written consent from PanDev; (v) use the Extension in violation of applicable law, including export control and sanctions requirements; or (vi) circumvent authentication, licensing, bandwidth controls, or interfere with the Server. 3. If the Extension includes paid features or subscriptions, additional licensing terms (named/seat, license keys, trial limits) apply and are communicated to the Customer during purchase or activation. 4. The Extension may be used only in accordance with the current PanDev Service terms (ToS) and any agreements between the parties; in case of conflict the applicable agreement or ToS prevails. 5. The Customer is responsible for the acts and omissions of its Users and any third parties that gain access to the Extension and/or the Services through the Customer. ## 3. SaaS and On-Prem Modes, Party Roles 1. When connected to **SaaS**, the Customer acts as the controller of personal data and PanDev acts as the processor in accordance with applicable data protection law. The relationship is governed by the **DPA**, which forms an integral part of the Services and applies only to the extent needed to provide SaaS. 2. When connected to **on-prem**, all Activity Data is processed and **controlled by the Customer** within its own infrastructure. The Customer acts as the controller and operator/processor, and PanDev **does not act as a processor** and does not access the data **unless otherwise expressly agreed** by the parties in a separate document. 3. **Remote support and access to data (if agreed).** If, at the Customer's request, PanDev obtains limited remote access to the on-prem environment or exported materials (for example logs or crash dumps) for support purposes, such access is limited to the minimum necessary scope and is governed by a separate DPA or Data Access Addendum defining the purpose, data categories, duration, and security measures. ## 4. Data Collected and Minimization 1. The Extension collects and sends **IDE activity metadata** to the Server: timestamps, action types, project/file identifiers (paths or patterns without content), IDE/OS versions, and technical identifiers (see Appendix A). 2. **Source code, secrets, and binary artifacts are not transmitted or stored** in the cache. 3. The Customer must ensure that processing is lawful under labor, privacy, and other applicable laws (for example employee notices, consent where required, local restrictions). PanDev is not responsible for the Customer's compliance with employee monitoring requirements. ## 5. Offline Cache and Deferred Delivery 1. If the Server is temporarily unavailable, the Extension stores events in a **temporary local cache** and automatically delivers them once connectivity is restored. 2. By default the local cache is **not limited** by volume or retention period and cannot be configured within the Extension. 3. The cache may be cleared automatically when signing out or switching users. Clearing the cache may cause unrecoverable loss of undelivered events. 4. The Customer accepts the risk of losing some events due to prolonged Server downtime, environment errors, user-driven data deletion, or device security policies. ## 6. Transmission and Storage Security 1. Data is transmitted via **TLS 1.2 or higher** with host verification. 2. The local cache is encrypted using OS capabilities and/or built-in mechanisms of the Extension. Access tokens or keys are stored in the OS-provided secure storage where available. 3. PanDev signs Extension distributions and/or publishes checksums. 4. PanDev is not responsible for data compromise caused by user tampering with system settings, registries, storage, or by disabling OS protection. ## 7. Diagnostic Telemetry of the Extension 1. In addition to user activity events, the Extension may collect **anonymized diagnostic telemetry** (state, crashes, versions, performance) to improve quality. 2. In **on-prem** mode diagnostic telemetry is not used. In **SaaS** mode anonymized diagnostic telemetry may be transmitted. ## 8. Third-Party Components and Open Licenses 1. The Extension may include third-party components distributed under their respective licenses. The list and terms are available in the NOTICE file or the "Licenses" section of the Extension. 2. The terms of such components govern to the extent of any conflict, and take priority over this Agreement where required. ## 9. Intellectual Property and Trademarks 1. The Extension is licensed, not sold. All rights, title, and interest in the Extension, including source code, design, databases, documentation, trade names, marks, and logos of PanDev, belong to the Licensor and/or its licensors. No rights are granted by implication beyond those expressly stated in Section 2. 2. Use of trademarks is permitted only for fair identification of the Extension and does not grant ownership, registration, licensing, or disposition rights to those marks. 3. **White-label/Co-branding.** The Licensor may, under a separate agreement and subject to PanDev brand guidelines, grant the Customer a limited, non-exclusive, non-transferable, and revocable license to use certain PanDev designations, names, and visual elements solely for co-branding the Extensions or their user interface. This license does not transfer any brand rights and terminates upon breach or revocation by the Licensor. 4. The Customer must not remove, modify, or obscure copyright notices, trademark notices, or other intellectual property notices in the Extension. Any user interface customization performed by the Customer must not mislead users about the origin of the Extension. ## 10. Feedback 1. The Customer and/or Users may provide the Licensor with ideas, comments, and other materials about improvements to the Extension or the Services (the "Feedback"). 2. By providing Feedback, the Customer grants the Licensor a free, non-exclusive, perpetual, irrevocable, worldwide license to use, reproduce, modify, publish, distribute, and incorporate the Feedback into the Licensor's products and services without any obligation to attribute or compensate. The Licensor is not obliged to review, implement, or respond to Feedback. ## 11. Updates, Compatibility, and Version Pinning 1. PanDev may release updates, including those that change cache or delivery behavior. 2. The Customer may disable automatic updates and pin a specific version of the Extension, accepting the associated security and compatibility risks. 3. Critical security patches may be marked as mandatory to install. ## 12. Warranties and Liability 1. The Extension is provided "AS IS" without any express or implied warranties, including merchantability, fitness for a particular purpose, or non-infringement. PanDev is not liable for losses resulting from the use of unofficial Extension builds or modifications, or from the use of third-party software or non-standard versions that may affect Extension performance. 2. To the maximum extent permitted by law, PanDev is not liable for any indirect, special, punitive, incidental damages, lost profits, data loss, or claims by the Customer's employees arising from monitoring their activity. 3. PanDev's aggregate liability under this Agreement is limited to **ten (10) US dollars** or the amount paid by the Customer for Extension licenses during the last **three (3) months** (if any fees apply), whichever is greater. Liability for the Services is governed by the applicable ToS and/or DPA. ## 13. Term and Termination 1. This Agreement becomes effective when the Extension is installed and remains in force until the Customer removes the Extension or the Licensor terminates it under the terms of this Agreement. 2. The Licensor may terminate the license unilaterally if the Customer materially breaches the Agreement. The Customer must immediately stop using and delete all copies of the Extension upon termination. 3. Termination does not affect the provisions on intellectual property, disclaimers, liability limitations, governing law, or jurisdiction, all of which survive termination. ## 14. Export Control and Sanctions 1. The parties will comply with applicable export control regimes and economic sanctions. The Customer confirms that it is not subject to sanctions and will not use the Extension in sanctioned jurisdictions in violation of law. ## 15. Governing Law, Jurisdiction, and Language 1. This Agreement is governed by the laws of **Kazakhstan**, and disputes are subject to the competent courts of that jurisdiction. 2. The United Nations Convention on Contracts for the International Sale of Goods (CISG) **does not apply**. 3. In case of interpretation issues, the **Russian** version prevails. 4. PanDev may update this Agreement. Continued use of the Extension after notice constitutes acceptance of the updated version. If you do not agree, remove the Extension. ## 16. Miscellaneous 1. This Agreement is intended solely for **B2B use**. The parties confirm that they act in the course of business and **are not consumers**. To the fullest extent permitted by law, consumer protection statutes do not apply. 2. If any mandatory consumer law provision applies contrary to the parties' intent, it applies only to the minimum extent required and does not affect the validity of the remaining terms. 3. Invalidity of a particular provision does not render the Agreement invalid as a whole. 4. Failure to enforce any right does not constitute a waiver. 5. The parties recognize the legal force of the Agreement and acceptance in electronic form. --- ## Appendix A. Data Categories and Default Exclusions **Categories:** event timestamps; IDE action types (navigation, editing, build, run, window/focus switches); project/repository identifiers; relative or normalized file paths/patterns; IDE/extension/plugin versions; OS version; technical device/session identifiers. **Exclusions (default patterns):** `**/secrets/**`, `**/*.key`, `**/.env*`, `**/node_modules/**`, directories containing confidential materials. **File contents/secrets:** are not collected or transmitted. --- ## Contacts **Licensor:** PanDev LLP\ **Office:** 050057, Republic of Kazakhstan, Almaty, 124 Gagarin Ave.\ **Support:** [**support@pandev.io**](mailto:support@pandev.io) --- ## PanDev Extensions Terms of Service URL: https://pandev-metrics.com/docs/legal/pandev-extensions-terms-of-service # PanDev Extensions Terms of Service (ToS) **Version:** 1.0\ **Effective Date:** January 1, 2025\ **Rights Holder (Provider):** PanDev Ltd > These terms govern only the use of PanDev software extensions for code editors and IDEs as a channel for transferring data from the IDE to PanDev services. Access to and rules for using the cloud services (SaaS) are defined in the Cloud Terms. The rules for server software deployed at the Customer (on-prem, self-managed) are set out in the Self-Managed EULA. Licensing of the Extensions themselves is governed by the Extensions EULA. --- ## Definitions **"Extensions"** - PanDev software modules installed in compatible code editors and IDEs that collect and transmit activity data to the Server.\ **"Editor"** - A compatible code editor or integrated development environment (IDE) in which an Extension is installed.\ **"Services (SaaS)"** - PanDev cloud services delivered from PanDev cloud infrastructure.\ **"Software (on-prem, self-managed)"** - PanDev server software deployed in the Customer's infrastructure under the Self-Managed EULA.\ **"Server"** - A remote endpoint that receives data from the Extensions. The Server may be the Platform (PanDev cloud) or the Customer's on-prem instance.\ **"Platform"** - PanDev cloud infrastructure on which the SaaS operates.\ **"Cloud Terms"** - Separate PanDev terms that govern access to and use of the SaaS.\ **"Customer"** - A legal entity that has entered into an agreement with PanDev.\ **"User"** - A Customer employee or contractor authorized to work with the Extensions.\ **"Activity Data"** - Metadata about events in the Editor without source code content. The categories are described in Appendix A.\ **"Diagnostic Telemetry"** - Anonymized technical information about the Extensions themselves (status, versions, crashes, performance) that is different from Activity Data.\ **"Cache"** - A temporary local storage used by the Extensions to accumulate Activity Data when the Server is unavailable and to forward it once connectivity is restored. ## 1. Scope and Order of Precedence 1.1. **SaaS.** These terms do not govern access to PanDev cloud services or set any rules for their use. Access to the SaaS is regulated by the Cloud Terms. This document describes only the use of the Extensions as a channel for transferring data from an IDE to the Services. Licensing of the Extensions themselves is governed by the Extensions EULA. 1.2. **On-prem.** Rights of use and limitations for software deployed by the Customer are defined in the Self-Managed EULA. These terms apply to on-prem only where they explicitly state "applies to on-prem," and when the on-prem instance uses PanDev cloud sub-services such as license updates, the extension catalog, or telemetry when it is enabled. 1.3. **Order of precedence.** If documents conflict, the order of precedence is: first, the agreement with the Customer; second, the Self-Managed EULA for on-prem or the Cloud Terms for SaaS; third, this ToS; fourth, published PanDev policies that are expressly incorporated by reference; fifth, the Extensions EULA. ## 2. Access and Accounts 2.1. Access to the SaaS is governed by the Cloud Terms. This ToS describes only the use of the Extensions as a data transfer channel and does not set rules for cloud access. 2.2. In on-prem deployments the Customer administers accounts and access. When an on-prem instance uses PanDev cloud sub-services, those sub-services are subject to these terms. ## 3. Extension Operation and Offline Cache 3.1. The Extensions collect and transmit Activity Data to the Server, which may be the cloud Platform or the Customer's on-prem instance. 3.2. If the Server is temporarily unavailable, the Extensions store events in a local cache and automatically transmit them once the connection is restored. 3.3. Source code contents and secrets are not transmitted or stored in the cache by default. 3.4. Some features require the Extensions to be installed and functioning correctly. PanDev is not responsible for blocks or environment changes introduced by the Customer. 3.5. For on-prem, PanDev does not receive Activity Data unless the parties agree on limited access for support purposes under a separate data access agreement. ## 4. Customer Obligations 4.1. Comply with applicable law, including labor and personal data law, and inform employees and obtain consents where required. 4.2. Ensure the legality of Customer Content and refrain from submitting unlawful materials. 4.3. Comply with this ToS, the Extensions EULA, the Self-Managed EULA for on-prem, agreements with third parties, and PanDev policies when expressly incorporated by reference. ## 5. Acceptable Use Illegal activity, circumvention of technical restrictions, interference with the Platform, scanning and load testing without consent, distribution of malicious code, using the Extensions or data to create or train competing solutions without PanDev's written consent, sharing credentials, violations of intellectual property rights, and breaches of export-control or sanctions regimes are prohibited. PanDev may publish a detailed policy later, which will supplement this section without reducing the Customer's rights. ## 6. Data and Security 6.1. **SaaS.** Processing of personal data in the cloud is governed by the Cloud Terms and PanDev's Privacy Policy. Upon request the parties may enter into a separate data processing agreement (DPA). This ToS does not establish rules for processing within the SaaS and covers only the use of the Extensions as a data transfer channel. 6.2. **On-prem.** Data is processed within the Customer's infrastructure. The Customer acts as controller and operator or processor. PanDev is not a processor and does not receive access to data unless otherwise agreed in writing. 6.3. **On-prem support.** At the Customer's request PanDev may receive limited remote access to the on-prem environment or to exported materials such as logs and crash dumps strictly in the minimum volume necessary. Such access is governed by a separate data access agreement. 6.4. **Security incidents.** For SaaS PanDev notifies the Customer about confirmed incidents affecting its data and acts in accordance with internal procedures and applicable law. For on-prem, incidents in the Customer's environment are the Customer's responsibility. ## 7. Availability, Support, and Updates 7.1. **SaaS.** Availability metrics and support are governed by the Cloud Terms. This ToS does not set cloud availability metrics. 7.2. **Integration via Extensions.** PanDev maintains integration sub-services such as authentication and telemetry intake on a commercially reasonable basis and may update interfaces and client versions. 7.3. **On-prem.** Support and updates for server software are governed by support and maintenance terms, if purchased. 7.4. **Extension updates.** PanDev may release functional and security updates. Some updates require specific Extension versions. Critical security updates may be mandatory. 7.5. **Suspension of SaaS integration.** PanDev may restrict cloud sub-services related to data transfer via the Extensions if these terms are violated or if there is a threat to the Platform's security. Full cloud access terms are governed by the Cloud Terms. 7.6. **Data export and deletion.** These terms govern only data transferred via the Extensions. Export and deletion within the SaaS are described in the Cloud Terms. For on-prem the Customer provides export and deletion. ## 8. Intellectual Property and Feedback 8.1. All rights to the Services, server software, and Extensions belong to PanDev and its licensors. 8.2. Customer Content remains the Customer's property. The Customer grants PanDev a limited license to use that content to the extent necessary to operate the cloud or cloud sub-services. 8.3. PanDev may use feedback free of charge, for any duration, and without any obligation of attribution or compensation. ## 9. Warranties and Disclaimers 9.1. The Extensions and related integration sub-services are provided "AS IS" and "AS AVAILABLE." PanDev does not guarantee the complete absence of errors or full alignment with expectations. 9.2. For on-prem, warranty provisions and limitations are specified in the Self-Managed EULA. 9.3. PanDev is not responsible for limitations caused by the Customer's security settings, environment, or third-party blocks. ## 10. Limitation of Liability 10.1. To the maximum extent permitted by law, PanDev is not liable for indirect, special, or punitive damages, lost profits, loss of data, or reputational harm. 10.2. PanDev's aggregate liability under this document is limited to the greater of ten US dollars or the amount paid by the Customer for Extension licenses during the three calendar months preceding the event. Liability for providing the SaaS and for on-prem server software is defined in the Cloud Terms and the Self-Managed EULA. 10.3. Nothing limits liability for willful misconduct, harm to life or health, or other cases where limitation is prohibited by law. ## 11. Export Control and Sanctions The parties comply with applicable sanctions regimes and export-control regulations. The Customer confirms it is not a sanctioned entity and undertakes not to use the Services and Software in violation of such restrictions. ## 12. Governing Law and Disputes The law of the Republic of Kazakhstan applies. Disputes are resolved by the competent courts of Almaty. The parties may agree to mediation or arbitration. The United Nations Convention on Contracts for the International Sale of Goods (CISG) does not apply. ## 13. Term, Changes, and Termination 13.1. These terms apply from the effective date above until termination. 13.2. PanDev may update this document. Changes become effective after publication and notification via the Services or by email. Continued use constitutes acceptance of the new version. 13.3. Notices are sent to the contacts listed in the agreement or the account and are deemed received when sent. 13.4. **Stopping use of the Extensions.** PanDev may restrict or terminate the use of the Extensions if these terms, legal requirements, or security measures are violated. The Customer may stop using the Extensions at any time by removing them from the Editor. Stopping the use of the Extensions does not affect the validity of SaaS or on-prem agreements and does not release the parties from obligations that survive termination, such as confidentiality and limitation of liability. ## 14. Miscellaneous The invalidity of a provision does not invalidate the entire document. Failure to exercise a right does not constitute a waiver. The document is concluded electronically. The parties act as independent contractors. --- ## Appendix A. Data Categories (for Extensions) - Timestamps of events in the Editor.\ - Types of actions in the Editor: navigation, editing, build, run, window focus.\ - Project and file identifiers without content.\ - Versions of the Editor, operating system, and installed extensions.\ - Technical device and session identifiers.\ - Diagnostic telemetry about the Extensions: versions, crashes, performance. **In on-prem mode diagnostic telemetry is not used.** --- ## Contacts **Rights Holder:** PanDev Ltd\ **Office:** 050057, Republic of Kazakhstan, Almaty, Gagarin Ave. 124\ **Support:** [**support@pandev.io**](mailto:support@pandev.io) --- ## Privacy Policy URL: https://pandev-metrics.com/docs/legal/privacy-policy # Policy on the Collection, Processing, and Protection of Personal Data **PanDev LLP** | BIN: 230140037871 | Version dated 09 February 2026 This Personal Data Processing Policy has been prepared in accordance with the requirements of the Law of the Republic of Kazakhstan No. 94-V dated 21 May 2013 "On Personal Data and Their Protection" and defines the procedure for the processing of personal data, as well as the measures to ensure the security of personal data implemented by the Personal Data Operator — PanDev Limited Liability Partnership (LLP), BIN 230140037871. The Operator considers compliance with the rights and freedoms of individuals and citizens to be a fundamental objective and a mandatory condition of its activities when processing personal data, including the protection of the right to privacy and personal and family secrecy. This Personal Data Processing Policy (hereinafter referred to as the "Policy") applies to all information that the Operator may obtain about visitors of the Website: https://workspace.pandev.io. The Policy constitutes an integral part of the License Agreement in the form of a public offer published on the Website and shall apply to all personal data processed by the Operator. --- ## 1. Terms and Definitions Key terms used in the Policy: 1.1. **Automated Processing of Personal Data** — processing of personal data by means of computer technology. 1.2. **Blocking of Personal Data** — temporary suspension of the processing of personal data (except where processing is necessary to clarify personal data). 1.3. **Website** — a set of graphic and informational materials, as well as computer programs and databases, united by a common purpose and ensuring their availability on the Internet at the following URL: https://workspace.pandev.io. 1.4. **Processing of Personal Data** — any action (operation) or set of actions (operations) performed with or without the use of automation tools in relation to personal data, including collection, recording, systematization, accumulation, storage, clarification (updating, modification), retrieval, use, transfer (dissemination, provision, access), anonymization, blocking, deletion, and destruction of personal data. 1.5. **Personal Data** — any information relating directly or indirectly to an identified or identifiable Client of the Website. 1.6. **Personal Data Permitted for Dissemination by the Personal Data Subject** — personal data to which access is granted to an unlimited number of persons by the personal data subject through the provision of consent to the processing of personal data permitted for dissemination in accordance with the procedure established by the Law on Personal Data (hereinafter — "Personal Data Permitted for Dissemination"). 1.7. **Client / User** — any visitor of the Website. 1.8. **Provision of Personal Data** — actions aimed at disclosing personal data to a specific person or a specific group of persons. 1.9. **Dissemination of Personal Data** — any actions aimed at disclosing personal data to an indefinite number of persons (transfer of personal data) or at making personal data available to an unlimited number of persons, including publication of personal data in mass media, placement in information and telecommunication networks, or provision of access to personal data by any other means. 1.10. **Cross-Border Transfer of Personal Data** — transfer of personal data to the territory of a foreign state to a public authority of a foreign state, a foreign natural person, or a foreign legal entity. --- ## 2. Personal Data Database Operator The operator of the database containing users' personal data is the Company: | | | |---|---| | **Name** | PanDev Limited Liability Partnership (LLP) | | **BIN** | 230140037871 | | **Location** | Almaty, Bostandyq District, Republic of Kazakhstan, 30/8 Satpaev Street, office 139, Postal Code: 050040 | | **E-mail** | bakbergenov@pandev.io | | **Phone** | +7 747 451 9454 | | **Telegram** | @mbakbergenov | | **Bank details** | Account: KZ878562203148733359 | | **Bank** | JSC "Bank CenterCredit" | | **BIC** | KCJBKZKX | --- ## 3. Personal Data Subjects 3.1. Personal data subjects shall include all Clients of the Website who have completed registration thereon and/or have paid remuneration to the Licensor. --- ## 4. Term of Consent 4.1. This Consent is granted to the Company unconditionally for an indefinite period. 4.2. In the event of a need to withdraw this Consent, the Client shall submit a corresponding written request to the Company, delivered in person or sent to the Company's registered address. --- ## 5. Conditions for the Transfer and Processing of Personal Data 5.1. The processing of Users' personal data is carried out on the following legal grounds: - the consent of the personal data subject; - the necessity to conclude and perform the User Agreement; - compliance with the requirements of the legislation of the Republic of Kazakhstan; - protection of the rights and legitimate interests of the Company and third parties. 5.2. Personal data shall be processed on a lawful, fair, and proportionate basis and shall be limited to the achievement of specific and legitimate purposes. 5.3. The scope and content of personal data shall correspond to the declared purposes of processing. 5.4. The personal data provided by the Client must be accurate and up to date. 5.5. Withdrawal of consent to the processing of personal data does not affect the legality of processing carried out prior to such withdrawal, and does not terminate the processing of personal data in cases provided for by the legislation of the Republic of Kazakhstan. 5.6. The User hereby consents to the Company transferring personal data to third parties, including cross-border transfer, if such transfer is necessary for the proper performance by the Company of its obligations under the public offer published on the Website, as well as for the purposes of improving and further developing the Website. --- ## 6. Purposes of Personal Data Use 6.1. The Company collects, stores, transfers, and processes Users' personal data in compliance with the legislation of the Republic of Kazakhstan for the following purposes: - identification of the Client; - registration and administration of user accounts; - conclusion and performance of the License Agreement; - providing access to the functionality of the Software Product; - provision of paid and free services; - ensuring the security of the Platform; - prevention of abuse and violations; - review of requests, complaints, and claims; - protection of the rights and legitimate interests of the Company; - compliance with the requirements of the legislation of the Republic of Kazakhstan. 6.2. The Company may disclose personal data in publicly available sources if such disclosure is required by the purposes of personal data use set out in this Section. --- ## 7. List of Personal Data 7.1. Users' personal data may include the following information: - surname, first name, patronymic (if any); - IIN (for individuals); - BIN (for legal entities); - name of the legal entity; - status of the subject (individual, sole proprietor, legal entity); - phone number; - email address; - User account data; - IP address; - information about browser, device, and operating system; - date and time of registration, login, and acceptance of agreements; - technical and system logs of the Platform; - information voluntarily provided by the User; - information obtained from public sources; - portrait image (photograph), if such image has been uploaded by the User in the personal account on the Website. --- ## 8. Principles of Collection, Storage, Transfer, and Processing of Personal Data 8.1. The Company processes personal data on a lawful and fair basis for the achievement of the stated purposes, including the proper performance of its obligations under the public offer published on the Website. 8.2. The Company obtains personal data directly from Users, unless otherwise provided by this Agreement or the public offer. 8.3. The Company processes personal data using both automated and non-automated means, with and without the use of computer technology. Personal data is collected in the following ways: - provision of personal data by the User when filling out forms on the Website; - automatic collection of personal data through technologies and services; - provision of personal data by the User in written form, including via communication tools; - and by other means not prohibited by the legislation of the Republic of Kazakhstan. 8.4. The Company shall ensure confidentiality of personal data, except in cases where such data is publicly available. 8.5. Personal data may be transferred to authorized state bodies of the Republic of Kazakhstan only on the grounds and in the manner established by the legislation of the Republic of Kazakhstan. --- ## 9. Security of Personal Data 9.1. When processing personal data, the Company takes the necessary legal, organizational, and technical measures, or ensures their adoption, to protect personal data against unauthorized or accidental access, destruction, alteration, blocking, copying, provision, dissemination, as well as any other unlawful actions in relation to personal data. 9.2. The measures implemented by the Company to ensure the security of personal data during their processing are planned and executed in order to comply with the requirements of the legislation of the Republic of Kazakhstan in the field of personal data protection. 9.3. The Company does not guarantee absolute protection of personal data in the event of unlawful actions by third parties. --- ## 10. Rights of the Client 10.1. The Client shall have the right: 10.1.1. to request information regarding the personal data being processed; 10.1.2. to request clarification (modification) of their personal data in the event that such data is incomplete, outdated, or inaccurate; 10.1.3. to withdraw consent previously granted for the collection, processing, and transfer of personal data; 10.1.4. to protect their rights and legitimate interests, including the right to seek compensation for losses and moral damages through judicial proceedings; 10.1.5. to appeal against actions or inaction of the Company to the authorized consumer protection body or through judicial proceedings. 10.3. For the exercise of their rights and legitimate interests, the Client shall have the right to contact the Company in accordance with the procedure established by the legislation of the Republic of Kazakhstan. --- ## 11. Final Provisions 11.1. This Policy shall be interpreted in accordance with the legislation of the Republic of Kazakhstan. Matters not regulated by this Policy shall be resolved in accordance with the legislation of the Republic of Kazakhstan. 11.2. This Policy is published in the relevant section of the Website. Registration by the Client on the Website, as well as payment of remuneration to the Licensor, shall constitute the Client's consent to the Company for the collection, storage, transfer, and processing of their personal data in the manner provided for by this Consent. In the event the Client disagrees with any provision of this Consent, the Client shall cease using the Company's services and delete their account on the Website. 11.3. The Client shall have the right to withdraw consent for the collection, processing, storage, and transfer of personal data at any time. Withdrawal of consent shall be carried out in accordance with the procedure established by the legislation of the Republic of Kazakhstan on personal data and their protection, through a state service, a non-state service, or any other method allowing confirmation of the fact of withdrawal of consent. 11.4. This Agreement shall enter into force with respect to each Client from the moment the Client performs the actions specified in clause 11.2 of this Consent. 11.5. The Company shall have the right to unilaterally amend this Policy. The new version shall enter into force from the moment it is published on the Platform. --- ## Public Offer URL: https://pandev-metrics.com/docs/legal/public-offer # License Agreement in the Form of a Public Offer ::: This License Agreement in the form of a Public Offer (hereinafter — the Agreement), in accordance with paragraph 5 of Article 395 of the Civil Code of the Republic of Kazakhstan, constitutes a public offer (oferta) of the Limited Liability Partnership «PanDev», BIN 230140037871 (hereinafter — the Licensor), addressed to an indefinite number of persons for the purpose of granting a Non-Exclusive License and other related services (hereinafter — the Services). This Agreement governs the general terms and conditions for the provision of a Non-Exclusive License and other related services by the Licensor to persons (natural persons, individual entrepreneurs, and legal entities regardless of the form of ownership) who have accepted the terms of this Agreement (hereinafter — the Licensee). The terms of the Agreement are established by the Licensor unilaterally in accordance with the legislation of the Republic of Kazakhstan and are accepted by the Licensee solely by adhering to the Agreement in its entirety. The performance of conclusive acts (conduct) by the Licensee shall constitute the Licensee's unconditional acceptance of the terms of the Agreement and adherence thereto in full. The fact of the Licensee's adherence to and acceptance (acceptance) of the terms of this Agreement shall be deemed to have occurred upon the Licensee's performance of the following conclusive acts — registration on the Licensor's platform (https://workspace.pandev.io/auth), and, upon subsequent amendments to the Agreement, payment of the Licensor's remuneration after the new version of the Agreement has been posted on the Licensor's website (Article 396, paragraph 3 of the Civil Code of the Republic of Kazakhstan). --- ## 1. Terms and Definitions 1.1. **"Software Product" (Software)** — the software "PanDev Metrics", including any updates, patches (bug-fixes), plugins and add-ons, available on the Licensor's Website, integrated with the Licensee's systems and enabling the generation of metrics, reports, and other functionally available indicators. The description of the Software Product's features and tools is available on the Website at https://pandev.io/ru (hereinafter — the Website). All rights to the Software Product and its components, individually and collectively, belong to the Licensor in full. No provision of this Agreement may be construed as a transfer (assignment) of exclusive rights to the Software Product to the Licensee or as permission to use it in any manner not provided for in this Agreement. 1.2. **"License" (License)** — a simple (non-exclusive), non-transferable, and non-sublicensable license to use the Software Product granted by the Licensor. The grant of the License under this Agreement means the provision of remote access to the functional capabilities of the Software Product (SaaS) via the Internet. 1.3. **"License Term" (License Term)** — the period of validity of the License, upon expiration of which access to the Software Product is fully terminated for the Licensee. 1.4. **"Rates" (Tariffs)** — the Licensor's price list, available at https://pandev.io/ru in the "Pricing" section, which determines the amount of the license fee and the paid functionality of the Software Product provided in exchange. The Licensor shall have the right to establish special Rate conditions as set out in a commercial offer or separate agreements sent to and executed by the Parties. 1.5. **"Users" (Authorized Users)** — employees or persons authorized by the Licensee to access the Software Product and included in the license metric. 1.6. **"Licensee's Developer" (Customer Developer)** — an active user of the Licensee's infrastructure in respect of whom data is collected, analyzed, and/or displayed within the Software Product for the purposes of objectively measuring their performance. 1.7. **"Support" (Support Services)** — technical assistance and consultations, including error resolution. 1.8. **"Response Time" (Response Time)** — the maximum period for the Licensor to respond to a Licensee's inquiry via Telegram — 1 (one) business day. 1.9. **"Support Channel" (Support Channel)** — the Telegram chat or other agreed means of communication used for receiving and processing the Licensee's requests. 1.10. **"Reverse Engineering" (Reverse Engineering)** — the study of the Software Product in whole or in part, as well as its documentation, for the purpose of reproducing a similar product. 1.11. **"Billing Period" (Billing Period)** — the calendar month for which the cost of the License is calculated. 1.12. In the Parties' calculations, the term "month" shall mean 30 calendar days, and the term "year" shall mean 365 days. 1.13. Other terms shall be interpreted in accordance with the legislation of the Republic of Kazakhstan. --- ## 2. Subject Matter of the Agreement 2.1. The Licensor, being the rightsholder and owner of exclusive rights to the software product "PanDev Metrics", and having the exclusive right to distribute the Software Product "PanDev Metrics", grants to the Licensee the right to use the Software Product and its functionality under a simple (non-exclusive) license, within the scope and on the terms provided for in this Agreement; while the Licensee undertakes to use the Software Product in accordance with the terms of this Agreement and to pay the license fee for such use in accordance with the selected Rate and additional options. 2.2. The Licensor shall provide technical support (Support), including rectification of technical errors in the Software Product itself, if any, in the manner and to the extent determined by this Agreement. 2.3. The collection, storage, use, and protection of personal data are governed by a separate document — the "Personal Data Processing Policy" (hereinafter — the Policy), published on the Website. The Policy is an integral part of this Agreement, and the Licensee confirms its acceptance of the Policy at the time of accepting this Agreement. 2.4. Accordingly, the Agreement consists of: 2.4.1. "License Agreement" — permanently published in the public domain on the Licensor's Website. 2.4.2. "Personal Data Processing Policy" — permanently published in the public domain on the Licensor's Website. --- ## 3. Registration 3.1. Registration shall be deemed completed at the moment the Licensee submits the completed electronic form to the Licensor via the Website's functionality. 3.2. Prior to submitting the electronic form, the Licensee must read the provisions of the Agreement. By submitting the electronic form, the Licensee confirms that the terms of the Agreement are understood and accepted in full. 3.3. The Licensee and the person authorized by the Licensee to complete Registration and fill in information in the Personal Account represent and warrant that they act in good faith, and in particular that: 3.3.1. The personal data provided during Registration and in the Personal Account is current, accurate, and does not belong to a third party. The Licensee warrants that all necessary consents for data processing have been obtained in cases where the personal data of authorized persons is provided to the Licensor. 3.3.2. If, at the time of Registration, a person acts on behalf of the Licensee — a legal entity or individual entrepreneur — such person warrants that they possess the necessary authority to accept the Agreement. Acceptance of the Agreement does not require approval from the Licensee's governing bodies, and the Agreement is concluded within the ordinary course of the Licensee's business activities. 3.4. The Licensor shall have the right to request from the Licensee confirmation of the Licensee's authority (a copy of a power of attorney or a copy of a document confirming the authority to enter into transactions on behalf of a legal entity without a power of attorney) and, in the event of non-provision, to restrict access to the System until the relevant document is received. --- ## 4. Scope and Activation of the License 4.1. The Licensor grants to the Licensee the right to use the Software Product under a simple (non-exclusive), non-sublicensable, and non-transferable License within its functional capabilities by connecting to the Software Product via the Internet. 4.2. The Licensor grants the Licensee the ability to use the Software Product on a paid basis (with access to paid functionality) or on a free-of-charge basis with limited functionality, depending on the mode of use and/or the Rate selected by the Licensee. 4.3. Use of the Software Product within the free (limited) functionality does not exempt the Licensee from compliance with the terms of this Agreement. Licensees using the Software Product without paying a license fee shall have the same obligations, responsibilities, and restrictions as Licensees using the paid functionality, except for rights directly associated with the scope of the paid functionality. 4.4. Access to the paid functionality of the Software Product is granted to the Licensee from the date of receipt of the license fee. In the event of any access problems, the Licensee must immediately contact the Licensor to identify and resolve the causes preventing access. If the relevant request from the Licensee is not received within 5 (five) business days from the date of payment, access shall be deemed duly provided. 4.5. Access to the Software Product shall terminate upon exhaustion of the license fee paid by the Licensee. 4.6. The License Term (period of validity of the License) is determined by the "License Term" section of this Agreement. 4.7. The License is granted for the duration of the License Term and includes the right to use all functionality of the Software Product in accordance with its intended purpose, including the use of the functional capabilities embedded in the product, under the terms set forth in this Agreement. ### 4.8. The Licensee is prohibited from: 4.8.1. transferring, selling, leasing, providing for use to third parties, or otherwise distributing the Software Product (including to partners, contractors, clients, etc.) unless otherwise agreed in a separate written agreement with the Licensor; 4.8.2. granting third parties access to the Software Product via remote connections, APIs, or other technical means; 4.8.3. modifying, adapting, altering, localizing, or otherwise making changes to the Software Product, including its user interface, database structure, data processing logic, or other components; 4.8.4. creating derivative products based on the Software Product or cracking images; 4.8.5. performing Reverse Engineering, including but not limited to: - decompilation, disassembly, decryption, code analysis; - reconstruction of source code, algorithms, architecture, or operational logic of the product; - analysis for the purpose of copying, reproducing, or creating functionally equivalent solutions. caution The prohibition on Reverse Engineering applies regardless of the purpose for which it is performed. ::: 4.8.6. incorporating the Software Product into other software solutions, platforms, or services intended for distribution to third parties. --- ## 5. Support 5.1. Support includes the Licensor's services specified in this Agreement. The cost of the Licensor's services within the scope of Support is included in the cost of the License. 5.1.1. Consulting on the use of the Software Product; 5.1.2. Resolution of technical errors in the Software Product itself, if any; 5.1.3. Providing technical feedback in response to the Licensee's inquiries, including recommendations, instructions, and explanations related to the operation of the Software Product. 5.2. The Licensor shall provide feedback on the Licensee's technical support requests within one business day from receipt of the request via the agreed communication channel. The resolution time for a technical support request shall be determined by agreement with the Licensee. 5.3. Support is provided remotely during the Licensor's business hours via the Telegram messenger (or another channel agreed upon by the Parties). A request shall be deemed received at the moment of its delivery to the Licensor through the specified channel during business hours. 5.4. Support does not extend to incidents caused by actions of third parties, improper use, or use of the Software Product outside the conditions provided for in this Agreement, or in violation of the product usage rules published on the platform at: https://pandev.io/ru --- ## 6. Rights and Obligations of the Parties ### 6.1. Under this Agreement, the Licensor undertakes to: 6.1.1. Grant the Licensee the License to the Software Product during the License Term. 6.1.2. Provide Support to the Licensee in the form of consultations on the use of the Software Product, diagnosis and resolution of product errors (bug-fixes) at its own expense, and timely feedback through the Support Channel in accordance with the Response Time and the Licensor's procedures. 6.1.3. Ensure a Response Time to the Licensee's requests of no more than one (1) business day from the time of receipt. The response may include: diagnostic information, recommendations, or a reasonable proposal for the timeline for resolution and further actions if an immediate solution is not possible. 6.1.4. No later than within 5 (five) calendar days after the end of each billing period, provide the Licensee with a Certificate of Completion and an Invoice, drawn up in accordance with the requirements of the legislation of the Republic of Kazakhstan. 6.1.5. Comply with the legislation of the Republic of Kazakhstan, the rules of the Corporate Foundation "International Technology Park of IT Startups 'Astana Hub'" in the field of confidentiality and personal data protection when performing obligations under this Agreement. ### 6.2. The Licensor shall have the right to: 6.2.1. Modify or release updates to the Software Product, add new features or functional capabilities that enhance its performance or otherwise improve its characteristics, or remove relevant functionality. 6.2.2. Suspend the License in the event of a breach of its obligations by the Licensee until such breach is remedied. 6.2.3. Terminate the Agreement unilaterally and out of court, having notified the Licensee thereof 30 (thirty) calendar days in advance. 6.2.4. Engage third parties (subcontractors) to perform obligations under this Agreement without the additional consent of the Licensee, while remaining fully liable to the Licensee for their actions. 6.2.5. Create anonymized (de-identified) statistical data on the basis of the Licensee's data that does not allow identification of the Licensee or its employees. Exclusive rights to such anonymized data and the results of its analysis belong to the Licensor and may be used by the Licensor indefinitely for the purpose of improving the Software Product, training algorithms, and analytical purposes. In the event of termination of the Agreement, the Licensor undertakes to discontinue access to the Licensee's Data but shall have the right to retain archival copies thereof in anonymized form. 6.2.6. The Licensor and its affiliated entities shall have the right to inform third parties that the Licensee is a client/partner of the Licensor. For the purposes of identifying the Licensee as a client/partner, the Licensee grants consent (provides a right) for the Licensor to use the Licensee's trademarks (service marks) and logos free of charge by placing them on the Licensor's website and other resources, in publications, banners, stands, and other marketing materials. Consent is granted without territorial restrictions until it is withdrawn. The Licensee warrants that granting this consent does not violate the rights of third parties. 6.2.7. In the event that the Licensee provides a review and/or article about the Licensor's activities or the experience of using the Software Product, the Licensee grants consent (provides a right) for the Licensor to use such materials free of charge without territorial restrictions until consent is withdrawn, in any manner permitted by law. If the review or article contains personal data of the Licensee's representatives (including as authors) and/or their images, the Licensee warrants that the necessary consents for the Licensor to use the images of the Licensee's representatives have been obtained. ### 6.3. The Licensee undertakes to: 6.3.1. Pay the license fee in a timely and complete manner in accordance with the terms of this Agreement and primary accounting documents (Certificates of Completion, Invoices). 6.3.2. Within the timeframe established by the Licensor, provide the necessary data, information, documentation, exclusively to the extent relating to the subject matter of this Agreement and the Software Product, and access to the Licensee's information and computing network, only to the extent objectively necessary for the performance of the Agreement. All required data shall be provided upon request by the Licensor addressed to the Licensee's representative. The Licensor shall not be entitled to request information unrelated to the provision of the License, implementation, operation, and maintenance of the Software Product. 6.3.3. Ensure that its employees and authorized persons using the Software Product comply with the rules governing its use. 6.3.4. Bear independent responsibility for compliance with legal requirements in the field of personal data processing, since the Licensee independently determines the volume and categories of data uploaded to the Software Product. If personal data of third parties is uploaded to the Software Product, the Licensee shall also independently bear responsibility for compliance with the legal requirements in the field of personal data processing. 6.3.5. Ensure the security of logins, passwords, access keys, and other means of authorization for Users, including in cases of their transfer to third parties in the interests of the Licensor. 6.3.6. Use the Software Product and Personal Account strictly for their intended purpose, without modifying the code, design, structure, or functional blocks, etc. 6.3.7. Notify the Licensor in writing of any identified malfunctions or improper operation of the Software Product via the Support Channel. 6.3.8. Refrain from transferring the use of the Software Product to persons who are not Users (see Terms and Definitions), including transfer to third parties for use. 6.3.9. Comply with all conditions set out in Clause 5.3 of this Agreement, as the Parties acknowledge that a breach by the Licensee of any of the obligations mentioned in that clause shall constitute a material breach of this Agreement within the meaning of Article 401 of the Civil Code of the Republic of Kazakhstan. ### 6.4. The Licensee shall have the right to: 6.4.1. Use the Software Product from the moment the Licensor confirms receipt of the license payment and completion of Registration. The Licensor's obligations to provide a non-exclusive license shall be deemed fulfilled from the moment access to the Software Product is granted to the Licensee. 6.4.2. Monitor the proper performance by the Licensor of its obligations under this Agreement without interfering in the Licensor's internal organizational and technical processes. 6.4.3. Refuse to use the Software Product unilaterally and out of court by ceasing to pay the fee for the next unpaid period. 6.4.4. In the event of identification of improper performance of obligations by the Licensor — notify the Licensor thereof in writing, after which the Licensor shall be obliged to take reasonable and necessary measures to remedy the identified breaches within the timeframe agreed upon by the Parties. --- ## 7. Terms and Procedure for Payments 7.1. For the grant of the right to use the paid functionality of the Software Product, the Licensee shall pay the Licensor a license fee. The amount of the license fee is determined based on the Rate and/or Additional Options selected by the Licensee as specified on the Licensor's Website, and is payable in the form of a 100% advance payment prior to commencing use of the applicable paid functionality. Amounts paid by the Licensee are credited to the Licensee's Personal Account. 7.2. All Rates and prices for Additional Options on the Licensor's Website are quoted in US Dollars (USD). If payment is made in another currency, the conversion shall be carried out by the payment system, issuing bank, or other financial intermediary such that the license fee actually credited to the Licensor corresponds to the license fee amount in US Dollars specified for the selected Rate and/or Additional Options. All costs, commissions, exchange rate differences, and other charges associated with currency conversion and fund transfers shall be borne by the Licensee. 7.3. In the event of incomplete payment of the license fee, including due to deduction of commissions, application of an unfavorable exchange rate, or other actions by payment intermediaries, the Licensee's payment obligation shall be deemed unfulfilled. In such a case, the Licensor shall be entitled to suspend or withhold access to the paid functionality until the full amount of the license fee in US Dollars has been received. 7.4. The license fee shall be paid by a method that allows identification of the Licensee, using payment systems, internet acquiring services, or via bank transfer based on an invoice issued by the Licensor. The Licensee's payment obligation shall be deemed fulfilled exclusively from the moment the funds are credited to the payment system's account or to the Licensor's settlement account. The processing time for funds may be up to 3 (three) banking days and is independent of the will and actions of the Licensor. 7.5. The Licensor is not a payment infrastructure operator and does not control the operation of payment systems, banks, processing centers, or other third parties involved in the execution of payments. The Licensor shall not be liable for temporary unavailability, technical failures, errors, delays, payment refusals, blocking of transactions, refunds, or other disruptions in the operation of such systems. In the event of any problems related to the processing of a payment, the Licensee undertakes to independently resolve such issues with the respective payment system, bank, or other financial intermediary. 7.6. If the Licensor issues an invoice for the license fee, such invoice shall be paid by the Licensee within no more than 10 (ten) calendar days from the date of issuance, unless a different period is specified in the invoice itself. If the invoice is paid after the specified period, currency conversion shall be carried out at the exchange rate applicable on the date of actual payment, with the Licensee bearing the full risk of exchange rate fluctuations. 7.7. Upon activation of a recurring (periodic) payment, the Licensee unconditionally consents to the automatic debiting of funds from the Licensee's bank card or other payment instrument in the amount of the license fee for the corresponding billing period. The Licensee shall bear independent responsibility for the currency and adequacy of funds on the payment instrument in use. 7.8. The Parties agree that a third party may act as the payer under this Agreement. In such case, the Licensee shall bear full responsibility for the actions of such payer and shall ensure that the payment reference contains information that unambiguously identifies the Licensee. The absence or incorrectness of such information shall not be regarded as proper performance of the payment obligation. 7.9. The Licensee shall have the right to unilaterally change the Rate in use and/or the composition of Additional Options through the Personal Account. A change of Rate shall take effect from the moment the relevant action is confirmed and the license fee in the new amount is paid, unless otherwise provided by the specific Rate conditions. 7.10. In the event the limits established by the selected Rate are exceeded (including but not limited to the number of users, developers, volume of functionality use, or other indicators), the Rate and/or Additional Options shall automatically be changed to the corresponding Rate with a higher cost. The Licensor shall have the right to recalculate the license fee, and the Licensee undertakes to pay the resulting difference. 7.11. Upon a change of Rate and/or the connection, modification, or disconnection of Additional Options, the period of access to the paid functionality of the Software Product shall be adjusted proportionally to the payment made, without requiring the execution of additional agreements. --- ## 8. License Term 8.1. The Agreement enters into force on the date of acceptance and is valid for 1 (one) year. If, within 30 (thirty) business days prior to the expiration of the Agreement, neither Party notifies the other Party in writing of the termination of the Agreement, the term of the Non-Exclusive License shall be deemed extended for 1 (one) year. The number of extensions is unlimited. 8.2. The Licensor shall have the right to unilaterally terminate the Agreement and/or block the Licensee's access to the Software Product in the event of a breach by the Licensee of the Agreement's terms, including in relation to payment, as well as violations of the current legislation of the Republic of Kazakhstan, the legislation of the place of state registration, and the place of the Licensee's activities. The Licensor shall not be liable for losses incurred by the Licensee in connection with the termination of the Agreement and/or blocking of access to the Software Product due to a violation of law. In such case, the Licensor shall send the Licensee a notice of unilateral termination of the Agreement 24 (twenty-four) hours before the termination. 8.3. The Licensor shall have the right to unilaterally and out of court terminate the Agreement by sending the Licensee an email notification of its intention at least 30 (thirty) calendar days before the intended date of termination. However, in this case, the license fee paid by the Licensee for the period of access to the Software Product unused as of the date of termination shall not be refunded, since the Licensor has fully performed its obligations to provide access to the Software Product as set out in this Agreement. --- ## 9. Warranties ### 9.1. The Licensee confirms and warrants the following: 9.1.1. The Licensee has all necessary authority to enter into, perform, and comply with the terms of this Agreement. 9.1.2. The Licensee shall use the Software Product exclusively within the scope of its business activities and only for purposes not contrary to this Agreement. 9.1.3. The Licensee acknowledges the exclusive rights of the Rightholder (Licensor) to the Software Product and undertakes to refrain from any actions that may result in the infringement of such rights, including attempts to register its own rights or claims to the Software Product. 9.1.4. The Licensee ensures an adequate level of information security, including protection against unauthorized access, copying, and distribution of the Software Product to third parties. 9.1.5. The Licensee has obtained consents from the Licensee's Developers for the collection, processing, storage, and transfer, including express consent to cross-border transfer, of their personal data to the extent sufficient for the implementation of the Software Product's functionality. 9.1.6. All actions performed by the Licensee, its employees, authorized representatives, and/or other persons who have obtained access to the License as a result of actions/inactions of the Licensee shall be deemed to be actions performed by the Licensee itself. The Licensor shall not be liable for the consequences of such actions. ### 9.2. The Licensor confirms and warrants the following: 9.2.1. The Licensor holds all rights to the Software Product and is authorized to enter into and perform the terms of this Agreement. 9.2.2. The availability and operability of the Software Product on a daily basis. 9.2.3. In the event of a breach of the guaranteed availability level, the sole and exclusive liability of the Licensor shall be the accrual to the Licensee of bonus access days (Service Credits) for the paid period, proportional to the downtime. The Parties have agreed that monetary compensation for downtime is not provided. --- ## 10. Liability of the Parties 10.1. The Parties shall be liable for non-performance or improper performance of their obligations under this Agreement in accordance with the current legislation of the Republic of Kazakhstan. 10.2. The Licensor shall not be liable for: (1) the dissemination of any information and any harm caused by a User to third parties through the use of the Software Product; (2) the results of the use of the Software Product by the Licensee and the actions of third parties (Licensee's Developers); (3) violation of the legislation of the Republic of Kazakhstan on personal data with respect to the Licensee's Developers, if such violation results from a breach by the Licensee of the warranties established under this Agreement. 10.3. The Licensor's liability shall in any case be limited to the amount received under the Agreement. The Licensor shall under no circumstances be liable for lost profits or indirect losses. 10.4. The Licensee shall be liable for the accuracy of any information transmitted to the Licensor. The Licensee shall independently bear responsibility for the infrastructure provided (development system, quality assurance system, and production system), as well as for the technical serviceability of hardware, uninterrupted network operation, and the overall infrastructure of the Licensee. 10.5. The Parties shall not be liable for partial or complete loss of information on electronic media as a result of mechanical damage to equipment, unauthorized access, or other possible internal system and equipment failures that occurred through no fault of theirs. 10.6. Without the prior written consent of the Licensor, the Licensee shall not, directly or indirectly, solicit for employment or engage any of the Licensor's specialists during the term of the Agreement and for 3 (three) years after the completion of services or termination of the Agreement. For a breach of this obligation, the Licensee shall be subject to a penalty in the amount determined in Kazakhstani tenge equivalent to 25,000 (twenty-five thousand) Euros at the exchange rate of the National Bank of the Republic of Kazakhstan on the date of payment, for each instance of such breach. 10.7. For a breach by the Licensee of the conditions set out in Clause 3.6 of the Agreement, the Licensee shall be subject to a penalty in the amount determined in Kazakhstani tenge equivalent to 25,000 (twenty-five thousand) Euros at the exchange rate of the National Bank of the Republic of Kazakhstan on the date of payment, for each instance of such breach. 10.8. The Software Product is provided to the Licensee "as is" (as is), in accordance with the generally accepted principle in international practice. Under this Agreement, the Licensor shall not be liable for issues arising during the installation, updating, support, and operation of the Software Product (including compatibility issues with other software products (packages, drivers, etc.), discrepancy between the results of use of the Software Product and the Licensee's expectations, etc.). The Licensee must understand that it bears full responsibility for any possible negative consequences caused by incompatibility or conflicts between the Software Product and other software products installed on the Licensee's computer or other device. 10.9. The Licensor shall not be liable for the inability to use the Software Product and/or its individual Additional Options for reasons attributable to the actions or inactions of the Licensee or third parties, including but not limited to improper use of means of individualization, provision of false documents, and other such actions, as well as in cases where access to the Software Product is restricted due to the Licensee's lack of access to the Internet. 10.10. The Licensee shall independently bear responsibility for the security of its login and password and for losses that may arise due to their unauthorized use. 10.11. The Licensor does not initiate or control the placement by the Licensee within the Software Product of any information (including personal data of third parties), does not influence its content or volume, and therefore is not in a position to assess whether such information and its placement in the Software Product violates the provisions of applicable legislation. The Licensee shall independently bear responsibility for such information and the decision to place it in the Software Product. 10.12. The Licensor shall not be liable for losses of the Licensee or third parties incurred in connection with the use of the Software Product, including if any corporate decisions of the Licensee were made as a result of the use of the Software Product. Any information, metrics, and other indicators reflected in the Software Product are interpreted and used by the Licensee exclusively for its own purposes and at its own discretion. The Software Product does not provide any binding recommendations and bears no liability for decisions made by the Licensee or its affiliated entities on the basis of such indicators and/or recommendations. --- ## 11. Force Majeure 11.1. Neither Party shall be liable for the complete or partial non-performance of its obligations under this Agreement if such non-performance results from the occurrence of force majeure circumstances arising after the conclusion of this Agreement, of an extraordinary, unavoidable, and unforeseeable nature, beyond the reasonable control of the relevant Party, and directly affecting the performance of obligations under this Agreement. 11.2. Such circumstances include, in particular: natural disasters (fires, floods, earthquakes, and other natural calamities), acts of military aggression, mass riots, epidemics, pandemics, actions of governmental authorities (including restrictions, prohibitions, and moratoria), cyberattacks, disruptions in energy and communications supply, provided that the specified events have directly affected the ability to perform obligations. 11.3. In the event of force majeure circumstances, the Party for which performance of obligations has become impossible shall notify the other Party thereof in writing immediately, but no later than 5 (five) business days from the occurrence of such circumstances. Confirmation of force majeure shall be an official notice or certificate issued by an authorized governmental body or other competent institution at the location of such circumstances. The said document shall be provided within 30 (thirty) calendar days from the date of notification. 11.4. For the duration of the force majeure circumstances, the performance of obligations under this Agreement shall be suspended. The term for performance of the Parties' obligations shall be extended for the period of such circumstances, as well as for a reasonable period for eliminating the consequences of their impact. 11.5. If the force majeure circumstances and/or their consequences continue for more than 60 (sixty) calendar days, either Party shall have the right to unilaterally terminate this Agreement by sending written notice to the other Party no less than 10 (ten) calendar days before the intended date of termination. In the event of such termination, the Parties undertake to carry out mutual settlements within a reasonable time. 11.6. The occurrence of force majeure circumstances shall not release the Parties from the obligation to interact in good faith with the aim of minimizing the consequences of such circumstances, including seeking temporary or alternative methods of performing the Agreement, if permissible under its terms. --- ## 12. Intellectual Property Rights 12.1. The Software Product is the result of intellectual activity and the object of the Licensor's exclusive rights, which are governed and protected by the intellectual property legislation of the Republic of Kazakhstan and the norms of international law. 12.2. The algorithms and source codes of the Software Product (including parts thereof) constitute the Licensor's trade secret. Any actions in respect of the Software Product that are not identified in this Agreement as lawful and non-infringing of the Licensor's rights shall be deemed unlawful and regarded as a violation of the Licensor's rights, which shall constitute sufficient grounds for the termination of this Agreement and submission of a claim aimed at protecting the Licensor's infringed rights. 12.3. The Intellectual Property Rights to all methods, methodologies, processes, procedures, techniques, ideas, concepts, know-how, technologies (including, without limitation, models of functions, processes, systems, and data), templates, general structural parameters, sequences and organization of software, user interfaces and screen formats, software tools, general-purpose tools and procedures, as well as the logic, sequence, and methodology of system operation, belong to the Licensor. 12.4. The Licensor warrants that it holds all necessary rights to the Software Product to grant access thereto, including its documentation. 12.5. Liability for infringement of the Licensor's rights with respect to the Software Product shall arise in accordance with the current legislation of the Republic of Kazakhstan. --- ## 13. Confidentiality 13.1. For the purposes of this Agreement, "Confidential Information" means any information related to the Software Product, its technical characteristics, commercial terms, source code, architecture, documentation, as well as any other information that has actual or potential value and is not subject to disclosure to third parties, unless otherwise expressly provided for in this Agreement or the legislation of the Republic of Kazakhstan. 13.2. Each Party undertakes to maintain the confidentiality of information received from the other Party and to ensure its protection against unauthorized access, disclosure, use, or dissemination during the term of this Agreement and for 5 (five) years after its termination; with respect to the algorithms and operational methods of the Software Product, the confidentiality regime shall apply indefinitely. 13.3. Neither Party shall be entitled to disclose Confidential Information to third parties without the prior written consent of the other Party, except in cases where such disclosure is required by applicable law, a court order that has entered into force, or a lawful demand of a competent authority. In such case, the disclosing Party shall, to the extent possible, notify the other Party of the fact, scope, and timing of the disclosure. 13.4. Each Party shall be liable for the actions and/or inactions of its employees, contractors, and other authorized persons who have been granted access to Confidential Information, including ensuring an adequate level of protection thereof. 13.5. "Disclosure of Confidential Information" means any action or inaction as a result of which such information becomes accessible to third parties, including instances of breach of information security protocols, loss of access control, or exploitation of vulnerabilities in the Licensee's Infrastructure. 13.6. The Party that has allowed unauthorized disclosure or use of Confidential Information shall compensate the other Party for all documented losses caused by such breach, except in cases expressly provided for in this Agreement. --- ## 14. Dispute Resolution 14.1. The Parties shall make all reasonable efforts to resolve any disagreements and/or disputes arising in connection with the performance, interpretation, amendment, or termination of this Agreement through negotiations and/or an exchange of claim letters accompanied by relevant documents and justifications. 14.2. The response period for a claim shall be 7 (seven) business days from the date of its receipt. Failure to respond within the specified period shall not deprive a Party of the right to further dispute resolution in the manner provided for under this Agreement. 14.3. If the dispute cannot be resolved through negotiations within the period specified in Clause 14.2 of this Agreement, the dispute shall be referred to the courts of the Republic of Kazakhstan in accordance with the applicable substantive and procedural law at the location of the Licensor. 14.4. Prior to filing a claim in court, the Parties undertake to follow the pre-trial dispute resolution procedure, except in cases where such resolution is impossible or violates statutory deadlines. --- ## 15. Miscellaneous Provisions 15.1. At the time of entry into this Agreement, the Licensor does not provide services for training users in the operation of the Software Product. The Licensee shall independently familiarize itself with the functionality and interface of the Software Product based on the current capabilities of the system. 15.2. From the moment of acceptance of this Agreement, all prior correspondence, documents, and negotiations between the Parties on matters that are the subject of this Agreement shall cease to have legal effect. 15.3. Any notices, correspondence, and other documents related to this Agreement shall be sent by the Parties to the electronic and postal addresses specified in this Agreement. The Parties acknowledge the legal validity of documents sent to the email address specified in this Agreement until the receipt of the corresponding original document. --- ## Licensor's Details | | | |---|---| | **Name** | LLP «PANDEV» | | **BIN** | 230140037871 | | **Location** | Kazakhstan, Almaty, Bostandyk district, Satpayev Street, 30/8, office 139, postal code 050040 | | **E-mail** | bakbergenov@pandev.io | | **Bank details** | Account: KZ878562203148733359 | | **Bank** | JSC "Bank CenterCredit" | | **BIC** | KCJBKZKX | --- ## Personal Workspace URL: https://pandev-metrics.com/docs/personal-getting-started # Personal Workspace Track your own productivity — completely independent from any company. - **Personal metrics** — your coding activity and patterns - **Gamification** — achievements and progress tracking - **Portable history** — stays with you between jobs - **Full privacy** — data visible only to you --- ## 1. Create Your Workspace 1. Sign up at [workspace.pandev.io](https://workspace.pandev.io) with your personal email. 2. Confirm your email and sign in. --- ## 2. Your Dashboard View your personal activity and metrics: --- ## 3. Install IDE Plugin Choose your IDE and install the PanDev Metrics plugin: **Supported IDEs:** VS Code, IntelliJ IDEA, PyCharm, PhpStorm, GoLand, Rider, CLion, RustRover, WebStorm, RubyMine, Visual Studio, Windsurf AI, Cursor AI, Android Studio ### Configure the Plugin **Connection settings:** - **Server URL:** `https://metrics-cloud.pandev.io` - **Login/Password:** Your personal workspace credentials - **Company Login:** Leave empty _(personal workspace)_ --- ## 4. Your Profile Customize your profile and view your overall stats: --- ## 5. Gamification & Achievements Track your progress with achievements and worklogs: --- ## Privacy & Control - **Your data stays private** — only visible to you - **Separate from company workspaces** — personal projects don't appear in team analytics - **Portable** — your history stays with you when changing jobs - **Works alongside teams** — can be used with any number of company workspaces --- ## Ready for a Team? When you want to collaborate, create a company workspace and invite teammates. **→** [Create Cloud workspace](https://pandev-metrics.com/docs/saas-getting-started) Your personal data remains completely separate from team analytics. --- ## Cloud (SaaS) Quick Start URL: https://pandev-metrics.com/docs/saas-getting-started # Cloud (SaaS) Quick Start Get started with PanDev Metrics Cloud in **15-20 minutes**. No infrastructure required. After setup you will see in real time: - Developer activity in IDEs - Project work statistics - Team productivity metrics - AI-powered insights --- ## 1. Register Your Account 1. Go to [workspace.pandev.io](https://workspace.pandev.io) and create an account. 2. Confirm your email and sign in. --- ## 2. Create Your Company Workspace 1. Use the workspace switcher to create a new company. 2. Enter company name and login (unique identifier). --- ## 3. Connect Git Integration Connect your Git system to track commits and merge requests. **Supported systems:** - GitLab (Cloud & Self-Managed) - GitHub - Bitbucket - Azure DevOps Go to **Settings → Integrations** and configure your Git provider: --- ## 4. Connect Task Tracker (Optional) Connect your task tracker for complete visibility. **Supported trackers:** - Jira (Cloud & Server) - Yandex Tracker --- ## 5. Set Up Organization Structure ### Add Employees Go to **Organization → Employees** and invite team members: ### Configure Departments & Teams (Optional) --- ## 6. Install IDE Plugins Plugins collect development activity from your team's IDEs. Go to **Settings → Plugins** to see installation instructions for each IDE: **Supported IDEs:** - VS Code - IntelliJ IDEA, PyCharm, PhpStorm, GoLand, Rider, CLion, RustRover, WebStorm, RubyMine - Visual Studio - Android Studio - Windsurf AI, Cursor AI **Connection settings:** - **Server URL:** `https://metrics-cloud.pandev.io` - **Company Login:** Your company identifier - **Employee Login/Password:** Employee credentials --- ## 7. Configure Working Hours Set up the work schedule for accurate overtime tracking. Go to **Settings → Calendar**: --- ## 8. Start Analyzing Once plugins are configured, metrics will appear within minutes. ### Dashboard ### AI Assistant Ask questions about your data in natural language: ### Employee Details ### Projects Overview --- ## Billing & Reports Generate payment reports based on actual development activity: --- ## Next Steps - [Plugin detailed setup](https://pandev-metrics.com/docs/setup/ide-plugins/overview) - [Git integrations](https://pandev-metrics.com/docs/setup/git-integrations/gitlab) - [Task tracker setup](https://pandev-metrics.com/docs/setup/task-trackers/jira) - [Book a demo](https://pandev.io/book) --- ## What's New in 2.0.0 URL: https://pandev-metrics.com/docs/whats-new # PanDev Metrics 2.0: The Big Leap **Release date:** 2025-12-15 **Total effort:** 1356 Hours 44 Minutes 59 Seconds We are proud to present **PanDev Metrics 2.0** — a major update that fundamentally changes how you work with development metrics. We have moved away from third-party visualization tools, launched a cloud version, and created a personal workspace for every developer. ## 🚀 SaaS Version Launch No more complex server setup required. You can now start using PanDev Metrics in the cloud in just a few minutes. - **Instant Start**: Register and connect your first plugin in 5 minutes. - **Cloud Infrastructure**: We handle updates, backups, and security. - **Free Tier**: Perfect for individual developers and small teams. [Try SaaS Version](https://metrics.pandev.io) ## 📊 Goodbye Grafana, Hello Workspace We have completely decommissioned Grafana as our visualization interface. In version 2.0, we introduce our own **PanDev Workspace** — a specialized UI built specifically for engineering analytics. - **Native Interactive Charts**: Drill down from global metrics to specific commits. - **Performance**: Dashboards load instantly, optimized for large datasets. - **UX for Developers**: Dark mode, code-like aesthetics, and intuitive navigation. ## 👤 Personal Developer Workspace Metrics are not just for managers. Version 2.0 brings value to every engineer. - **Personal Dashboard**: Track your own dynamics, coding time, and focus hours. - **Gamification**: Earn achievements for code consistency, impactful reviews, and rapid bug fixes. - **Self-Improvement**: See where you get stuck and how to improve your workflow. ## 🏢 Advanced Organization Structure We have introduced a flexible hierarchy to match your company structure. - **Departments**: Group teams into departments (e.g., "Mobile", "Backend", "QA") for high-level analytics. - **Role Model**: New "Admin" and "Developer" roles to manage access and visibility securely. - **Team Management**: Drag-and-drop interface for organizing your workforce. ## 🛠 Component Updates Despite the major platform changes, we continue to improve our core components: - **PanDev Metrics Core 5.0.0**: Backend support for multi-tenancy and hierarchy. - **JetBrains Plugin 9.0.1**: Improved offline data caching. - **VS Code Plugin 0.5.3**: Experimental support for remote development. - **New Plugins**: Visual Studio and Eclipse support. --- # Section 3 — Blog (Engineering Intelligence) > Engineering productivity, DORA metrics, DevEx, and software delivery research from PanDev Metrics. ~85 published posts as of 2026-04-28. ## On-Call Rotation Best Practices: SRE-Style Schedules to Reduce Burnout (2026) URL: https://pandev-metrics.com/docs/blog/oncall-rotation-best-practices Date: 2026-04-28 Tags: engineering-management, tutorial, on-call, developer-wellbeing, sre Description: Manage on-call rotations without burnout: Google SRE workbook alerting policies, real schedules, and burnout-prevention metrics for engineering teams in 2026. Your best SRE quit last quarter. She didn't say "burnout" in the exit interview, but her last three months included 14 after-hours pages, 2 weekend incidents, and a 3am call on her birthday. A 2021 Catchpoint / DevOps Institute survey of 500+ on-call engineers found **67% reported burnout symptoms** tied directly to paging load. Google's SRE book sets an internal ceiling of **2 incidents per on-call shift** before a rotation is declared unhealthy — most teams we measure blow past that in week one. On-call is fixable. It's a scheduling and sociotechnical problem, not a personality flaw in the people who can't hack it. Here's a 9-rule playbook that keeps your SLA intact and keeps your best engineers on the team past their second rotation. ## The problem Three failure modes show up in almost every team with a broken rotation: **Too few rotators.** A 4-person rotation means each person is on-call every 4th week. Over a year that's 13 weeks of degraded sleep, cancelled plans, and interrupted focus. Google's SRE team targets a minimum of 6 people per rotation for exactly this reason — below six and recovery time vanishes. **No hand-off ritual.** The incoming on-call engineer learns about the flapping alert from PagerDuty at 2am. The outgoing engineer had context but didn't write it down. Every rotation resets knowledge to zero, so the same incident gets rediscovered monthly. **Compensation pretends the pager doesn't exist.** Engineers are salaried, the pager fires at 3am, and nobody adjusts expectations for the following day. A 2023 Blameless / DevOps Institute report found that teams without explicit on-call comp or recovery time had **2.4× higher turnover** among senior engineers than teams that did. The rules below attack all three at once. ![Rotation flow from primary to post-incident review, showing handoff, escalation, and recovery points.](https://pandev-metrics.com/img/blog/oncall-rotation-best-practices/rotation-flow.png) *The healthy rotation loop: primary → secondary → escalation → review → handoff. Every arrow is a decision point teams skip.* ## The 9 rules ### Rule 1 — Minimum 6 engineers per rotation Below six, there's no slack. One person on PTO or sick takes the rotation to a 5-way split, then the shift that was already heavy becomes brutal. At six or more, the math works: each engineer is on primary every ~6 weeks, giving a real recovery window between shifts. If you don't have six, don't have a 24/7 rotation — use follow-the-sun with a partner team or triage-only hours with deferred response. ### Rule 2 — Primary + secondary, always Never route pages directly to one person. The secondary picks up if the primary doesn't acknowledge within **5 minutes**. This single rule cuts unresolved pages roughly in half in teams we've seen adopt it — because the primary is asleep, in a meeting, or out of signal more often than the org expects. | Role | Acknowledge window | Escalation trigger | |:-:|:-:|:-:| | Primary | 5 min | No ack → secondary paged | | Secondary | 10 min | No ack → EM paged | | EM | 15 min | No ack → VP Eng | Secondary isn't "backup" — it's an active role with expected availability during the shift. ### Rule 3 — Hard cap: 2 paging incidents per 12-hour shift This is Google's SRE ceiling from their public book, and it's the single most useful number in rotation design. If a shift exceeds 2 paging incidents, something upstream is broken: the alerting is noisy, the system is fragile, or both. Track this monthly. If it trends above 2 for two consecutive months, the rotation is declared unhealthy and engineering leadership owns a remediation plan, not the on-call engineer. ### Rule 4 — Structured handoff at every rotation swap 15 minutes, synchronous if possible, a short written artifact otherwise. Cover: - **Active incidents** (open, mitigated-not-resolved, under investigation) - **Ongoing concerns** (deploy freezes, known-flapping alerts, dependency issues) - **This week's change log** (what deployed that the next on-call should know about) - **Runbook updates** (any new runbooks, any gaps found) Skipping handoff is the most common tax. We've seen teams rediscover the same flaky alert three rotations in a row because no one wrote it in the handoff doc. ### Rule 5 — Compensation reflects the cost Three models that work, pick one and commit: 1. **Time-in-lieu** — every paged hour after 10pm or on weekends adds paid recovery time, taken within two weeks. 2. **Flat stipend** — $300-$800/week while on rotation, independent of incidents, clearly communicated. 3. **Hybrid** — small base stipend + per-paged-incident bonus. The worst model is "you're salaried, figure it out." It externalizes the cost to the engineer's health and, eventually, to your turnover budget. Blameless' 2023 data tied compensation clarity to retention more strongly than any other on-call variable. ### Rule 6 — Mandatory post-incident recovery If someone was paged between 10pm and 6am, they don't start at 9am. Policy, not negotiation. Teams that publish this policy and enforce it see **30-40% fewer self-reported burnout symptoms** over 12 months (DevOps Institute 2023). Teams that rely on "feel free to come in late if you need to" see engineers show up anyway and quietly build resentment. ### Rule 7 — Rotate types, not just names Three kinds of on-call work rotate separately: - **Paging rotation** (the pager itself) - **Incident commander rotation** (runs the response when things go sideways) - **Review rotation** (owns the postmortem within 48 hours) Merging these into one role overloads the same person. Splitting them means on any given week, three different engineers carry reduced load rather than one engineer carrying all of it. ### Rule 8 — No on-call within 30 days of termination or role change Announced resignation, internal transfer, PIP — all reasons to pull someone off the rotation. Their attention is elsewhere, their motivation to stay heroic is gone, and putting them on the pager is asking for a missed page. The remaining rotation absorbs the gap, which is also a signal to hire before it's urgent. ### Rule 9 — Review rotation health monthly with data, not vibes A 30-minute monthly meeting. Three charts only: - Paging incidents per shift (is it under 2?) - After-hours page count per engineer (is it evenly distributed?) - Post-incident recovery actually taken (is the policy being honored?) If any of the three is red, that's the agenda for the next month. Our [CTO Dashboard](https://pandev-metrics.com/docs/blog/cto-dashboard) pattern works well here — leaders see the signal weekly, but the on-call conversation is monthly so it doesn't crowd out delivery work. ## Common mistakes to avoid | Mistake | Why it hurts | Fix | |---------|-------------|-----| | One-week shifts | Too long — sleep debt compounds to a breaking point by day 4 | Split into two half-weeks with different primaries | | "Volunteer" on-call | The same 2-3 people carry 80% of shifts until they quit | Mandatory rotation with codified exceptions | | Paging on every error | Alert fatigue kills response quality | Ruthless alert tiering — page only SLO-level impact | | No runbooks | Each incident relitigated from scratch | Runbook-per-alert as a merge gate | | Counting only incidents | Misses low-sev interruptions that still break focus | Track paged minutes, not just paged events | ## The checklist - [ ] Minimum 6 engineers per rotation - [ ] Primary + secondary both staffed for every shift - [ ] Paging incidents per shift tracked and under 2 avg - [ ] Handoff ritual documented and followed - [ ] Compensation model published - [ ] Recovery-time policy published and enforced - [ ] Incident commander and review roles rotated separately - [ ] People leaving / transferring are pulled off rotation - [ ] Monthly rotation-health review on the calendar ## How to measure if this is working Four signals tell you the rotation is healthy: - **Paged incidents per shift** — trend stays below 2 for rolling 3 months - **After-hours coding time** — [we track this as a burnout signal](https://pandev-metrics.com/docs/blog/burnout-detection-data) in PanDev Metrics via IDE heartbeat data; sustained after-hours activity post-incident suggests recovery policy is being skipped - **On-call-to-exit gap** — measure time between a person's rotation and voluntary exit; if it's consistently under 6 months, the rotation is contributing to attrition - **MTTR trend** — a healthy rotation correlates with flat or improving [MTTR](https://pandev-metrics.com/docs/blog/mttr-speed-of-recovery); a deteriorating rotation shows up there first Our dataset across 100+ B2B engineering teams shows a consistent pattern: teams that publish explicit on-call comp and recovery policies hit a **30% lower after-hours IDE activity spike** in the week following an incident compared to teams with implicit norms. Our signal is limited to work we can see in the editor — Slack triage and pager-only engagement are invisible to us, so treat this as a directional indicator, not the full picture. ## When this framework doesn't fit If your team is under six engineers, stop. You cannot run a sustainable 24/7 rotation with fewer than six bodies — the math defeats any rules you layer on top. Options: follow-the-sun with another team, triage-only business hours, or a paid external SRE partner for overnight coverage until you hire. Also skip this if your paging volume is structurally low (say, fewer than 4 pages per quarter). A formal rotation becomes overhead; informal coverage with a clear escalation chain works better at that volume. ## The contrarian rule Most playbooks start with "improve your alerts." We disagree. Alert noise is a symptom; the root cause is nobody owns the alerts as a product. Rule 3 (the 2-incidents-per-shift ceiling) creates the forcing function: when the ceiling is breached, alerting ownership becomes an engineering-leadership problem, not a line engineer's weekend project. Fix rotation health first, alert hygiene follows. ## Related reading - [5 Data Patterns That Scream 'Your Developer Is Burning Out'](https://pandev-metrics.com/docs/blog/burnout-detection-data) - [MTTR: Why Speed of Recovery Matters More Than Preventing All Incidents](https://pandev-metrics.com/docs/blog/mttr-speed-of-recovery) - [Change Failure Rate: Why 15% Is Normal and 0% Is Suspicious](https://pandev-metrics.com/docs/blog/change-failure-rate-15-percent-normal) --- ## Incident Post-Mortem Template That Actually Helps (Not CYA) URL: https://pandev-metrics.com/docs/blog/incident-postmortem-templates Date: 2026-04-27 Tags: tutorial, engineering-management, incident-management, sre, dora-metrics Description: Most post-mortems read like legal disclaimers. Here's the 5-section template that drives real action items — used by teams that actually reduce MTTR. The average post-mortem takes 4 hours to write and generates zero action items the team actually completes within 30 days. We looked at 120 post-mortem documents from three of our on-prem customers before rebuilding this template. **83% of action items were still "open" six months later.** That's not an incident review — that's a document graveyard. A post-mortem is worth writing only if it changes something. Everything else is CYA. ## Why most post-mortems fail Google's SRE Workbook has been the unofficial reference since 2018. The "blameless" framing is right, but teams over-index on tone and under-index on follow-through. The 2022 Atlassian State of Incident Management survey found that **61% of engineering teams run post-mortems, but only 23% track completion of the action items**. The ritual exists. The outcome doesn't. Three patterns recur in the documents we reviewed: - **Narrative bloat** — 3 pages of timeline detail, 4 sentences of fix. Reviewers skim the fix and move on. - **Action items without owners** — "We should improve monitoring" with no name, no date, no acceptance criteria. - **No 30-day follow-up** — action items are logged in the doc, not in the tracker. They evaporate. A useful post-mortem is short, surgical, and tied to the team's existing task tracker. Anything else is theatre. ## The 5W template We call it the 5W template because every section answers a W-question. The whole document should fit on one screen and take no longer than 90 minutes to write. | Section | Question | Target length | |---------|----------|:-:| | What happened | One-paragraph customer-impact summary | 3-4 sentences | | When | Timeline in UTC, key events only | 5-8 bullets | | Why | 5 Whys chain ending in a systemic cause | 1 paragraph | | Who was impacted | Users, tenants, revenue if known | 2-3 lines | | What changes (action items) | 3-5 concrete tasks with owners + due dates | Table | Five sections. No "heroes", no "commendations", no "lessons learned" block (lessons should be the action items themselves). ![5-step post-mortem flow from incident resolution to 30-day follow-up](https://pandev-metrics.com/img/blog/incident-postmortem-templates/postmortem-flow.png) *The lifecycle of a post-mortem that actually ships change. The follow-up loop is where 83% of teams drop the ball.* ### Section 1 — What happened One paragraph. Written for a reader who was not on-call. Must answer: what broke, what did customers see, how long, what fixed it. > "On April 3, 2026, between 14:12 and 14:47 UTC, payment confirmations failed for 12% of checkouts on `api.example.com`. Root cause was a PostgreSQL connection pool exhaustion following a scheduled vacuum. Resolved by manual pool restart and rollback of the migration that raised `max_connections` target. 280 customer orders retried successfully; 4 duplicated charges required manual refund." Note what's missing: drama, blame, narrative arc. Just the facts. ### Section 2 — When (the timeline) UTC only. Don't mix timezones — the 2:47 AM vs 2:47 PM confusion has cost teams hours in reconstruction. Log events that materially changed the incident: first alert, first human response, first rollback, customer-impact end. ``` 14:12 — first alert fired (PG pool saturation) 14:14 — on-call engineer acknowledged 14:19 — war room opened, 3 engineers joined 14:28 — first mitigation attempt (read replica failover) — no effect 14:41 — rollback of migration merged 14:47 — pool recovered, customer impact ended 15:10 — all-clear communicated to support ``` 7 lines. If your timeline is longer than 15 lines, you're probably logging Slack messages instead of events. ### Section 3 — Why (the 5 Whys) This is the only section where prose helps. Write the 5 Whys chain, but stop when you hit a systemic cause — not a person. > **Why did payments fail?** Connection pool exhausted. > **Why was the pool exhausted?** A vacuum full acquired table locks longer than expected. > **Why didn't we see this in staging?** Staging database is 0.3% of production size; vacuum completes in seconds there. > **Why didn't we check pool saturation before vacuum?** Our runbook for manual vacuum has no pre-flight check. > **Why doesn't the runbook have that check?** Runbooks are written reactively after incidents, not proactively. We've never had a vacuum-triggered saturation before. Systemic cause: runbook coverage gap for low-frequency maintenance operations. That's the claim your action items attack. ### Section 4 — Who was impacted Two numbers matter: how many users, how much money (if revenue-adjacent). Skip the narrative. A table is fine. | Impact | Number | |--------|--------| | Affected customers | 280 | | Duplicated charges | 4 | | Revenue at risk (1hr) | $14,200 | | Support tickets generated | 31 | | Senior-eng hours spent resolving | 9 | The last row matters for the cost-per-feature conversation — see our [cost per feature analysis](https://pandev-metrics.com/docs/blog/cost-per-feature) for how we track incident burn. ### Section 5 — What changes (action items) The only section auditors should be reading six months later. Rules: 1. **Each action item has one owner, not a team.** "Platform team" is nobody's job. "Marat" is somebody's job. 2. **Each action item has a due date.** Not "Q2". A calendar date. 3. **Each action item has an acceptance criterion.** "Improve monitoring" is not measurable. "Pool saturation alert fires at 80% utilization, tested in staging" is. 4. **Each action item is a ticket in your tracker.** Not a bullet in the doc. If it's not in Jira/Linear/ClickUp, it doesn't exist. | # | Action item | Owner | Due | Acceptance | |---|-------------|-------|-----|-----------| | 1 | Add pool-saturation alert at 80% | Marat | Apr 10 | Alert fires in staging test; runbook links to it | | 2 | Pre-vacuum checklist in runbook | Aliya | Apr 12 | Checklist reviewed by 2 SREs; used on next vacuum | | 3 | Staging dataset scaling plan | Danil | May 1 | Plan doc reviewed; 10% sampling approach chosen | | 4 | Automated duplicate-charge detection | Zhanna | May 15 | Fires on test transaction; refund script linked | Four action items. Not ten. **The team that writes ten action items finishes zero.** ## Common mistakes to avoid - **The "blameless" fetish** — blameless doesn't mean "no accountability". The owner column is not blame. It's responsibility for the fix. - **Writing the post-mortem while the incident is fresh (and angry)** — wait 24 hours. First-draft post-mortems at 2 AM tend to over-narrate and under-action. - **Treating the doc as the output** — the output is the action items in your tracker, closed by the due date. - **Repeating the same root cause across 3 incidents** — if "we didn't have monitoring for X" appears three times, the action item isn't "add monitoring for Y", it's "budget 20% engineer time this sprint for monitoring gaps". ## How to measure if your post-mortems actually work Two metrics. Both simple. **Action-item completion rate.** Count action items with a due date in the last 6 months. Divide by how many were closed by that date. Target: **≥ 70%**. If you're below 50%, the ritual is theatre. **Recurrence rate.** Count incidents where the root cause appears for the second or third time. Target: **≤ 15%**. Above that, the action items aren't fixing the systemic cause. In PanDev Metrics, we link incidents to the deployments that caused them and the tasks that fixed them — pull branch names like `fix/INC-204` into the incident record automatically. It's the same branch-name convention we use for lead time, which means post-mortem follow-through shows up in the same dashboard as [change failure rate](https://pandev-metrics.com/docs/blog/change-failure-rate-15-percent-normal). Our dataset skews B2B SaaS and on-prem enterprise. We don't have signal on gaming studios or consumer mobile teams, where incident dynamics differ. The template still applies; the completion benchmarks may not. ## The template, copy-paste ``` # Post-Mortem: [Incident ID] — [One-line title] ## What happened [One paragraph, no drama, customer-impact framing] ## When (UTC) - HH:MM — event - HH:MM — event ## Why (5 Whys) Q1: Why did X fail? A: ... Q2: Why did Y? A: ... (continue until systemic cause) Systemic cause: [one sentence] ## Who was impacted | Impact | Number | |--------|--------| | Affected customers | ... | | Revenue at risk | ... | | Hours spent resolving | ... | ## Action items | # | Action | Owner | Due | Acceptance criteria | |---|--------|-------|-----|---------------------| | 1 | ... | @name | YYYY-MM-DD | measurable signal | ``` Save it to the incident tracker, link to the Git branches that fix it, and schedule a 30-day review in the same sprint where you do retro. The post-mortem isn't the work. The 30-day review is. ## Related reading - [MTTR: Why Speed of Recovery Matters More Than Preventing All Incidents](https://pandev-metrics.com/docs/blog/mttr-speed-of-recovery) - [Change Failure Rate: Why 15% Is Normal and 0% Is Suspicious](https://pandev-metrics.com/docs/blog/change-failure-rate-15-percent-normal) - [DORA Metrics: The Complete Guide for Engineering Leaders](https://pandev-metrics.com/docs/blog/dora-metrics-complete-guide-2026) --- ## Design Docs: When to Write, When to Skip (Decision Framework) URL: https://pandev-metrics.com/docs/blog/design-docs-when-to-write Date: 2026-04-26 Tags: tutorial, engineering-management, developer-productivity, guide Description: Most teams write too many design docs or none at all. A 3-question framework to decide which changes need one — and which waste an engineer's afternoon. A mid-size team I advised last year had a standing rule: every ticket above 3 story points needed a design doc. Eight engineers, roughly four docs per week, each doc eating a half-day to write and another half-day in review cycles. That's 32 engineering hours per week — **four full working days a week, spent on documents that most people scanned once and never reopened**. The CTO thought they were a high-discipline shop. The data said they were documentation-heavy and velocity-poor. The opposite extreme is worse. A 2019 report from Stack Overflow's Developer Survey listed "poor documentation of internal systems" as the #2 productivity blocker after technical debt itself. Skipping design docs entirely means every sixth-month refactor is an archaeology dig. This is the framework I use to decide which changes deserve a doc, which deserve a 3-sentence RFC comment, and which deserve nothing at all. ## The problem: docs written for the wrong reason Design docs fail in two ways, both avoidable. **Failure 1: Written as a ritual.** The doc exists because the process says it should exist. Nobody opened it after approval. The writer spent half a day; the reviewers spent an hour of calendar time; the artifact added zero decision value. **Failure 2: Not written when they should have been.** Something gets built, breaks in a non-obvious way six months later, and the post-mortem asks "why wasn't this decision documented?" The senior who made the call has left. The reasoning is lost. The rebuild costs 3x the original effort. Google's engineering-practices handbook puts the purpose bluntly: a design doc exists to **surface disagreement before code exists**, because the cost of disagreement at design time is minutes, and the cost at code-review time is days. If your doc isn't surfacing disagreement, you either wrote it too late, or you didn't need it. The academic case is supportive but limited. Ernst et al. (2015), *Measure It? Manage It? Ignore It?* (an IEEE Software paper on design documentation practices) found that teams producing targeted design docs shipped with 20-30% fewer post-release defects than teams relying on ad-hoc documentation — but only when the doc captured tradeoffs, not when it re-described the code. A doc that restates what the PR shows is worse than no doc: it adds calendar friction without adding reasoning. ## The 3-question decision framework ![Flow diagram: three yes/no questions leading to either a full design doc, a quick RFC comment, or skipping documentation entirely.](https://pandev-metrics.com/img/blog/design-docs-when-to-write/decision-flow.png) *Three questions, three possible outcomes. Most changes land at "skip" or "RFC comment". Only a minority need a full doc.* ### Question 1: Is the scope more than 1 engineer-week? If a single engineer can finish the change in a week, they should usually just build it and let the PR description carry the context. A PR description is a lightweight design doc with 100% read-through because reviewers can't merge without opening it. The week threshold is not arbitrary. Work that takes longer than a week almost always crosses module boundaries, and once module boundaries are crossed, multiple people have opinions about the interface. That's when writing compresses into review time. ### Question 2: Does the change affect more than one team? Cross-team changes need a doc regardless of scope. A half-day schema migration that touches two services needs a 1-page design doc, because the two teams won't meet until the PR, and a PR is the wrong venue for interface disagreement. Single-team changes — even large ones — can often be handled in a shared `/rfcs/` channel or pull-request thread. The reviewer set is small and already context-sharing, so a long written artifact has diminishing returns. ### Question 3: Is the change reversible within one business day? This is the "blast radius" test borrowed from site-reliability practice. If rolling the change back takes one engineer one day, write it up after, don't design-doc it before. If rollback would take a week, or is physically impossible (a schema migration, a public API change, a data-format change), the decision is worth the hour of writing. "Reversible in a day" is a useful shortcut because it maps cleanly to MTTR data. In teams we've measured, an average deploy recovers in under 4 hours when the change has a clear rollback path. Changes without rollback paths are the ones that [dominate MTTR numbers](https://pandev-metrics.com/docs/blog/mttr-speed-of-recovery) — and those are exactly the changes worth writing up. ### The decision matrix | Scope > 1 week | Cross-team | Reversible in a day | What to do | |:-:|:-:|:-:|-----| | No | No | Yes | Skip — ship with a good PR description | | No | No | No | Short RFC comment (200-400 words) | | No | Yes | Either | 1-page design doc | | Yes | No | Yes | RFC thread in shared channel | | Yes | Yes | Either | **Full design doc, required** | | Yes | No | No | **Full design doc, required** | Six combinations, three written outcomes. The matrix prevents the "every ticket gets a doc" regression, and it prevents the "no doc, ever" regression. ## The anatomy of a design doc that gets used A doc that gets reopened six months later has these five sections and no others. Sections beyond the five are where LLM-authored slop hides. ### 1. Context (3-5 sentences) What triggered the work. The ticket, the incident, the strategic goal. One paragraph. If it's longer, the ticket title is doing the work for you. ### 2. Decision (1-3 bullet points) What we're going to build, stated flat. Not "options we're considering." The decision. Options live in section 4. ### 3. Why this and not the alternatives (the heart of the doc) Two or three alternatives considered, each with a one-paragraph explanation of why it was rejected. This is the only section that justifies the doc's existence. If you can't name alternatives, you didn't explore the space and the doc is premature. ### 4. Risks and rollback plan What could go wrong. How we'd undo this. If rollback is "revert the commit," say that in 5 words. If rollback is "migrate data back with a 12-step runbook," write the runbook. ### 5. Open questions The questions you couldn't answer alone. This is the section reviewers actually use. An open question is an invitation; an answered question is a signal you should have asked earlier. **That's it. Five sections.** If your design doc template has a "success criteria" section, a "user impact" section, and a "future work" section, they are performing ritual rather than decision capture. ## Common mistakes to avoid | Mistake | Why it hurts | Fix | |---------|-------------|-----| | Doc written after code is half-built | Review becomes rubber-stamp — the decision is already made | Write at the point of genuine uncertainty, not after | | Doc restates the PR without new reasoning | Adds calendar time, zero decision value | If it's describing code, make it a PR description instead | | Doc with 20 "options considered" | Analysis theater — no real contender ranking | Cap at 3 alternatives, brutal one-para rejection each | | Doc in a Google Doc nobody can find | Knowledge evaporates in 6 months | Store in repo under `/docs/design/` or `/rfcs/` — searchable, grep-able, PR-reviewable | | Everyone approves, nobody reviews | Social approval without decision pressure | Require at least one named "reviewer" who must leave a written comment | ## How to measure if this is working The metric is not "number of design docs written." That's a vanity count. Track two things instead: - **Fraction of docs that got reopened at least once after approval** — if under 30%, the docs aren't being used; they're being performed. The template is too heavy or the scope filter is too loose. - **Post-decision rework rate** — how often a decision made in a design doc gets revisited or reversed within 90 days. Under 15% means the doc is catching design errors; over 30% means the doc is rubber-stamping decisions that should have stayed in RFC form. At PanDev Metrics we track document-linked ticket activity — when an engineer switches IDE focus to a file referenced in a design doc, that's a signal the doc is doing what it's supposed to do. If a doc is never visited after merge, it's a candidate for deletion on the next housekeeping pass. This is data we get from [IDE heartbeat telemetry](https://pandev-metrics.com/docs/blog/how-much-developers-actually-code) cross-referenced with Git and tracker signals. The honest limit of our data: we see file-open and IDE-focus events, but we don't see whether an engineer **read and understood** the doc versus scrolled through it for 30 seconds. A doc that gets scanned isn't much better than a doc that's never opened. The qualitative signal still matters. ## The contrarian position Most engineering blogs recommend writing *more* design docs. I recommend writing *fewer*, *shorter*, and *earlier*. Fewer, because ritual documentation is worse than none — it trains engineers that docs are overhead, which makes them skip the ones that genuinely matter. Shorter, because a 5-page doc gets 3 readers; a 1-page doc gets 10. Earlier, because a doc written mid-implementation is political cover, not decision capture. If your team is in the "document everything" failure mode, reduce scope rules until at least one change per sprint is non-documented. If your team is in the "document nothing" mode, the cross-team + irreversible combination is where to start. Both extremes respond to the same 3-question framework; the difference is which direction you're tightening. ## When this framework doesn't fit Regulated environments — medtech, avionics, defense — often have mandatory documentation that the framework's scope filter won't override. A 1-day reversible change in a FDA-regulated codebase still needs a traceable design record. The framework is optimized for B2B SaaS engineering; if you're in a world where an auditor will read the doc, write the doc regardless of the scope matrix. Research organizations also operate under different rules. A 2-week exploratory prototype doesn't need a design doc; a 2-week production-bound prototype does. If the output is a paper, the paper is the doc. ## Related reading - [The CTO Dashboard: What to Show at Your Weekly](https://pandev-metrics.com/docs/blog/cto-dashboard) — where documentation metrics fit in an engineering-leader view - [MTTR: Why Speed of Recovery Matters More Than Preventing All Incidents](https://pandev-metrics.com/docs/blog/mttr-speed-of-recovery) — the "reversibility" test borrowed in Question 3 - [Context Switching Kills Productivity](https://pandev-metrics.com/docs/blog/context-switching-kills-productivity) — why ritual docs hurt focus time more than they help alignment - External: Google's [engineering practices documentation](https://google.github.io/eng-practices/) — a concise reference on code-review and design-doc norms --- ## Sprint Retrospectives That Don't Waste Time: Data-Driven Framework URL: https://pandev-metrics.com/docs/blog/sprint-retrospectives-that-work Date: 2026-04-26 Tags: tutorial, engineering-management, retrospective, agile, guide Description: Most retros end with the same five sticky notes and no follow-through. Here's a 30-minute data-driven retro that actually changes behavior. The average engineering retro runs 60 minutes, produces five sticky notes, and ships zero action items into the next sprint. The Scrum Alliance's 2023 practitioner survey put "retros feel performative" as the #1 complaint from senior engineers. That's not a meeting problem. It's a measurement problem. Teams debate feelings because nobody pulled the data before the call. This article gives you a 30-minute retrospective that opens with numbers, ends with named owners, and works on any team between 5 and 25 engineers. ## The problem with "what went well / what didn't / what to improve" That 3-column board encourages narrative, and narrative bends toward the loudest voice. A VP Engineering we spoke with at a 40-person SaaS team put it bluntly: "After the fifth retro, I realized we were solving whoever-complained-most, not whatever-actually-hurt-the-sprint." Atlassian's 2024 Agile Practitioner Report found that **62% of teams never revisit action items from the previous retro**. Items are written, agreed on, then forgotten by Wednesday. The rituals of agile outlive the discipline. Three failure modes show up in every unproductive retro: | Failure mode | What it looks like | What it actually costs | |---|---|---| | Feelings-first | Team vents; no data backs any claim | 45 minutes, zero decisions | | Loudest-voice bias | One engineer dominates the "improve" column | Junior devs stop participating | | No follow-through | Actions written but not tracked | Same issue re-raised 3 sprints later | The fix is not a better Miro board. It's bringing the sprint's actual signal into the room before anyone opens their mouth. ## The 30-minute framework Five blocks, timed strictly. A meeting facilitator with a timer runs it. No slack. ### Step 1. Data pull (5 min, before the meeting) The facilitator drops **four numbers** into the retro doc 15 minutes before start: - Planned vs delivered story points (or tickets) - Cycle time median for the sprint (commit to merge) - Incidents / rollbacks / hotfixes count - Unplanned-work ratio (ad-hoc tickets that entered mid-sprint ÷ total) If your team uses PanDev Metrics, the sprint report pulls those four automatically from IDE heartbeat data and Git events, so no one spends 20 minutes manually scraping Jira. If you don't have tooling, the scrum master spends 10 minutes in Jira + GitHub before the call. Either way, numbers on the screen before anyone talks. ### Step 2. Silent written reflection (5 min) Everyone writes in the doc, muted, for 5 minutes. Two prompts: - "One thing the data surprises me about." - "One specific thing I'd change next sprint." No "what went well" column. Engineers are bad at positive retrospection and good at specific complaints, so lean into the strength. A specific complaint is an actionable signal; a vague "team felt good" is noise. ### Step 3. Cluster and dot-vote (5 min) The facilitator clusters similar notes in real time. Everyone gets **3 dots**. Only the top 2 clusters move forward. Ignore the rest; they'll resurface if they matter. This is where you cut the typical 60-minute retro. Most teams try to address every sticky note. You're picking the 2 that actually show up in the numbers. ### Step 4. Root cause on the top 2 (10 min) For each of the 2 winners, ask "why" three times. Not five. Five is a PowerPoint ritual; three reaches the cause without turning into therapy. Example from a real retro we observed (anonymized Kazakh fintech, 12-person team): - Symptom: "Cycle time doubled this sprint" - Why 1: "PRs sat for 2 days before review" - Why 2: "Two senior reviewers were on the incident response" - Why 3: "Our on-call rotation has no backup reviewer coverage" The action wrote itself: add a "backup reviewer" rotation slot. Not a workshop on "improving collaboration." ### Step 5. Action owners and dates (5 min) Each action gets a single named owner and a due date that falls inside the next sprint. If a proposed action can't get a named owner, it dies in the meeting. If it can't fit in one sprint, it's an epic, not a retro action; kick it to planning. Write actions as `@owner will ship X by sprint-end Friday`. No "the team will explore". "Exploring" is how retro debt accumulates. ![Retro framework five-step flow diagram](https://pandev-metrics.com/img/blog/sprint-retrospectives-that-work/retro-framework.png) *Five timed blocks, 30 minutes total. Data arrives before feelings do.* ## The numbers to pull, with an interpretation cheat sheet | Metric | Healthy signal | Worth a conversation | Red-flag territory | |---|---|---|---| | Delivered / planned | 80–100% | 60–80% | Below 60% two sprints in a row | | Cycle time median | Stable or trending down | +20% sprint over sprint | Doubled | | Incidents during sprint | 0–1 | 2–3 | 4+ (every other day) | | Unplanned work ratio | Under 20% | 20–35% | Over 35% (you're not sprinting, you're firefighting) | These aren't universal targets. They're conversation starters. A team with 40% unplanned work might have a broken prioritization loop, or might be a platform team that plans that way on purpose. The retro's job is to surface the gap between the number and the story. ## Common mistakes to avoid | Mistake | Why it hurts | Fix | |---|---|---| | Running retros with no data | Loudest voice wins; you optimize for vibes | Pull the 4 numbers BEFORE the meeting | | Trying to fix everything | 6 actions = 0 shipped | Max 2 actions per retro | | Orphaned actions | "The team will look into…" | Named owner + sprint-end date | | Retros weekly at sprint end | Everyone's tired; attention tanks | Mid-morning mid-week after sprint end | | Skipping retros when sprint went well | You lose the learning signal | Good sprints have more teachable data than bad ones | That fifth one surprises people. Teams we've watched only hold retros after bad sprints, then wonder why their improvement curve plateaus. Good sprints are where you reverse-engineer what to protect. ## The checklist (copy and use) - [ ] Facilitator pulls 4 sprint numbers into retro doc, 15 min before call - [ ] 5-min silent written reflection, data visible on screen - [ ] Cluster + 3-dot vote, top 2 only - [ ] 3-whys on each top-2 cluster, 10 min total - [ ] Each action has named owner + due date inside next sprint - [ ] Previous retro's actions are reviewed at the top of the *next* retro (not this one) - [ ] Retro ends on time, no overflow Running the previous actions at the *top* of the next retro, not the bottom, is the single change that fixes the "62% of actions forgotten" problem from the Atlassian data. People show up having done the homework because they know it gets called out first. ## How to measure if the retro is working Tracking whether a meeting works is meta, but it's the only way out of ritual theater. Watch these over 4–6 sprints: - **Action closure rate.** % of retro actions closed within the sprint they were assigned. Target: >80%. Under 50% means you're generating commitments you can't keep. - **Issue recurrence rate.** How often the same theme re-appears. If "code review is slow" shows up in 3 consecutive retros, the retro itself is broken, not the code review. - **Sprint-over-sprint cycle time.** Slow but real improvement signal. If cycle time hasn't moved in 6 sprints, the retros aren't producing usable learning. PanDev Metrics tracks cycle time and incident count as first-class metrics across sprints, which makes the first-2-minutes "pull the numbers" step take literal seconds. If you're doing it manually, budget 10 minutes of pre-meeting prep. It's the highest-ROI 10 minutes of the week. ## When this framework doesn't fit Two cases: very small teams and distributed async-only teams. For a 2–3 person team, the whole ritual is overhead. Swap it for a weekly 15-minute sync on one number that matters and one action. The formal framework adds structure you don't need at that scale. For async-only teams across 6+ timezones, the 30-minute synchronous block is the wrong shape. Run the same 5 steps over 24 hours on a shared doc, with the facilitator driving each block's deadline. Less fun, same output. ## The hardest part isn't the meeting Writing actions is easy. Closing them is where teams die. The teams we've seen get retros right share one habit: retro actions are treated as real tickets in the tracker, with the same scrutiny as customer-facing work. The moment they become "nice-to-have improvement items in a Notion page," they're dead. ## Related reading - [Code Review Checklist: 11 Rules That Cut Review Time in Half](https://pandev-metrics.com/docs/blog/code-review-checklist-2026) - [10 Engineering Metrics Every Manager Should Track in 2026](https://pandev-metrics.com/docs/blog/10-metrics-every-engineering-manager-should-track) - [How to Run Data-Driven 1:1s With Your Developers](https://pandev-metrics.com/docs/blog/data-driven-one-on-one) --- ## Pair Programming ROI: Is It Worth the Time? (Research) URL: https://pandev-metrics.com/docs/blog/pair-programming-roi Date: 2026-04-25 Tags: research, engineering-management, developer-productivity, pair-programming Description: Two developers, one keyboard — does it double cost or double quality? We crossed Cockburn–Williams data with our IDE telemetry to get the real ROI. Two developers on one task. Double the labor cost, half the bugs, and nobody agrees on whether it pays back. The most-cited study on this question — [Cockburn & Williams, *The Costs and Benefits of Pair Programming* (2000)](https://collaboration.csc.ncsu.edu/laurie/Papers/XPSardinia.PDF) — reported a **15% time overhead** for paired work and a **15% drop in defects**. That looks neutral on paper. It isn't. The math of defects-caught-early flips the ROI by roughly **2×** once you include rework avoided and shipped-bug incidents prevented. This article crosses Cockburn and Williams' academic data with our own IDE heartbeat dataset across 100+ B2B companies — including teams that pair daily and teams that never do — to answer the question practically. Not "is pair programming good?" but "when does it pay back and when is it theatre?". ## Why the original 15/15 number is misleading Cockburn and Williams' headline numbers — 15% more time, 15% fewer defects — were computed against a student baseline doing a fixed algorithmic assignment. Real engineering work is messier. Three factors push the real ROI up: 1. **Defect cost escalates exponentially.** A bug caught in pair-review costs ~1× the coding time. A bug caught in QA costs ~5×. A bug shipped to production costs 15-30× once you include incident response, rollback, and customer trust. Boehm's cost-of-defect curve (1981, validated repeatedly since) hasn't moved much. 2. **Onboarding is invisible to the 15% overhead.** Paired sessions double as context transfer. Our dataset shows new developers paired for 4+ hours per day during week one reach [baseline commit cadence](https://pandev-metrics.com/docs/blog/developer-onboarding-ramp) in **18 days vs 32 days** for solo onboardees. 3. **Knowledge silos compound interest.** Single-owner code ages into technical debt. Pairing distributes the knowledge — a separate ROI lever most pair-programming studies ignore entirely. The flip side: pairing has a real cost that the 15% number understates. Context switches, scheduling overhead, personality friction, and the fact that not all code benefits equally. We'll quantify those too. ![Bar chart showing defect rates relative to solo coding, with driver-navigator at 57%, strong-style at 42%, and mob programming reducing further](https://pandev-metrics.com/img/blog/pair-programming-roi/defect-reduction-bars.png) *Relative defect rates by pair/mob style, normalized to solo=100%. Data synthesized from Cockburn–Williams 2000, Nosek 1998, and three internal teams in our dataset that run strict pair rotations.* ## What the research actually says Four studies are worth citing directly. They disagree on magnitude but agree on direction. | Study | Setting | Time overhead | Defect reduction | |-------|---------|:-:|:-:| | Cockburn & Williams (2000) | University, algorithmic | +15% | −15% | | Nosek (1998) | Professional, 45-min sessions | +40% | −40% (significant at p<0.05) | | Williams et al. (2003) | Industry, IBM | +15-25% | −40-50% (integration defects) | | Müller (2006) | Industry, long-term adoption | +25-30% | "No measurable difference on simple tasks; large on complex" | Two patterns hold across every study: - **Pairing doesn't help simple work.** CRUD endpoints, data migrations, config changes — solo is faster and just as safe. Müller (2006) found the benefit disappears entirely for task complexity below a threshold that roughly corresponds to "can one experienced dev hold it fully in their head?" - **Pairing disproportionately helps complex work.** Architecture decisions, new-system design, security-critical paths, unfamiliar languages. Nosek's 40% defect reduction came from algorithmic problems experienced devs found genuinely hard. The honest limit: no study we've seen controls for developer *preference*. Teams that chose pair programming tend to be the teams that would outperform anyway. Effect size is real, but it's smaller than zealots claim. ## Our data: how pairing looks from the IDE Our [IDE heartbeat dataset](https://pandev-metrics.com/docs/blog/how-much-developers-actually-code) can't see "who was in the room", but it can see co-located editing — two developers with heartbeats on the same file, same branch, within overlapping 30-minute windows. Across 100+ B2B companies in our dataset, we identified 17 teams with sustained pair-programming signatures (≥ 2 co-edit sessions per developer per week for at least 6 weeks). Headline findings from those 17 teams vs matched solo-working teams: | Metric | Pair-programming teams | Solo-working teams | Delta | |-------|:-:|:-:|:-:| | Median coding time per dev/day | 1h 24m | 1h 18m | +6 min | | Focus blocks ≥ 45 min per week | 11 | 9 | +22% | | [Change failure rate](https://pandev-metrics.com/docs/blog/change-failure-rate-15-percent-normal) | 8.7% | 14.2% | −39% | | Code review round-trips per PR | 1.3 | 2.1 | −38% | | New-hire time to first merged PR | 4.2 days | 7.8 days | −46% | Two things stand out. First, pair-programming teams don't code *less* in our data — the "pair penalty" the literature predicts isn't visible at the daily-hours level. We suspect pairing replaces context-switching and Slack-chatter time, not focused coding time. Second, the review-round-trip delta (1.3 vs 2.1) is where the real throughput gain hides. Most engineering-productivity frameworks ignore this entirely. ![Donut chart showing how a 2-hour pair session splits between coding, discussion, handoffs, and breaks](https://pandev-metrics.com/img/blog/pair-programming-roi/time-overhead-donut.png) *Inside a 2-hour pair session: 65% active coding, 20% discussion, 8% driver-switch handoffs, 7% breaks. The "overhead" is mostly discussion that would otherwise happen in Slack or in a PR comment three days later.* ## When pair programming actually pays back Based on the combined research and our dataset, pairing has positive ROI when one or more of these conditions hold: **1. The task is novel or architectural.** Anything where a senior dev would need to think carefully before writing. Not typing practice. **2. One of the pair is new to the codebase or language.** Onboarding ROI alone justifies 4-8 weeks of daily pairing for every new hire. The 46% faster time-to-first-merged-PR in our data pays back the "cost" instantly. **3. The code is security- or money-critical.** Payments, auth, data-migration scripts. Two heads reduce the probability of silent production mistakes that cost six figures to unwind. **4. The team is geographically co-located enough to pair without video-call fatigue.** Remote pairing works but adds ~20% overhead on top of the standard 15-25%. If your team is across three timezones, see our [distributed sprint planning guide](https://pandev-metrics.com/docs/blog/sprint-planning-distributed-teams) before mandating pairs. ## When it's theatre, not value Equally important — when NOT to pair: - **Routine CRUD, bug fixes under 50 LOC, documentation updates.** Solo is strictly faster with no quality penalty. - **When one person is clearly not at the keyboard.** If the "navigator" is answering Slack or checking email, the session is just a solo session with a distraction tax. Teams running honest pair time track who drove and who navigated, and rotate every 15-25 minutes. - **When the pair is two juniors on an unfamiliar area.** Nosek and others consistently find junior-junior pairs produce more bugs than either would alone. The value of pairing is asymmetric senior-junior or equal-senior-senior. - **Status-broadcast pairing.** "We pair because it looks good on our hiring page" — instantly detectable by the absence of any measurable change in review cycle time. ## The ROI calculation we recommend Instead of the academic "time overhead vs defect reduction" framing, we recommend teams compute pair programming ROI as: > **ROI ratio = (defects-avoided × average-defect-cost + onboarding-time-saved × hourly-rate + review-cycle-reduction × throughput-value) ÷ (pair-time × 2 × hourly-rate)** For a US-rate $120/hr team with an average production-incident cost around $5,000, a 40% defect reduction on the 20% of tasks worth pairing typically returns **1.8× to 2.4×** the investment. The arithmetic depends sharply on incident cost — fintech teams where an outage costs millions will see ROI of 5× or more. A low-stakes internal tool sees close to break-even. The spreadsheet that computes this lives inside PanDev Metrics as the AI Assistant view "Pair-vs-solo productivity by project" — you can ask natural-language questions like "compare defect rates for the payments team against the dashboard team over the last quarter" and get the ratio on a chart. ## How to pilot pair programming without waste If you're going to try it, try it as an experiment with measurable outputs: 1. **Pick 3-5 engineers who want to try it.** Volunteer-first pilots have 3× the survival rate of mandates. 2. **Limit to complex-task pairing only.** Define "complex" up front (e.g. "any ticket estimated 3+ points" or "anything touching payment flows"). 3. **Track the 4 metrics from our table above** — coding time, change failure rate, PR review rounds, onboarding time. Run for 8 weeks minimum. 4. **Measure the pair-driver split.** Nobody types for 2 hours straight — rotate every 15-25 min. If your pairs aren't rotating, you have one person working and one watching. 5. **Kill or expand based on data.** If review rounds dropped ≥30% and defect rate dropped ≥20%, expand. If neither moved, kill the pilot — it's theatre. ## What the data says about mob programming Mob programming (3+ devs on one task) is pair programming's riskier cousin. Our dataset has only 3 teams with sustained mob signatures, so treat this as directional: - Mob reduces defects further than pair (roughly −55% vs solo in these 3 teams, vs −39% for pair). - Mob overhead is much higher (2.5-3× labor cost for ~55% defect reduction = net negative for most work). - Mob ROI positive only on highest-criticality problems — regulatory code, cryptographic primitives, migration cutovers. Woody Zuill's [original mob programming writeups](https://www.agilealliance.org/glossary/mob-programming/) confirm the pattern. Don't mob for routine features. Mob when the cost of getting it wrong is catastrophic. ## The contrarian view The loudest pair-programming advocates frame it as a cultural practice. "We pair because we care about craft." Our data says the craft-narrative usually isn't what's driving the ROI — it's the **review-round-trip reduction** (1.3 vs 2.1). Pair programming works mostly because it compresses code review into the writing phase itself. If your team's bottleneck is review latency, pair programming is a high-leverage fix. If your bottleneck is elsewhere (requirements churn, deploy friction, flaky tests), pairing won't help you, no matter how much you love the idea. The sharpest finding: in our 17 pair-programming teams, the defect reduction correlates **0.72** with the review-round-trip reduction, but only **0.31** with developer-reported satisfaction. The mechanism is technical, not cultural — even when the team thinks the opposite. ## Where to go next - If your review cycle is slow, start there: [Code review checklist](https://pandev-metrics.com/docs/blog/code-review-checklist-2026). - If onboarding is the motivation, see [developer onboarding ramp data](https://pandev-metrics.com/docs/blog/developer-onboarding-ramp). - If you want to measure defect reduction honestly, wire up [change failure rate tracking](https://pandev-metrics.com/docs/blog/change-failure-rate-15-percent-normal) before you pilot pairing — otherwise you're measuring vibes. Pair programming isn't a silver bullet and isn't a waste. It's a targeted instrument with roughly 2× ROI on the right 20% of your team's work. The question isn't "should we pair?" — it's "which 20%?". --- ## Code Review Checklist: 11 Rules That Cut Review Time in Half URL: https://pandev-metrics.com/docs/blog/code-review-checklist-2026 Date: 2026-04-24 Tags: engineering-management, tutorial, code-review, developer-productivity Description: Every team has 3+ PRs stuck 'in review' right now. The best engineering managers use 11 rules to fix it, backed by Google, SmartBear, and DORA data. Right now, your team has pull requests stuck in review. Probably three or more. One's been sitting for five days. A 2018 study from Google's engineering productivity group ([Sadowski et al., *Modern Code Review: A Case Study at Google*](https://research.google/pubs/pub47511/)) found that the median review at Google completes in less than 4 hours. In most teams we see, that number is 4 days — a **24× gap** explained almost entirely by process, not talent. This is a checklist of 11 rules that cut review time in half without reducing quality. Each is backed by external research, refined against real engineering-team data, and structured into three phases: author discipline, reviewer discipline, team discipline. ## Why most code review fails today Three patterns appear across teams with slow review cycles: **Pattern 1: Oversized PRs.** SmartBear's *State of Code Review* research found defect detection effectiveness falls off sharply once a diff exceeds ~400 lines. Above 400, reviewers skim. Above 1,000, they rubber-stamp. Most teams we measure have a median PR size between 350-600 lines, right at the edge of the cliff. **Pattern 2: Context reconstruction.** Microsoft Research (Bacchelli & Bird, 2013, *Expectations, Outcomes, and Challenges of Modern Code Review*) found reviewers spend up to 30% of review time just figuring out what the PR is trying to do. A weak PR description is the single biggest time-sink in review. **Pattern 3: Review-as-tax mentality.** Reviewers treat reviews as an interruption rather than scheduled work. The result: [context-switching penalties compound](https://pandev-metrics.com/docs/blog/context-switching-kills-productivity), reviewer opens the PR, reads 20 lines, gets pinged in Slack, closes the tab, returns three hours later. The 11 rules below attack all three patterns at once. ![Three-phase code review framework: Author, Reviewer, Team. Each phase lists its rules in a purple-pink gradient flow diagram.](https://pandev-metrics.com/img/blog/code-review-checklist-2026/framework-flow.png) *The framework in one picture: 3 author rules, 4 reviewer rules, 4 team rules. Each phase enforces a different failure mode.* ## Phase 1: Author discipline The author controls 70% of review speed. If they do these three things, reviewers have a realistic shot at fast turnaround. ### Rule 1: Cap PR size at 400 lines of diff Hard limit. SmartBear's data shows defect detection per hour peaks at 200-400 lines and drops fast after that. A 1,200-line PR doesn't get 3× the review of a 400-line one. It gets just 1/3. Split it. | PR size (lines) | Typical outcome | |:-:|-----| | Under 100 | Reviewed in minutes; 90%+ comments are substantive | | 100-400 | Optimal zone; reviewer stays engaged end-to-end | | 400-1000 | Reviewer skims second half; misses 40%+ issues | | **Over 1000** | Rubber-stamp approval; no meaningful review | **Exception:** generated code, config files, and pure test-additions don't count toward the 400. Count files where a human actually wrote new logic. ### Rule 2: Write a structured PR description Every PR description answers three questions, in this order: 1. **What changed?** (one paragraph) 2. **Why?** (link to ticket, we use the `feature/TASK-324` branch naming convention so Jira auto-links) 3. **How to verify?** (exact steps, screenshots, or test output) If the reviewer can't answer "what is this supposed to do?" in 30 seconds, the description is broken. ### Rule 3: Self-review before requesting others Open your own PR. Read the diff as if a stranger wrote it. Bacchelli & Bird's research found authors who self-review catch ~30% of the issues that would otherwise land with a reviewer. The time cost is 5-10 minutes; the savings are a full review cycle. ## Phase 2: Reviewer discipline Reviewers control quality. These four rules prevent the silent quality decay that creeps in as PRs pile up. ### Rule 4: Limit review sessions to 60 minutes Cognitive fatigue is real. SmartBear's data shows that after 60 minutes of focused review, defect detection rates drop by more than half. If a PR needs more than an hour, either split it (see Rule 1) or schedule a second session with a break. ### Rule 5: Tag every comment with a severity level Three levels only: - `must-fix`: blocks merge - `should-fix`: worth doing, not a blocker - `nit`: preference, safe to ignore Without tags, authors treat every comment as a blocker. Teams that adopt this convention report review turnaround improvements of 30-40% in the first month. ### Rule 6: No LGTM on non-trivial changes "LGTM" ("looks good to me") is fine for a typo fix or dependency bump. For anything with logic, require the reviewer to articulate **what they verified**. One sentence is enough: "Verified error path handles timeout correctly; checked migration is idempotent." This sentence is the artifact of the review; it's also what catches fake-approvals during audit. ### Rule 7: Two reviewers maximum: one domain expert + one peer This is the contrarian rule and the most frequently broken. Adding a third reviewer feels safer but makes reviews **slower AND lower quality**. Once three people are assigned, the bystander effect kicks in; each reviewer assumes someone else is doing the careful read. Research on group decision-making (Latané & Darley's classic work, plus more recent engineering-team studies) consistently shows two-person teams produce sharper critiques than three-person ones. The right combination: one domain expert (for correctness) + one peer (for maintainability and knowledge-sharing). Three reviewers are only justified for changes touching security-critical paths, and even then,, explicit sign-off from each. ## Phase 3: Team discipline Individual rules fail without team agreement on norms. These four rules are process, not craft. ### Rule 8: First review within 4 business hours of PR creation Not four wall-clock hours. Four business hours, the time your reviewer is actually online and working. Google's median-4-hours benchmark is achievable for most teams if this rule is enforced. We measure this in [lead time's 4 stages](https://pandev-metrics.com/docs/blog/lead-time-4-stages-breakdown) — "first-review-response" is stage 2, and it's where most teams hemorrhage time. ### Rule 9: All automated checks pass before human review Linters, tests, security scans, and build verification all run on PR creation. A human reviewer should never spend a minute on something a machine would catch. If your automated suite is slow (takes longer than 10 minutes to complete), fix that before optimizing review. It's upstream of every review metric. ### Rule 10: Author merges, not reviewer After approval, the **author** merges. This preserves ownership: the author confirms they agree with all resolved discussion, they verify the branch is still green against main, and they own the consequences. Reviewer-merge creates zombie PRs: approved and then abandoned because the author moved to other work. ### Rule 11: Escalate after 48 hours without final decision If a PR has been open for 48 business hours without either a merge or an explicit "don't merge this," the EM escalates. Someone is blocked, either the reviewer is overloaded, the author is avoiding feedback, or the team priority is unclear. 48-hour PRs are a process-health signal, not individual failures. ## Common mistakes that break the system | Mistake | Why it hurts | Fix | |---------|-------------|-----| | "LGTM" on a 900-line PR | Reviewer couldn't have actually verified it; creates false audit trail | Rule 1 + Rule 6 | | Author doesn't self-review | Reviewer burns 10 min on issues author could have seen | Rule 3 | | 3+ reviewers on routine changes | Bystander effect; none of them reviews carefully | Rule 7 | | Reviewer pages author mid-review instead of commenting | Context switches both parties | Add comment + `@mention` in PR | | PR sits for 3 days; author starts new work | Author loses context of the PR; rework cost compounds | Rule 11 | | "Suggestion" on whitespace as a blocker | Wastes cycles on subjective preference | Rule 5 (`nit` tag) | ## The checklist, print and pin Author: - [ ] PR under 400 lines of human-written logic - [ ] Description answers What / Why / How-to-verify - [ ] Self-reviewed - [ ] All automated checks green Reviewer: - [ ] Session ≤ 60 minutes (take a break if longer needed) - [ ] Every comment tagged `must-fix` / `should-fix` / `nit` - [ ] If approving, wrote one sentence on what was verified - [ ] At most 2 reviewers assigned Team: - [ ] First review started within 4 business hours - [ ] Author merges after approval - [ ] Escalate any PR open > 48 business hours ## How to measure if this is working Track these [engineering metrics](https://pandev-metrics.com/docs/blog/10-metrics-every-engineering-manager-should-track) before and after enforcement. Expected shifts after 4-6 weeks: | Metric | Before typical | After target | |--------|:-:|:-:| | Median PR size (LoC) | 350-600 | **≤ 400** | | Median time to first review | 1-3 days | **< 4 business hours** | | Median PR open-to-merge time | 3-5 days | **≤ 1 business day** | | Rejected-after-approval rate | 8-15% | **< 5%** | | Reviewer comment specificity rate (`must-fix` tagged) | 0% | **> 60%** | PanDev Metrics tracks PR cycle time directly from Git events tied to task-tracker IDs, you can see these numbers per team, per repository, or per individual reviewer in the dashboard. **Honest limit:** we measure PR timestamps (created, first-review, merged), but we don't measure active minutes spent scrolling or commenting in the review UI. We infer reviewer engagement from their IDE activity gaps during the open-to-merge window, a good proxy, but not a direct measure. ## When this framework doesn't fit Three scenarios where the 11 rules need adjustment: 1. **Research or spike branches.** Experimental code that won't merge to main can ignore most of this. Mark it as WIP and skip the review SLA. 2. **Solo developers on early-stage projects.** There's no one to review. Run the author rules (self-review in particular) and defer the reviewer rules until the team grows. 3. **Massive automated generators.** Kubernetes manifests, generated API clients, translations, these can legitimately produce 10,000-line diffs. Review the generator, not the output. For everything else, product teams, service teams, maintenance work, hotfixes, the 11 rules apply without modification. ## Related reading - [Lead Time for Changes: the 4-Stage Breakdown That Reveals Your Real Bottleneck](https://pandev-metrics.com/docs/blog/lead-time-4-stages-breakdown) - [The 40% Productivity Tax of Context Switching](https://pandev-metrics.com/docs/blog/context-switching-kills-productivity) - [10 Engineering Metrics Every Manager Should Track in 2026](https://pandev-metrics.com/docs/blog/10-metrics-every-engineering-manager-should-track) --- ## How Much Time Developers Actually Code, Debug, and Meet (2026 Data from 100k Devs) URL: https://pandev-metrics.com/docs/blog/how-much-developers-actually-code Date: 2026-04-16 Tags: research, developer-productivity, engineering-metrics, data Description: Real IDE-tracked stats: developers code 3.2h, debug 1.8h, meet 2.5h per day. Full breakdown by SPACE framework — debugging and meeting time statistics 2026. Every engineering leader asks the same question: **how much time do developers actually spend writing code?** Microsoft Research found that developers spend only 30-40% of their time writing code. A 2019 study by Haystack Analytics suggested closer to 2 hours. Our own IDE heartbeat data across B2B engineering teams confirms a **median of 78 minutes per day**. Here's what the data actually shows and why it matters. ## Why This Question Is Hard to Answer Most "developer productivity" numbers online are self-reported. The problem? Research published in the Journal of Biomedical Informatics found that self-reported work hours are inflated by 10-20% compared to observed hours. Developers are no exception: context switching, debugging, and "thinking time" feel like coding. IDE heartbeat data solves this. Every few minutes, the editor sends a signal confirming the developer is actively writing or editing code. No self-reporting. No guesswork. Just timestamps. Here's what real coding activity looks like when measured through IDE heartbeats — an activity heatmap from PanDev Metrics showing coding sessions across two weeks, broken down by hour: ![Activity heatmap showing developer coding sessions by hour and day — yellow blocks indicate active coding, gaps show meetings or non-coding work](https://pandev-metrics.com/img/blog/activity-heatmap.png) Each colored block represents an active coding session. The pattern is immediately visible: most coding happens between 9 AM and 6 PM, with noticeable gaps during lunch and meeting-heavy hours. Some late-night sessions appear, but they're rare. ## What the Data Shows ### Median: 78 minutes per day | Metric | Value | |--------|-------| | **Median coding time per day** | **78 min (1h 18m)** | | **Mean coding time per day** | **111 min (1h 51m)** | | Minimum (among regular coders) | ~10 min | | Maximum | ~280 min (4h 40m) | The median is **30% lower** than the mean, a classic sign of right-skewed distribution. A few power coders pull the average up. For benchmarking, **always use the median**. This aligns closely with external research. A 2022 paper by Xia et al. in IEEE Transactions on Software Engineering found that developers spend an average of 52 minutes per day in active coding sessions, with significant variation based on role and project phase. ### Distribution: the 1-2 hour sweet spot | Daily coding time | Share | |-------------------|:-----:| | Under 30 min | ~12% | | 30-60 min | ~21% | | **1-2 hours** | **~32%** | | 2-3 hours | ~9% | | 3-4 hours | ~21% | | 4+ hours | ~6% | The largest group codes **1-2 hours per day**. Over half fall between 30 minutes and 2 hours. The "mythical 8-hour coder" doesn't exist in any dataset we've seen, academic or commercial. This distribution matches findings from the SPACE framework paper (Forsgren et al., 2021) which argues that developer productivity cannot be reduced to a single dimension like coding time. ### Tuesday is the most productive day | Day | Activity level | |-----|:-------------:| | Monday | High | | **Tuesday** | **Peak** | | Wednesday | High | | Thursday | Medium-High | | Friday | Medium | | Saturday | Low | | Sunday | Minimal | Tuesday consistently leads in aggregate coding activity across companies of different sizes and industries. Friday shows a noticeable dip, and weekend coding runs at roughly 3-4x lower volume than weekdays. Similar patterns appear in GitHub's analysis of commit timestamps across millions of repositories: Tuesday and Wednesday dominate global commit activity. ### VS Code leads, Cursor is the fastest-growing | IDE | Market position | |-----|:--------------:| | **VS Code** | Dominant | | **Cursor** | Fastest-growing (AI-first) | | **JetBrains** (IntelliJ, PhpStorm, WebStorm) | Strong in Java/PHP ecosystems | | Visual Studio | Enterprise / .NET | The 2024 Stack Overflow Developer Survey confirmed VS Code as the most popular IDE at 73.6%. Our data shows a similar pattern, with **Cursor emerging as a significant new player**, reflecting the rapid adoption of AI-assisted development tools. ### Java and TypeScript dominate actual coding time | Language | Position | |----------|:-------:| | Java | Leading | | TypeScript (including TSX) | Close second | | Python | Third | | PHP | Significant | | Kotlin, Dart, C# | Notable presence | | YAML | Top 10 | The presence of **YAML in the top 10** reflects modern development reality. Infrastructure-as-code, CI/CD configs, and Kubernetes manifests consume meaningful engineering time. The 2023 CNCF Survey found that 84% of organizations use or evaluate Kubernetes, which explains the YAML investment. ## What This Means for Engineering Leaders ### 1. Stop expecting 6-8 hours of coding Pure coding time of 1-2 hours per day is **normal and healthy**. The remaining time goes to code reviews, architecture discussions, debugging, documentation, and context switching. As Cal Newport argues in *Deep Work*, the capacity for focused creative work is limited to roughly 4 hours per day, and that's the upper bound. Most knowledge workers operate well below that. ### 2. Protect Focus Time over total hours Developers who code 3-4 hours daily likely have **fewer interruptions**, not more talent. Research by Gloria Mark at UC Irvine found that it takes an average of 23 minutes to refocus after an interruption. A developer with three meetings scattered throughout the day may have zero effective focus blocks. PanDev Metrics tracks Focus Time as a percentage of total activity — the higher the percentage, the fewer interruptions a developer experienced. In the dashboard below, you can see real-time activity across the entire team: ![PanDev dashboard showing real-time team activity, online status, projects, and event timeline](https://pandev-metrics.com/img/blog/dashboard-clean.png) **Actionable**: Reduce meetings on Tuesdays and Wednesdays when coding momentum peaks. Establish "focus hours" with no meetings. ### 3. Use median for team benchmarking The mean (111 min) is misleading because outliers skew it. **Median (78 min) is your honest benchmark.** If your team is in this range, they're performing normally. If significantly lower, investigate meeting culture before questioning motivation. ### 4. Measure, don't guess Self-reported time tracking is consistently inaccurate. IDE heartbeat data captures actual editor focus, providing ground truth instead of perception. This matters especially for remote teams where visibility is lower. > "As a CTO and for our tech leads, it's important to see not individual employees but the state of the development process: where it's efficient and where it breaks down. The product allows natively collecting metrics right from the IDE, without feeling controlled or surveilled. Implementation was very simple." > — Maksim Popov, CTO ABR Tech ([Forbes Kazakhstan, April 2026](https://forbes.kz)) ## Methodology This analysis uses anonymized, aggregated IDE heartbeat data from PanDev Metrics. We filtered for B2B engineering teams with consistent activity over a 90-day window. All data represents pure coding activity (editor focus), excluding idle time, browser activity, and meetings. No individual or company-identifying data was exposed. Our findings are consistent with published academic research on developer work patterns, including studies from Microsoft Research, IEEE, and the SPACE framework. --- **Want to understand your team's real coding patterns?** [PanDev Metrics](https://pandev-metrics.com) tracks IDE activity with second-level precision across VS Code, JetBrains, and 8 more editors. Free to start. --- ## As Featured in Forbes Kazakhstan: How PanDev Metrics Helps CTOs See What Actually Happens in Development URL: https://pandev-metrics.com/docs/blog/forbes-kazakhstan-pandev-metrics-2026 Date: 2026-04-14 Tags: press, case-study, forbes, client-stories, engineering-metrics Description: Forbes Kazakhstan (April 2026) featured PanDev Metrics in their article 'Trust the Big Brother.' Here are the key takeaways, real client quotes, and results from ~40 companies piloting the platform. Forbes Kazakhstan dedicated pages 104–107 of their April 2026 issue to engineering intelligence — and to PanDev Metrics specifically. The article, titled **"Доверься «большому брату»"** ("Trust the Big Brother"), explored how data-driven development management is gaining traction across Central Asia and beyond. Rather than republishing the piece, we want to highlight the parts that matter most: what our clients actually said, what the numbers show, and where the industry is heading. ## What CTOs Are Saying The Forbes article featured interviews with two CTOs currently using PanDev Metrics. Their feedback captures what we hear most often — the platform works because it measures **processes**, not people. > "As a CTO and for our tech leads, it's important to see not individual employees but the state of the development process: where it's efficient and where it breaks down. For this you need transparent metrics and convenient tools. The product allows natively collecting metrics right from the IDE, without feeling controlled or surveilled. Implementation was very simple — the main challenge was correctly communicating the tool's value to the team." > > — **Maksim Popov**, CTO, ABR Tech > "The main thing that stands out about the team is their responsiveness and client orientation. If questions or bugs arise, the team reacts quickly and promptly makes fixes. Our improvement requests are always heard and considered. The service continues to improve, there are growth areas in onboarding and metric collection." > > — **Rauan Bozabaev**, CTO, Chocofood Two different companies, two different scales — but a consistent theme: transparency without surveillance, and a team that listens. ## Results by the Numbers Forbes cited several data points from PanDev clients. Here's a summary: | Metric | Impact | |---|---| | Developer productivity | **+30%** increase | | Release quality | **+25%** improvement | | Labor cost reduction (hourly pay model) | **25–30%** savings | | Overall development budget savings | **10–30%** | These aren't projections. They come from real pilots across ~40 companies, including Biometric, Neo Code, Parqour, Zeely, ABR Tech, and Chocofood. ## The "Whoop for Developers" Analogy One comparison from the article stuck with us. Forbes drew a parallel between PanDev and fitness trackers like **Whoop** and **Garmin** — devices that don't tell athletes what to do, but give them the data to make better decisions. The same principle applies here: a developer can evaluate how productively they work, identify patterns, and improve on their own terms. Management gets process-level visibility. Nobody gets a surveillance camera pointed at their screen. ## AI Transparency: A Real Problem, A Real Solution The article highlighted a telling data point: within the same team, one developer writes **30% of their code with AI**, while another writes **70%**. Without visibility into this, a CTO has no way to assess actual skill levels, code ownership risks, or where AI-generated code might need extra review. PanDev also includes **anti-fraud protection** — the system detects when developers attempt to game their metrics. This isn't about catching people; it's about ensuring the data teams rely on for decisions is trustworthy. ## Company Snapshot For those unfamiliar with PanDev, here's where things stand as of April 2026: - **Founders:** Artur Pan (CTO, former early engineer at Kaspi Marketplace) and Madiyar Bakbergenov (CEO) - **Investment:** $400K at a $5M valuation from MA7 Ventures, MOST Accelerator Fund, and Axiom Capital - **Next round:** Planning $15–20M - **Clients in pilot:** ~40 companies - **Revenue (YTD from start of 2026):** $8,000 ### Pricing | Team Size | Monthly Price | |---|---| | Up to 20 engineers | $300/mo | | 20–50 engineers | $700/mo | | 50–100 engineers | $1,500/mo | ## What This Means Being featured in Forbes Kazakhstan is a milestone, but it's not the point. The point is that engineering leaders across the region are actively looking for better ways to understand their development processes — and the old methods (gut feeling, lines of code, story points) aren't cutting it anymore. If you're a CTO or VP of Engineering dealing with the same questions Maksim and Rauan described — where does time go, where do processes break, how do you measure without micromanaging — [we'd like to show you what we've built](https://pandev-metrics.com). --- ## DORA Metrics: The Complete Guide for Engineering Leaders (2026) URL: https://pandev-metrics.com/docs/blog/dora-metrics-complete-guide-2026 Date: 2026-04-13 Tags: dora-metrics, devops, engineering-leadership, guide Description: Everything you need to know about DORA metrics in 2026: Deployment Frequency, Lead Time, Change Failure Rate, and MTTR. With benchmarks, implementation guide, and common pitfalls. According to the 2023 McKinsey developer productivity report, developers spend only 25-30% of their time writing code. The rest disappears into meetings, waiting, and process overhead. DORA metrics exist to make that invisible waste visible — and fixable. If you're a CTO, VP of Engineering, or Engineering Manager who hasn't adopted DORA yet, you're managing by intuition in an era that demands evidence. This guide covers what each metric measures, how to benchmark your team, how to implement tracking, and the mistakes that make DORA data useless. ## What Are DORA Metrics? DORA (DevOps Research and Assessment) metrics come from the research team behind Google's *Accelerate: State of DevOps* reports. After studying thousands of engineering organizations over 10 years, they identified **four key metrics** that predict software delivery performance and organizational success. These aren't vanity metrics. The research, based on data from over 36,000 professionals across ten years of annual surveys, has demonstrated statistically significant links between DORA performance and organizational outcomes including profitability and market share. Teams that score "Elite" deliver **973x more frequently** than low performers, with **6,570x faster lead times** (Accelerate State of DevOps Report, 2023). ## The Four DORA Metrics ### 1. Deployment Frequency **What it measures:** How often your team deploys code to production. | Performance level | Benchmark | |-------------------|-----------| | Elite | On-demand (multiple times per day) | | High | Between once per day and once per week | | Medium | Between once per week and once per month | | Low | Less than once per month | **Why it matters:** High deployment frequency means smaller changesets, lower risk per deploy, and faster feedback loops. Teams that deploy daily catch bugs in hours, not weeks. **Common mistake:** Counting "merges to main" instead of actual production deployments. A merge is not a deploy. ### 2. Lead Time for Changes **What it measures:** Time from first commit to code running in production. | Performance level | Benchmark | |-------------------|-----------| | Elite | Less than one hour | | High | Between one day and one week | | Medium | Between one week and one month | | Low | More than one month | **Why it matters:** Long lead times mean slow feedback, large risky releases, and frustrated product teams waiting weeks for a "small fix." #### The 4 Stages of Lead Time Most tools show Lead Time as a single number. That's like a doctor saying "you're sick" without telling you what's wrong. **PanDev Metrics breaks Lead Time into 4 stages:** | Stage | What happens | Where time is lost | |-------|-------------|-------------------| | **Coding** | First commit → Merge Request created | Developer working on the feature | | **Pickup** | MR created → First review | Waiting for someone to start reviewing | | **Review** | First review → MR merged | Review cycles, back-and-forth | | **Deploy** | MR merged → Running in production | CI/CD pipeline, manual approvals | This breakdown reveals **where your bottleneck actually is**: - Long **Coding** stage? Tasks are too large — break them down. - Long **Pickup** stage? Your team has a review culture problem — PRs sit unreviewed. - Long **Review** stage? Too many review cycles — clarify standards upfront. - Long **Deploy** stage? Your CI/CD pipeline needs work — automate approvals. ### 3. Change Failure Rate **What it measures:** Percentage of deployments that cause a failure in production (requiring a hotfix, rollback, or patch). | Performance level | Benchmark | |-------------------|-----------| | Elite | 0–5% | | High | 5–10% | | Medium | 10–15% | | Low | More than 15% | **Why it matters:** Deploying frequently is only valuable if deploys don't break things. Change Failure Rate balances speed with stability. **Common mistake:** A 0% failure rate isn't good — it usually means you're not deploying enough, or you're not detecting failures. **5% is healthy.** ### 4. Mean Time to Restore (MTTR) **What it measures:** How long it takes to recover from a failure in production. | Performance level | Benchmark | |-------------------|-----------| | Elite | Less than one hour | | High | Less than one day | | Medium | Between one day and one week | | Low | More than one week | **Why it matters:** Failures are inevitable. What separates elite teams is **how fast they recover**. An MTTR of 30 minutes means a production incident is a minor inconvenience. An MTTR of 3 days means it's a crisis. ## How DORA Metrics Work Together The four metrics form two pairs: **Speed pair:** - Deployment Frequency (how often) - Lead Time (how fast) **Stability pair:** - Change Failure Rate (how safe) - MTTR (how resilient) Elite teams score high on **both** speed and stability. This is the key insight from the DORA research, first articulated in *Accelerate* by Forsgren, Humble, and Kim (2018): **speed and stability are not trade-offs**. The best teams are both fast and safe. This finding has been replicated consistently across every subsequent State of DevOps Report. > According to Forbes Kazakhstan, companies that adopted DORA-aligned engineering metrics saw "a 30% productivity increase, while release quality improved by 25%." — [Forbes Kazakhstan, April 2026](https://forbes.kz) If you optimize only for speed (high deploy frequency, low lead time) but ignore stability — you'll ship bugs constantly. If you optimize only for stability (low failure rate) but ignore speed — you'll deploy once a quarter and still have outages. ![Team dashboard with DORA metrics overview](https://pandev-metrics.com/img/blog/dashboard-clean.png) *PanDev Metrics team dashboard — Activity, Online status, Event timeline, and team overview in one place.* ## Implementing DORA Metrics: A 2-Week Plan ### Week 1: Connect Your Data Sources | Day | Action | |-----|--------| | 1 | Connect your Git provider (GitLab, GitHub, Bitbucket, or Azure DevOps) via webhooks | | 2 | Define your production branch(es) and deployment detection rules | | 3 | Connect your task tracker (Jira, ClickUp) to link issues to deployments | | 4-5 | Let data accumulate — you need at least a few deployments to see meaningful metrics | ### Week 2: Establish Baselines and Identify Bottlenecks | Day | Action | |-----|--------| | 6 | Review your first DORA dashboard — identify which performance level you're at | | 7 | Drill into Lead Time stages — find where time is being lost | | 8 | Set initial targets (e.g., "reduce Pickup time from 18h to 8h") | | 9-10 | Share dashboard with the team — make metrics visible, not hidden | ## Five Mistakes That Make DORA Metrics Useless ### 1. Using DORA for individual performance reviews DORA metrics measure **team and system performance**, not individual developer performance. The moment you use them in reviews, developers will game the metrics — splitting PRs artificially to boost frequency, or avoiding risky deploys to keep failure rate low. ### 2. Measuring without acting A dashboard nobody looks at is worthless. Assign an owner for each metric. Review trends weekly. Set specific improvement targets. ### 3. Ignoring context A team working on a legacy monolith will have different DORA numbers than a greenfield microservices team. Compare teams to their **own history**, not to each other. ### 4. Treating Lead Time as one number "Our Lead Time is 5 days" tells you nothing actionable. You need to know **which stage** takes 5 days. Is it coding? Review? Deployment? Each has a completely different fix. ### 5. Optimizing one metric at the expense of others Deploying 10 times a day means nothing if your Change Failure Rate is 40%. All four metrics must improve together. ## DORA in 2026: What's Changed The original DORA framework was defined in 2014. Here's what's evolved: - **AI impact measurement** — Teams now track how AI code assistants (Copilot, Cursor, Claude) affect Lead Time and Change Failure Rate. Early data suggests AI-assisted PRs have similar failure rates but shorter coding stages. - **SPACE and DevEx frameworks** — DORA is increasingly used alongside the SPACE framework (Forsgren, Storey, Maddila et al., 2021) and Developer Experience metrics for a fuller picture. As the SPACE authors argue, no single metric captures developer productivity — DORA measures the pipeline, SPACE measures the people. - **Platform Engineering** — Internal Developer Platforms (IDPs) are measured partly by their impact on DORA metrics. ## Who Should Own DORA Metrics? | Role | Responsibility | |------|---------------| | **CTO / VP Engineering** | Set organizational targets, ensure metrics are visible | | **Engineering Manager** | Review weekly with team, identify improvement areas | | **DevOps / SRE** | Own Deploy stage optimization, MTTR response | | **Tech Lead** | Own Review stage, PR standards, code review culture | --- *DORA benchmarks cited from the Accelerate State of DevOps Report (Google Cloud, 2023). SPACE framework: Forsgren et al., "The SPACE of Developer Productivity" (ACM Queue, 2021). McKinsey developer productivity report (2023). Implementation recommendations based on PanDev Metrics platform capabilities and data from B2B engineering organizations.* **Ready to measure your DORA metrics?** [PanDev Metrics](https://pandev-metrics.com) tracks all four DORA metrics with a **4-stage Lead Time breakdown** — connect your GitLab or GitHub in 15 minutes. --- ## 10 Engineering Metrics Every Manager Must Track in 2026 (DORA + SPACE + DevEx) URL: https://pandev-metrics.com/docs/blog/10-metrics-every-engineering-manager-should-track Date: 2026-04-10 Tags: engineering-management, metrics, developer-productivity, leadership Description: Updated April 2026: 10 essential engineering metrics every engineering manager tracks — DORA, SPACE, DevEx with real benchmarks and developer productivity trends. McKinsey's 2023 developer productivity report found that engineers spend only 25-30% of their time writing code. The rest vanishes into meetings, context switching, and waiting. If you're an Engineering Manager relying on gut feeling, you're blind to where 70% of your team's capacity actually goes. Here are 10 metrics that will sharpen your decisions. No fluff, no "track everything" advice — just the ones that separate informed management from guesswork. ## 1. Activity Time (Actual Coding Hours) **What it is:** Real time spent actively coding in the IDE, measured through editor heartbeats — not self-reported, not calendar-based. **Why it matters:** Most managers have no idea how much their team actually codes. Our platform data across B2B engineering teams shows the **median is 78 minutes per day**. This aligns with McKinsey's finding that developers spend less than a third of their time on coding — the rest goes to meetings, communication, and process overhead. **How to use it:** - Don't use it to rank developers (a dev coding 30 min/day might be doing architecture work) - Use it to detect **anomalies** — if a usually active developer drops to 10 min/day for a week, something's wrong - Track the **team average** over time, not individual numbers **Benchmark:** 1-2 hours/day of pure coding is normal for a developer who also does reviews, meetings, and planning. ![Activity Time and Focus Time metrics cards](https://pandev-metrics.com/img/blog/employee-metrics-safe.png) *PanDev Metrics employee view — Activity Time (198h) and Focus Time (63%) at a glance.* ## 2. Focus Time **What it is:** Uninterrupted blocks of coding time — continuous work sessions without context switches between projects or long gaps. **Why it matters:** Cal Newport's *Deep Work* research argues that most professionals can sustain at most 4 hours of deeply focused creative work per day. For developers, even that ceiling is hard to reach. Gloria Mark's research at UC Irvine found it takes an average of **23 minutes** to refocus after a single interruption. A developer with two 90-minute focus blocks is **far more productive** than one with six 30-minute fragments spread across meetings. **How to use it:** - Audit your team's meeting schedule — are you breaking their focus blocks? - Aim for at least **one 2-hour uninterrupted block** per developer per day - Compare Focus Time across days — if Wednesdays show zero focus blocks, check the meeting calendar **Benchmark:** If your developers have less than 1 hour of uninterrupted focus per day, your meeting culture is the problem. ## 3. Lead Time for Changes (with Stage Breakdown) **What it is:** Time from first commit to production deployment, broken into stages: **Coding → Pickup → Review → Deploy**. **Why it matters:** This is the single most actionable DORA metric. But only if you break it into stages. **How to use it:** - **Coding stage too long?** Tasks are too big. Break them into smaller PRs. - **Pickup stage too long?** PRs sit unreviewed. Establish a "review within 4 hours" team norm. - **Review stage too long?** Too many review rounds. Create a PR checklist to reduce back-and-forth. - **Deploy stage too long?** CI/CD pipeline needs optimization. Talk to DevOps. **Benchmark (Elite teams):** Total Lead Time under 1 day. Pickup time under 4 hours. ## 4. Deployment Frequency **What it is:** How often your team ships code to production. **Why it matters:** Frequent deploys = smaller changesets = lower risk = faster feedback. Teams that deploy daily find bugs in hours. Teams that deploy monthly find bugs in... the next month. **How to use it:** - Track the trend, not the absolute number - If frequency is dropping, ask why — is it a complex feature, or is the process slowing down? - Set a team goal (e.g., "at least 3 deploys per week") **Benchmark:** High-performing teams deploy between daily and weekly. ## 5. Change Failure Rate **What it is:** Percentage of deployments that cause production incidents (requiring hotfix, rollback, or patch). **Why it matters:** It keeps deployment frequency honest. Deploying 10 times a day means nothing if 4 of those deployments break something. **How to use it:** - Track it alongside Deployment Frequency — they must improve together - If failure rate spikes, review what changed — new team members? Reduced testing? Rushed deadline? - A **0% failure rate is suspicious**, not impressive. It usually means insufficient monitoring. **Benchmark:** 5-10% is healthy. Below 5% is elite. Above 15% is a red flag. ## 6. Planning Accuracy **What it is:** How close your team's estimates are to actual delivery time. The ratio of planned effort to actual effort. **Why it matters:** Inaccurate planning creates a cascade: missed deadlines → scope cuts → unhappy stakeholders → pressure → more missed deadlines. Breaking this cycle starts with measuring it. **How to use it:** - Review at every retrospective - Track which **types of tasks** are consistently underestimated (usually: integrations, migrations, "small" refactors) - Use historical data to calibrate future estimates — "tasks like this typically take 1.5x our estimate" **Benchmark:** A Planning Accuracy of 70-80% is good. Below 50% means your estimation process is broken. ## 7. Delivery Index **What it is:** A velocity metric that measures development speed without relying on lines of code — factoring in complexity, commits, and delivery throughput. **Why it matters:** Lines of code is a terrible metric (deleting code can be more valuable than writing it). Delivery Index gives you a velocity signal that actually correlates with output. **How to use it:** - Track weekly trends per team - Compare a team to its **own historical baseline**, not to other teams - A declining Delivery Index with stable Activity Time suggests increasing complexity or tech debt ## 8. MTTR (Mean Time to Restore) **What it is:** Average time from a production incident to full recovery. **Why it matters:** You can't prevent all incidents. But you can **recover fast**. An MTTR of 30 minutes means an incident is a hiccup. An MTTR of 3 days means it's a crisis. **How to use it:** - Run incident post-mortems and track MTTR for each - Invest in **detection** (fast alerting) and **recovery** (feature flags, rollback automation) - Set a team MTTR target and review monthly **Benchmark:** Elite teams recover in under 1 hour. If your MTTR is over 1 day, prioritize observability and rollback mechanisms. ## 9. Cost per Project **What it is:** The actual engineering cost of each project, calculated from developer time (tracked via IDE) multiplied by hourly rates. **Why it matters:** When the CEO asks "how much did Feature X cost us?" most engineering leaders can't answer. This metric lets you respond with real numbers. **How to use it:** - Report to leadership with confidence — "Project Alpha cost $45,000 in engineering time over 6 weeks" - Compare cost across projects to identify where engineering investment goes - Use it for budgeting — historical cost data makes future estimates more accurate **Why most companies don't track it:** Because it requires combining time tracking with financial data. PanDev Metrics does this automatically through IDE heartbeats + configurable hourly rates. ## 10. Team Productivity Trend (30-day) **What it is:** A rolling 30-day view of your team's combined productivity score — accounting for activity, focus time, delivery index, and other factors. **Why it matters:** Point-in-time metrics are noisy. Trends tell the story. A team trending down over 4 weeks needs attention. A team trending up is doing something right — find out what. **How to use it:** - Review in your weekly team sync - Correlate dips with events (holidays, re-orgs, on-call rotations, crunch periods) - Use it to **detect burnout early** — a gradual decline over weeks often signals overwork before the developer tells you ![Departments overview with team structure and employee counts](https://pandev-metrics.com/img/blog/dashboard-departments.png) *PanDev Metrics departments view — see how teams are structured, who manages each department, and where headcount is distributed.* ## The Anti-Metrics: What NOT to Track | Metric | Why it's harmful | |--------|-----------------| | **Lines of code** | Incentivizes bloated code. Deleting code is often more valuable. | | **Commits per day** | Incentivizes meaningless micro-commits. | | **Hours in office/online** | Measures presence, not productivity. | | **Individual rankings** | Creates competition instead of collaboration. | | **Story points velocity** | Easily gamed, varies wildly between teams, meaningless for comparison. The SPACE framework (Forsgren et al., 2021) explicitly warns against using single activity metrics to evaluate individuals. | > "As a CTO and for our tech leads, it's important to see not individual employees but the state of the development process: where it's efficient and where it breaks down. The product allows natively collecting metrics right from the IDE, without feeling controlled or surveilled." > — Maksim Popov, CTO ABR Tech ([Forbes Kazakhstan, April 2026](https://forbes.kz)) ## Building Your Dashboard Start with these three. Add more only when you've acted on these: **Tier 1 (start here):** 1. Activity Time (team average) 2. Lead Time with stage breakdown 3. Deployment Frequency **Tier 2 (add after 1 month):** 4. Focus Time 5. Change Failure Rate 6. Planning Accuracy **Tier 3 (add after 3 months):** 7. Cost per Project 8. Delivery Index 9. MTTR 10. Team Productivity Trend --- *Benchmarks based on DORA State of DevOps Reports (Google Cloud, 2019-2023), SPACE framework (Forsgren et al., ACM Queue, 2021), McKinsey developer productivity report (2023), and PanDev Metrics platform data across B2B engineering organizations.* **Track all 10 metrics from a single platform.** [PanDev Metrics](https://pandev-metrics.com) connects to your IDE, Git provider, and task tracker — giving you a complete picture in one dashboard. Free to start. --- ## How to Measure Lead Time for Changes: The 4-Stage Breakdown That Reveals Your Real Bottlenecks URL: https://pandev-metrics.com/docs/blog/lead-time-4-stages-breakdown Date: 2026-04-08 Tags: dora-metrics, lead-time, engineering-leadership, bottlenecks Description: Break Lead Time into 4 stages — Coding, Pickup, Review, Deploy — to find where your delivery pipeline actually stalls. With benchmarks and fixes. Stripe's 2018 "Developer Coefficient" study estimated that $300 billion is lost globally each year to developer inefficiency. A large share of that waste hides inside a single metric: Lead Time. A Lead Time of 5 days tells you nothing. Is it 4 days of coding and 1 day of review? Or 1 day of coding and 4 days waiting for someone to open your merge request? The fix for each scenario is completely different — and if you're treating Lead Time as a single number, you're solving the wrong problem. ## Why a Single Lead Time Number Is Useless The DORA research program defines Lead Time for Changes as the time from first commit to code running in production. The 2023 State of DevOps Report sets the benchmarks: | Performance Level | Lead Time | |-------------------|-----------| | Elite | Less than 1 hour | | High | Between 1 day and 1 week | | Medium | Between 1 week and 1 month | | Low | More than 1 month | These benchmarks are useful for positioning your team on the industry curve. They are useless for figuring out what to fix. If your Lead Time is 12 days, the aggregate number doesn't tell you whether to invest in CI/CD automation, code review processes, or developer tooling. You need decomposition. ## The 4 Stages of Lead Time At PanDev Metrics, we break Lead Time into four sequential stages. Each stage represents a distinct phase with distinct owners, distinct causes of delay, and distinct interventions. ### Stage 1: Coding Time **Definition:** From the first commit on a branch to the moment a merge request (or pull request) is created. **What it captures:** The time a developer spends writing, testing locally, and preparing the change for review. This includes IDE time, local debugging, and writing test coverage. **Healthy range:** 1–3 days for a typical feature. Anything over 5 days often signals scope creep, unclear requirements, or a developer stuck without help. **Common antipatterns:** - Developers batch multiple unrelated changes into one MR because the review process is painful - No work-in-progress limits, so developers context-switch between 3–4 features - Requirements are ambiguous, leading to rework before the MR is even opened **What to fix:** - Break work into smaller tickets (aim for MRs under 400 lines of diff) - Track IDE activity with heartbeat data to distinguish "actively coding" from "branch sits idle" - Pair unclear tickets with a short design review before coding starts ### Stage 2: Pickup Time **Definition:** From when the merge request is created to the first meaningful review action (comment, approval, or request for changes). **What it captures:** How long code sits waiting for someone to start reviewing it. This is pure queue time — no value is being added. **Healthy range:** Under 4 hours during business hours. Over 24 hours is a red flag. **Why this stage matters most:** Our platform data across B2B engineering teams consistently shows Pickup Time as the #1 hidden bottleneck — a pattern that mirrors findings in the GitHub Octoverse reports, where pull request wait times are a leading indicator of delivery friction. Teams often assume their problem is slow reviews. In reality, the review itself takes 30 minutes — but the MR sat in a queue for 2 days before anyone opened it. **Common antipatterns:** - No clear reviewer assignment — MRs sit in a shared queue that everyone ignores - Reviewers are overloaded (each reviewer has 8+ open MRs assigned) - Teams work across time zones without accounting for review handoff delays - MR notifications drown in Slack noise **What to fix:** - Assign reviewers explicitly at MR creation (use CODEOWNERS or round-robin) - Set a team SLA: "Every MR gets a first review within 4 business hours" - Create a dedicated review channel or dashboard — not a Slack thread - Monitor Pickup Time as a team metric, not an individual metric ### Stage 3: Review Time **Definition:** From the first review action to the merge request being approved and ready to merge. **What it captures:** The back-and-forth of code review — comments, discussions, requested changes, and follow-up commits. **Healthy range:** 4–24 hours for most changes. Multi-day reviews usually signal either large MRs or architectural disagreements that should have been resolved earlier. **Common antipatterns:** - Large MRs (1000+ lines) that take multiple rounds of review - "Approval gatekeeping" — only one senior engineer can approve, and they're in meetings all day - Nit-picking style issues that could be caught by automated linters - Review ping-pong: reviewer requests changes → developer pushes fix 2 days later → reviewer re-reviews 1 day later **What to fix:** - Enforce MR size limits (most teams see optimal throughput at 200–400 lines) - Automate style and formatting checks (linters, formatters in CI) - Expand the pool of approved reviewers — invest in enabling mid-level engineers to review - Set expectations for re-review turnaround (same day) ### Stage 4: Deploy Time **Definition:** From merge request approval to code running in production. **What it captures:** The CI/CD pipeline execution, staging validation, manual approval gates, and the actual deployment process. **Healthy range:** Under 1 hour for Elite teams. Under 1 day for High performers. **Common antipatterns:** - Manual deployment windows ("we deploy on Tuesdays") - Slow CI pipelines (45+ minutes) that block the merge queue - Manual QA gates that require sign-off from a specific person - Deploy freezes that stack up changes and increase batch risk **What to fix:** - Invest in CI speed: parallelize tests, cache dependencies, use faster runners - Move to continuous deployment with feature flags instead of release trains - Replace manual QA gates with automated smoke tests and canary deployments - Track deploy queue length — if 10 MRs are waiting to deploy, that's a problem ## Benchmark Data: Where Teams Actually Lose Time Based on the DORA State of DevOps reports and industry research (consistent with patterns described in Forsgren, Humble, and Kim's *Accelerate*, 2018), here's where time typically goes for a team with a 10-day Lead Time: | Stage | Typical % of Lead Time | Typical Duration | Biggest Lever | |-------|----------------------|------------------|---------------| | Coding | 30–40% | 3–4 days | Smaller tickets, clearer specs | | Pickup | 25–35% | 2.5–3.5 days | Reviewer assignment, SLAs | | Review | 15–25% | 1.5–2.5 days | Smaller MRs, automation | | Deploy | 10–15% | 1–1.5 days | CI/CD speed, remove gates | The takeaway: **Pickup and Review together consume 40–60% of Lead Time** in most organizations. These are process problems, not technical problems. They don't require new infrastructure — they require new habits. ## How to Measure Each Stage ### Option 1: Manual Tracking (Not Recommended Long-Term) You can calculate stages from git and your code hosting platform: - **Coding Time:** First commit timestamp → MR creation timestamp - **Pickup Time:** MR creation timestamp → first review comment/approval timestamp - **Review Time:** First review action → final approval timestamp - **Deploy Time:** Final approval → deployment timestamp (from CI/CD logs) This works for a one-time audit. It breaks down at scale because timestamps live in different systems, edge cases are messy (draft MRs, force-pushes, re-reviews), and nobody wants to maintain a spreadsheet. ### Option 2: Automated Platform Tools like PanDev Metrics connect to your Git provider (GitLab, GitHub, Bitbucket, Azure DevOps) and calculate all four stages automatically. The advantage isn't just automation — it's consistency. Every team uses the same definitions, the same edge-case handling, and the same benchmarks. PanDev also correlates Lead Time stages with IDE heartbeat data. This means you can distinguish "Coding Time where a developer is actively writing code" from "Coding Time where a branch sits idle for 3 days because the developer is pulled into incident response." ![Team dashboard with delivery metrics](https://pandev-metrics.com/img/blog/dashboard-clean.png) *PanDev Metrics team dashboard — track activity, online status, and event timeline to correlate Lead Time improvements with team behavior.* ## A Real Improvement Playbook Here's a step-by-step approach that works for most teams with a Lead Time over 7 days: **Week 1: Measure and baseline** - Set up stage-level tracking for all MRs merged in the last 90 days - Identify which stage consumes the most time - Present findings to the team without blame — frame it as "where does our process create wait time?" **Week 2: Fix Pickup Time (usually the biggest win)** - Implement explicit reviewer assignment - Set a team SLA (e.g., first review within 4 business hours) - Create visibility: a dashboard showing "MRs waiting for review" with age **Week 3–4: Fix Review Time** - Introduce MR size guidelines (under 400 lines) - Add linters and formatters to CI to eliminate style-related review comments - Expand the reviewer pool **Week 5–6: Fix Deploy Time** - Audit CI pipeline duration — target under 15 minutes - Remove or automate manual approval gates - Move toward deploying each MR independently **Expected results:** Teams following this playbook typically reduce Lead Time by 40-60% within 6 weeks, consistent with improvement rates observed in the DORA research. The biggest gains come from Pickup Time — it's common to go from 3 days to 4 hours just by assigning reviewers and tracking the SLA. ## What About Coding Time? Coding Time is the hardest stage to compress because it depends on the complexity of the work. However, two interventions consistently help: 1. **Smaller scope per ticket.** If the median MR is 800 lines, the Coding Time reflects a large scope. Breaking tickets into smaller deliverables (200–400 lines) shortens each cycle. 2. **IDE activity tracking.** Tools that capture developer heartbeats (keystrokes, file saves, build triggers) can distinguish between "actively coding" and "blocked." If a developer's branch shows zero activity for 2 days mid-coding, something is wrong — and it's probably not laziness. It's a blocker, a context switch, or a missing dependency. PanDev Metrics captures IDE heartbeats from 10+ IDE plugins (VS Code, JetBrains, Eclipse, Xcode, Visual Studio, and more) specifically to provide this visibility — not for surveillance, but for identifying systemic blockers. ## Common Mistakes When Measuring Lead Time **Mistake 1: Measuring from ticket creation, not first commit.** Ticket creation captures planning time, which is a product management metric, not a delivery metric. DORA Lead Time starts at first commit. **Mistake 2: Excluding weekends and holidays.** The clock doesn't stop for customers waiting for a fix. Measure calendar time. If weekends distort your numbers, that tells you something useful about your deployment process. **Mistake 3: Only measuring "happy path" MRs.** Exclude reverted MRs or hotfixes and you lose the most informative data points. Measure everything, then segment. **Mistake 4: Averaging instead of using percentiles.** A mean Lead Time of 3 days might hide a bimodal distribution: 50% of MRs merge in 1 day, 50% take 5 days. Use p50, p75, and p95 to understand the real distribution. **Mistake 5: Treating Lead Time as an individual metric.** Lead Time is a team metric. Using it to evaluate individual developers creates incentives to game the numbers (small cosmetic MRs, skipping tests, avoiding complex work). ## From Measurement to Improvement The goal of measuring Lead Time in stages is not to produce dashboards. It's to make better decisions about where to invest engineering effort in process improvement. When you can see that 35% of your Lead Time is Pickup Time, you stop debating whether to rewrite the CI pipeline and start fixing reviewer assignment. Measurement without action is overhead. Action without measurement is guessing. The 4-stage breakdown gives you the resolution to do both. --- *Benchmarks cited from the DORA State of DevOps Reports (2019–2023) published by Google Cloud / DORA team.* **Ready to see where your Lead Time actually goes?** PanDev Metrics breaks down Lead Time into Coding, Pickup, Review, and Deploy stages automatically — for GitLab, GitHub, Bitbucket, and Azure DevOps. [Start measuring what matters →](https://pandev-metrics.com) --- ## From Monthly Releases to Daily Deploys: A Practical Roadmap URL: https://pandev-metrics.com/docs/blog/deployment-frequency-monthly-to-daily Date: 2026-04-06 Tags: dora-metrics, deployment-frequency, devops, continuous-deployment Description: A step-by-step roadmap to move from monthly release cycles to daily deployments. With benchmarks, prerequisites, and real-world tradeoffs. The 2023 Accelerate State of DevOps Report found that elite teams deploy on demand, multiple times per day — and have **fewer** production incidents than teams deploying monthly. After ten years and 36,000+ survey respondents, the data is unambiguous: deploying more often does not mean breaking more things. Yet most teams are stuck in monthly release cycles, treating frequency as risk instead of risk mitigation. Here's a practical roadmap to change that. ## What Deployment Frequency Actually Measures Deployment Frequency is one of the four DORA metrics. It measures how often your organization deploys code to production. Not to staging. Not to a QA environment. Production. The 2023 State of DevOps Report benchmarks: | Performance Level | Deployment Frequency | |-------------------|---------------------| | Elite | On-demand (multiple deploys per day) | | High | Between once per day and once per week | | Medium | Between once per week and once per month | | Low | Fewer than once per month | The gap between Elite and Low performers is staggering. Elite teams deploy **973x more frequently** than low performers. This isn't a marginal difference — it's a fundamentally different way of building software. ## Why Monthly Releases Cause More Incidents, Not Fewer It sounds counterintuitive: deploy more often, have fewer problems. But the math is straightforward. **A monthly release bundles 4 weeks of changes into a single deployment.** If something breaks, the blast radius is enormous. You have to sift through hundreds of commits to find the issue. Rollback means losing everything — including the 95% of changes that were fine. **A daily deploy ships a few hours of changes.** If something breaks, the diff is small. You know exactly what changed. Rollback is surgical. The mean time to restore (MTTR) drops dramatically because diagnosis is trivial. The DORA data supports this: teams with Elite deployment frequency also have the lowest Change Failure Rate. More deploys = smaller batches = lower risk per deploy. | Batch Size | Avg Commits per Deploy | Typical Rollback Time | Debugging Difficulty | |------------|----------------------|----------------------|---------------------| | Monthly | 200–500+ | Hours to days | Very high | | Weekly | 50–150 | 30 min to hours | Moderate | | Daily | 5–30 | Minutes to 30 min | Low | | On-demand | 1–5 | Minutes | Trivial | ## The Prerequisites (Don't Skip These) Before you increase deployment frequency, you need certain foundations in place. Skipping them turns "deploy more often" into "break production more often." ### 1. Automated Testing You Trust You don't need 100% code coverage. You need a test suite that, when it passes, gives you confidence to deploy. Specifically: - **Unit tests** covering core business logic - **Integration tests** for critical user flows (login, checkout, data processing) - **Smoke tests** that run post-deploy and verify the application starts correctly If your team routinely ignores test failures ("oh, that test is flaky"), fix or delete those tests first. A test suite nobody trusts is worse than no tests — it creates a false sense of security and slows down the pipeline. ### 2. CI/CD Pipeline Under 15 Minutes If your pipeline takes 45 minutes, deploying daily means developers wait 45 minutes for feedback on every change. That's not sustainable. Target: | Pipeline Stage | Target Duration | |---------------|----------------| | Build | Under 2 minutes | | Unit tests | Under 5 minutes | | Integration tests | Under 8 minutes | | Deploy to staging | Under 2 minutes | | Smoke tests | Under 2 minutes | | **Total** | **Under 15 minutes** | Common speedups: parallelize test suites, cache dependencies (Docker layers, npm/Maven caches), use faster CI runners, split slow tests into a separate non-blocking pipeline. ### 3. Feature Flags When you deploy daily, you need to decouple deployment from release. Feature flags let you merge and deploy code that isn't ready for users yet. This eliminates long-lived feature branches and the merge conflicts that come with them. Essential feature flag capabilities: - Toggle features per environment, per user segment, or by percentage - Kill switch: disable a feature in production within seconds, without a new deploy - Cleanup: process for removing old flags (tech debt accumulates fast) ### 4. Monitoring and Alerting You can't deploy daily if you don't know when something breaks. Minimum viable monitoring: - Application error rate tracking - Latency percentiles (p50, p95, p99) - Key business metric dashboards (conversion, sign-ups, transaction volume) - Alerting with clear ownership (who gets paged, and what's their runbook?) ### 5. Rollback Capability Under 5 Minutes If rollback requires a meeting, a ticket, and a deployment window, you can't deploy daily. Rollback must be: - Triggerable by a single engineer - Executable in under 5 minutes - Tested regularly (if you've never rolled back, your first rollback will be during an incident) ## The Roadmap: Month by Month Here's a realistic timeline for moving from monthly releases to daily deploys. This assumes a team of 8–15 engineers with an existing CI/CD pipeline. ### Month 1: Baseline and Foundations **Goal:** Understand where you are and fix the biggest blocker. - Measure your current Deployment Frequency. Count actual production deploys over the last 90 days. Not "releases" or "versions" — actual deployments. - Audit your CI pipeline speed. If it's over 15 minutes, make pipeline optimization the first project. - Inventory your test suite. Identify and fix or remove flaky tests. Calculate the "false failure rate" — how often does CI fail for reasons unrelated to the code change? - Set up deployment tracking. Every deploy should be recorded with a timestamp, the commit SHA, and who triggered it. **Target by end of Month 1:** Pipeline under 20 minutes, flaky test rate under 5%. ### Month 2: Move to Biweekly **Goal:** Cut your release cycle in half. - If you're deploying monthly, move to biweekly deployments. - Create a lightweight release checklist (not a heavyweight process — a checklist). - Start each deploy with a small batch: limit the number of features per release to 3–5. - After each deploy, run a 15-minute retrospective: What broke? What was slow? What was scary? **Target by end of Month 2:** Deploying every 2 weeks with a documented, repeatable process. ### Month 3: Move to Weekly **Goal:** Deploy every week, same day. - Pick a deploy day (Tuesday and Wednesday are popular — Monday has weekend carryover, Friday adds weekend risk). - Implement feature flags for any in-progress work that can't be completed within a week. - Automate the release checklist. Anything that requires a human should be questioned: does this step actually need a person, or can it be a CI job? - Start tracking Change Failure Rate alongside Deployment Frequency. You want to increase frequency without increasing failure rate. **Target by end of Month 3:** Weekly deploys with under 15% Change Failure Rate. ### Month 4: Move to Twice Per Week **Goal:** Prove that more frequent deploys don't increase risk. - Deploy Monday/Wednesday or Tuesday/Thursday. - Remove remaining manual approval gates. Replace "manager approval" with "automated test pass + peer review approval." - Introduce canary deployments or blue-green deployments to reduce blast radius. - Start measuring MTTR. When something does break, how fast do you recover? **Target by end of Month 4:** Deploying 2x per week with MTTR under 4 hours. ### Month 5: Move to Daily **Goal:** Deploy at least once per business day. - Move to trunk-based development or short-lived branches (merge within 1–2 days). - Implement automated deploy-on-merge: when a MR is merged to main and CI passes, it deploys automatically. - Set up a deploy dashboard visible to the whole team: what's deployed, what's in the queue, what's the current status. - Eliminate deploy freezes except for genuinely critical events (major infrastructure migration, not "it's Thursday afternoon"). **Target by end of Month 5:** Daily deploys, automated, with monitoring and rollback in place. ### Month 6: Move to On-Demand **Goal:** Any engineer can deploy any time, multiple times per day. - Self-service deploys: no coordination needed, no deploy queue, no "it's my turn." - Each merged MR deploys independently (no batching). - Progressive rollout: new code goes to 1% of traffic, then 10%, then 100%. - Invest in observability: distributed tracing, error budgets, SLO dashboards. **Target by end of Month 6:** On-demand deployment capability. Elite DORA performance. ## What Changes in Your Team Culture Increasing deployment frequency changes more than your pipeline. It changes how your team works. **Code review gets faster.** When the goal is to merge and deploy today, reviewers can't sit on MRs for 3 days. Teams that deploy daily typically have Pickup Time under 4 hours. **Scope per ticket shrinks.** You can't ship a 2-week feature in a daily deploy cadence. Work gets broken into smaller, independently deployable increments. This is a good thing — smaller scope means less risk and faster feedback. **Incidents feel less catastrophic.** When you deploy daily, a production issue is "roll back this morning's change." When you deploy monthly, it's "cancel Thanksgiving." **Product teams get happier.** Features ship in days, not months. Experiments can be run and concluded within a week. The feedback loop between "we had an idea" and "users are using it" compresses dramatically. ## Metrics to Track During the Transition Don't just track Deployment Frequency in isolation. Monitor these alongside to ensure you're improving, not just going faster recklessly: | Metric | What to Watch For | Red Flag | |--------|------------------|----------| | Deployment Frequency | Steady increase over months | Plateau or decrease | | Change Failure Rate | Should stay flat or decrease | Rising with frequency | | MTTR | Should decrease as batch size shrinks | Increasing (rollback isn't working) | | Lead Time | Should decrease as process improves | Flat despite more deploys | | CI Pipeline Duration | Must stay under 15 min | Creeping up as tests are added | | Flaky Test Rate | Must stay under 5% | Rising, causing "just re-run it" culture | ## Common Objections (And Responses) **"We're in a regulated industry — we can't deploy daily."** Regulation typically requires auditability and approval, not infrequent deploys. Automated audit trails, mandatory code review, and automated compliance checks satisfy most regulatory requirements while enabling daily deployment. Some of the most regulated industries (banking, healthcare) include organizations deploying multiple times per day. **"Our QA team needs time to test."** Shift testing left. Automated tests run in CI. QA focuses on exploratory testing and test automation, not manual regression. QA should be involved before the code is written (test planning), not after it's already in a deploy queue. **"We have too many dependencies between services."** This is a valid concern and often the hardest to solve. Start by deploying independent services daily while maintaining a weekly cadence for tightly coupled services. Over time, invest in API contracts and backward compatibility to decouple deploy schedules. **"Our customers don't want constant changes."** Deploy frequently, release carefully. Feature flags decouple deployment from user-facing changes. You can deploy 10 times a day without users noticing any change, then "release" a feature to all users with a flag flip. ## Measuring Deployment Frequency Properly What counts as a "deploy"? Be precise: - **Count:** Automated deploys to production triggered by CI/CD - **Count:** Manual production deploys (but work to eliminate these) - **Count:** Hotfixes and rollbacks (they're deployments) - **Don't count:** Deploys to staging, QA, or development environments - **Don't count:** Infrastructure changes (unless they affect application behavior) - **Don't count:** Config changes via feature flag systems (no code deployed) Track deployment frequency per team or per service, not per organization. An organization-level number (like "we deploy 50 times per day") can mask the fact that one service deploys constantly while others deploy monthly. PanDev Metrics calculates Deployment Frequency from your CI/CD pipeline data across GitLab, GitHub, Bitbucket, and Azure DevOps — automatically segmented by team, service, and time period. ![PanDev Metrics dashboard showing real-time team activity and deployment events](https://pandev-metrics.com/img/blog/dashboard-clean.png) *PanDev Metrics dashboard showing real-time team activity and deployment events.* ## The Bottom Line Moving from monthly to daily deploys is not a weekend project. It's a 4–6 month journey that requires investment in testing, pipeline speed, feature flags, and monitoring. But the payoff is real: faster feedback, lower risk, fewer incidents, and happier teams. The DORA data across ten years of research — published in *Accelerate* (Forsgren, Humble, Kim, 2018) and updated annually — is unambiguous: **deploying more frequently is strictly better**, as long as you invest in the supporting practices. There are no elite-performing teams deploying monthly. This finding is consistent with the CNCF Annual Survey, which shows organizations adopting cloud-native practices (containers, CI/CD automation) achieving significantly higher deployment cadence. Start measuring, set a realistic timeline, and move one step at a time. --- *Benchmarks from the DORA State of DevOps Reports (2019–2023), published by Google Cloud / DORA team.* **Want to track your Deployment Frequency alongside Lead Time, Change Failure Rate, and MTTR — all in one place?** PanDev Metrics connects to your CI/CD pipeline and shows your DORA performance in real time. [See where you stand →](https://pandev-metrics.com) --- ## Change Failure Rate: Why 15% Is Normal and 0% Is Suspicious URL: https://pandev-metrics.com/docs/blog/change-failure-rate-15-percent-normal Date: 2026-04-03 Tags: dora-metrics, change-failure-rate, engineering-leadership, quality Description: What your Change Failure Rate actually tells you, why 0% means you're hiding failures, and how to reduce it without slowing down. When a VP of Engineering tells me their Change Failure Rate is 0%, I don't congratulate them. I ask what they're not counting. Stripe's 2018 "Developer Coefficient" study estimated that $300 billion is lost globally to bad code and inefficient processes — and much of that loss hides behind unrealistic quality metrics. A 0% CFR almost always means the team either deploys so rarely that each release is over-tested to the point of paralysis, or — more commonly — they have a definition of "failure" so narrow that real incidents don't qualify. ## What Change Failure Rate Measures Change Failure Rate (CFR) is the percentage of deployments that cause a failure in production. "Failure" means the deployment requires a remediation action: a rollback, a hotfix, a forward-fix, or a patch. The DORA benchmarks from the 2023 State of DevOps Report: | Performance Level | Change Failure Rate | |-------------------|-------------------| | Elite | 0–15% | | High | 0–15% | | Medium | 16–30% | | Low | 46–60% | Notice something unusual: **Elite and High performers share the same range.** The researchers found that CFR doesn't meaningfully differentiate top performers. What differentiates them is how quickly they recover (MTTR) and how often they deploy (Deployment Frequency). This is a critical insight. Optimizing for zero failures is the wrong goal. ## Why 0% Change Failure Rate Is a Red Flag A 0% CFR typically signals one of these problems: ### 1. You're Not Counting Properly The most common cause. Teams exclude: - **Incidents that were "caught" before users noticed.** If your monitoring caught a spike in 500 errors and you rolled back within 5 minutes, that's still a failure. The deployment caused a production issue. - **Feature bugs discovered after deploy.** If a feature doesn't work as intended and requires a follow-up fix, the original deployment failed. - **Performance degradations.** Latency doubled after a deploy but "no one complained"? That's a failure. - **Config-related incidents.** The code was fine but the deployment broke because of a missing environment variable. Still a deployment failure. A useful definition: **any deployment that required unplanned remediation work is a failure.** If an engineer had to do something they didn't expect to do because of that deployment, count it. ### 2. You Deploy Too Rarely If you deploy once a month with a week of manual QA, your CFR might genuinely be low. But you're paying for it with: - 4+ week Lead Times - Large, risky batches when something does slip through - Slow time-to-market for features and fixes - Developer frustration from slow feedback loops A low CFR achieved through infrequent deployment is not a win. It's a tradeoff — and usually a bad one. ### 3. You're Over-Testing in Production Environments Some teams run extensive manual testing in staging environments that mirror production perfectly. By the time code reaches production, it's been validated extensively. CFR is low, but: - Staging environments are expensive to maintain - Manual testing is slow and doesn't scale - You've shifted the cost from "occasional production failure" to "permanent testing overhead" ## Why 15% Is Normal (And Healthy) The DORA research, validated across 36,000+ professionals over a decade (Forsgren, Humble, Kim, *Accelerate*, 2018; annual State of DevOps Reports), consistently shows that elite teams have a CFR of 5-15%. This is not a sign of poor quality. It's a sign of: **Speed over perfection.** Elite teams deploy multiple times per day. Not every deploy will be perfect. But every deploy is small, so when it fails, recovery is fast and blast radius is limited. **Real-world complexity.** Production is messy. No staging environment perfectly replicates production traffic patterns, data volumes, third-party API behavior, and user interaction sequences. Some failures can only be discovered in production. **Honest measurement.** Elite teams count everything. They have mature incident tracking, and they classify failures accurately. Teams with lower reported CFR often have less mature incident tracking. **Innovation velocity.** Teams that ship fast are trying new things. New features, new architectures, new integrations. Some will break. That's the cost of innovation, and it's worth paying. ## The Real Cost of Chasing 0% Organizations that optimize for zero failures typically exhibit these behaviors: | Behavior | Surface Metric | Hidden Cost | |----------|---------------|-------------| | Week-long manual QA | Low CFR | Lead Time 4–6 weeks | | Multiple approval gates | Low CFR | Pickup Time 3–5 days | | Deploy freeze "just in case" | Low CFR | Deployment Frequency 1–2x/month | | Reject risky features | Low CFR | Innovation velocity near zero | | Under-report incidents | Low CFR | Reality disconnect, trust erosion | The net result: the team is "safe" but slow. Product teams learn to work around engineering by hiring contractors, using no-code tools, or building features themselves. The engineering team becomes a bottleneck, not an enabler. ## What to Actually Optimize Instead of minimizing CFR, optimize the **cost of each failure.** This means: ### 1. Reduce Blast Radius Make each failure affect fewer users for less time. - **Canary deployments:** Route 1% of traffic to the new version first. If error rates spike, roll back automatically before 99% of users are affected. - **Feature flags:** Ship code behind a flag. Enable for internal users first, then 10%, then 100%. A "failure" affects only the flagged segment. - **Independent service deploys:** If Service A fails, Service B continues working. Microservices architecture limits blast radius. ### 2. Reduce Recovery Time (MTTR) Make each failure shorter. - **One-click rollback:** Any engineer should be able to roll back a deploy in under 5 minutes, without approval. - **Automated rollback triggers:** If error rate exceeds threshold within 10 minutes of deploy, roll back automatically. - **Clear ownership:** When an alert fires, one specific person is responsible. No "diffusion of responsibility." ### 3. Reduce Detection Time Find failures faster. - **Real-time error tracking:** Sentry, Datadog, or equivalent. Errors should be visible within seconds of occurring. - **Deployment-correlated alerts:** "Error rate increased 300% starting 2 minutes after deploy of commit abc123." Instant diagnosis. - **Business metric monitoring:** Technical metrics miss some failures. Monitor conversion rate, sign-up completion, transaction success rate. ### 4. Learn from Each Failure Make each failure improve the system. - **Blameless post-mortems:** Focus on "what happened" and "what do we change," not "who messed up." - **Categorize failures:** Was it a code bug, a configuration error, a dependency issue, an infrastructure problem? Each category has different prevention strategies. - **Track repeat failures:** If the same type of failure happens three times, it's a systemic issue that requires a systemic fix. ## How to Measure Change Failure Rate Correctly ### Definition Agreement Before you start measuring, the team must agree on what counts as a failure. Recommended definition: **A deployment failure is any production deployment that results in:** - A rollback - A hotfix deployed within 24 hours - A service degradation visible in monitoring (error rate increase, latency increase, availability decrease) - A customer-facing bug that requires immediate remediation **Not a deployment failure:** - A bug discovered weeks later that was introduced by that deployment (this is a product quality issue, not a deployment issue) - A planned feature that doesn't get adopted (that's a product strategy issue) - An infrastructure issue unrelated to the deployment (cloud provider outage during deploy window) ### Calculation $$ Change Failure Rate = (Number of failed deployments / Total deployments) x 100% $$ Measure this weekly or monthly. Single-week spikes are noise; multi-week trends are signals. ### Segmentation Track CFR by: - **Team:** Identify which teams need support - **Service:** Find which systems are fragile - **Day of week:** Some teams see higher failure rates on Mondays (weekend changes) or Fridays (rushed before weekend) - **Deploy size:** Correlate CFR with lines of code changed per deploy. This almost always shows larger deploys failing more often. ## CFR Benchmarks by Industry While the DORA report provides general benchmarks, industry context matters: | Industry | Typical CFR | Notes | |----------|-------------|-------| | SaaS / Web applications | 8–15% | High deploy frequency, fast recovery | | Fintech | 5–12% | Regulated, but mature engineering practices | | E-commerce | 10–20% | Seasonal spikes cause stress-related failures | | Enterprise B2B | 15–25% | Complex integrations, slower deploy cycles | | Mobile apps | 5–10% | Can't rollback easily; more cautious deploys | | Embedded / IoT | 3–8% | Rollback is expensive; more pre-release testing | These ranges are consistent with data from Stack Overflow Developer Surveys and the DORA research. Your specific context matters more than industry averages. ## A Framework for Reducing CFR (Without Slowing Down) If your CFR is above 20%, here's a priority-ordered list of interventions: **Tier 1: High impact, low effort** - Add deployment-correlated error tracking (so you know immediately when a deploy causes issues) - Implement one-click rollback - Enforce MR size limits (under 400 lines) **Tier 2: High impact, medium effort** - Add automated smoke tests that run post-deploy - Implement canary deployments for critical services - Establish a blameless post-mortem process **Tier 3: High impact, high effort** - Increase test coverage for critical paths - Decouple services for independent deployment - Build progressive rollout infrastructure Track CFR weekly as you implement each tier. Expect CFR to drop 5–10 percentage points per tier, with most of the improvement coming from Tier 1 (faster detection and rollback means you classify and count failures properly, and you recover before small issues become big ones). ## The Relationship Between CFR and Other DORA Metrics CFR doesn't exist in isolation. Its relationship with other metrics tells a story: **High CFR + Low Deployment Frequency** = Large batches are causing failures. Fix: smaller, more frequent deploys. **High CFR + High Deployment Frequency** = Insufficient testing or review. Fix: invest in CI quality gates and code review. **Low CFR + Low Deployment Frequency** = Over-caution is masking quality problems. Fix: increase deployment frequency and see what surfaces. **Low CFR + High Deployment Frequency** = Strong engineering maturity. Maintain and iterate. PanDev Metrics tracks all four DORA metrics together so you can see these correlations in real time — not in a quarterly report when it's too late to act. ![Real-time activity dashboard where deployment events and failures are tracked](https://pandev-metrics.com/img/blog/dashboard-clean.png) *Real-time activity dashboard where deployment events and failures are tracked.* ## The Bottom Line Change Failure Rate is a health metric, not a target to minimize to zero. Healthy teams fail 5–15% of the time because they're deploying frequently, measuring honestly, and recovering quickly. If your CFR is 0%, you're probably hiding failures. If it's above 25%, you need better testing and smaller batches. The goal is not to prevent all failures. The goal is to make failures cheap, fast to detect, and fast to recover from. --- *Benchmarks from the DORA State of DevOps Reports (2019–2023), published by Google Cloud / DORA team.* **Want to track your real Change Failure Rate — correlated with deployment events, incident data, and recovery time?** PanDev Metrics calculates CFR automatically from your GitLab, GitHub, Bitbucket, or Azure DevOps pipeline data. [Measure what matters →](https://pandev-metrics.com) --- ## MTTR Targets 2026: Realistic DORA Speed of Recovery Benchmarks for Your Team URL: https://pandev-metrics.com/docs/blog/mttr-speed-of-recovery Date: 2026-03-31 Tags: dora-metrics, mttr, sre, incident-management, devops Description: Industry MTTR benchmarks for DORA's Speed of Recovery in 2026: realistic targets by team size and tech stack, plus a playbook to reduce MTTR fast. Google's Site Reliability Engineering book (2016) popularized a counterintuitive principle: accept failure as inevitable and invest in recovery speed. The DORA research confirmed it with data — the difference between elite and low-performing teams isn't that elite teams have fewer incidents. It's that they recover in under an hour instead of under a week. Every engineering organization invests in preventing failures. Fewer invest in recovering from them quickly. The data says this is backwards. ## What MTTR Actually Measures MTTR in the DORA context stands for **Mean Time to Restore Service** — the average time from when a production failure is detected to when service is fully restored for users. Key distinction: this is not Mean Time to Repair (fix the root cause). It's Mean Time to Restore (get users back to normal). You can restore service by rolling back while the root cause investigation continues. The DORA metric cares about user impact duration, not engineering investigation duration. The 2023 State of DevOps Report benchmarks: | Performance Level | MTTR | |-------------------|------| | Elite | Less than 1 hour | | High | Less than 1 day | | Medium | Between 1 day and 1 week | | Low | More than 1 week | The gap is enormous. An elite team restores service in under 60 minutes. A low performer can take over a week. For a customer-facing service, the difference between 45 minutes and 5 days of degradation is not incremental — it's existential. ## The Prevention Trap Most engineering organizations invest heavily in prevention: - More tests - More code review - More approval gates - More staging environments - Longer QA cycles These investments have diminishing returns. You can't test for every production scenario. You can't review away every bug. You can't gate-keep your way to zero incidents. Meanwhile, the same organizations treat incident response as an afterthought: - No documented runbooks - Rollback requires 3 approvals and a deployment window - Incident communication happens ad-hoc in a Slack thread - Post-mortems happen "when we have time" (never) - Nobody has practiced recovering from the most likely failure modes This is like a hospital that invests everything in preventive medicine and nothing in the emergency room. Prevention is important, but when something goes wrong — and it will — you need the ER to be world-class. ## The Math of Recovery vs. Prevention Consider two teams: **Team A: Prevention-focused** - Deploys biweekly (lots of QA) - Change Failure Rate: 5% (very low) - MTTR: 8 hours (slow recovery) - Deployments per month: ~2 - Expected incidents per month: 0.1 - Expected downtime per month: 0.1 × 8 hours = **0.8 hours** **Team B: Recovery-focused** - Deploys daily - Change Failure Rate: 12% (moderate) - MTTR: 30 minutes (fast recovery) - Deployments per month: ~22 - Expected incidents per month: 2.6 - Expected downtime per month: 2.6 × 0.5 hours = **1.3 hours** Team B has more incidents and more total downtime. But Team B also ships 11x more frequently, has a 4x shorter Lead Time, gets faster feedback, and delivers features weeks sooner. The additional 30 minutes of monthly downtime is a trivial cost for a massive delivery advantage. Now improve Team B's MTTR to 15 minutes: - Expected downtime: 2.6 × 0.25 = **0.65 hours** — less than Team A. **Fast recovery + frequent deployment beats slow deployment + infrequent failure.** This is the core DORA insight, articulated in *Accelerate* (Forsgren, Humble, Kim, 2018) and reinforced by the Google SRE framework's concept of error budgets. ## The Anatomy of MTTR MTTR consists of four phases. To improve MTTR, you need to compress each one: ### Phase 1: Detection Time **What it is:** Time from when the failure occurs to when someone knows about it. **Elite target:** Under 5 minutes. **What slows it down:** - No automated alerting — incidents are discovered by customers or by someone manually checking dashboards - Alert fatigue — so many alerts fire that teams ignore them - Monitoring gaps — the affected component doesn't have health checks - Threshold-based alerts that don't account for normal variation **How to compress it:** - Deploy anomaly detection on key metrics (error rate, latency p95, throughput) - Correlate alerts with deployment events — "error rate spiked 2 minutes after deploy X" is immediately actionable - Reduce alert noise: consolidate related alerts, set meaningful thresholds, delete alerts that never result in action - Implement synthetic monitoring (uptime checks every 30 seconds from multiple regions) ### Phase 2: Triage Time **What it is:** Time from detection to understanding the scope and severity of the incident. **Elite target:** Under 10 minutes. **What slows it down:** - Unclear ownership — "whose service is this?" - No standardized severity definitions — people argue about whether it's a P1 or P2 - Incident response requires assembling a team manually - No deployment tracking — "did anyone deploy something recently?" **How to compress it:** - Maintain a service ownership map (every service has a team, every team has an on-call) - Define severity levels with objective criteria (e.g., P1: >1% of users affected, revenue impact >$X/hour) - Automate incident channel creation with pre-populated context (recent deploys, current metrics, on-call roster) - Display recent deployments prominently in incident dashboards ### Phase 3: Remediation Time **What it is:** Time from understanding the problem to executing a fix (rollback, hotfix, config change, infrastructure scaling). **Elite target:** Under 15 minutes. **What slows it down:** - Rollback requires approval from someone who's asleep or in a meeting - No rollback automation — someone has to manually check out an old commit, build, test, and deploy - The system doesn't support rollback (database migrations are irreversible, API contracts are broken) - Hotfix process requires a full code review cycle **How to compress it:** - **One-click rollback:** Any on-call engineer can trigger a rollback without approval. Trust your people. - **Automated rollback:** If error rate exceeds X% within Y minutes of deploy, roll back automatically - **Forward-compatible changes:** Database migrations should be backward-compatible. Old code should work with new schema and vice versa. - **Hotfix fast path:** A documented, expedited process for emergency changes (abbreviated review, immediate deploy) ### Phase 4: Verification Time **What it is:** Time from executing the fix to confirming that service is restored. **Elite target:** Under 10 minutes. **What slows it down:** - No automated health checks post-rollback - Manual verification requires someone to test multiple user flows - Monitoring lag — metrics take 10+ minutes to reflect reality - Unclear definition of "restored" — does latency need to return to baseline or just below the alert threshold? **How to compress it:** - Automated post-rollback smoke tests - Real-time monitoring with sub-minute granularity - Define "service restored" criteria in advance (error rate below 0.1%, latency p95 below 200ms, key user flows succeeding) - Synthetic transactions that verify end-to-end functionality ## MTTR Benchmark Data Across Industries Based on the State of DevOps research and industry surveys (including CNCF Annual Surveys for cloud-native organizations), here are typical MTTR ranges: | Industry | Median MTTR | Elite MTTR | Primary Recovery Challenge | |----------|-------------|------------|--------------------------| | SaaS / Cloud-native | 1–4 hours | 15–30 min | Service dependency chains | | Fintech | 2–8 hours | 30–60 min | Regulatory notification requirements | | E-commerce | 30 min–4 hours | 10–30 min | Revenue pressure drives investment | | Enterprise B2B | 4–24 hours | 1–4 hours | Complex on-premise deployments | | Mobile apps | 24–72 hours | 4–24 hours | App store review for hotfixes | | Government / Public sector | Days to weeks | 4–24 hours | Change control processes | Mobile apps are a notable outlier: you can't roll back a mobile release. This makes prevention more important for mobile — and makes server-side feature flags critical for controlling behavior without app updates. ## Building an MTTR Improvement Program ### Step 1: Measure Accurately (Week 1) Most teams don't measure MTTR at all, or measure it incorrectly. Start with: 1. **Define "incident" for your team.** Recommendation: any event that causes user-visible degradation or requires unplanned remediation work. 2. **Record four timestamps for every incident:** Detection time, Triage complete, Remediation executed, Service verified restored. 3. **Calculate MTTR** as the duration from Detection to Verification. 4. **Baseline your current MTTR** using the last 90 days of incidents. If you don't have clean data, start tracking now. ### Step 2: Fix Detection (Week 2–3) Detection is often the longest phase and the easiest to fix. - Audit your monitoring: does every production service have error rate, latency, and availability metrics? - Audit your alerting: are alerts actionable? Review the last 30 alerts — how many required human action? Delete the rest. - Implement deployment-correlated alerting: when a deploy happens, tighten alert thresholds for 30 minutes. - Add synthetic monitoring for critical user journeys. **Expected improvement:** Detection time drops from 15–30 minutes to under 5 minutes. ### Step 3: Fix Remediation (Week 3–4) The highest-impact investment. - **Build one-click rollback.** If your system doesn't support rollback, this is your top priority. - **Write runbooks for the top 5 incident types.** Look at your last 20 incidents, categorize them, and write step-by-step remediation guides for the most common categories. - **Run a "game day."** Simulate a production incident during business hours. Practice the entire response: detection, triage, remediation, verification. Time each phase. Identify bottlenecks. - **Eliminate approval gates for rollback.** If rollback requires a manager's approval, remove that requirement. The on-call engineer should be empowered to act. **Expected improvement:** Remediation time drops from hours to under 15 minutes for rollback-eligible incidents. ### Step 4: Build the Feedback Loop (Ongoing) - **Blameless post-mortems** for every P1 and P2 incident, within 48 hours. - **Track MTTR trend** weekly. Display it on a team dashboard. - **Categorize incidents** by root cause type. If 40% of incidents are caused by deployment config errors, invest in config validation. - **Run game days quarterly.** Practice builds confidence and reveals decay in processes. ## MTTR vs. MTTF: The Philosophical Shift Traditional reliability engineering focuses on **Mean Time to Failure (MTTF)** — how long the system runs between failures. The goal is to maximize uptime by preventing failures. Modern reliability engineering (SRE, DORA) focuses on **MTTR** — how quickly you recover when (not if) failures occur. The goal is to minimize the impact of inevitable failures. This represents a philosophical shift: | Aspect | MTTF / Prevention | MTTR / Recovery | |--------|--------------------|-----------------| | Assumption | Failures are preventable | Failures are inevitable | | Strategy | Invest in quality gates | Invest in recovery speed | | Risk model | Avoid risk | Manage risk | | Deploy approach | Deploy rarely, test exhaustively | Deploy frequently, recover quickly | | Culture | Failure is bad | Failure is expected and manageable | | Scale behavior | Gets harder as system grows | Can improve as system grows | The MTTF approach breaks down at scale. Complex distributed systems have so many potential failure modes that preventing them all is impossible. The MTTR approach scales: invest in observability, automation, and response processes that work regardless of the specific failure. ## MTTR and the Other DORA Metrics MTTR is deeply connected to the other three DORA metrics: **Deployment Frequency → MTTR:** More frequent deploys mean smaller changesets. Smaller changesets are easier to diagnose and roll back. Teams that deploy daily have inherently lower MTTR than teams that deploy monthly. **Lead Time → MTTR:** Shorter lead times mean hotfixes ship faster. If a forward-fix takes 2 hours to go from commit to production instead of 2 weeks, your MTTR for non-rollback-eligible issues drops dramatically. **Change Failure Rate → MTTR:** A lower CFR means fewer incidents to respond to, which means less alert fatigue and more capacity for each response. However, investing heavily in CFR reduction at the expense of MTTR improvement is a common mistake. ## Tools for Measuring MTTR To measure MTTR accurately, you need: 1. **Incident tracking** with timestamps (PagerDuty, Opsgenie, or even a well-maintained spreadsheet) 2. **Deployment tracking** with timestamps (CI/CD pipeline data) 3. **Correlation** between deployments and incidents PanDev Metrics connects to your Git provider (GitLab, GitHub, Bitbucket, Azure DevOps) and correlates deployment events with incident data to calculate MTTR automatically. The AI assistant (powered by Gemini) can analyze your incident patterns and suggest specific interventions based on your team's data. ![Team dashboard showing online status and event timeline for incident response tracking](https://pandev-metrics.com/img/blog/dashboard-clean.png) *Team dashboard showing online status and event timeline for incident response tracking.* ## The Bottom Line MTTR is the most underrated DORA metric. Teams pour resources into prevention (testing, review, QA) while neglecting recovery (monitoring, rollback, runbooks, practice). The data is clear: elite teams don't prevent all failures. They recover from failures so fast that most users never notice. If you could improve only one DORA metric, improve MTTR. Fast recovery makes every other metric more forgiving. High Change Failure Rate? Less painful if you recover in 15 minutes. Low Deployment Frequency? Less risky to increase if you know you can roll back instantly. Invest in the emergency room, not just preventive medicine. --- *Benchmarks from the DORA State of DevOps Reports (2019–2023), published by Google Cloud / DORA team. Philosophy influenced by the Google SRE book (2016).* **Want to track MTTR alongside all four DORA metrics?** PanDev Metrics correlates your deployment and incident data to calculate recovery time automatically — and the AI assistant identifies patterns in your incidents. [Measure recovery speed →](https://pandev-metrics.com) --- ## DORA vs SPACE vs DevEx 2026: Engineering Productivity Frameworks Compared URL: https://pandev-metrics.com/docs/blog/dora-vs-space-vs-devex-2026 Date: 2026-03-30 Tags: dora-metrics, space, devex, developer-experience, engineering-leadership Description: Side-by-side comparison of DORA, SPACE (ACM Queue 2021) and DevEx frameworks for measuring developer productivity in 2026 — when each works, real benchmarks. The 2023 Stack Overflow Developer Survey reported that developer satisfaction directly predicts retention and output quality. Meanwhile, DORA metrics predict organizational performance. And yet many engineering leaders treat these as competing approaches rather than complementary lenses. In 2026, the problem isn't lack of frameworks — it's choosing the right combination. DORA, SPACE, and DevEx each claim to measure "developer productivity." None of them measures the same thing. Here's how to cut through the noise. ## The Three Frameworks at a Glance Before comparing, let's establish what each framework actually is and where it came from. ### DORA Metrics **Origin:** The DevOps Research and Assessment (DORA) team, originally independent, acquired by Google in 2018. Based on 10+ years of research across tens of thousands of organizations. **Published in:** *Accelerate: The Science of Lean Software and DevOps* (2018) by Nicole Forsgren, Jez Humble, and Gene Kim. Updated annually in the State of DevOps Report. **What it measures:** Software delivery performance — how quickly and reliably an engineering team delivers changes to production. **The four metrics:** | Metric | Measures | Direction | |--------|----------|-----------| | Deployment Frequency | How often you deploy to production | Higher is better | | Lead Time for Changes | Time from commit to production | Lower is better | | Change Failure Rate | % of deploys causing failures | Lower is better | | Mean Time to Restore (MTTR) | Recovery time from failures | Lower is better | **Strengths:** Objective, measurable from system data (no surveys needed), well-researched, industry-standard benchmarks. **Limitations:** Only measures the delivery pipeline. Doesn't capture developer experience, collaboration quality, or whether the team is building the right things. ### SPACE Framework **Origin:** Nicole Forsgren (again), Margaret-Anne Storey, Chandra Maddila, Thomas Zimmermann, Brian Houck, and Jenna Butler. Published in 2021. **Published in:** ACM Queue (March 2021), "The SPACE of Developer Productivity." **What it measures:** Developer productivity across five dimensions. SPACE is an acronym: | Dimension | What It Covers | Example Metrics | |-----------|---------------|-----------------| | **S**atisfaction and well-being | How developers feel about their work | Survey: job satisfaction, burnout risk | | **P**erformance | Outcomes of the work | Quality, reliability, customer impact | | **A**ctivity | Observable actions | Commits, PRs, deployments, code reviews | | **C**ommunication and collaboration | How people work together | Review turnaround, knowledge sharing, meeting load | | **E**fficiency and flow | Speed and interruptions | Flow state frequency, wait times, handoff delays | **Strengths:** Holistic view, combines quantitative data with surveys, explicitly warns against using metrics for individual evaluation. **Limitations:** Requires surveys (ongoing cost), many metrics are subjective, harder to benchmark across organizations, no standard implementation. ### DevEx Framework **Origin:** Abi Noda, Margaret-Anne Storey, Nicole Forsgren, and Michaela Greiler. Published in 2023. **Published in:** ACM Queue (April 2023), "DevEx: What Actually Drives Productivity." **What it measures:** The lived experience of developers across three dimensions: | Dimension | What It Covers | Example Metrics | |-----------|---------------|-----------------| | **Feedback loops** | How quickly developers get responses | CI speed, code review turnaround, deployment time | | **Cognitive load** | Mental effort required to do the work | Codebase complexity, documentation quality, number of tools | | **Flow state** | Ability to focus and make progress | Interruptions per day, meeting-free blocks, context switches | **Strengths:** Developer-centric, research-backed, focuses on actionable dimensions that engineering leaders can directly influence. **Limitations:** Primarily survey-based, newer (less longitudinal data), no established industry benchmarks. ## The Key Differences ### What They Measure These frameworks measure fundamentally different things: | Framework | Measures | Analogy | |-----------|----------|---------| | DORA | Output of the delivery system | Car speedometer and fuel efficiency | | SPACE | Multiple dimensions of productivity | Full vehicle diagnostic dashboard | | DevEx | The driver's experience | Driver comfort and ergonomics survey | **DORA** answers: "How fast and reliably does our pipeline deliver software?" **SPACE** answers: "How productive is our engineering organization across multiple dimensions?" **DevEx** answers: "How do our developers experience their daily work?" ### Data Sources | Framework | Primary Data Source | Survey Required? | Automation Level | |-----------|-------------------|-----------------|-----------------| | DORA | System data (Git, CI/CD, incident tracking) | No | Fully automatable | | SPACE | Mixed (system data + surveys) | Yes | Partially automatable | | DevEx | Primarily surveys + some system data | Yes | Mostly manual | This difference matters operationally. DORA metrics can be computed entirely from system data — no surveys, no manual input, no quarterly data collection exercises. You connect your Git provider and CI/CD system, and you have metrics immediately. SPACE and DevEx require ongoing survey programs. Surveys need to be designed, distributed, collected, and analyzed. Response rates matter. Question phrasing affects results. Survey fatigue is real. This creates operational overhead that DORA avoids. ### Research Foundation | Framework | Years of Research | Sample Size | Predictive Validity | |-----------|------------------|-------------|-------------------| | DORA | 10+ years (2014–present) | 36,000+ professionals | Proven: predicts organizational performance | | SPACE | 3+ years | Research-backed but smaller empirical base | Theoretical framework, validated dimensions | | DevEx | 2+ years | Research-backed, industry surveys | Emerging validation | DORA has the strongest empirical foundation. The research, led by Nicole Forsgren and published through Google Cloud, has demonstrated statistically significant links between DORA metrics and organizational outcomes (profitability, market share, customer satisfaction). Notably, the SPACE framework was co-authored by Forsgren as a deliberate extension of DORA's scope, not a replacement. DevEx, published in ACM Queue by Noda, Storey, Forsgren, and Greiler, is conceptually sound and research-backed but has less longitudinal validation. ## When to Use Each Framework ### Use DORA When: **You need to measure and improve your delivery pipeline.** DORA is unmatched for answering "how fast and reliably do we ship software?" **You want objective, automated metrics.** No surveys, no opinions — just data from your systems. **You need industry benchmarks.** DORA's Elite/High/Medium/Low benchmarks let you compare against the industry. **You're reporting to executives or boards.** DORA's four metrics are simple enough for non-technical stakeholders to understand. "We deploy 3x per day with a 10% failure rate and 45-minute recovery time" is a sentence a CFO can process. **You're a team of any size.** DORA scales from a 5-person startup to a 5,000-person enterprise. ### Use SPACE When: **You suspect your delivery metrics are fine but something is still wrong.** If DORA numbers look good but developers are burned out, turnover is high, and morale is low, SPACE captures what DORA misses. **You're managing a large engineering organization.** SPACE's breadth is useful at the VP/CTO level when you need to understand productivity across dozens of teams with different contexts. **You want to measure collaboration quality.** DORA doesn't directly measure how well people work together. SPACE's Communication dimension fills this gap. **You have the operational capacity for ongoing surveys.** SPACE requires survey infrastructure and someone to manage the program. ### Use DevEx When: **Developer retention is a priority.** DevEx directly measures the factors that make developers want to stay or leave: cognitive load, flow state, feedback loops. **You're investing in developer tooling.** If you're spending money on internal platforms, developer portals, or toolchain improvements, DevEx surveys measure whether developers feel the impact. **You want to identify friction points.** DevEx's focus on cognitive load and flow state is excellent for finding the specific annoyances (bad documentation, slow CI, too many meetings) that make daily work painful. ## The Case for Combining Frameworks These frameworks are not competitors. They measure different things and complement each other naturally. A practical combination for most organizations: ### Tier 1: DORA (Always On) Automate DORA metrics collection from day one. These are your continuous, objective delivery metrics. Track them weekly, display them on team dashboards, review them in retrospectives. DORA gives you the "what" — what is our delivery performance right now? ### Tier 2: DevEx Surveys (Quarterly) Run a focused DevEx-style survey quarterly. Keep it short (15–20 questions). Focus on: - Feedback loop speed (CI, code review, deployment) - Cognitive load (complexity, documentation, tooling) - Flow state (interruptions, meetings, context switches) DevEx gives you the "why" — why is delivery performance the way it is? ### Tier 3: SPACE Dimensions (Annual Deep Dive) Once a year, conduct a comprehensive assessment that includes SPACE's broader dimensions: satisfaction, well-being, collaboration, and performance outcomes. SPACE gives you the "where" — where should you invest next year? ### How They Feed Each Other | DORA Shows | DevEx Explains | SPACE Adds Context | |------------|---------------|-------------------| | Lead Time is increasing | "CI takes 35 minutes and I have to wait for it" | Satisfaction is dropping; engineers feel blocked | | Deployment Frequency plateaued | "I spend 3 hours/day in meetings, can't finish features" | Collaboration overhead is high; too many ceremonies | | Change Failure Rate is rising | "The codebase is too complex, I can't understand the impact of changes" | Knowledge sharing is low; no documentation culture | | MTTR is high | "I don't know which team owns which service" | Communication channels are unclear; no ownership map | ## Common Mistakes ### Mistake 1: Choosing One Framework and Ignoring the Others "We use DORA, so we don't need to measure developer experience." This leads to optimizing delivery metrics while developers burn out. You can have elite DORA numbers and 30% annual turnover. That's not sustainable. ### Mistake 2: Measuring Everything at Once "We'll implement all three frameworks this quarter." This overwhelms teams with metrics, surveys, and dashboards. Start with DORA (automated, low overhead), add DevEx surveys after you've established a baseline, and explore SPACE dimensions when you're ready for a comprehensive assessment. ### Mistake 3: Using Any Framework for Individual Performance Evaluation All three frameworks explicitly warn against this. DORA metrics are team-level delivery indicators. SPACE dimensions are organizational health signals. DevEx measures are experience indicators. Using any of them to rank individual developers creates perverse incentives, gaming, and distrust. ### Mistake 4: Survey Fatigue If you run SPACE and DevEx surveys monthly, response rates will drop below 30% within two quarters. Quarterly is the right cadence for most organizations. Annual for comprehensive assessments. ### Mistake 5: Ignoring the Framework That Challenges You If DORA metrics look great, you'll be tempted to dismiss DevEx findings that say developers are unhappy. If DevEx scores are high, you'll be tempted to ignore DORA metrics showing you deploy once a month. Each framework reveals blind spots. That's the point. ## The 2026 Landscape Several trends are shaping how these frameworks are used in 2026: **AI-assisted development changes the math.** With AI coding assistants reducing Coding Time, the relative importance of Pickup Time and Review Time (DORA) increases. DevEx's "cognitive load" dimension becomes critical — AI generates code fast, but developers still need to understand and review it. **Platform engineering makes DORA metrics easier to collect.** Internal developer platforms increasingly provide DORA metrics out of the box. The barrier to adoption is lower than ever. **Remote work makes DevEx more important.** In distributed teams, friction that was invisible in an office (waiting for a reply, unclear ownership, poor documentation) becomes measurable and impactful. DevEx surveys surface these issues. **Regulatory pressure increases demand for DORA.** Industries like fintech, healthcare, and government increasingly require evidence of software delivery maturity. DORA metrics provide that evidence. (The EU's Digital Operational Resilience Act — also called DORA, confusingly — drives interest in the DevOps DORA metrics as a way to demonstrate operational maturity.) ## Practical Recommendations by Role ### For CTOs Start with DORA. It's objective, automated, and speaks the language of business outcomes. Add DevEx surveys quarterly to understand developer satisfaction and retention risk. Use SPACE dimensions for annual strategic planning. ### For VPs of Engineering Implement DORA across all teams. Use it for identifying teams that need support (not punishment). Layer DevEx surveys to understand whether DORA improvements are translating into better developer experience. ### For Engineering Managers DORA is your weekly operating metric. Use it in retrospectives. DevEx feedback from your team tells you what to fix. Don't try to implement SPACE at the team level — it's designed for organizational assessment. ### For DevOps / Platform Engineers Focus on DORA. Your job is the delivery pipeline, and DORA measures exactly that. Use DevEx data to prioritize which parts of the pipeline to improve (developers will tell you whether CI speed or deployment complexity is the bigger pain point). ## How PanDev Metrics Fits In PanDev Metrics is a DORA-first platform. We automate collection of all four DORA metrics from your Git provider (GitLab, GitHub, Bitbucket, Azure DevOps) and project tracker (Jira, ClickUp, Yandex.Tracker). Lead Time is broken into four stages (Coding, Pickup, Review, Deploy) for actionable insights. We complement DORA with IDE heartbeat tracking from 10+ plugins (VS Code, JetBrains, Eclipse, Xcode, Visual Studio, and more) — bridging into DevEx territory by measuring actual developer activity, not just pipeline events. This gives you data on cognitive load proxies (context switches, multi-repo work) and flow state indicators (uninterrupted coding blocks) without requiring surveys. ![Activity Time and Focus Time indicators — SPACE framework dimensions measured automatically](https://pandev-metrics.com/img/blog/employee-metrics-safe.png) *Activity Time and Focus Time indicators — SPACE framework dimensions measured automatically.* The built-in AI assistant (powered by Gemini) analyzes your metrics, identifies patterns, and suggests interventions — combining the objectivity of DORA data with the contextual intelligence that SPACE and DevEx frameworks emphasize. --- *Framework sources: DORA State of DevOps Reports (2014–2023); "The SPACE of Developer Productivity" (ACM Queue, 2021); "DevEx: What Actually Drives Productivity" (ACM Queue, 2023).* **Start with what you can automate.** PanDev Metrics gives you DORA metrics from day one — no surveys, no manual data collection, no spreadsheets. [Get started →](https://pandev-metrics.com) --- ## How to Implement DORA Metrics in Your Team in 2 Weeks URL: https://pandev-metrics.com/docs/blog/implement-dora-metrics-2-weeks Date: 2026-03-26 Tags: dora-metrics, tutorial, engineering-management, implementation Description: A day-by-day tutorial for Engineering Managers: go from zero to live DORA dashboards in 2 weeks. Covers tooling, definitions, baselines, and team buy-in. Most DORA adoption efforts fail not because of tooling or data — but because they become 6-month projects that die in committee. The Accelerate research (Forsgren, Humble, Kim, 2018) showed that organizations with visible delivery metrics improve faster. The key word is *visible*: a dashboard nobody looks at is worse than no dashboard, because it creates the illusion of measurement. Here's a day-by-day plan to go from zero to live DORA dashboards in two weeks — fast enough that the momentum doesn't dissipate. ## Before You Start: Prerequisites This guide assumes: - You're an Engineering Manager (or similar role) with a team of 5–30 engineers - Your team uses Git (GitLab, GitHub, Bitbucket, or Azure DevOps) - You have a CI/CD pipeline that deploys to production - You have some form of incident tracking (even if it's a Slack channel) - You have authority to introduce new tools and processes to your team If you're missing any of these, the plan still works — you'll just need to substitute or skip certain steps. ## Week 1: Setup and Baseline ### Day 1: Define Your Metrics Precisely The biggest source of DORA measurement failure is ambiguous definitions. Before connecting any tools, write down exactly how you'll measure each metric. **Deployment Frequency** Answer these questions for your team: - What counts as a "deployment"? (Recommended: any code change that reaches production, triggered by CI/CD or manually) - Do you count deploys to staging? (No — DORA measures production only) - Do you count hotfixes? (Yes) - Do you count rollbacks? (Yes — a rollback is a deployment) - Do you count infrastructure-only changes? (Recommended: only if they affect application behavior) **Lead Time for Changes** - Where does the clock start? (Recommended: first commit on the branch) - Where does the clock stop? (Recommended: code running in production) - Do you count calendar time or business hours? (Recommended: calendar time — the DORA research uses calendar time) - How do you handle MRs that sit as drafts for a week before being marked "ready"? (Recommended: clock starts at first commit, not when MR is marked ready) **Change Failure Rate** - What counts as a "failure"? (Recommended: any deployment that requires a rollback, hotfix, or unplanned remediation within 24 hours) - Do you count performance degradations? (Recommended: yes, if they breach your SLO) - Do you count feature bugs found post-deploy? (Recommended: yes, if they require a hotfix within 24 hours) - How do you handle partial failures? (e.g., deploy worked but one endpoint broke) (Recommended: count it as a failure) **MTTR (Mean Time to Restore)** - When does the clock start? (Recommended: when the incident is detected — either by monitoring alert or customer report) - When does the clock stop? (Recommended: when service is verified restored — metrics back to normal, smoke tests passing) - Do you include only production incidents? (Recommended: yes) - What severity levels do you include? (Recommended: all severities for now; you can segment later) **Write these definitions in a shared document.** They don't need to be perfect. They need to be explicit. You'll refine them in Week 2. ### Day 2: Choose Your Tooling You have three options: **Option A: Build It Yourself (Not Recommended)** Query your Git API, CI/CD API, and incident tracker. Build dashboards in Grafana or Looker. This works for a proof of concept but requires ongoing maintenance, edge-case handling, and typically consumes 2–4 weeks of an engineer's time. **Option B: Use a DORA Platform** Tools like PanDev Metrics connect to your Git provider, CI/CD system, and project tracker. They calculate all four metrics (including Lead Time broken into Coding, Pickup, Review, and Deploy stages) automatically. Setup typically takes 30–60 minutes. **Option C: Spreadsheet Baseline (Temporary)** Export data from your Git provider and CI/CD system. Calculate metrics in a spreadsheet. This is appropriate for a one-time baseline assessment but is unsustainable for ongoing tracking. **Recommendation:** Use a platform (Option B) for automated, ongoing tracking. If budget approval takes time, start with Option C for the baseline and switch later. ### Day 3: Connect Your Data Sources If using a platform like PanDev Metrics: ![Git integration settings in PanDev Metrics — Step 1 of DORA implementation](https://pandev-metrics.com/img/blog/settings-git-detail.png) *Git integration settings in PanDev Metrics — Step 1 of DORA implementation.* 1. **Connect your Git provider** (GitLab, GitHub, Bitbucket, or Azure DevOps). This gives you: - Deployment Frequency (from deployment/merge events) - Lead Time (from commit and MR timestamps) - Lead Time stages (from MR lifecycle events) 2. **Connect your project tracker** (Jira, ClickUp, or Yandex.Tracker). This gives you: - Task-level context for changes - Correlation between tickets and code changes 3. **Connect your CI/CD pipeline data.** This gives you: - Deploy timestamps - Build/test durations - Deploy success/failure status 4. **Set up incident tracking integration** (if available). This gives you: - MTTR calculation - Change Failure Rate correlation If doing this manually: export the last 90 days of merged MRs, deployments, and incidents. Organize them in a spreadsheet with timestamps. ### Day 4: Calculate Your Baseline Run the numbers for the last 90 days. Fill in this table: | Metric | Your Value | DORA Level | Target | |--------|-----------|------------|--------| | Deployment Frequency | ___ per week | Elite / High / Medium / Low | | | Lead Time for Changes | ___ days (median) | Elite / High / Medium / Low | | | Change Failure Rate | ___% | Elite / High / Medium / Low | | | MTTR | ___ hours (median) | Elite / High / Medium / Low | | Use median, not mean. Means are distorted by outliers. **Benchmark reference (2023 State of DevOps Report):** | Metric | Elite | High | Medium | Low | |--------|-------|------|--------|-----| | Deploy Frequency | On-demand (multiple/day) | Daily to weekly | Weekly to monthly | Less than monthly | | Lead Time | Less than 1 hour | 1 day to 1 week | 1 week to 1 month | More than 1 month | | Change Failure Rate | 0–15% | 0–15% | 16–30% | 46–60% | | MTTR | Less than 1 hour | Less than 1 day | 1 day to 1 week | More than 1 week | Don't set targets yet. Just understand where you are. ### Day 5: Present to Your Team This is the most important day of the entire implementation. If you skip this or do it poorly, DORA metrics will be seen as surveillance, and your team will resist. **Structure of the presentation (30 minutes):** 1. **What DORA metrics are and why they exist** (5 minutes) - Research-backed by 10+ years of data from 36,000+ professionals (Forsgren et al., *Accelerate*, 2018) - Measures the delivery system, not individual developers — the SPACE framework (Forsgren, Storey, Maddila et al., 2021) explicitly warns against individual-level application - Teams that score well deliver faster AND have fewer incidents 2. **Our baseline numbers** (10 minutes) - Show each metric and where the team falls on the DORA scale - Be honest about what's good and what's not - Frame gaps as process problems, not people problems 3. **What we're NOT doing** (5 minutes) - Not using metrics for individual performance evaluation - Not setting arbitrary targets - Not punishing anyone for current numbers - Not adding more process or bureaucracy 4. **What we ARE doing** (5 minutes) - Making delivery performance visible - Identifying one improvement area to work on - Tracking progress over time 5. **Questions and concerns** (5 minutes) - Expect pushback. Listen to it. Address it honestly. **Common concerns and how to address them:** | Concern | Response | |---------|----------| | "You're going to judge me by commit count" | "DORA metrics are team-level. We're measuring the pipeline, not people." | | "This is just micromanagement" | "The goal is to find process bottlenecks. If Lead Time is 2 weeks, I want to know if it's slow CI or slow reviews — so I can fix the system." | | "Our numbers are bad because of X" | "Great — that's exactly the kind of insight we need. Let's document that context." | | "We don't have time for metrics" | "The metrics are automated. No one needs to do manual tracking. The 30-minute weekly review replaces guessing about our delivery performance." | ## Week 2: Refine and Act ### Day 6–7: Deep Dive Into Your Worst Metric Look at your baseline. Identify the metric where you're furthest from "High" performance. This is your focus area. **If Deployment Frequency is your weakest:** - Map your deployment process end-to-end. Where are the manual steps? - Identify what prevents you from deploying more often. Is it slow CI? Manual QA? Change approval boards? - Pick one blocker to remove in the next 2 weeks. **If Lead Time is your weakest:** - Break it into stages (Coding, Pickup, Review, Deploy). PanDev Metrics does this automatically; if doing manually, sample 20 recent MRs and calculate each stage. - Identify the longest stage. This is where improvement effort should focus. - Common finding: Pickup Time (waiting for review) is the #1 bottleneck. **If Change Failure Rate is your weakest:** - Categorize your last 10 failures by root cause: code bug, config error, dependency issue, infrastructure, other. - Identify the most common category. - Implement one prevention measure for that category (e.g., config validation in CI, dependency version pinning). **If MTTR is your weakest:** - Time the last 5 incidents: detection → triage → remediation → verification. - Identify the longest phase. - Common finding: detection takes too long because monitoring is inadequate. ### Day 8: Set Your First Target Now that you understand the baseline and the biggest bottleneck, set one target: **Rules for good targets:** - One metric only. Don't try to improve everything at once. - Specific and time-bound. "Reduce median Lead Time from 8 days to 5 days within 6 weeks." - Achievable without heroics. Aim for a 20–40% improvement, not a 90% improvement. - Team-owned. The team should agree this is worth pursuing. **Example targets:** | Current State | Target | Timeline | |--------------|--------|----------| | Deploy monthly | Deploy biweekly | 4 weeks | | Lead Time 12 days | Lead Time 7 days | 6 weeks | | CFR 25% | CFR below 18% | 8 weeks | | MTTR 6 hours | MTTR under 2 hours | 4 weeks | ### Day 9: Establish Your Review Cadence DORA metrics are useless if nobody looks at them. Set up: **Weekly metric review (15 minutes, part of existing team meeting):** - Display the DORA dashboard - Note any changes from last week - Discuss: "Is our improvement initiative making a difference?" - No blame, no individual call-outs **Monthly deep dive (30 minutes, standalone):** - Review trend over the last month - Assess progress toward target - Decide: continue current initiative or pivot? - Identify next improvement area if current target is met **Quarterly review with leadership (30 minutes):** - Present DORA performance and trends - Highlight improvements and their business impact - Request resources if needed (e.g., CI/CD investment, tooling budget) ### Day 10: Start Your First Improvement Sprint Pick one concrete action based on your Day 6–7 analysis. Examples: **For Lead Time — reducing Pickup Time:** - Implement CODEOWNERS for automatic reviewer assignment - Set team SLA: "Every MR reviewed within 4 business hours" - Create a "Needs Review" dashboard or Slack notification **For Deployment Frequency — removing manual gates:** - Automate one manual step in your deployment process - Replace one approval gate with an automated check - Set a "deploy day" if you don't have a regular cadence **For Change Failure Rate — improving test coverage:** - Add smoke tests for the top 3 user-facing flows - Fix or delete flaky tests (identify the top 5 flakiest) - Add deployment-correlated error tracking **For MTTR — improving detection:** - Set up alerting for error rate and latency on your primary service - Create a basic runbook for the most common incident type - Practice a rollback (actually do it, in production, with a no-op change) ## After Week 2: The Ongoing Rhythm Congratulations — you now have DORA metrics tracking. The hard part isn't setup; it's sustaining the practice. Here's how to keep it alive: ### Monthly Checkpoints | Month | Activity | |-------|----------| | Month 1 | Baseline established, first improvement sprint running | | Month 2 | Evaluate first sprint results, start second improvement | | Month 3 | Review trends, adjust targets, present to leadership | | Month 4–6 | Continue improvement sprints, refine definitions | | Month 6 | Full retrospective: where were we, where are we, what worked | ### Signs It's Working - Team discusses DORA metrics organically (not just in formal reviews) - Developers suggest improvements to the delivery process - Lead Time or Deployment Frequency is measurably better - New team members onboard faster because the process is visible ### Signs It's Not Working - Nobody looks at the dashboard - Metrics are discussed only to assign blame - Numbers improve but team sentiment worsens (gaming) - Targets are set but no action is taken to achieve them If it's not working, the most common cause is #2 — the metrics are being used punitively. Go back to Day 5 and reinforce the purpose. ## Common Pitfalls and How to Avoid Them ### Pitfall 1: Measuring Individuals **Symptom:** "Let's see who has the longest Lead Time." **Fix:** Aggregate all metrics at the team level. Never display individual developer metrics in team dashboards. If you need individual-level data for coaching, use it 1:1, privately, with context. ### Pitfall 2: Optimizing One Metric at the Expense of Others **Symptom:** Deployment Frequency goes up, but Change Failure Rate doubles. **Fix:** Always display all four DORA metrics together. Improvement in one metric should not degrade another. If it does, you're going too fast. ### Pitfall 3: Perfect Definitions Before Starting **Symptom:** "We can't start tracking until we agree on whether a canary rollback counts as a failure." **Fix:** Start with "good enough" definitions. Note the edge cases. Refine definitions monthly. Consistency matters more than perfection — if you count the same way every week, the trend is valid even if the absolute number is debatable. ### Pitfall 4: Dashboard Without Action **Symptom:** Beautiful Grafana dashboard. No improvement in 6 months. **Fix:** Every weekly review must end with: "What one thing are we doing this week to improve?" If the answer is "nothing," cancel the meeting and try again when there's energy for improvement. ### Pitfall 5: Comparing Teams Without Context **Symptom:** "Team Alpha deploys 3x per day. Why can't Team Beta?" **Fix:** Team Alpha builds a web frontend. Team Beta builds a banking core system with regulatory approval requirements. Context matters. Compare teams to their own historical baseline, not to each other. ## The Tooling Decision A quick comparison of approaches: | Approach | Setup Time | Ongoing Effort | Coverage | Cost | |----------|-----------|---------------|----------|------| | Spreadsheet | 2–4 hours | 2–3 hours/week | Basic 4 metrics | Free | | Custom scripts + Grafana | 2–4 weeks | 4–8 hours/week | 4 metrics + custom | Engineer time | | DORA platform (e.g., PanDev Metrics) | 30–60 minutes | 15 min/week (review) | 4 metrics + stages + IDE data | Subscription | For this 2-week tutorial, any approach works. For ongoing tracking, a platform pays for itself quickly — the 2–3 hours/week spent on spreadsheet maintenance is better spent on actually improving the metrics. PanDev Metrics specifically offers: - Automated DORA metrics from GitLab, GitHub, Bitbucket, Azure DevOps - Lead Time broken into 4 stages (Coding, Pickup, Review, Deploy) - IDE heartbeat tracking from 10+ plugins for Coding Time visibility - Integration with Jira, ClickUp, and Yandex.Tracker - AI assistant (powered by Gemini) that analyzes your data and suggests improvements - On-premise deployment option with LDAP/SSO for enterprise security requirements ## Day-by-Day Checklist Here's your complete checklist: | Day | Task | Output | |-----|------|--------| | 1 | Define metrics precisely | Shared document with metric definitions | | 2 | Choose tooling | Tool selected, access requested | | 3 | Connect data sources | Data flowing into dashboard | | 4 | Calculate baseline | Table with 4 metrics + DORA levels | | 5 | Present to team | Team alignment, concerns addressed | | 6–7 | Deep dive into weakest metric | Root cause analysis | | 8 | Set first target | One specific, time-bound goal | | 9 | Establish review cadence | Weekly review on team calendar | | 10 | Start first improvement sprint | One concrete action in progress | After Day 10, you have: live DORA metrics, a baseline, a target, and an active improvement. That's more than most teams achieve in a quarter. > "As a CTO and for our tech leads, it's important to see not individual employees but the state of the development process: where it's efficient and where it breaks down. The product allows natively collecting metrics right from the IDE, without feeling controlled or surveilled. Implementation was very simple." > — Maksim Popov, CTO ABR Tech ([Forbes Kazakhstan, April 2026](https://forbes.kz)) --- *Benchmarks from the DORA State of DevOps Reports (2019–2023), published by Google Cloud / DORA team.* **Ready to set up DORA metrics in under an hour?** PanDev Metrics connects to your Git provider, breaks Lead Time into 4 stages, and gives you a live DORA dashboard — no spreadsheets, no custom scripts. [Start your 2-week implementation →](https://pandev-metrics.com) --- ## DORA Metrics for Fintech: Proving Process Maturity to Regulators URL: https://pandev-metrics.com/docs/blog/dora-metrics-fintech-regulators Date: 2026-03-23 Tags: dora-metrics, fintech, compliance, engineering-leadership, regulation Description: How fintech CTOs use DORA metrics to demonstrate operational maturity to regulators, auditors, and enterprise clients. Practical guide with compliance mapping. Regulation is not the enemy of speed — lack of measurement is. The 2023 State of DevOps Report shows that top-quartile financial services organizations deploy daily while maintaining stricter change control than their slower peers. When an auditor asks "how do you ensure your deployment process is controlled and reliable?" you need a better answer than "we have code review." DORA metrics give you that answer — with quantitative evidence that auditors and risk committees can actually verify. ## The Regulatory Landscape for Fintech Delivery Fintech companies operate under a growing web of regulations that directly affect how software is built and deployed. The key regulations and frameworks in 2026: ### EU Digital Operational Resilience Act (DORA Regulation) Yes, "DORA" appears twice in fintech — the DevOps Research and Assessment metrics, and the EU's Digital Operational Resilience Act (Regulation (EU) 2022/2554). This is not a coincidence in naming, but the two are distinct. The EU regulation took full effect in January 2025 and applies to: - Banks and credit institutions - Payment service providers - Electronic money institutions - Investment firms - Insurance companies - ICT third-party service providers The regulation requires financial entities to maintain and test their ICT risk management frameworks, including software delivery and change management processes. Article 9 specifically requires "ICT change management" controls, including documentation, testing, and rollback capabilities. ### PCI DSS 4.0 The Payment Card Industry Data Security Standard (version 4.0, effective March 2025) includes requirements for: - Change control processes (Requirement 6.5) - Documented change management procedures - Testing of changes before deployment - Rollback procedures ### SOC 2 Type II Not a regulation but effectively required for B2B fintech. SOC 2 audits evaluate: - Change management controls - System monitoring and incident response - Risk assessment processes ### Country-Specific Regulations - **UK:** FCA requirements for operational resilience - **US:** OCC guidance on third-party risk management, FFIEC IT Examination Handbook - **Russia/CIS:** Central Bank regulations on information security for financial organizations (242-P, 683-P), with similar frameworks emerging across CIS jurisdictions ## How DORA Metrics Map to Regulatory Requirements Here's the key insight: DORA metrics provide **quantitative evidence** for controls that auditors typically verify through **documentation review**. Instead of showing auditors a 50-page change management policy that may or may not reflect reality, you show them live data. ### Deployment Frequency → Change Management Control | Regulatory Requirement | What Auditors Want to See | How DORA Data Helps | |----------------------|--------------------------|-------------------| | Changes are controlled and documented | Evidence that changes go through a defined process | Deployment Frequency data shows every production deployment, with timestamps, commit SHAs, and who triggered it | | Changes are authorized | Approval before production deployment | MR approval data shows who reviewed and approved each change | | No unauthorized changes | All production changes are tracked | Automated deployment tracking catches every change, including hotfixes | **What to show auditors:** "In Q1 2026, we made 247 production deployments. 100% went through our CI/CD pipeline with mandatory code review. Here's the log." ### Lead Time for Changes → Process Efficiency Evidence | Regulatory Requirement | What Auditors Want to See | How DORA Data Helps | |----------------------|--------------------------|-------------------| | Efficient change process | Changes don't sit in queue for weeks | Lead Time data shows median time from commit to production | | Separation of duties | Different people write, review, and deploy code | Lead Time stages show different participants at each stage | | Review before deployment | All changes are reviewed | Pickup Time and Review Time show every change was reviewed | **What to show auditors:** "Our median Lead Time is 3.2 days. Every change spends time in code review (median: 6 hours) before deployment. Different engineers write and review the code — here's the data." ### Change Failure Rate → Quality Control Evidence | Regulatory Requirement | What Auditors Want to See | How DORA Data Helps | |----------------------|--------------------------|-------------------| | Testing before deployment | Changes are validated before production | Low CFR demonstrates effective testing | | Post-deployment monitoring | Failures are detected and tracked | CFR tracking shows incidents are identified and classified | | Continuous improvement | Process improves over time | CFR trend shows improvement quarter over quarter | **What to show auditors:** "Our Change Failure Rate in Q1 was 8.5%, down from 12% in Q4. Here's the trend chart and the root cause breakdown." ### MTTR → Incident Response Evidence | Regulatory Requirement | What Auditors Want to See | How DORA Data Helps | |----------------------|--------------------------|-------------------| | Incident response capability | Documented incident response process | MTTR data shows actual response times | | Timely recovery | Systems are restored within defined SLAs | MTTR demonstrates recovery capability with real data | | Incident tracking | All incidents are documented with timestamps | MTTR calculation requires and provides this data | | Business continuity | Organization can recover from disruption | MTTR trend shows recovery capability is maintained | **What to show auditors:** "Our median MTTR is 47 minutes. In Q1, we had 21 incidents. The longest recovery took 3.5 hours. Here's the incident log with timestamps for detection, triage, and restoration." ## Building an Audit-Ready DORA Dashboard An audit-ready DORA dashboard differs from an internal engineering dashboard in several ways: ### Data Retention Internal dashboards might show the last 30 days. Audit dashboards need: - **Minimum 12 months of historical data** (most regulations require 1–3 years) - **Immutable records** (data cannot be retroactively modified) - **Export capability** (auditors may request raw data) ### Access Control - **Role-based access:** Auditors get read-only access - **Audit trail:** Log who accessed the dashboard and when - **SSO integration:** Use your corporate identity provider (LDAP, SAML) ### Content Requirements Your audit dashboard should show: **Per quarter:** - Deployment Frequency (total count + weekly average) - Lead Time (median, p75, p95) - Change Failure Rate (percentage + raw numbers) - MTTR (median, p75, p95) - Trend vs. previous quarter **Per deployment:** - Timestamp - Commit SHA and branch - Who authored the change - Who reviewed and approved the change - CI/CD pipeline status (all stages passed) - Whether the deployment caused a failure (and if so, recovery details) **Per incident:** - Detection timestamp - Severity classification - Affected services - Root cause category - Time to restore - Post-mortem reference ## The Compliance Argument for Higher Deployment Frequency Many fintech CTOs assume regulators want infrequent, heavily-controlled releases. This is a misunderstanding. Regulators want **controlled** releases. They don't specify frequency. In fact, the DORA research demonstrates that higher deployment frequency correlates with: - Lower Change Failure Rate (smaller batches are less risky) - Lower MTTR (smaller changes are easier to roll back) - Better audit trails (automated CI/CD captures everything) - Stronger separation of duties (every change goes through review and automated gates) **The argument to make to auditors and risk committees:** "We deploy 3 times per day instead of once per month. Each deployment is small (median 150 lines of code change), automatically tested by 2,400 tests in our CI pipeline, reviewed by a different engineer, and deployed through an automated pipeline that captures a full audit trail. If any deployment causes an issue, we detect it within 3 minutes and roll back within 10 minutes. Our Change Failure Rate is 8%, and our recovery time is under 1 hour. Compare this to monthly deployments: 5,000 lines of change, manual testing, higher risk of failure, and a rollback that requires reverting a month of work." This argument works because regulators care about **risk management**, not release cadence. Frequent, small, automated deployments with comprehensive audit trails represent better risk management than infrequent, large, partially-manual deployments. ## The EU DORA Regulation: Specific Requirements The EU Digital Operational Resilience Act (the regulation, not the metrics) has specific ICT change management requirements that DORA metrics (the DevOps metrics) directly address: ### Article 9: Protection and Prevention The regulation requires financial entities to implement ICT change management policies that include: 1. **Documentation of changes:** DORA metrics platforms automatically log every deployment with full metadata. 2. **Testing of changes:** Lead Time stages show that every change goes through a CI pipeline (testing) before deployment. 3. **Risk assessment of changes:** Change Failure Rate data provides quantitative risk assessment of the deployment process. 4. **Rollback capability:** MTTR data demonstrates that the organization can and does roll back failed changes. 5. **Post-implementation review:** DORA metrics provide automatic post-deployment monitoring through deployment-correlated incident tracking. ### Article 11: Response and Recovery The regulation requires: 1. **ICT incident management process:** MTTR tracking requires and demonstrates this. 2. **Classification of incidents:** Change Failure Rate categorization includes incident classification. 3. **Timely detection and response:** MTTR data shows detection and response times. ### Article 25: Testing of ICT Tools and Systems The regulation requires regular testing of operational resilience. DORA metrics provide ongoing evidence that: - The deployment pipeline works reliably (Deployment Frequency data) - Changes are tested (Lead Time stages include CI/CD pipeline data) - Recovery procedures work (MTTR data from real incidents) ## Benchmarks: DORA Performance in Financial Services Based on the DORA State of DevOps Reports and industry surveys, fintech organizations typically perform as follows: | Metric | Fintech Median | Fintech Top Quartile | DORA "Elite" | |--------|---------------|---------------------|--------------| | Deployment Frequency | 1–2x per week | Daily | Multiple per day | | Lead Time | 3–7 days | 1–2 days | Less than 1 hour | | Change Failure Rate | 10–15% | 5–8% | 0–15% | | MTTR | 2–6 hours | 30 min–1 hour | Less than 1 hour | Top-quartile fintech organizations are at or near DORA "Elite" performance. These include major digital banks, payment processors, and trading platforms. This pattern aligns with findings in the *Accelerate* research (Forsgren, Humble, Kim, 2018): regulation is not a barrier to elite performance — it's an incentive to automate and measure rigorously. The CNCF Annual Survey similarly shows that regulated industries adopting cloud-native practices achieve deployment frequencies comparable to unregulated SaaS companies. ## Implementation Guide for Fintech ### Phase 1: Instrument (Weeks 1–2) 1. **Connect your Git provider** to a DORA metrics platform. Ensure the connection captures: - All merge requests and deployments - Author and reviewer identity - Timestamps for all lifecycle events 2. **Connect your CI/CD pipeline** data. Ensure capture of: - All pipeline stages and their status - Build artifacts and their provenance - Deployment targets (staging, production) 3. **Connect your incident tracker.** Ensure capture of: - Incident creation and resolution timestamps - Severity and impact classification - Associated deployments (if deployment-caused) 4. **Verify data retention** meets regulatory requirements (minimum 12 months, ideally 3 years). ### Phase 2: Baseline and Context (Weeks 3–4) 1. **Calculate baseline metrics** for the last 90 days. 2. **Document your deployment process** end-to-end, mapping it to DORA stages. 3. **Create a compliance mapping document** showing how each DORA metric addresses specific regulatory requirements. 4. **Review with your compliance team.** Get their input on what additional data auditors might request. ### Phase 3: Improve and Document (Months 2–3) 1. **Set targets** for each metric (aligned with DORA "High" performance level as a starting point). 2. **Run improvement sprints** focused on the weakest metric. 3. **Document all improvements** — auditors want to see continuous improvement. 4. **Create audit-ready reports** that can be generated on demand. ### Phase 4: Audit Preparation (Ongoing) 1. **Prepare a DORA metrics briefing** for auditors. Explain what each metric measures and how it relates to their requirements. 2. **Maintain a FAQ** based on previous auditor questions. 3. **Run quarterly internal audits** of your DORA data accuracy (are all deployments captured? Are incidents correctly classified?). 4. **Keep historical data** accessible and exportable. ## Enterprise Client Requirements Beyond regulators, enterprise fintech clients often require evidence of engineering maturity during vendor due diligence. DORA metrics address common RFP questions: | RFP Question | DORA Answer | |-------------|-------------| | "What is your release cadence?" | Deployment Frequency data with trend | | "How do you manage change control?" | Lead Time stages showing review, testing, and approval | | "What is your production failure rate?" | Change Failure Rate with quarterly trend | | "How quickly do you recover from incidents?" | MTTR with percentile breakdown | | "Do you have automated testing?" | CI/CD pipeline data within Lead Time metrics | | "What is your rollback procedure?" | MTTR data showing actual rollback execution times | | "How do you ensure separation of duties?" | Lead Time stages showing different participants for authoring, reviewing, and deploying | Having DORA data ready for these questions differentiates you from competitors who can only provide policy documents. Data beats documentation. ## Security and Deployment Considerations Fintech organizations often have stricter security requirements for any tool that accesses their codebase. Key considerations when choosing a DORA metrics platform: **On-premise deployment:** Some organizations cannot send code metadata to cloud services. PanDev Metrics offers on-premise deployment, keeping all data within your infrastructure. **SSO/LDAP integration:** Access control must integrate with your identity provider. PanDev Metrics supports LDAP and SSO. ![LDAP/AD integration settings with enterprise security compliance](https://pandev-metrics.com/img/blog/settings-ldap.png) *LDAP/AD integration settings with enterprise security compliance.* **Data classification:** DORA metrics platforms access commit messages, branch names, and MR titles — which may contain references to security issues or customer data. Ensure your platform encrypts data at rest and in transit, and that access is audited. **Network security:** The platform should only require outbound connections to your Git provider API. No inbound ports, no agent installation on production servers, no access to source code contents (only metadata). ## Real-World Compliance Scenarios ### Scenario 1: SOC 2 Audit **Auditor question:** "Show me evidence that all production changes go through your change management process." **Traditional answer:** Policy document + sample of 25 change records manually compiled. **DORA-powered answer:** Live dashboard showing 100% of 847 production deployments in the audit period, each with automated CI/CD pipeline records, code review approvals, and deployment timestamps. Exportable as CSV. ### Scenario 2: EU DORA Regulation Compliance Review **Regulator question:** "Demonstrate your ICT change management and incident response capabilities." **Traditional answer:** 30-page policy document + quarterly test results. **DORA-powered answer:** 12-month DORA metrics dashboard showing: - 1,247 deployments with full audit trail - Median Lead Time of 2.8 days with stage breakdown - Change Failure Rate of 7.2% (below industry median) - Median MTTR of 38 minutes with incident classification - Quarter-over-quarter improvement trend ### Scenario 3: Enterprise Client Due Diligence **Client question:** "How mature is your engineering process? We need confidence that your platform will be reliable." **Traditional answer:** Architecture diagram + SLA commitment. **DORA-powered answer:** "We deploy to production 4x per day. Our median Lead Time is 1.8 days. Our Change Failure Rate is 6%. When failures occur, we recover in under 45 minutes on average. Here's our DORA dashboard showing the last 12 months of data. We benchmark as 'Elite' on 3 of 4 metrics and 'High' on the fourth." ## The Competitive Advantage Fintech companies that track DORA metrics gain three competitive advantages: 1. **Faster audits.** Instead of weeks of document preparation, generate reports on demand. Auditors spend less time requesting evidence and more time on substantive review. 2. **Stronger sales.** Enterprise clients choose vendors with demonstrable engineering maturity. DORA data is more convincing than marketing claims. 3. **Better engineering.** The metrics don't just satisfy auditors — they actually improve your delivery process. You ship faster, break less, and recover quicker. In a market where every fintech claims "bank-grade security" and "enterprise reliability," DORA metrics provide proof. As the Basel III operational risk framework evolves to cover ICT risk more explicitly, having quantitative engineering data will shift from competitive advantage to regulatory necessity. --- *Benchmarks from the DORA State of DevOps Reports (2019–2023), published by Google Cloud / DORA team. Regulatory references: EU Regulation 2022/2554 (Digital Operational Resilience Act), PCI DSS v4.0, SOC 2 Trust Services Criteria.* **Need audit-ready DORA metrics for your fintech?** PanDev Metrics provides automated DORA tracking with on-premise deployment, LDAP/SSO, and full data export — built for regulated environments. [See how it works →](https://pandev-metrics.com) --- ## Focus Time: Why 2 Hours of Uninterrupted Code Equals 6 Hours of Fragmented Work URL: https://pandev-metrics.com/docs/blog/focus-time-deep-work Date: 2026-03-20 Tags: focus-time, developer-productivity, deep-work, engineering-management Description: Data shows uninterrupted coding sessions produce 3x more output than fragmented ones. Here's how to protect focus time for your engineering team. Gloria Mark's research at UC Irvine found that it takes an average of **23 minutes and 15 seconds** to refocus after a single interruption. Now consider a typical developer morning: 9:07 Slack pings, 9:15 standup reminder, 9:45 a "quick question" from a PM. By 10:30, they've been "working" for 90 minutes but written exactly 11 lines of code. Three interruptions consumed roughly 70 minutes of cognitive recovery time. This isn't a productivity problem. It's a **focus time** problem. And the data shows it's costing your team far more than you think. ## What Is Focus Time and Why It Matters Focus Time is uninterrupted, sustained coding activity — the periods when a developer is genuinely engaged in writing, refactoring, or debugging code without switching to Slack, email, or meetings. Cal Newport's *Deep Work* (2016) argues that most knowledge workers can sustain at most **4 hours of deeply focused creative work per day** — and that this capacity is the scarce resource that determines output quality. For software developers, this translates directly to **continuous IDE activity** — the stretches where fingers are on the keyboard, the mental model of the codebase is loaded into working memory, and progress actually happens. At PanDev Metrics, we track Focus Time as a core metric alongside Activity Time. The difference is significant: Activity Time counts any time the IDE is active. Focus Time counts only **sustained sessions** where a developer maintains continuous engagement without significant gaps. ## The Research Behind the 3x Multiplier The claim that 2 hours of focused work equals 6 hours of fragmented work isn't hyperbole — it's grounded in research and production data. ### The cognitive cost of interruptions A widely cited study by Gloria Mark at UC Irvine found that it takes an average of **23 minutes and 15 seconds** to return to a task after an interruption. But for developers, the cost is even higher. Programming requires holding complex mental models — data flows, state transitions, architectural patterns — in working memory. Each interruption forces a reload of that mental context. Chris Parnin's research on programmer interruptions (published in IEEE) found that after being interrupted, developers needed an average of **10-15 minutes** to resume editing code, and only **10% of interrupted sessions** resulted in resuming work within a minute. ### What our data shows Across B2B engineering teams tracked by PanDev Metrics, the median developer codes **78 minutes per day**, with a mean of **111 minutes**. These figures are consistent with McKinsey's 2023 finding that developers spend only 25-30% of their time writing code. But the averages hide a critical distribution pattern: | Session type | Avg. duration | Code output quality | Frequency | |-------------|:------------:|:-------------------:|:---------:| | Micro-sessions (< 15 min) | 8 min | Low — mostly navigation and small fixes | Very common | | Short sessions (15–45 min) | 28 min | Medium — feature work begins but rarely completes | Common | | Deep sessions (45–120 min) | 72 min | High — complex features, meaningful refactors | Uncommon | | Extended sessions (120+ min) | 148 min | Very high — architecture-level work | Rare | Developers in our dataset who maintain at least one 90+ minute uninterrupted session daily have significantly higher Delivery Index scores than those whose work is fragmented into sub-30-minute bursts. ## The Tuesday Effect: When Focus Time Peaks Our data across thousands of tracked hours shows that **Tuesday is the peak coding day**. This isn't random. Here's the pattern: | Day | Focus Time potential | Why | |-----|:-------------------:|-----| | Monday | Medium | Standups, sprint planning, catching up on weekend messages | | **Tuesday** | **High** | Plans are set, minimal meetings, maximum runway | | Wednesday | Medium-High | Mid-week reviews start creeping in | | Thursday | Medium | Demo prep, code reviews, planning next sprint | | Friday | Low-Medium | Wrap-up mentality, deployment freezes, early checkouts | Tuesday works because Monday absorbs the coordination overhead. By Tuesday, developers know what they're building and have the clearest calendar to build it. Engineering managers who protect Tuesday and Wednesday mornings from meetings see measurable improvements in their team's Focus Time. ![Coding activity heatmap by hour and day](https://pandev-metrics.com/img/blog/activity-heatmap.png) *Activity heatmap from PanDev Metrics — yellow blocks show active coding sessions, gaps reveal meetings and interruptions throughout the week.* ## Five Practical Strategies to Protect Focus Time ### 1. Implement meeting-free mornings Block 9 AM to 12 PM (or your team's equivalent) on at least three days per week. Our data shows that morning coding sessions tend to be longer and more productive than afternoon ones. When meetings cluster in the morning, the entire day's deep work potential collapses. **How to measure it:** Track Focus Time before and after implementing the policy. In PanDev Metrics, compare Focus Time distribution across weeks to see if session lengths increase. ### 2. Batch communication windows Instead of real-time Slack responsiveness, establish 2-3 communication windows per day. For example: 8:30–9:00 AM, 12:00–12:30 PM, and 4:30–5:00 PM. Outside these windows, developers should feel empowered to mute notifications. | Communication model | Avg. Focus session length | Interruptions per hour | |--------------------|:------------------------:|:---------------------:| | Always-on Slack | 12–18 min | 3–5 | | Batched (3x/day) | 45–70 min | 0.5–1 | | Async-first (Slack + tickets) | 60–90 min | 0.3–0.5 | ### 3. Use "office hours" for cross-team questions PMs, designers, and stakeholders often need developer input. Instead of ad-hoc interruptions, establish daily office hours — a 30-minute window where developers are available for questions. This respects both sides: stakeholders get access, developers get predictability. ### 4. Make Focus Time visible What gets measured gets managed. When Focus Time is a visible metric on a team dashboard, it changes behavior. Managers start noticing when a developer's Focus Time drops from 2 hours to 30 minutes — and they investigate why. PanDev Metrics tracks Focus Time automatically through IDE plugins. No self-reporting, no timers, no distractions. The data flows from the editor directly into dashboards that engineering managers can review during 1:1s. ### 5. Protect your top contributors differently Our data shows significant variance in coding patterns. The top 6% of developers in our dataset code more than 4 hours per day. These developers aren't 3x more talented — they typically have **fewer meetings, fewer Slack channels, and more autonomy**. If your senior engineers are drowning in meetings, you're paying senior rates for junior-level output. | Developer tier | Median daily coding time | Typical meeting load | |---------------|:------------------------:|:-------------------:| | IC (Junior) | 65 min | 1–2 meetings/day | | IC (Mid) | 82 min | 2–3 meetings/day | | IC (Senior) | 95 min | 3–5 meetings/day | | Staff+ | 45 min | 4–7 meetings/day | Notice the paradox: Staff+ engineers — your most experienced and expensive contributors — often have the **least** Focus Time because they're pulled into every architectural discussion, planning meeting, and incident review. ## How to Measure Focus Time Properly Not all "time tracking" captures Focus Time. Here's what works and what doesn't: | Method | Accuracy | Developer friction | Captures Focus Time? | |--------|:--------:|:------------------:|:-------------------:| | Self-reported timesheets | Low | High | No | | Calendar analysis | Medium | None | Partially (shows meeting load) | | Browser/app tracking | Medium | Medium | No (activity ≠ focus) | | **IDE heartbeat tracking** | **High** | **None** | **Yes** | IDE heartbeat tracking — the method used by PanDev Metrics — sends anonymous activity signals from the editor. When a developer is actively coding (keystrokes, navigation, debugging), the signal is "active." When they switch to Slack or a browser, the coding session ends. This creates an accurate timeline of Focus Time without requiring any manual input. ## The ROI of Protecting Focus Time Let's do the math for a 10-person engineering team: **Current state:** Average 78 minutes of coding per day, fragmented into 5-6 sessions. **After Focus Time protection:** Average 110 minutes of coding per day, consolidated into 2-3 sessions. That's a **41% increase** in coding time — without hiring anyone, without working longer hours, just by restructuring when and how interruptions happen. | Scenario | Daily coding/developer | Weekly team total | Monthly team total | |----------|:---------------------:|:-----------------:|:-----------------:| | Fragmented (baseline) | 78 min | 65 hours | 260 hours | | Focus-protected | 110 min | 91.7 hours | 367 hours | | **Difference** | **+32 min** | **+26.7 hours** | **+107 hours** | That's the equivalent of adding **2.7 full-time developers** to your team — just by protecting focus. ## What Engineering Managers Should Do Monday Morning 1. **Audit your team's meeting load.** Count meetings per developer per day. If anyone has more than 2 hours of meetings daily, they're unlikely to achieve meaningful Focus Time. 2. **Establish meeting-free blocks.** Start with Tuesday and Wednesday mornings. Communicate the policy clearly and enforce it. 3. **Start measuring Focus Time.** You can't improve what you don't measure. Set up IDE-level tracking to see actual Focus Time, not estimated time. 4. **Review Focus Time in 1:1s.** When a developer's Focus Time drops, ask why. Often the answer is a new recurring meeting, an on-call rotation, or a cross-team dependency that can be restructured. 5. **Set a team Focus Time target.** Based on our data, a healthy target is **90-120 minutes of Focus Time per developer per day**. Not as a quota — as a signal that your team has the space to do their best work. ## Focus Time Is a Leadership Responsibility Developers can't protect their own Focus Time. They can't decline meetings invited by their skip-level. They can't ignore a VP's Slack message. They can't refuse to help a teammate who's stuck. Protecting Focus Time is a **management responsibility**. It requires setting policies, enforcing boundaries, and sometimes saying "no" to stakeholders who want a developer's attention right now. The data is clear: the difference between a high-performing engineering team and a struggling one often isn't talent, tools, or technology. It's whether developers have the uninterrupted time to actually think. --- *Based on aggregated data from PanDev Metrics Cloud (April 2026), thousands of hours of IDE activity across B2B engineering teams. Research references: Gloria Mark, "The Cost of Interrupted Work" (UC Irvine, 2008); Chris Parnin, "Resumption Strategies for Interrupted Programming Tasks" (IEEE, 2011); Cal Newport, "Deep Work" (2016); McKinsey developer productivity report (2023).* **Ready to measure your team's Focus Time?** [PanDev Metrics](https://pandev-metrics.com) tracks Focus Time automatically through IDE plugins — no timers, no self-reporting, just real data from your editors. --- ## Delivery Index: How to Measure Development Velocity Without Lines of Code URL: https://pandev-metrics.com/docs/blog/delivery-index-without-loc Date: 2026-03-18 Tags: delivery-index, engineering-metrics, developer-productivity, velocity Description: Lines of code is a broken metric. Delivery Index combines coding activity, task completion, and consistency to measure real development velocity. Fred Brooks warned in *The Mythical Man-Month* (1975) that measuring programmer productivity by volume of code is a trap: adding more code isn't the same as adding more value. Fifty years later, some organizations still equate lines written with work done. The SPACE framework (Forsgren et al., 2021) explicitly cautions against single-dimensional activity metrics — yet the need they address is real: **how do you measure whether your engineering team is delivering?** The answer isn't another vanity metric. It's a composite signal we call the **Delivery Index**. ## Why Lines of Code Failed Lines of code (LoC) as a productivity metric has been criticized for decades, and for good reason. Let's start with the obvious problems: | Scenario | Lines of code | Actual value delivered | |----------|:------------:|:--------------------:| | Developer refactors 3,000 lines into 800 | −2,200 | High — simpler, faster, fewer bugs | | Junior copies Stack Overflow answer | +500 | Low — untested, poorly integrated | | Senior designs clean API | +120 | Very high — enables 5 other developers | | Developer adds logging everywhere | +2,000 | Low — noise, performance impact | LoC penalizes good engineering. A senior developer who spends a week designing an elegant 200-line solution appears "less productive" than a junior who writes 2,000 lines of spaghetti. The metric rewards verbosity, not value. ### But the deeper problem is incentive distortion When you measure LoC, developers write more code. They copy-paste instead of abstracting. They avoid refactoring because it reduces their "score." They add unnecessary complexity. The metric doesn't just fail to measure productivity — it actively makes your codebase worse. Bill Gates reportedly said: "Measuring software productivity by lines of code is like measuring progress on an airplane by how much it weighs." Whether he actually said it is debatable. Whether it's true is not. ## What the VP of Engineering Actually Needs When a VP of Engineering asks "are we delivering?", they're really asking several questions at once: 1. **Are developers actively working on the right things?** (Activity) 2. **Are tasks and features actually getting completed?** (Throughput) 3. **Is the pace sustainable and consistent?** (Consistency) 4. **Are estimates improving over time?** (Predictability) No single metric answers all four. That's why we built Delivery Index as a **composite metric** that considers multiple signals. ## How Delivery Index Works Delivery Index in PanDev Metrics is calculated from several weighted components: | Component | What it measures | Why it matters | |-----------|-----------------|---------------| | **Activity Time** | Hours of active IDE coding time | Shows effort input — is the developer actually coding? | | **Focus Time** | Sustained uninterrupted sessions | Quality of effort — fragmented vs. deep work | | **Task velocity** | Tasks completed per time period | Output signal — are things getting done? | | **Consistency score** | Variance in daily/weekly output | Sustainability — steady pace vs. boom-bust cycles | | **Planning accuracy delta** | Estimated vs. actual completion | Predictability — can the team forecast reliably? | The Delivery Index produces a normalized score that accounts for the reality of software development: some weeks are heavy coding weeks, some are architecture and planning weeks. A healthy Delivery Index doesn't require maximum coding every day — it requires **consistent, predictable delivery**. ### The math in plain English Think of Delivery Index like a credit score. No single factor determines it. A developer who codes 4 hours daily but never finishes tasks has a mediocre Delivery Index. A developer who codes 1 hour daily but consistently ships features on schedule scores well. The metric rewards **completed work delivered predictably** — not raw activity. ## What Our Data Reveals About Velocity Analyzing data from B2B engineering teams using PanDev Metrics, we see clear patterns in how healthy delivery looks — patterns that align with McKinsey's 2023 finding that developers spend only 25-30% of their time writing code: ![Activity heatmap showing real coding patterns — the data behind Delivery Index](https://pandev-metrics.com/img/blog/activity-heatmap.png) *Activity heatmap showing real coding patterns — the data behind Delivery Index.* ### Coding time is not the bottleneck you think it is The median developer in our dataset codes **78 minutes per day**. The mean is **111 minutes**. This means the "typical" developer spends roughly 1.5 hours in active coding. | Coding time bucket | % of developers | Avg. Delivery Index | |-------------------|:--------------:|:-------------------:| | < 30 min/day | 12% | Low — often blocked or in too many meetings | | 30–60 min/day | 21% | Medium — common for senior roles with review duties | | 60–120 min/day | 32% | High — the sweet spot for most IC roles | | 120–180 min/day | 9% | High — strong individual contributors | | 180+ min/day | 27% | Varies — sometimes high velocity, sometimes burnout signal | The sweet spot is **60-120 minutes of coding per day** with a high Delivery Index. Developers in this range tend to code efficiently, complete tasks on schedule, and maintain a sustainable pace. Going above 180 minutes daily doesn't consistently correlate with better delivery — in some cases, it signals thrashing or rework. ### IDE choice and velocity Our data shows interesting patterns across the three dominant IDEs: | IDE | Users | Total hours | Avg. hours/user | |-----|:-----:|:-----------:|:--------------:| | VS Code | 100 | 3,057 | 30.6 | | IntelliJ IDEA | 26 | 2,229 | 85.7 | | Cursor | 24 | 1,213 | 50.5 | IntelliJ users show higher average hours per user — likely reflecting that Java (our #1 language at 2,107 hours) is primarily developed in IntelliJ, and Java projects tend to require more typing due to the language's verbosity. This is exactly why LoC doesn't work: a Java developer writing 200 lines has done less "work" than a Python developer writing 50 lines of equivalent logic. ## Five Anti-Patterns That Kill Delivery When Delivery Index drops across a team, it's usually caused by one of these patterns: ### 1. The estimation death spiral Teams consistently underestimate tasks → they miss deadlines → managers add buffer → estimates become meaninglessly large → planning accuracy drops → nobody trusts the roadmap. **Delivery Index signal:** Planning accuracy component drops below 50%, task velocity stays flat or declines. ### 2. The meeting tax A developer with 4 hours of meetings has, at best, 4 hours of fragmented time remaining. With context switching overhead, this yields maybe 45 minutes of actual Focus Time. **Delivery Index signal:** Activity Time drops while task assignments stay constant. The developer is "busy" but not coding. ### 3. The hero dependency One senior developer is the bottleneck for all code reviews, architecture decisions, and debugging sessions. Their Delivery Index may look fine, but the team's aggregate drops because everyone is waiting on them. **Delivery Index signal:** One developer shows high Activity Time with low task velocity (they're helping others, not shipping their own work). Team-level Delivery Index declines despite individual effort. ### 4. The scope creep silent killer Tasks keep growing after estimation. A "2-day feature" becomes a "2-week epic" through accumulated changes. The work gets done, but it doesn't match what was planned. **Delivery Index signal:** Task velocity drops dramatically while coding time stays constant or increases. Developers are working hard on tasks that never close. ### 5. The tech debt avalanche The codebase is so fragile that every new feature requires fixing three things first. Development feels slow not because developers are slow, but because the environment resists change. **Delivery Index signal:** High Activity Time, high Focus Time, low task velocity. Developers are coding intensely but progress is minimal — a clear sign of codebase friction. ## How to Implement Delivery Index in Your Organization ### Step 1: Establish a baseline (Week 1-2) Deploy IDE tracking across your team. PanDev Metrics supports VS Code, all JetBrains IDEs, Cursor, Visual Studio, and more. Let data collect for at least two full sprints before drawing conclusions. ### Step 2: Identify patterns, not outliers (Week 3-4) Look at team-level trends first: | What to look for | Healthy signal | Warning signal | |-----------------|---------------|---------------| | Daily coding time distribution | 60–120 min median | Bimodal (< 30 or > 240) | | Day-over-day consistency | Low variance | Boom-bust cycles | | Task completion trend | Steady or improving | Declining week-over-week | | Estimation accuracy | Within ±30% | Consistently off by 2x+ | ### Step 3: Address systemic issues (Month 2) Use the data to make structural changes: reduce meeting load, rebalance work across the team, break down oversized tasks, or allocate time for tech debt reduction. ### Step 4: Track improvement (Ongoing) Delivery Index should trend upward as you remove friction. If it doesn't, you're solving the wrong problems. ## Delivery Index vs. DORA Metrics DORA metrics (Deployment Frequency, Lead Time, Change Failure Rate, Mean Time to Recovery) measure the **delivery pipeline**. Delivery Index measures the **development process** that feeds the pipeline. | Dimension | DORA | Delivery Index | |-----------|------|---------------| | What it measures | CI/CD pipeline health | Developer and team work patterns | | Granularity | Team/service level | Individual + team level | | Leading/lagging | Mostly lagging (measures output) | Leading (measures conditions for output) | | Data source | Git, CI/CD systems | IDE activity, task management | | Best for | DevOps maturity | Engineering management | They're complementary. DORA tells you **how fast your pipeline ships**. Delivery Index tells you **how effectively your team develops**. Poor Delivery Index will eventually show up as degraded DORA metrics — but by then, you've lost weeks. ## What to Tell Your Board VPs of Engineering often need to translate engineering metrics into business language. Here's how Delivery Index maps to business outcomes: - **High Delivery Index + High Planning Accuracy** → "We ship what we promise, when we promise it." - **High Delivery Index + Low Planning Accuracy** → "We're delivering well, but our estimates need work. Roadmap dates have uncertainty." - **Low Delivery Index + High Activity** → "The team is working hard but there are structural blockers — tech debt, dependencies, or process overhead." - **Low Delivery Index + Low Activity** → "We have a staffing, engagement, or tooling problem." The value of Delivery Index isn't the number itself — it's the **conversation it enables**. Instead of "are we productive?", you can ask "what's blocking delivery?" and have data to guide the answer. --- *Based on aggregated data from PanDev Metrics Cloud (April 2026), thousands of hours of IDE activity across B2B engineering teams. All data anonymized and aggregated. References: SPACE framework (Forsgren et al., ACM Queue, 2021); Fred Brooks, "The Mythical Man-Month" (1975); McKinsey developer productivity report (2023).* **Want to see your team's Delivery Index?** [PanDev Metrics](https://pandev-metrics.com) calculates it automatically from IDE activity and task data — no manual tracking, no timesheets, no guesswork. --- ## Planning Accuracy: How to Know If Your Team Overestimates or Underestimates Tasks URL: https://pandev-metrics.com/docs/blog/planning-accuracy Date: 2026-03-16 Tags: planning-accuracy, engineering-metrics, project-management, estimation Description: Most engineering teams can't estimate well. Planning Accuracy tracks estimation bias over time so you can finally build roadmaps you can trust. "This should take two days." Three weeks later, the feature is still in progress. Steve McConnell, in *Software Estimation: Demystifying the Black Art*, found that software projects typically overrun initial estimates by **28-85%**. Brooks's Law from *The Mythical Man-Month* explains part of the reason: complexity grows non-linearly with scope, and adding people to a late project makes it later. The PM is frustrated. The developer feels guilty. The roadmap is fiction. And the entire organization has quietly accepted that **engineering estimates are unreliable**. This isn't a people problem. It's a measurement problem. And it's fixable. ## The Estimation Problem Nobody Wants to Admit Every engineering team estimates. Story points, t-shirt sizes, hours, days — the format varies, but the outcome is remarkably consistent: **estimates are wrong**. The question isn't whether estimates are wrong. It's whether they're wrong in a **predictable, correctable direction**. This is what Planning Accuracy measures: not whether your team estimates perfectly (nobody does), but whether their estimation bias is consistent enough to compensate for, and whether it's improving over time. ### Two types of estimation failure | Failure mode | What it looks like | Business impact | |-------------|-------------------|----------------| | **Chronic underestimation** | Tasks consistently take 2-3x longer than estimated | Missed deadlines, eroded stakeholder trust, death march sprints | | **Chronic overestimation** | Tasks finish early but buffer time is wasted | Slow perceived velocity, sandbagged commitments, underutilized capacity | Most teams suffer from underestimation. Research by Steve McConnell (author of *Software Estimation: Demystifying the Black Art*) found that software projects typically overrun initial estimates by **28-85%**, depending on how early the estimate was made. But some teams — especially those burned by past deadline misses — swing the other way. They pad everything by 50-100%, delivering on time but at a pace that frustrates product teams. Both patterns are problems. Both are fixable with data. ## What Planning Accuracy Looks Like in Practice Planning Accuracy in PanDev Metrics compares **estimated effort** (hours, story points, or days — whatever your team uses) against **actual effort** (measured through IDE activity data and task completion timestamps). The formula is straightforward: **Planning Accuracy = 1 − |Estimated − Actual| / Estimated** A score of 1.0 means perfect estimation. A score of 0.5 means your estimates are off by 50%. A negative score means your estimates are worse than random. ### Example: A real sprint breakdown | Task | Estimated (days) | Actual (days) | Planning Accuracy | |------|:-----------------:|:-------------:|:-----------------:| | User auth refactor | 3 | 5 | 0.33 | | Search API endpoint | 2 | 2.5 | 0.75 | | Dashboard widget | 1 | 0.5 | 0.50 | | CSV export | 2 | 2 | 1.00 | | Payment integration | 5 | 8 | 0.40 | | Bug fix batch | 1 | 1 | 1.00 | | **Sprint total** | **14** | **19** | **0.64** | This sprint has a Planning Accuracy of 0.64 — not terrible, but with a clear underestimation bias. The two largest tasks (auth refactor and payment integration) drove most of the miss. This is a common pattern: **large tasks have worse estimation accuracy than small tasks**. ## Why Developers Can't Estimate (And It's Not Their Fault) ### The planning fallacy Daniel Kahneman and Amos Tversky identified the "planning fallacy" in 1979: people systematically underestimate the time needed to complete future tasks, even when they know similar tasks took longer in the past. For developers, this manifests as: - Remembering the coding time but forgetting the debugging time - Assuming the happy path without accounting for edge cases - Not factoring in code review cycles, deployment issues, or dependency delays - Estimating based on "how long it would take if everything goes right" ### Unknown unknowns Software estimation is fundamentally harder than estimating physical tasks because the **scope of unknowns is unknown**. A carpenter can estimate a bookshelf because they've built hundreds. A developer building a new microservice has variables they literally cannot foresee: API quirks, library bugs, infrastructure issues, security requirements that emerge mid-development. ### The anchoring effect In sprint planning, the first estimate spoken aloud anchors all subsequent discussion. If a senior developer says "that's a 3-pointer," junior developers hesitate to disagree even when their gut says it's an 8. Planning Poker was designed to prevent this, but in practice, many teams have abandoned it for "quick" verbal estimates that are heavily anchored. ## Patterns We See Across Engineering Teams Analyzing Planning Accuracy data from PanDev Metrics across B2B engineering teams reveals consistent patterns — patterns that mirror what Kahneman described as the "planning fallacy" in action: ### Pattern 1: Small tasks are estimated well, large tasks are not | Task size | Avg. Planning Accuracy | Direction of error | |-----------|:---------------------:|:------------------:| | < 4 hours | 0.82 | Slight overestimate | | 4–8 hours (1 day) | 0.71 | Slight underestimate | | 1–3 days | 0.58 | Underestimate by ~40% | | 3–5 days | 0.45 | Underestimate by ~55% | | 5+ days | 0.31 | Underestimate by 2-3x | The lesson is clear: **break tasks into pieces smaller than one day wherever possible**. A 5-day task estimated as five 1-day subtasks will be more accurate than a single 5-day estimate, even though the total scope is identical. ### Pattern 2: Estimation accuracy improves with feedback loops Teams that review their Planning Accuracy data after each sprint show measurable improvement: | Sprint # | Avg. Planning Accuracy (no review) | Avg. Planning Accuracy (with review) | |:---------:|:----------------------------------:|:------------------------------------:| | 1 | 0.52 | 0.51 | | 2 | 0.49 | 0.56 | | 3 | 0.53 | 0.61 | | 4 | 0.50 | 0.65 | | 5 | 0.51 | 0.68 | | 6 | 0.48 | 0.72 | Without feedback, teams hover around 0.50 indefinitely — essentially coin-flip accuracy. With regular review, they improve to 0.70+ within 6 sprints. The data, not the talent, makes the difference. ### Pattern 3: Tuesday velocity predicts sprint success Our data shows Tuesday is the peak coding day across the dataset. Teams that front-load complex tasks to Monday-Tuesday have better sprint completion rates than teams that distribute evenly. The reason: when Tuesday goes well, the rest of the sprint has momentum. When the hardest tasks are left to Thursday-Friday, risks accumulate. ### Pattern 4: Language and framework affect estimation accuracy | Primary language | Avg. Planning Accuracy | Likely cause | |-----------------|:---------------------:|-------------| | Python | 0.68 | Rapid prototyping, fewer surprises | | TypeScript | 0.62 | Frontend complexity, design iterations | | Java | 0.57 | Boilerplate overhead, enterprise complexity | | Multi-language projects | 0.48 | Context switching, integration issues | Java projects (2,107 hours in our dataset — the most of any language) tend to have lower Planning Accuracy. This reflects the language's verbosity and the enterprise environments where Java dominates — more stakeholders, more compliance requirements, more "surprises" during implementation. ## How to Improve Planning Accuracy: A Framework for CPOs and PMs ### Step 1: Start tracking the gap Before you can improve, you need a baseline. For every task, record: - Estimated effort (in whatever unit your team uses) - Actual effort (measured, not self-reported) - Date estimated, date started, date completed - Whether scope changed mid-task PanDev Metrics automates the "actual effort" part through IDE tracking. When a developer works on a task tagged to a specific ticket, the system records how much active coding time went into it. ### Step 2: Identify your bias direction After 2-3 sprints, calculate your team's average Planning Accuracy and bias direction. Most teams will find they consistently underestimate. This is normal. | Bias direction | What to do | |---------------|-----------| | Consistent underestimate by 20-40% | Apply a 1.3x multiplier to estimates as a starting correction | | Consistent underestimate by 50%+ | Tasks are too large — break them down before estimating | | Consistent overestimate by 20%+ | Reduce padding — your team is sandbagging (possibly unconsciously) | | Random — sometimes over, sometimes under | Estimation process is broken — try different granularity or estimation methods | ### Step 3: Implement reference class forecasting Instead of estimating from scratch, compare new tasks to **completed similar tasks** and use their actual duration as the baseline. PanDev Metrics maintains a historical record of task durations by type, making reference class forecasting practical. Example: "The last three API endpoints took 1.5, 2, and 2.5 days. This one is similar in complexity. Estimate: 2 days." This approach, recommended by Kahneman, dramatically reduces the planning fallacy because it anchors on **actual outcomes** rather than optimistic projections. ### Step 4: Make Planning Accuracy a sprint metric Add it to your sprint retrospective dashboard alongside velocity and burndown. When the team sees their accuracy score, they naturally start to calibrate. **Don't use it punitively.** Planning Accuracy is not a score that determines bonuses or performance reviews. It's a calibration tool. If a team's accuracy drops because they took on a novel technical challenge, that's expected and healthy. ### Step 5: Communicate uncertainty, not dates Instead of "this will ship on March 15," say "our Planning Accuracy is 0.65 with an underestimation bias. Based on our estimate of 10 days, the likely range is 10-16 days." Stakeholders can handle uncertainty — what they can't handle is surprise. ## The Cost of Bad Estimates Poor Planning Accuracy has compounding costs: | Impact area | Cost | |------------|------| | **Missed commitments** | Eroded trust with customers, sales, and leadership | | **Overtime/crunch** | Burnout, attrition — our data shows coding time spikes before deadlines followed by crashes | | **Sandbagging** | Reduced throughput as teams pad estimates to protect themselves | | **Bad hiring decisions** | "We need more developers" when the real problem is estimation and process | | **Product delays** | Features promised to customers arrive late, affecting revenue | This mirrors Brooks's Law perfectly: "adding manpower to a late software project makes it later." One VP of Engineering we spoke with summarized it well: "We hired two developers to fix a velocity problem. It didn't help because the problem wasn't capacity — it was that our estimates were 2x wrong, so we were always behind no matter how many people we added." ## Planning Accuracy as a Leading Indicator Planning Accuracy is one of the few **leading indicators** available to engineering leadership. By the time DORA metrics show degradation, the damage is done. But Planning Accuracy trends give you weeks of warning: - Dropping accuracy → team is taking on unfamiliar work or has hidden blockers - Increasing bias toward underestimation → scope creep or growing tech debt - Sudden accuracy improvement → team may be sandbagging to hit numbers When you combine Planning Accuracy with Activity Time data (our median of 78 min/day tells you what's realistic), you can build roadmaps grounded in **what your team actually does**, not what you wish they did. ![Planning Accuracy indicator showing actual vs estimated delivery](https://pandev-metrics.com/img/blog/employee-metrics-safe.png) *Planning Accuracy indicator showing actual vs estimated delivery.* --- *Based on aggregated data from PanDev Metrics Cloud (April 2026). Estimation patterns observed across B2B engineering teams. References: Steve McConnell, "Software Estimation: Demystifying the Black Art" (2006); Daniel Kahneman, "Thinking, Fast and Slow" (2011); Fred Brooks, "The Mythical Man-Month" (1975).* **Want to track your team's Planning Accuracy automatically?** [PanDev Metrics](https://pandev-metrics.com) connects IDE activity to your task tracker, measuring actual effort against estimates — no manual timesheets required. --- ## 5 Data Patterns That Scream 'Your Developer Is Burning Out URL: https://pandev-metrics.com/docs/blog/burnout-detection-data Date: 2026-03-13 Tags: burnout, developer-wellbeing, engineering-management, data-patterns Description: Burnout doesn't start with a resignation letter. IDE activity data reveals 5 warning patterns weeks before a developer quits or crashes. Nobody quits on a Monday. The resignation email you receive on a random Thursday was written — emotionally — six weeks ago. The disengagement started three months ago. And the data saw it coming the entire time. The 2023 Stack Overflow Developer Survey found that over 70% of developers reported some level of burnout symptoms. Replacing a mid-level software engineer costs an estimated **50-200% of their annual salary** when you factor in recruiting, onboarding, and lost institutional knowledge. The SPACE framework (Forsgren et al., 2021) explicitly includes "Satisfaction and well-being" as a core productivity dimension — recognizing that burned-out developers aren't just unhappy, they're materially less productive. But the signals are visible in activity data long before the resignation letter. Here are five patterns that show up in IDE activity data weeks — sometimes months — before a developer burns out or leaves. ## Pattern #1: The Disappearing Evening Spike ### What it looks like A developer who used to code in the evenings stops. Not because they've improved their work-life balance — but because they've lost the internal motivation to engage with code outside required hours. ### The data pattern | Time period | Before (engaged) | Transition (early warning) | After (burned out) | |------------|:-----------------:|:--------------------------:|:------------------:| | 9 AM – 12 PM | High activity | High activity | Medium activity | | 12 PM – 5 PM | High activity | Medium activity | Low activity | | 5 PM – 8 PM | Medium activity | Low activity | Zero | | Weekends | Occasional commits | Zero | Zero | This pattern is counterintuitive. You might think "great, they stopped working evenings — they're taking care of themselves." But when a previously engaged developer suddenly drops to zero off-hours activity, it often signals a loss of interest, not healthy boundary-setting. The key is the **context of the change**. If a developer proactively sets boundaries and maintains or improves their daytime output, that's healthy. If evening coding disappears alongside declining daytime Focus Time and increasing short sessions, it's a warning sign. ### Why it matters Intrinsic motivation — coding because you want to, not because you're told to — is one of the strongest signals of engagement. When it vanishes from the data, disengagement has already begun. ## Pattern #2: The Boom-Bust Cycle ### What it looks like Alternating weeks of intense overwork followed by weeks of minimal activity. The developer swings between 4+ hours of daily coding and less than 30 minutes, with no middle ground. ### The data pattern | Week | Daily coding time | Focus sessions | Pattern | |:----:|:-----------------:|:--------------:|:-------:| | 1 | 240 min | 3 long | BOOM | | 2 | 210 min | 3 long | BOOM | | 3 | 25 min | Short only | BUST | | 4 | 15 min | Minimal | BUST | | 5 | 260 min | 4 long | BOOM | | 6 | 20 min | Minimal | BUST | Our platform data across B2B engineering teams shows the median developer codes **78 minutes per day** with relatively stable consistency — a figure consistent with McKinsey's finding that developers spend only 25-30% of their time coding. Developers exhibiting boom-bust patterns often average the same 78 minutes — but the variance is extreme. ### Why it matters This pattern indicates a developer who is coping with burnout through intermittent recovery, rather than addressing the root cause. They push until they crash, recover just enough to function, then push again. Each cycle depletes reserves further. A developer showing this pattern in PanDev Metrics' Activity Time chart will have a sawtooth graph instead of a steady line. The Productivity Score — which factors in consistency — will reflect this instability. ### What managers miss The average looks fine. If you only check monthly totals, the boom weeks compensate for bust weeks. It's only when you look at **daily or weekly granularity** that the pattern emerges. ## Pattern #3: The Shrinking Focus Session ### What it looks like A developer's Focus Time sessions get progressively shorter over weeks. They used to code in 90-minute blocks. Then 60 minutes. Then 30. Now they can barely maintain 15 minutes of continuous coding. ### The data pattern | Month | Avg. Focus session length | Sessions per day | Total Focus Time | |:-----:|:------------------------:|:----------------:|:----------------:| | January | 72 min | 2.1 | 151 min | | February | 58 min | 2.3 | 133 min | | March | 41 min | 2.8 | 115 min | | April | 23 min | 3.5 | 81 min | Notice the total Focus Time decreases, but the number of sessions increases. The developer is **trying** to work — starting sessions more often — but can't maintain concentration. This is a hallmark of cognitive exhaustion. ### Why it matters The inability to sustain focus is one of the earliest and most reliable indicators of burnout, consistent with Gloria Mark's research on attention fragmentation (UC Irvine). If a developer can no longer maintain the 23+ minutes of uninterrupted focus needed to enter a productive state, their effective output collapses — and this often precedes visible symptoms like missing deadlines or declining code quality by weeks. PanDev Metrics' Focus Time metric captures this directly. When you see a downward trend in average session length, it's time for a conversation — not about performance, but about wellbeing. ## Pattern #4: The Language/Project Scattering ### What it looks like A developer who normally works in 1-2 languages or projects starts touching many files across many projects without depth in any. ### The data pattern | Month | Primary language % | Projects touched | Avg. time per project | |:-----:|:-----------------:|:----------------:|:---------------------:| | Normal | 75% (TypeScript) | 2 | 85% of time in main project | | Warning | 55% (TypeScript) | 4 | 40% of time in main project | | Critical | 30% (TypeScript) | 6+ | < 20% in any single project | In our production data, the top three languages — Java (2,107 hours), TypeScript (1,627 hours), and Python (1,350 hours) — dominate individual developer profiles. Most developers spend 70-80% of their time in one primary language. When this concentration drops sharply, it often means: - The developer is **avoiding** their main project (subconsciously or deliberately) - They're being pulled into too many contexts (a management problem) - They're looking for new stimulation because their main work has become emotionally draining ### Why it matters Context switching is expensive (research shows 20-80% productivity loss depending on task complexity), but when a developer starts **voluntarily** scattering across projects, it signals disengagement from their primary work. They're seeking novelty — a common coping mechanism for burnout. ## Pattern #5: The Weekend Creep ### What it looks like A developer who rarely coded on weekends starts showing consistent Saturday and Sunday activity. Not the occasional "I had an idea and wanted to try it" session, but regular multi-hour weekend coding. ### The data pattern | Phase | Weekend coding hours | Weekday coding hours | Total weekly | |:-----:|:-------------------:|:-------------------:|:------------:| | Healthy | 0-1 hr | 6-9 hr | 6-10 hr | | Early warning | 2-4 hr | 8-10 hr | 10-14 hr | | Critical | 4-8 hr | 8-10 hr | 12-18 hr | | Pre-burnout | 4-8 hr | 5-7 hr (declining) | 9-15 hr | The dangerous phase is the last one: weekend hours stay high while weekday hours **drop**. The developer has shifted their productive time to weekends — possibly because weekdays are filled with meetings, or because they can only focus when nobody else is online. Our data shows that weekend coding activity is approximately **3.5x lower** than weekday activity across the overall dataset. When an individual developer's weekend-to-weekday ratio significantly exceeds the population average, it's a signal worth investigating. ### Why it matters Weekend work isn't inherently bad. Many developers enjoy weekend side projects. The warning sign is **sustained weekend work on company projects** combined with **declining weekday productivity**. This means the developer has lost productive hours during the week (usually to meetings and interruptions) and is compensating on their own time — an unsustainable pattern. ![Working calendar settings showing work days and hours configuration](https://pandev-metrics.com/img/blog/calendar-settings.png) *PanDev Metrics calendar settings — define standard work days (Mon-Fri) and hours (09:00-18:00) so the system can flag after-hours and weekend activity as potential burnout signals.* ## How to Use This Data Without Being Creepy Let's address the elephant in the room: tracking developer activity can feel invasive. There's a line between **protecting your team** and **surveilling your team**, and it's important to stay on the right side. ### Principles for ethical burnout detection | Do | Don't | |----|-------| | Track **aggregate patterns** over weeks | React to a single day's data | | Use data to **start conversations** | Use data to make accusations | | Share dashboards **with the developer** | Keep data hidden from the people it's about | | Focus on **team-level trends** first | Single out individuals without context | | Frame as **wellbeing support** | Frame as performance management | | Respect **opt-out preferences** | Make tracking mandatory without discussion | PanDev Metrics is designed around this philosophy. Developers can see their own data. Managers see team-level aggregates first, individual patterns only when they need to have a supportive conversation. ### The right conversation to have When you see these patterns, don't say: "Your coding hours are down, what's going on?" Instead say: "I've noticed some changes in our team's work patterns and I want to check in. How are you feeling about your workload? Is there anything blocking your ability to do focused work?" Make it about the **environment**, not the person. Burnout is a systemic problem, not an individual weakness. ## Building a Burnout Detection System ### Step 1: Establish baselines (Month 1) Collect data for at least 4 weeks before establishing what "normal" looks like for each developer. People have different patterns — a developer who naturally codes 200+ minutes daily isn't burning out when they hit 180 minutes. ### Step 2: Set change-detection thresholds | Metric | Normal variance | Warning threshold | |--------|:--------------:|:-----------------:| | Daily coding time | ±20% week-over-week | > 30% decline for 2+ weeks | | Focus session length | ±15% | > 25% decline over 4 weeks | | Weekend-to-weekday ratio | 0-0.15 | > 0.35 for 3+ weeks | | Project scatter (Herfindahl index) | > 0.5 | < 0.3 for 2+ weeks | | Boom-bust variance (CoV) | < 0.3 | > 0.6 for 4+ weeks | ### Step 3: Create intervention protocols | Alert level | Trigger | Action | |:----------:|---------|--------| | Yellow | 1 pattern detected for 2+ weeks | Manager mental note, observe | | Orange | 2 patterns detected, or 1 for 4+ weeks | 1:1 check-in, offer support | | Red | 3+ patterns, or sustained decline over 6+ weeks | Workload restructuring, potential time off | ### Step 4: Measure and iterate Track whether interventions actually help. If a check-in conversation leads to meeting reduction, does the developer's Focus Time recover? If you mandate a week off, does the boom-bust pattern stabilize? Use the same data that detected the problem to verify the solution. ## The Cost of Doing Nothing The average cost of developer turnover is significant — recruiting, onboarding, ramp-up time, and lost productivity typically add up to 6-9 months of salary for a mid-level engineer. But the cost of a burned-out developer who **stays** is often worse: - Reduced code quality leads to more bugs and tech debt - Disengagement spreads to teammates - Innovation and initiative drop to zero - The team works around the person, reducing everyone's efficiency Data-driven burnout detection isn't about surveillance. It's about seeing the problem while there's still time to fix it. --- *Based on aggregated, anonymized patterns from PanDev Metrics Cloud (April 2026), thousands of hours of IDE activity across B2B engineering teams. No individual developer data was used in this analysis — patterns described are composites of observed trends. References: SPACE framework (Forsgren et al., ACM Queue, 2021); Gloria Mark, "The Cost of Interrupted Work" (UC Irvine, 2008); Stack Overflow Developer Survey (2023).* **Want to protect your team from burnout before it happens?** [PanDev Metrics](https://pandev-metrics.com) tracks Activity Time, Focus Time, and work pattern consistency — giving engineering managers the data to have the right conversation at the right time. --- ## The 10x Developer: What the Data Actually Shows (And Why It Doesn't Matter) URL: https://pandev-metrics.com/docs/blog/10x-developer-myth Date: 2026-03-10 Tags: developer-productivity, 10x-developer, engineering-culture, data, contrarian Description: We analyzed thousands of hours of real coding data. The productivity gap between developers is real — but the '10x' framing is wrong and harmful. The "10x developer" is one of the most persistent myths in our industry — and one of the most damaging. Fred Brooks observed in *The Mythical Man-Month* (1975) that individual programmer productivity varies widely, but he also warned against the conclusion that hiring solves systemic problems. The SPACE framework (Forsgren et al., 2021) goes further: measuring individual developer "productivity" with a single metric is not just inaccurate, it's counterproductive. We have data from B2B engineering teams and thousands of hours of tracked coding time. Here's what it actually says about developer performance variance — and why the answer matters less than you think. ## The Origin of the 10x Claim The concept traces back to a 1968 study by Sackman, Erikson, and Grant, which measured programmer performance on coding and debugging tasks. They found a **28:1 ratio** between the best and worst performers on debugging time, and a **5:1 ratio** on coding time. Since then, the numbers have been cited, inflated, and mythologized. By the time it reached Silicon Valley folklore, "5-28x" became "10x" — a clean, memorable number that became shorthand for "some developers are dramatically better than others." But there are problems with applying a 1968 lab study to modern software development: | Factor | 1968 study | 2026 reality | |--------|-----------|-------------| | Participants | Students with < 2 years experience | Professional developers with 3-20+ years | | Task type | Small, isolated coding puzzles | Complex systems with dependencies, tests, CI/CD | | Duration | Hours-long exercises | Multi-month projects | | Collaboration | Individual | Teams of 3-15 | | Tools | Text editors, punch cards | IDEs, AI assistants, frameworks, libraries | | Measurement | Time to complete task + debug | Shipping features, code quality, system reliability | The original study measured **individual coding speed on isolated tasks**. Modern software development is a team sport where coding speed is one of many factors. ## What Our Data Shows About Developer Variance Across B2B engineering teams tracked by PanDev Metrics, here's the distribution of daily coding time: | Percentile | Daily coding time | Label | |:----------:|:-----------------:|:-----:| | P5 | 6 min | Minimal | | P10 | 18 min | Very low | | P25 | 38 min | Below average | | **P50 (median)** | **78 min** | **Average** | | P75 | 148 min | Above average | | P90 | 223 min | High | | P95 | 261 min | Very high | | P99 | 279 min | Maximum zone | The ratio between P90 and P10 is **12.4:1**. The ratio between P95 and P25 is **6.9:1**. So yes — there is a large variance in raw coding time. You could look at this data and say "10x confirmed." But you'd be wrong. Here's why. ## Why Raw Coding Time Is a Terrible Proxy for "10x" ### Problem 1: Role differences The developer coding 6 minutes per day might be a Staff Engineer who spends their time in architecture reviews, mentoring, and design documents. The developer coding 279 minutes might be a junior implementing CRUD endpoints. Who is more valuable? | Role | Typical daily coding time | Primary value contribution | |------|:------------------------:|---------------------------| | Junior IC | 80-150 min | Feature implementation, learning | | Mid IC | 60-120 min | Feature implementation, some design | | Senior IC | 50-100 min | Design, code review, mentoring, implementation | | Staff+ | 20-60 min | Architecture, cross-team alignment, force multiplication | | Tech Lead | 30-70 min | Planning, unblocking, implementation | Coding time **decreases** as seniority increases, because the developer's value shifts from direct output to **multiplying the team's output**. Measuring a Staff Engineer by their coding time is like measuring a coach by their personal sprint time. ### Problem 2: IDE choice and language inflate differences Our data shows significant variation in hours per user across IDEs: | IDE | Users | Total hours | Avg. hours/user | |-----|:-----:|:-----------:|:--------------:| | VS Code | 100 | 3,057 | 30.6 | | IntelliJ IDEA | 26 | 2,229 | 85.7 | | Cursor | 24 | 1,213 | 50.5 | IntelliJ users average **2.8x more hours** than VS Code users. Is this because IntelliJ users are 2.8x more productive? No. It's because IntelliJ is primarily used for Java (2,107 hours — our top language), which requires more typing, more boilerplate, and more IDE time than TypeScript (1,627 hours) or Python (1,350 hours). A Python developer who solves a problem in 50 lines and 30 minutes is not less productive than a Java developer who writes 300 lines in 90 minutes for equivalent functionality. The language defines the measurement, not the developer. ### Problem 3: The denominator problem "10x" requires you to define what "1x" is. Is it: - Lines of code? (Broken, as discussed above) - Features shipped? (Size and complexity vary enormously) - Story points? (Subjective, team-calibrated, not comparable across teams) - Revenue impact? (Most developers can't attribute their work to revenue) - Bugs prevented? (Immeasurable by definition) There is no universal unit of developer output, which means "10x" is undefined. It's not a measurement — it's a **feeling** dressed up as a number. ## What the Data Actually Reveals: The 3x Band When we control for role, language, team size, and project complexity, the variance narrows dramatically. Within a team of similarly-experienced developers working on the same codebase, the typical performance spread looks like this: | Metric | Bottom quartile | Median | Top quartile | Ratio (top/bottom) | |--------|:--------------:|:------:|:------------:|:------------------:| | Tasks completed per sprint | 3 | 5 | 8 | 2.7x | | Focus Time per day | 35 min | 72 min | 105 min | 3.0x | | Planning Accuracy | 0.42 | 0.62 | 0.78 | 1.9x | | Code review turnaround | 18 hours | 8 hours | 3 hours | 6.0x | | Consistency (CoV) | 0.55 | 0.30 | 0.15 | 3.7x | The real spread within comparable teams is roughly **2-3x**, not 10x. And much of that 2-3x is explained by environment, not talent: - The top-quartile developer has **fewer meetings** - They work on a **less fragile codebase** - Their tasks are **better defined** - They have **more autonomy** over their schedule ![Coding activity heatmap by hour and day](https://pandev-metrics.com/img/blog/activity-heatmap.png) *Activity heatmap from PanDev Metrics — the real picture of developer work patterns. Yellow blocks are active coding; gaps are meetings, context switches, and interruptions.* ## The Five Factors That Actually Create "10x" Gaps When you do see a 10x gap between two developers on the same team, it's almost always explained by these factors: ### 1. Meeting load inequality | Developer | Meetings/day | Available Focus Time | Effective coding | |-----------|:------------:|:-------------------:|:----------------:| | Developer A | 1 | 5+ hours | 120 min | | Developer B | 5 | 1.5 hours | 20 min | | **Apparent ratio** | | | **6x** | Developer A isn't "6x more talented." They have 6x more opportunity. ### 2. Codebase familiarity A developer who's worked on a codebase for 2 years navigates it 3-5x faster than a developer who joined last month. This isn't talent — it's institutional knowledge. It decays when the experienced developer leaves, which is another reason the "10x hire" narrative is dangerous. ### 3. Task assignment bias Senior developers often get the cleanest, most well-defined tasks. Junior developers get the ambiguous, cross-cutting, "nobody knows exactly what this should look like" tasks. Then we compare their output and conclude the senior is "10x." ### 4. Tooling and environment A developer with a fast CI pipeline, a reliable staging environment, and modern tooling will outproduce a developer fighting Docker configs, flaky tests, and 20-minute build times — regardless of individual skill. ### 5. AI augmentation gap With Cursor already at 24 users and 1,213 hours in our dataset, AI-augmented developers are producing code faster than non-augmented ones. This gap will only widen. Is a developer "10x" because they use Copilot and their teammate doesn't? That's a tooling decision, not a talent difference. ## Why the 10x Narrative Is Harmful ### It justifies underinvestment in teams "We don't need to fix the process — we just need better developers." This thinking leads to endless recruiting cycles instead of addressing systemic issues that make everyone on the team slower. Gerald Weinberg's *Quality Software Management* showed decades ago that context switching alone can destroy 20% or more of a developer's productive capacity — a systemic problem no individual hire can overcome. ### It creates toxic hero culture When you celebrate individual "rock stars," you devalue collaboration, code review, documentation, and mentoring — the activities that make the **team** better but aren't visible in individual metrics. ### It distorts compensation The belief in 10x developers leads to extreme compensation packages for perceived "stars" while undervaluing the solid mid-level developers who actually ship most of the product. ### It ignores force multiplication The most valuable senior developers don't produce 10x the code. They make **10 other developers** 20% more productive through good architecture, clear documentation, fast code reviews, and effective mentoring. That's a 2x team multiplier — far more valuable than any individual contributor. ## What CTOs Should Measure Instead If 10x is a myth, what should you actually track? | Instead of... | Track this... | Why | |---------------|--------------|-----| | Individual coding speed | **Team Delivery Index** | Team output matters more than individual speed | | "Rock star" identification | **Focus Time distribution** | Ensures everyone has the environment to do their best | | Hero-based planning | **Planning Accuracy** | Sustainable pace over individual sprints | | Hours coded | **Productivity Score** | Composite metric that includes quality and consistency | | Top performer | **Bottleneck detection** | Find what's slowing the team, not who's fastest | PanDev Metrics provides all of these as built-in metrics. The Productivity Score, for example, combines Activity Time, Focus Time, consistency, and delivery metrics into a single score that reflects sustainable performance — not just raw speed. ## The Real "10x": Environment Multipliers If you want 10x improvement, stop trying to hire 10x developers and instead **create a 10x environment**: | Multiplier | Potential improvement | How | |-----------|:--------------------:|-----| | Meeting reduction | 1.5-2x | Protect Focus Time blocks, async standups | | Task decomposition | 1.3-1.5x | Smaller tasks = better estimates = less rework | | CI/CD speed | 1.2-1.5x | Fast feedback loops reduce context switching | | Code review SLA | 1.2-1.3x | Unblock developers faster | | AI tooling | 1.3-2x | Cursor/Copilot for boilerplate, test generation | | **Combined** | **3-10x** | | A team working in a well-optimized environment with protected Focus Time, fast CI, AI tooling, and small well-defined tasks can absolutely produce 10x the output of a team drowning in meetings, fighting a legacy codebase, and waiting hours for code reviews. The 10x difference is real. It's just not about the developer — it's about the system. --- *Based on anonymized, aggregated data from PanDev Metrics Cloud (April 2026), thousands of hours of IDE activity across B2B engineering teams. References: Sackman, Erikson, Grant, "Exploratory Experimental Studies Comparing Online and Offline Programming Performance" (1968); Fred Brooks, "The Mythical Man-Month" (1975); Gerald Weinberg, "Quality Software Management: Systems Thinking" (1992); SPACE framework (Forsgren et al., ACM Queue, 2021).* **Want to build a 10x environment instead of hunting for 10x developers?** [PanDev Metrics](https://pandev-metrics.com) shows you where your team's time goes, what's blocking delivery, and how to create conditions for everyone to do their best work. --- ## Context Switching Kills Developer Productivity: Real Data on the 40% Loss URL: https://pandev-metrics.com/docs/blog/context-switching-kills-productivity Date: 2026-03-09 Tags: context-switching, developer-productivity, engineering-management, focus-time Description: Multi-project devs lose 40% of their day to context switching. We measured 100k+ engineers IDE time to show the real productivity loss — with statistics and fixes. Your senior developer is assigned to three projects. You assume they're giving each project a third of their time. Gerald Weinberg calculated the real math in *Quality Software Management* (1992): with three concurrent projects, each project gets about **20% of a developer's time** — and the remaining 40% evaporates into context switching overhead. This isn't speculation. It's a well-documented cognitive phenomenon, confirmed by our platform data across B2B engineering teams and consistent with Gloria Mark's research at UC Irvine showing 23 minutes of recovery time per interruption. Context switching is one of the most expensive invisible costs in software engineering. ## The Hidden Tax on Multi-Project Work Context switching — the cognitive cost of shifting between different tasks, codebases, or mental models — is software engineering's silent productivity killer. Unlike meetings (which show up on calendars) or outages (which trigger alerts), context switching is invisible. It doesn't appear in any project management tool. It has no Jira ticket. But it consumes a substantial portion of your team's capacity. Gerald Weinberg, in his book *Quality Software Management*, proposed a rule of thumb for the cost of context switching: | Number of simultaneous projects | % time per project | % time lost to switching | |:-------------------------------:|:------------------:|:------------------------:| | 1 | 100% | 0% | | 2 | 40% | 20% | | 3 | 20% | 40% | | 4 | 10% | 60% | | 5 | 5% | 75% | These numbers have been cited for decades. Microsoft Research studies on developer productivity have found similar patterns — developers working on multiple tasks simultaneously show measurably lower code quality and throughput. Let's see what actual IDE data says. ## What Thousands of Hours of IDE Data Reveal At PanDev Metrics, we track which projects developers are working on through IDE heartbeat data. When a developer switches from Project A's codebase to Project B's codebase, we see it. When they switch languages, we see that too. This gives us a ground-truth view of context switching that self-reported data can never provide. ### Finding 1: The average developer touches 2.3 projects per day Across our dataset, developers don't just work on one thing. The distribution looks like this: | Projects per day | % of developers | Avg. daily Focus Time | |:----------------:|:--------------:|:---------------------:| | 1 project | 31% | 92 min | | 2 projects | 38% | 71 min | | 3 projects | 19% | 48 min | | 4+ projects | 12% | 29 min | The correlation is stark: developers working on a single project per day achieve **3.2x more Focus Time** than those juggling four or more projects. And this isn't because single-project developers are more senior or more talented — it's because context switching is destroying the multi-project developers' ability to enter and maintain flow state. ### Finding 2: Each project switch costs 15-25 minutes When we analyze the gap between switching away from one project and reaching sustained coding activity in a new project, the average ramp-up time is significant: | Switch type | Avg. ramp-up time | Focus session quality after switch | |------------|:-----------------:|:----------------------------------:| | Same language, related project | 12 min | Good — shared mental models help | | Same language, unrelated project | 18 min | Medium — different architecture to load | | Different language, related domain | 22 min | Medium-low — syntax + domain switch | | Different language, unrelated project | 28 min | Low — full context reload required | Our top three languages — Java (2,107 hours), TypeScript (1,627 hours), and Python (1,350 hours) — are often used by the same developers across different projects. A developer switching from a Java backend to a TypeScript frontend within the same product incurs less overhead than one switching between completely unrelated codebases. ### Finding 3: Tuesday's productivity peak correlates with lower switching Tuesday is the peak coding day in our data. It also shows the lowest context-switching rate of any weekday: | Day | Avg. project switches per developer | Avg. Focus Time | Relative productivity | |-----|:-----------------------------------:|:--------------:|:---------------------:| | Monday | 3.2 | 68 min | Medium | | **Tuesday** | **2.1** | **89 min** | **High** | | Wednesday | 2.5 | 79 min | Medium-High | | Thursday | 2.8 | 74 min | Medium | | Friday | 3.0 | 62 min | Medium-Low | Monday has the most context switching (catching up after the weekend, sprint planning distributes work across projects). Tuesday benefits from Monday's coordination — developers know what to focus on and can commit to a single project for longer stretches. ![Coding activity heatmap showing fragmented work](https://pandev-metrics.com/img/blog/activity-heatmap.png) *Activity heatmap from PanDev Metrics — fragmented yellow blocks across multiple projects reveal the real cost of context switching throughout the day.* ## The Five Types of Context Switches Not all context switches are equal. Understanding the taxonomy helps you identify which ones to eliminate: ### Type 1: Project switching (highest cost) Switching between entirely different codebases. This requires unloading one mental model (architecture, data flow, naming conventions, tech stack) and loading another. Cost: **20-30 minutes** per switch. ### Type 2: Language switching (high cost) Moving between programming languages. Our data shows developers commonly switch between Java and TypeScript, or Python and TypeScript, within the same day. Even experienced polyglots lose time to syntax mode switching. Cost: **15-25 minutes**. ### Type 3: Task switching within a project (medium cost) Switching from feature work to bug fixing within the same codebase. The project context stays loaded, but the specific code area changes. Cost: **10-15 minutes**. ### Type 4: Tool switching (low-medium cost) Moving between IDE, browser, Slack, Jira, and terminal. Modern development requires constant tool switching, but it's lower cost because the mental model stays active. Cost: **5-10 minutes**. ### Type 5: Interruption-driven switching (variable cost) Someone asks a question on Slack. A PR review request arrives. A meeting starts in 5 minutes. These are the most damaging because they're **unplanned** — the developer didn't choose to switch, so there's no natural stopping point in their current work. Cost: **15-30 minutes** (aligns with Gloria Mark's interruption research). ## The Mathematics of Destruction Let's quantify the cost for a typical engineering team. ### Scenario: 8-person team, average multi-project load | Parameter | Value | |-----------|:-----:| | Team size | 8 developers | | Avg. projects per developer | 2.3 | | Avg. project switches per day | 2.8 | | Avg. cost per switch | 20 min | | Total daily switching cost | 56 min per developer | | Team daily switching cost | 7.5 hours | | **Monthly team switching cost** | **150 hours** | That's 150 hours per month — nearly a **full developer's monthly output** — lost to context switching overhead. Not to meetings. Not to bugs. Just to the cognitive tax of switching between projects. ### Comparison to median coding time Our median developer codes **78 minutes per day** — consistent with McKinsey's 2023 finding that developers spend only 25-30% of their time writing code. If 56 minutes are lost daily to context switching, the developer is spending **42% of their total available coding time** just ramping back up after switches. That means less than half of their coding effort is in sustained, productive flow. Cal Newport's *Deep Work* framework would classify this as entirely shallow work — never reaching the concentrated state where complex problem-solving happens. | Time allocation | Minutes per day | |----------------|:--------------:| | Available work time (excl. meetings) | ~360 min | | Non-coding work (email, Slack, reviews) | ~225 min | | Actual coding time | 78 min (median) | | Of which: context switching overhead | ~33 min | | **Sustained productive coding** | **~45 min** | Forty-five minutes of sustained, productive coding per day. That's what many developers are left with after meetings, communication, and context switching take their share. ## Strategies to Reduce Context Switching ### Strategy 1: Project days, not project hours Instead of splitting each day across multiple projects, assign developers to one project per day (or ideally, multi-day blocks). | Approach | Switches per week | Weekly Focus Time per developer | |----------|:-----------------:|:------------------------------:| | Daily multi-project (current) | 14 | 5.9 hours | | Half-day blocks | 10 | 6.8 hours | | Full-day blocks | 5 | 8.2 hours | | Multi-day blocks (2-3 days) | 2-3 | 9.1 hours | Multi-day project blocks reduce switching by 80% and increase weekly Focus Time by **54%** compared to daily multi-project work. ### Strategy 2: Reduce simultaneous project assignments The most effective change is the simplest: assign fewer concurrent projects. | Projects per developer | Management convenience | Developer productivity | |:----------------------:|:---------------------:|:---------------------:| | 1 | Low (requires more devs) | Maximum | | 2 | Medium | Good (20% loss) | | 3 | High | Poor (40% loss) | | 4+ | Maximum | Terrible (60%+ loss) | Engineering managers often assign developers to multiple projects because they believe it maximizes utilization. The data shows it does the opposite — it maximizes the **appearance** of utilization while destroying actual output. A developer assigned to three projects looks busy on all three but delivers less total work than if they focused on one at a time. ### Strategy 3: Group related work If multi-project work is unavoidable, minimize the cognitive distance between projects: - Same language, related domain → lowest switching cost - Frontend + backend of same product → medium cost - Completely unrelated codebases → highest cost When you must split a developer across projects, choose projects that share context: same tech stack, same domain, ideally same codebase repository. ### Strategy 4: Buffer meetings as switch boundaries If a developer must switch projects, schedule the switch around natural breaks — lunch, end of day, or after a meeting. Switching mid-flow is far more expensive than switching at a natural stopping point. | Switch timing | Context loss | Ramp-up time | |--------------|:------------:|:------------:| | Mid-flow (interrupted) | High | 25-30 min | | At natural break | Medium | 15-20 min | | After a meeting/lunch | Low | 10-15 min | | Start of day (new project) | Minimal | 5-10 min | ### Strategy 5: Measure and make visible You can't manage what you can't see. PanDev Metrics tracks project switches automatically through IDE data — no self-reporting needed. When the data is visible on team dashboards, both managers and developers become aware of switching costs and naturally start reducing them. The **cost per project** feature in PanDev Metrics helps quantify the true cost of splitting developer attention. When a manager can see that assigning Developer A to three projects costs 40% of their productive time, the decision to consolidate becomes obvious. ## The Organizational Challenge Reducing context switching isn't just an engineering decision — it's an organizational one. Product managers want "their" developer available on "their" project every day. Stakeholders want immediate responsiveness. Company culture often rewards visible busyness over actual output. ### Making the case to leadership | Argument | Data point | |----------|-----------| | "Multi-project work wastes capacity" | 150 hours/month lost for an 8-person team | | "Single-project focus is faster" | 3.2x more Focus Time for single-project developers | | "It's cheaper than hiring" | Reducing from 3 projects to 1 per developer is equivalent to adding 40% more engineers | | "Tuesday proves it" | Our highest-productivity day is also our lowest-switching day | ### The utilization trap The instinct to "fully utilize" every developer by assigning them to multiple projects comes from manufacturing thinking. In manufacturing, an idle machine is wasted capacity. In knowledge work, **idle time is thinking time** — and thinking is where design decisions, debugging insights, and architectural clarity happen. Brooks made this point in *The Mythical Man-Month*: software development is a creative, design-heavy activity, not an assembly line. A developer staring at the ceiling for 15 minutes might be solving a problem that saves three days of implementation time. A developer "fully utilized" across four projects never has those 15 minutes. ## How PanDev Metrics Helps PanDev Metrics provides several tools specifically designed to identify and reduce context switching: | Feature | How it helps | |---------|-------------| | **Activity Time by project** | Shows exactly how time is distributed across projects | | **Focus Time tracking** | Reveals whether developers achieve sustained coding sessions | | **Cost per project** | Calculates the true cost (including switching overhead) of each project | | **Gamification (XP/levels)** | Rewards sustained focus, not just total activity | | **Productivity Score** | Composite metric that penalizes high-variance, fragmented patterns | The gamification system is particularly relevant: developers earn more XP for sustained focus sessions than for fragmented activity. This creates positive incentive alignment — developers naturally protect their focus because it's visible and rewarded. ## Action Plan for Engineering Managers 1. **Audit project assignments this week.** List every developer and how many projects they're assigned to. If anyone has 3+, flag it. 2. **Implement project-day scheduling.** Start with your most senior developers first — they have the most complex context to switch and the highest cost of lost productivity. 3. **Track context switching for one month.** Use IDE-level data to establish your baseline switching rate and Focus Time. 4. **Present the cost to leadership.** Use the math: developer count × switches per day × 20 minutes × working days = monthly hours lost. Convert to dollars. 5. **Set a team target.** Aim for an average of 1.5 projects per developer per day or less. Monitor weekly. Context switching is the invisible tax on every multi-project engineering team. The data is clear: reducing it is the highest-leverage productivity improvement most teams can make. --- *Based on aggregated data from PanDev Metrics Cloud (April 2026), thousands of hours of IDE activity across B2B engineering teams. References: Gerald Weinberg, "Quality Software Management: Systems Thinking" (1992); Gloria Mark, "The Cost of Interrupted Work" (UC Irvine, 2008); Cal Newport, "Deep Work" (2016); Fred Brooks, "The Mythical Man-Month" (1975); McKinsey developer productivity report (2023).* **Want to see your team's context switching cost?** [PanDev Metrics](https://pandev-metrics.com) tracks project switches, Focus Time, and cost per project — giving you the data to eliminate your team's biggest invisible productivity drain. --- ## Remote vs Office Developers: What Thousands of Hours of Real IDE Data Tell Us URL: https://pandev-metrics.com/docs/blog/remote-vs-office-productivity Date: 2026-03-05 Tags: remote-work, developer-productivity, data, engineering-management, hybrid-work Description: The remote vs office debate lacks data. We analyzed thousands of hours of real IDE activity across 100+ B2B companies. Here's what we found. According to McKinsey's research on developer productivity, software engineers spend only 25-30% of their time actually writing code. So where developers work should matter far less than *how* their time is structured. Yet the remote vs. office debate has been running for six years, with CEOs citing "collaboration" and developers citing "focus" — both arguing from conviction, not evidence. We have thousands of hours of tracked IDE activity across 100+ B2B companies. The data tells a more nuanced story than either side wants to hear. ## Why Most Remote Work Studies Are Unreliable Before presenting our data, let's address why the existing research is so contradictory. ### The measurement problem Most "remote productivity" studies measure one of two things: | Study type | What they measure | Why it's flawed | |-----------|------------------|----------------| | Survey-based | Self-reported productivity perception | People overestimate their own output by 20-40% | | Output-based (LoC, PRs) | Raw volume metrics | Quantity ≠ quality; gaming is trivial | Neither approach captures what actually matters: **sustained, high-quality coding effort** measured objectively, at the individual level, across diverse companies. ### The selection bias Companies that embraced remote work early tend to be tech-forward, well-managed, and already good at async communication. Companies that mandate office presence tend to have different management styles. Comparing their outcomes tells you about **management culture**, not about where butts sit. ### The survivorship problem Remote developers who couldn't thrive remotely already returned to offices or left for different roles. The remote population in any study is pre-filtered for people who work well remotely — making remote look better than it "is" on average. ## Our Data: What IDE Activity Actually Shows PanDev Metrics collects IDE heartbeat data regardless of where the developer is located. We don't track GPS or location — we track coding activity. This means our data measures the **same thing** for remote and office developers: active time in the IDE, Focus Time sessions, project switches, and coding patterns. Here's what we observe across 100+ B2B companies: ### Coding time: Similar totals, different distributions | Metric | Remote-first companies | Office-first companies | Hybrid | |--------|:---------------------:|:---------------------:|:------:| | Median daily coding time | 82 min | 71 min | 78 min | | Mean daily coding time | 118 min | 102 min | 111 min | | Std. deviation | 68 min | 74 min | 71 min | Remote-first developers show slightly higher median coding time (82 min vs 71 min for office-first). But the difference is modest — **15% higher median**, not the 2x-3x difference that remote work advocates sometimes claim. The more interesting signal is in the standard deviation: office-first companies have **higher variance**, meaning their developers have a wider spread between low and high coders. This suggests that office environments help some developers (through osmotic learning and easy collaboration) while hindering others (through interruptions and meetings). ### Focus Time: Remote wins clearly | Focus Time metric | Remote-first | Office-first | Hybrid | |------------------|:------------:|:------------:|:------:| | Avg. Focus session length | 68 min | 42 min | 53 min | | Sessions > 90 min (% of all sessions) | 22% | 11% | 16% | | Longest daily session (avg.) | 94 min | 61 min | 74 min | This is where remote work shows its strongest advantage. Remote developers achieve Focus Time sessions that are **62% longer** on average than office developers. The percentage of deep work sessions (90+ minutes) is **double** for remote-first companies. The reason is straightforward: offices generate interruptions. Tap-on-the-shoulder questions, overheard conversations, ambient noise, and "got a minute?" requests all fragment focus. Remote developers can close Slack, put on headphones, and disappear into code. Office developers cannot. ### Day-of-week patterns: The Tuesday effect persists Both remote and office developers show Tuesday as the peak coding day, but the pattern differs: | Day | Remote-first productivity | Office-first productivity | |-----|:-------------------------:|:-------------------------:| | Monday | Medium-High | Medium (more meetings post-weekend) | | **Tuesday** | **Peak** | **Peak** | | Wednesday | High | Medium-High | | Thursday | Medium-High | Medium (meeting-heavy) | | Friday | Medium | Low-Medium | Office-first companies show a steeper decline from Tuesday to Friday, likely due to accumulating meeting overhead through the week. Remote companies maintain more consistent daily productivity. ### Late-hour coding: Remote developers work different hours | Time window | Remote-first activity share | Office-first activity share | |-------------|:--------------------------:|:--------------------------:| | 6–9 AM | 12% | 4% | | 9 AM–12 PM | 32% | 38% | | 12–2 PM | 8% | 12% | | 2–5 PM | 24% | 34% | | 5–8 PM | 16% | 9% | | 8 PM–12 AM | 8% | 3% | Remote developers spread their work across a wider time window. They start earlier, take longer midday breaks, and code more in the evening. Office developers concentrate work in the traditional 9-5 window. ![Working calendar settings showing standard work days and hours](https://pandev-metrics.com/img/blog/calendar-settings.png) PanDev's calendar settings let you define standard working hours for each team — critical for comparing remote vs office patterns against the expected 09:00-18:00 baseline. This pattern is consistent with findings from the *Accelerate* research (Forsgren, Humble, Kim), which shows that high-performing teams tend to optimize for flow over rigid schedules. Companies that force remote developers into 9-5 meeting schedules negate much of the remote Focus Time advantage. ## IDE and Language Patterns by Work Mode ### IDE adoption differs | IDE | Remote-first share | Office-first share | |-----|:------------------:|:------------------:| | VS Code | 62% | 54% | | Cursor | 18% | 8% | | IntelliJ IDEA | 12% | 22% | | Other JetBrains | 5% | 11% | | Visual Studio | 3% | 5% | Remote-first companies show notably higher adoption of **Cursor** (18% vs 8%). This aligns with a broader pattern: remote teams tend to adopt AI-assisted development tools earlier. The AI assistant partially compensates for the loss of "ask a colleague" moments that office developers rely on. Our overall data shows Cursor adoption growing rapidly, with usage disproportionately driven by remote-first organizations. The Stack Overflow Developer Survey has similarly documented faster AI tooling adoption among remote-heavy teams. ### Language distribution | Language | Remote-first hours share | Office-first hours share | |----------|:-----------------------:|:-----------------------:| | TypeScript | 32% | 21% | | Python | 24% | 16% | | Java | 14% | 28% | | C# | 4% | 12% | | Other | 26% | 23% | Remote-first companies lean heavily toward TypeScript and Python — languages associated with startups, web applications, and cloud-native development. Office-first companies have more Java and C# — languages dominant in enterprise and regulated industries. This is a confounding factor: **the industries that favor remote work also favor different tech stacks**. Some of the "remote productivity advantage" may actually be a "TypeScript/Python productivity advantage" — these languages have faster feedback loops, less boilerplate, and quicker iteration cycles. ## What the Data Does NOT Show ### It doesn't show that remote is "better" for everyone The 15% median coding time advantage for remote-first companies is real but modest. For some developers — especially juniors who benefit from mentorship, or those in noisy home environments — office work may be genuinely more productive. ### It doesn't show causation Companies that go remote-first may already have better engineering practices, stronger async cultures, and more disciplined meeting hygiene. The remote work may be a symptom of good management, not a cause of high productivity. ### It doesn't measure collaboration quality IDE data captures individual coding productivity. It doesn't capture the quality of design discussions, the speed of knowledge transfer, or the serendipitous conversations that sometimes produce breakthrough ideas. These are real benefits of co-location, even if they're hard to measure. ### It doesn't account for time zones Distributed remote teams spanning multiple time zones face coordination challenges that co-located teams don't. Our data doesn't isolate this variable, but it's a significant factor for remote-first companies with global teams. ## The Real Question: What Are You Optimizing For? The remote vs. office debate is often framed as a binary. The data suggests a more useful framework: | Priority | Favors | Why | |----------|--------|-----| | **Individual Focus Time** | Remote | 62% longer focus sessions, fewer interruptions | | **Junior developer onboarding** | Office (or structured hybrid) | Osmotic learning, immediate feedback | | **Synchronous collaboration** | Office | Same-time, same-room discussions are faster | | **Async documentation culture** | Remote | Forces writing things down, which scales | | **Developer satisfaction** | Flexible/hybrid | Most developers prefer choice | | **Cost optimization** | Remote | No office overhead, broader talent pool | The most effective approach for most organizations is **structured hybrid** — not "come in 3 days because we said so," but purposeful in-office time for activities that genuinely benefit from co-location (design sprints, retrospectives, team bonding) with remote time protected for focus work. ## Five Recommendations Based on the Data ### 1. Protect remote Focus Time religiously If you have remote developers, their biggest advantage is Focus Time. Don't destroy it with mandatory 9-5 availability, excessive Slack responsiveness expectations, or back-to-back video calls. Our data shows that remote developers who are treated like "office developers with cameras" lose their productivity advantage entirely. ### 2. Invest in async communication The companies in our data with the highest remote developer productivity have strong async cultures: written RFCs, recorded decision logs, detailed PR descriptions, and Slack threads instead of huddles. This takes discipline but pays dividends. ### 3. Don't compare raw numbers across modes A remote developer coding 82 minutes/day and an office developer coding 71 minutes/day may be delivering identical business value — the office developer might get more done in shorter sessions due to quick in-person clarifications, or the remote developer might spend more time on rework due to miscommunication. Compare **outcomes** (features shipped, quality metrics, planning accuracy) not just activity. ### 4. Use data, not ideology Too many return-to-office mandates are driven by executive belief, not measurement. If you're going to change work policy, **measure before and after**. Track Focus Time, coding time, and Delivery Index before the policy change, then compare 60 days later. Let the data decide. PanDev Metrics provides consistent measurement regardless of where developers work — the same IDE plugins, the same metrics, the same dashboards. This makes before/after comparisons methodologically sound. ### 5. Optimize the calendar, not the location Our data suggests that meeting load is a bigger determinant of productivity than location. A remote developer with 5 hours of Zoom calls is less productive than an office developer with 1 hour of meetings. Fix the calendar first, then worry about geography. | Meeting load | Remote coding time | Office coding time | |-------------|:------------------:|:------------------:| | < 1 hr/day | 105 min | 92 min | | 1–2 hr/day | 78 min | 72 min | | 2–3 hr/day | 52 min | 54 min | | 3+ hr/day | 28 min | 31 min | At high meeting loads (3+ hours), remote and office productivity **converge to the same low level**. The location advantage disappears entirely when the calendar is full. ## The Hybrid Reality The data paints a nuanced picture that neither remote absolutists nor office mandators want to accept: - **Remote work provides a real but moderate Focus Time advantage** (62% longer sessions) - **Total coding time differences are small** (15% median gap) - **The biggest productivity driver is meeting load**, not location - **Tech stack, company culture, and management practices** confound simple remote-vs-office comparisons - **Individual variation within each mode exceeds variation between modes** — some office developers outperform most remote developers, and vice versa The future of engineering productivity isn't about where developers sit. It's about whether they have the uninterrupted time, clear objectives, and proper tooling to do their best work — regardless of location. This conclusion aligns with the SPACE framework (Forsgren et al., 2021), which argues that productivity is multidimensional and cannot be reduced to a single environmental factor. --- *Based on aggregated, anonymized data from PanDev Metrics Cloud (April 2026). thousands of hours of IDE activity across 100+ B2B companies. Analysis based on company-level work mode policies (remote-first, office-first, hybrid) — individual developer locations were not tracked.* **Want to measure your team's real productivity — remote, office, or hybrid?** [PanDev Metrics](https://pandev-metrics.com) tracks IDE activity consistently across all work modes. Same plugins, same metrics, same truth — regardless of where your developers code. --- ## How to Run Data-Driven 1:1s With Your Developers URL: https://pandev-metrics.com/docs/blog/data-driven-one-on-one Date: 2026-03-02 Tags: engineering-management, one-on-one, developer-productivity, leadership Description: A practical guide to running effective 1:1 meetings with developers using real engineering data — templates, questions, and anti-patterns included. Gallup research consistently shows that manager quality is the single largest factor in employee engagement — yet most engineering managers run 1:1s the same way: "How are things going?" followed by an awkward silence, then a pivot to project status updates. That's not a 1:1 — that's a standup with extra steps. Real 1:1s should be the most valuable 30 minutes in your developer's week, and **data makes them dramatically better**. ## Why Most 1:1s Fail Let's be honest about the three failure modes: 1. **The Status Update** — You spend 25 minutes going through Jira tickets. The developer tells you things you could have read in a dashboard. Nobody grows. 2. **The Therapy Session** — Pure vibes, no structure. You ask "how are you feeling?" and get "fine." Neither of you knows what to do with the meeting. 3. **The Surprise Attack** — The developer hears feedback for the first time in months, and it's negative. No context. No data. Just opinions. Data-driven 1:1s fix all three. When you walk in with objective metrics, you can skip the status theater and go straight to the conversations that matter: growth, blockers, career development, and team dynamics. ## The Data You Actually Need Before a 1:1 You don't need a 50-metric dashboard. Here's what to pull before each 1:1: ### Core Metrics (5-minute prep) | Metric | What to Look For | Where It Helps | |--------|-------------------|----------------| | **Activity Time trend** (2 weeks) | Sudden drops or spikes | Detecting burnout or blockers | | **Focus Time** | Are they getting uninterrupted blocks? | Meeting load, context switching | | **PR cycle time** | How long from first commit to merge? | Process bottlenecks | | **Review participation** | Are they reviewing others' code? | Team collaboration | | **Current project allocation** | What are they actually working on? | Alignment with priorities | ### Context Metrics (when relevant) | Metric | When to Check | |--------|---------------| | **Delivery Index** | Before quarterly reviews | | **Cost per project** | When discussing project impact | | **Comparison to team average** | Only for context, never for ranking | The key principle: **use data to ask better questions, not to deliver verdicts**. As Will Larson writes in *An Elegant Puzzle*, the best engineering managers use metrics as conversation starters, not as scorecards. ## The Data-Driven 1:1 Framework Here's a practical framework that works for weekly 30-minute 1:1s. ### Phase 1: Open (5 minutes) Start with the human. This part is not data-driven, and that's intentional. - "What's on your mind this week?" - "Anything you want to make sure we cover today?" - "How's your energy level — 1 to 5?" This gives the developer control. If something urgent is burning, they'll tell you here and you can skip the rest of the framework. ![Employee metrics — Activity Time and Focus Time](https://pandev-metrics.com/img/blog/employee-metrics-safe.png) *PanDev Metrics employee dashboard — Activity Time (198h) and Focus Time (63%) cards give you the data foundation for a productive 1:1 conversation.* ### Phase 2: Data Review (10 minutes) Share your screen (or a printed summary) with the developer's metrics. Go through them **together** — this is collaborative, not evaluative. **Template conversation:** > "I noticed your Focus Time dropped from an average of 3.2 hours/day to 1.1 hours this past week. I see you were pulled into the payments project mid-sprint. What happened there?" > "Your PR cycle time has been consistently under 4 hours for the past month — that's great. Is there anything about the review process that's still frustrating you?" > "Activity Time shows Wednesday and Thursday were almost zero last week. Were you in meetings, doing design work, or something else?" **Rules for the data review:** 1. **Always ask before assuming.** Low coding time might mean architecture work, research, or mentoring — all valuable. 2. **Show trends, not snapshots.** One bad week means nothing. Three weeks of declining focus time means something. 3. **Compare to their own baseline**, not to other developers. Ever. 4. **Let them explain first.** Present the data, then ask an open question. ### Phase 3: Growth & Blockers (10 minutes) Now that you have a shared picture of reality, dig into what matters: **Blocker questions:** - "What slowed you down the most this week?" - "Is there a decision you're waiting on from someone?" - "Are there any tools or access issues I can fix for you?" **Growth questions:** - "What did you learn this week that was interesting?" - "Is there a skill you want to develop that you're not getting to practice?" - "Looking at your project allocation — is this the kind of work you want to be doing?" **Career questions (monthly):** - "Where do you want to be in a year? Are we making progress toward that?" - "What's the most impactful thing you've done this quarter? Let's make sure it's visible." ### Phase 4: Action Items (5 minutes) Every 1:1 should end with concrete commitments. Write them down in a shared doc. **Template:** | Owner | Action | Due | |-------|--------|-----| | Manager | Move Wednesday architecture sync to async | Next week | | Developer | Write ADR for the caching approach | Friday | | Manager | Talk to PM about reducing mid-sprint scope changes | Before next 1:1 | Review last week's action items at the start of this phase. If the same items keep rolling over, that's a signal. ## 1:1 Templates for Common Scenarios ### Template 1: The New Hire (First 90 Days) Focus: onboarding progress, comfort level, early wins. ``` Pre-meeting data pull: - Activity Time trend (is it ramping up?) - First PR cycle times (are reviews fast enough?) - Project allocation (are they on the right starter tasks?) Questions: 1. What surprised you most about the codebase this week? 2. Is the onboarding documentation accurate, or did you find gaps? 3. Who on the team has been most helpful? (Reveals team dynamics) 4. [Data] Your first PRs are getting reviewed in ~6 hours — is that fast enough, or are you blocked waiting? 5. What's one thing I could change to make your ramp-up faster? ``` ### Template 2: The Senior Developer Focus: impact, autonomy, technical direction. ``` Pre-meeting data pull: - Review participation (are they mentoring via code review?) - Focus Time (are they protected enough to do deep work?) - Cross-project involvement (are they spread too thin?) Questions: 1. What's the most important technical decision you made this week? 2. [Data] You reviewed 12 PRs this week — is that sustainable, or should we redistribute review load? 3. Is there a tech debt item that's silently costing us? 4. Are you getting enough time for deep technical work? 5. What should I be worried about that I'm not? ``` ### Template 3: The Struggling Developer Focus: support, clarity, specific improvement areas. ``` Pre-meeting data pull: - Activity Time (is it declining?) - Focus Time (are external factors blocking them?) - PR cycle time (stuck in review loops?) - Delivery trend (are commitments being met?) Questions: 1. How are you feeling about your work right now? (Open, honest) 2. [Data] I notice your delivery pace has slowed over the past three weeks. Walk me through what's happening. 3. Is the work clear enough? Do you know what "done" looks like? 4. What kind of support would help most — pairing, mentoring, fewer meetings, clearer specs? 5. Let's pick one specific thing to improve this week. What feels most important to you? IMPORTANT: Never ambush. If this is the first time you're raising performance concerns, the problem is your management, not their performance. ``` ### Template 4: The Pre-Promotion Check-in Focus: evidence gathering, gap identification. ``` Pre-meeting data pull: - 3-month trend across all metrics - Cross-team impact (reviews, mentoring) - Project complexity and delivery record - Cost efficiency of their projects Questions: 1. Let's look at your last quarter together. What are you most proud of? 2. [Data] Your Delivery Index has been consistently above team average for 3 months. Let's document specific examples. 3. For the next level, we need evidence of [specific competency]. Where are you demonstrating that already? 4. What's one gap we should close before the review cycle? 5. Who else should I talk to about your impact? ``` ## Anti-Patterns to Avoid ### 1. The Leaderboard Manager **What it looks like:** Ranking developers by Activity Time and sharing the ranking. "Alex coded 6 hours this week, why did you only code 2?" **Why it's toxic:** Activity Time doesn't measure value. A developer who spends 2 hours coding and 4 hours designing a system that saves the team weeks is more valuable than one who writes code all day that needs to be rewritten. **What to do instead:** Compare individuals to their own trends. Use team averages only as broad context. ### 2. The Gotcha Manager **What it looks like:** Saving up data surprises for the 1:1. "Three weeks ago, on Tuesday, you only coded for 15 minutes..." **Why it's toxic:** It breaks trust instantly. The developer feels surveilled, not supported. **What to do instead:** Address patterns in real-time via Slack when they're fresh. Use 1:1s for trends and deeper conversations. ### 3. The Dashboard Zombie **What it looks like:** Spending the entire 1:1 staring at charts. "Let's go through all 15 of your metrics one by one." **Why it's toxic:** It turns a human conversation into a reporting ceremony. The developer checks out mentally. **What to do instead:** Pick 2-3 relevant data points max. The data is the appetizer, not the main course. ### 4. The Metric Denier **What it looks like:** Refusing to use any data because "I trust my team." Running 1:1s purely on vibes. **Why it's broken:** Without data, feedback is based on recency bias, availability bias, and who is loudest. Quiet high performers become invisible. **What to do instead:** You can trust your team AND use data. Data isn't surveillance — it's shared context. ## Setting Up Your 1:1 Data Workflow Here's a practical workflow that takes less than 5 minutes of prep per developer: **Weekly routine (Monday morning, before 1:1 week starts):** 1. Open your engineering intelligence platform (PanDev Metrics or similar) 2. For each developer with a 1:1 this week: - Check Activity Time and Focus Time trend (30 seconds) - Check PR metrics and review activity (30 seconds) - Note any anomalies or patterns (30 seconds) 3. Write 2-3 data-informed questions in your 1:1 doc 4. Total prep time: ~2 minutes per developer **In the meeting:** - Share the dashboard briefly (or don't — just reference the data verbally) - Ask your prepared questions - Take notes on action items **After the meeting:** - Log action items in your shared doc - Set a reminder to check on blocker-removal commitments you made ## Measuring Whether Your 1:1s Are Working How do you know your data-driven 1:1s are actually better? Track these proxy signals: - **Developer satisfaction scores** — if you run engagement surveys, are 1:1-related questions improving? - **Action item completion rate** — are commitments being kept? On both sides? - **Surprise count** — how often do performance reviews contain surprises? (Target: zero) - **Retention** — developers rarely leave managers who invest in them with genuine, data-informed attention - **Developer self-awareness** — do your developers start referencing their own metrics proactively? The last one is the gold standard. When a developer walks into a 1:1 and says, "I noticed my Focus Time tanked this week because of the incident response rotation — can we talk about the on-call schedule?" — you've won. Research from the State of DevOps reports confirms that teams with strong feedback loops — including data-informed 1:1s — consistently outperform on both delivery speed and employee retention. ## Quick-Start Checklist If you want to start running data-driven 1:1s this week: - [ ] Set up access to your team's engineering metrics (Activity Time, Focus Time, PR cycle time at minimum) - [ ] Create a shared 1:1 doc per developer (Google Doc, Notion, whatever works) - [ ] Before your next 1:1, spend 2 minutes reviewing the developer's data - [ ] Prepare 2 data-informed questions (not accusations — questions) - [ ] In the meeting: share the data, ask the question, listen - [ ] End with written action items - [ ] Follow up on your commitments before the next 1:1 The bar is low. Most managers don't prepare at all. Two minutes of data review before a 1:1 puts you ahead of the vast majority of engineering managers. --- **Ready to make your 1:1s actually useful?** [PanDev Metrics](https://pandev-metrics.com) gives you per-developer dashboards with Activity Time, Focus Time, and delivery trends — everything you need for a 2-minute pre-meeting prep. Your developers get their own dashboards too, so the conversation starts from shared context. --- ## Performance Reviews Based on Data: Templates and Anti-Patterns URL: https://pandev-metrics.com/docs/blog/performance-review-data Date: 2026-02-27 Tags: engineering-management, performance-review, metrics, hr, leadership Description: How to run fair, data-backed performance reviews for engineers. Includes templates, calibration frameworks, and the anti-patterns that destroy trust. A Harvard Business Review analysis found that over 90% of managers admit their company's performance review process does not produce accurate results. In engineering, the problem is even worse: managers write vague paragraphs based on what they remember from the last two weeks. High performers who are quiet get overlooked. Loud underperformers get rated higher than they should. And everyone walks away feeling like the process was arbitrary. **Data fixes this** — but only if you use it correctly. ## The Problem With Traditional Engineering Reviews Let's name the biases that poison most review cycles: | Bias | What Happens | Example | |------|--------------|---------| | **Recency bias** | Only recent work is evaluated | A developer who shipped a major feature in Q1 but had a slow Q3 gets rated "needs improvement" | | **Availability bias** | Visible work counts more | The developer who presents in all-hands gets rated higher than the one who quietly fixes critical infrastructure | | **Halo effect** | One trait colors everything | "She's a great communicator" becomes "she's great at everything" | | **Similarity bias** | People like managers get rated higher | Extroverted developers get better reviews from extroverted managers | | **Anchoring** | Last year's rating persists | "He was a 3 last year, so he's probably a 3 this year" | Data doesn't eliminate bias — humans still interpret data — but it creates an objective foundation that's much harder to ignore or distort. This is consistent with research from the *Accelerate* program (Forsgren, Humble, Kim), which found that data-informed management practices correlate with both higher team performance and stronger organizational culture. ## What Data to Collect for Reviews A solid engineering review should draw from multiple data sources. No single metric tells the whole story. ### Quantitative Data (from your engineering platform) | Data Point | Time Range | Purpose | |------------|------------|---------| | **Activity Time trend** | Full review period | Baseline work patterns | | **Focus Time average** | Full review period | Deep work capacity and environment quality | | **Delivery Index** | Full review period | Consistency of delivery against commitments | | **PR cycle time** | Full review period | Workflow efficiency | | **Code review participation** | Full review period | Team contribution beyond own code | | **Project allocation** | Full review period | Scope and complexity of work | | **Cost per project** | Full review period | Business impact context | ### Qualitative Data (from humans) | Source | Method | Purpose | |--------|--------|---------| | **Peer feedback** | 360 survey or direct conversations | Collaboration, mentorship, influence | | **Self-assessment** | Written reflection | Developer's own perspective on impact | | **PM/Design feedback** | Cross-functional input | Communication, reliability, partnership | | **Customer impact** | Incident reports, feature adoption | Business outcomes | | **Manager observations** | 1:1 notes over the period | Growth, challenges, context | The formula is simple: **quantitative data shows what happened; qualitative data explains why it matters**. ![Employee metrics for performance review](https://pandev-metrics.com/img/blog/employee-metrics-safe.png) *PanDev Metrics employee view — Activity Time (198h) and Focus Time (63%) provide objective data points for fair performance evaluations.* ## The Data-Driven Review Template Here's a complete template for writing an engineering performance review backed by data. ### Section 1: Summary & Rating ``` Developer: [Name] Role: [Current title] Review Period: [Q1-Q2 2026 / Annual 2025-2026] Manager: [Your name] Overall Rating: [Exceeds / Meets / Below Expectations] One-paragraph summary: [2-3 sentences capturing the developer's overall performance, key accomplishments, and growth trajectory. This should be defensible with the data below.] ``` ### Section 2: Delivery & Impact ``` Key Metrics (review period): - Delivery Index: [X] (team avg: [Y]) - Projects completed: [list] - Estimated business impact: [revenue, cost savings, risk reduction] Highlights: - [Specific accomplishment #1 with data] - [Specific accomplishment #2 with data] - [Specific accomplishment #3 with data] Example: "Led the payment processing migration (Project Falcon) from legacy system to Stripe. Delivery Index of 0.92 for the project against a team average of 0.78. The migration reduced payment processing costs by 34% ($180K annual savings) and cut checkout errors by 60%." ``` ### Section 3: Technical Growth ``` Key Metrics: - PR cycle time trend: [improving / stable / declining] - Code review quality: [peer feedback summary] - Technical scope: [types of projects and complexity] Assessment: - [Technical skill area #1]: [Evidence-based assessment] - [Technical skill area #2]: [Evidence-based assessment] - [Architecture/design contributions]: [Specific examples] Example: "PR cycle time improved from 8 hours to 3.5 hours average over the review period, reflecting better PR sizing and clearer descriptions. Peer feedback consistently mentions thorough, constructive code reviews — reviewed 156 PRs across 4 teams." ``` ### Section 4: Collaboration & Leadership ``` Key Metrics: - Cross-team review activity: [X reviews outside own team] - Mentoring: [evidence from 1:1s, peer feedback] - Knowledge sharing: [docs, tech talks, pair programming] Assessment: [Narrative based on peer feedback and observable behaviors] Example: "Mentored two junior developers through their onboarding. Both ramped to independent contribution within 6 weeks (team average: 10 weeks). Peer feedback highlights patience and clarity in code review comments." ``` ### Section 5: Areas for Growth ``` Based on data and feedback, focus areas for next period: 1. [Area #1]: [Specific, evidence-based observation] Action plan: [Concrete steps] 2. [Area #2]: [Specific, evidence-based observation] Action plan: [Concrete steps] Example: "Focus Time averaged 1.2 hours/day vs. team average of 2.8 hours. Investigation shows high meeting load (12 recurring meetings/week) and frequent context switching between 4 concurrent projects. Action plan: Reduce recurring meetings to 6, limit concurrent projects to 2, establish Wednesday as a no-meeting deep work day." ``` ### Section 6: Goals for Next Period ``` Goal 1: [SMART goal tied to growth area] Measurable by: [Specific metric or milestone] Goal 2: [SMART goal tied to career progression] Measurable by: [Specific metric or milestone] Goal 3: [SMART goal tied to team/org impact] Measurable by: [Specific metric or milestone] ``` ## The Calibration Process Writing individual reviews is only half the battle. Calibration — the process of ensuring consistency across managers and teams — is where data becomes essential. ### Pre-Calibration Data Pack Before the calibration meeting, every manager should prepare: | Element | Details | |---------|---------| | **Rating distribution** | Proposed ratings for their team | | **Metrics summary** | Key metrics for each team member (anonymized for initial discussion if needed) | | **Outlier justification** | For anyone rated "Exceeds" or "Below" — specific data supporting the rating | | **Cross-team comparison** | How team metrics compare to org averages | ### Calibration Meeting Framework **Step 1: Present distributions (15 min)** Each manager shares their proposed rating distribution. Look for statistical red flags: - Is one manager rating everyone "Exceeds"? (Leniency bias) - Is another manager's team all "Meets"? (Central tendency bias) - Do distributions roughly follow expected patterns? **Step 2: Review outliers (30 min)** Focus on "Exceeds Expectations" and "Below Expectations" ratings. For each: - Manager presents the data case - Other managers challenge with questions - Group decides if the rating is calibrated **Step 3: Cross-team consistency (15 min)** Compare developers with similar ratings across teams: - Does a "Meets" in Team A look like a "Meets" in Team B? - Are the bar and expectations consistent? **Step 4: Finalize (10 min)** Lock ratings, note any follow-up actions. ### The Data Calibration Grid Use this grid to spot miscalibrations quickly: | Developer | Delivery Index | Focus Time | PR Cycle Time | Peer Score | Proposed Rating | |-----------|---------------|------------|---------------|------------|-----------------| | Dev A | 0.91 | 3.1 hrs | 3.2 hrs | 4.5/5 | Exceeds | | Dev B | 0.85 | 2.8 hrs | 4.1 hrs | 4.2/5 | Meets | | Dev C | 0.88 | 2.9 hrs | 3.0 hrs | 4.4/5 | Meets | | Dev D | 0.62 | 1.1 hrs | 12.3 hrs | 3.1/5 | Below | In this example, Dev C's data looks comparable to Dev A's — the calibration group should ask why the ratings differ. Maybe there's a valid qualitative reason. Maybe there's a bias at play. ## Anti-Patterns That Destroy Trust ### Anti-Pattern 1: The Metrics-Only Review **What it looks like:** "Your Activity Time was 2.1 hours/day. Team average is 2.8. Rating: Below Expectations." **Why it fails:** No context. The developer might have been doing architecture work, mentoring juniors, handling incidents, or dealing with a personal situation. Metrics without narrative are accusations. **Fix:** Every metric cited must be accompanied by a question or conversation. If you didn't discuss it in a 1:1 first, it doesn't belong in the review. ### Anti-Pattern 2: The Surprise Review **What it looks like:** The developer learns about performance issues for the first time during the review. **Why it fails:** It's too late to course-correct. The developer feels ambushed and the trust is broken permanently. **Fix:** If data shows a concerning trend, address it in 1:1s immediately. By review time, there should be zero surprises. ### Anti-Pattern 3: The Stack Rank **What it looks like:** Forcing a normal distribution. "We need exactly 10% Exceeds, 70% Meets, 20% Below." **Why it fails:** If you hired well, most people should be meeting expectations. Forcing a curve means you're lying about someone's performance — either inflating or deflating — to hit a quota. **Fix:** Rate against expectations for the role, not against each other. Use calibration to ensure consistency, not to force distribution. ### Anti-Pattern 4: The Copy-Paste **What it looks like:** "Continues to be a strong contributor. Meets expectations across all areas." — identical to last quarter. **Why it fails:** It tells the developer you didn't pay attention. It provides no growth guidance. It's demoralizing. **Fix:** Reference specific data from the review period. Cite project names, metric changes, and concrete examples. If you can't, you didn't observe enough during the period. ### Anti-Pattern 5: The Moving Goalpost **What it looks like:** "You shipped everything we asked for, but we expected you to also take on more leadership." **Why it fails:** You can't evaluate someone against criteria you never communicated. **Fix:** Set explicit expectations at the start of each review period. Write them down. Review them at mid-point. Evaluate against them — and only them — at the end. ## The Review Delivery Conversation Having good data and a well-written review is necessary but not sufficient. How you deliver it matters enormously. ### Before the Meeting - Share a self-assessment form at least a week before the review - Read the developer's self-assessment carefully before writing your final review - Prepare for disagreements — know which data points support your assessment ### During the Meeting 1. **Start with their self-assessment** (5 min): "How do you feel about your performance this period?" 2. **Share the overall rating** (2 min): Don't bury the lede. Say the rating early. 3. **Walk through evidence** (15 min): Go section by section through the review, referencing data 4. **Discuss growth areas** (10 min): Frame as investment, not criticism 5. **Set goals together** (10 min): Collaborative, not dictated 6. **Q&A** (remaining time): Let them ask anything ### After the Meeting - Share the written review document within 24 hours - Schedule a follow-up 1:1 within a week (they'll have questions after processing) - Track progress on growth goals in regular 1:1s ## Building a Review-Ready Data Culture If you want data-driven reviews to work, you need to build the infrastructure before review season: **Ongoing (not just at review time):** - Track engineering metrics continuously — don't try to reconstruct 6 months of data retroactively - Use 1:1s to discuss data regularly so it's normalized, not surprising - Collect peer feedback throughout the cycle, not just in a last-minute 360 **Per-cycle prep timeline:** | When | Action | |------|--------| | **Period start** | Set expectations and measurable goals with each developer | | **Monthly** | Quick data check per developer; course-correct in 1:1s | | **Mid-cycle** | Formal mid-point check-in with data review | | **Pre-review (2 weeks)** | Pull full-period metrics; collect peer feedback | | **Pre-review (1 week)** | Distribute self-assessment forms | | **Review week** | Write reviews; hold calibration; deliver | | **Post-review (1 week)** | Follow-up conversations; set next-period goals | ## A Fair Review Starts With Fair Data The entire framework above rests on one assumption: that your data is comprehensive and fair. This means: - **Measuring outcomes, not just outputs** — delivery impact, not just lines of code - **Accounting for invisible work** — code reviews, mentoring, incident response, documentation - **Recognizing role differences** — a staff engineer's metrics will look different from a junior developer's - **Transparency** — developers should be able to see the same data you're using to evaluate them The last point is critical. When developers have access to their own dashboards and can track their own metrics, the review becomes a conversation between two people looking at the same data — not a judgment handed down from above. As Will Larson argues in *An Elegant Puzzle*, the best review systems are ones where the outcome is already known to both parties before the meeting begins — because the data has been shared and discussed all along. --- **Build a review process your engineers actually trust.** [PanDev Metrics](https://pandev-metrics.com) provides per-developer dashboards with Activity Time, Focus Time, Delivery Index, and cost analytics — visible to both managers and developers. Export to Excel or PDF for review documentation. Start collecting the data now so your next review cycle is backed by evidence, not memory. --- ## How to Justify Hiring 5 More Developers to Your CFO URL: https://pandev-metrics.com/docs/blog/justify-hiring-to-cfo Date: 2026-02-25 Tags: engineering-management, hiring, leadership, cost-analytics, cto Description: A step-by-step guide for CTOs and VP Engs to build a data-backed business case for engineering headcount. Speak the CFO's language. Stripe's "Developer Coefficient" report estimated that companies worldwide lose over $300 billion annually due to developer inefficiency — much of it from understaffed teams fighting technical debt instead of shipping features. You need more engineers. Your team is overloaded, deadlines are slipping, and technical debt is piling up. You know this intuitively. But your CFO doesn't care about your intuition — they care about numbers, ROI, and risk. **The reason most headcount requests fail isn't that they're wrong. It's that they're argued in the wrong language.** ## Why "We're Overwhelmed" Doesn't Work Here's what the CFO hears when you say "we need 5 more developers": - **You hear:** "My team is at breaking point and we can't deliver the roadmap" - **CFO hears:** "I can't manage my team's capacity and I want to throw money at the problem" It's not fair, but it's reality. CFOs are trained to be skeptical of headcount requests because: 1. **Engineering is already the biggest cost center.** Developers are expensive. A CFO sees a $150K+ fully loaded cost per engineer and wants hard evidence before approving five more. 2. **They can't verify your claims.** When you say "we're at capacity," the CFO has no way to validate that. Are you really at capacity, or is there waste? 3. **Headcount is a permanent commitment.** Unlike a software license you can cancel, hiring someone is a long-term financial obligation. To win the headcount argument, you need to build a business case that addresses all three concerns with data. ![Departments overview showing team structure and employee counts](https://pandev-metrics.com/img/blog/dashboard-departments.png) The Departments view lets you break down headcount by team — giving the CFO a clear picture of where people are allocated and why you need more. ## Step 1: Prove Current Capacity Is Maxed Before asking for more people, you need to prove that your current team is running at full capacity — and that this capacity is well-utilized. ### The Data You Need | Metric | What It Shows | CFO Translation | |--------|---------------|-----------------| | **Activity Time per developer** | Hours of actual coding work per day | "Our developers are already working at maximum productive output" | | **Focus Time** | Uninterrupted deep work blocks | "We've already optimized their environment — there's no hidden slack" | | **Utilization rate** | % of available time spent on productive work | "We're running at X% utilization, above the sustainable threshold" | | **Overtime indicators** | Work outside business hours | "People are already working beyond normal hours to keep up" | ### How to Present It > "Our team of 20 developers currently averages 5.2 hours of productive work per day, with Focus Time of 2.8 hours. Industry benchmarks suggest this is in the 85th percentile for engineering productivity. We've already optimized meeting load and tooling — there's minimal slack left to capture." This preempts the CFO's first objection: "Can't you just make the current team more efficient?" **Key principle:** You're not saying "we work hard." You're saying "we've already optimized, and here's the data to prove it." ## Step 2: Quantify the Cost of Not Hiring This is where most CTOs fail. They talk about what they could do with more people. CFOs care more about **what it costs to not have them**. ### Revenue at Risk Calculate the revenue impact of delayed features: ``` Feature: Enterprise SSO Integration Blocked deals waiting for SSO: 8 Average deal size: $85,000 ARR Expected close rate with SSO: 60% Revenue at risk: 8 × $85,000 × 0.60 = $408,000 ARR Current timeline without new hires: Q4 2026 Timeline with 2 additional engineers: Q2 2026 Revenue acceleration: 6 months × $408,000/12 = $204,000 ``` ### Technical Debt Cost Quantify what technical debt is costing you right now: ``` Incident frequency (last quarter): 14 production incidents Average incident cost: - Engineer time per incident: 6 hours × 3 engineers = 18 hours - Fully loaded hourly cost: $95/hour - Cost per incident: $1,710 - Customer impact/compensation: ~$3,000 average Quarterly incident cost: 14 × ($1,710 + $3,000) = $65,940 Root cause: 9 of 14 incidents (64%) traced to legacy payment system that requires dedicated refactoring effort. Cost to fix: 2 engineers × 3 months = ~$95,000 Annual savings after fix: ~$190,000 (reduced incidents) ROI: 100% in first year ``` ### Opportunity Cost of Delayed Roadmap Map out the roadmap items being deferred and their expected impact: | Feature | Expected Impact | Current Delay | Cost of Delay | |---------|----------------|---------------|---------------| | Enterprise SSO | $408K ARR pipeline | 6 months | $204K delayed revenue | | API v2 | 40% reduction in support tickets | 4 months | $32K in support costs | | Mobile app | Access to new market segment | 8 months | $500K estimated first-year revenue | | Performance overhaul | 25% reduction in infrastructure costs | 6 months | $90K in excess AWS spend | **Total annual cost of not hiring: $826K** Compare this to the cost of 5 developers: ``` 5 developers × $150K fully loaded = $750K/year Net benefit in year 1: $826K - $750K = $76K positive Net benefit in year 2+: $826K (ongoing savings/revenue) ``` ## Step 3: Show the Hiring Plan, Not Just the Number CFOs hate vague requests. "We need about 5 engineers" sounds like a guess. A detailed plan shows rigor. ### Headcount Allocation Plan | Role | Team | Primary Project | Expected Impact | Start Date | |------|------|-----------------|-----------------|------------| | Senior Backend | Platform | Payment system refactor | Reduce incidents by 64% | Q2 2026 | | Senior Backend | Platform | API v2 | Reduce support tickets by 40% | Q2 2026 | | Mid Frontend | Product | Enterprise SSO | Unblock $408K pipeline | Q2 2026 | | Mid Full-stack | Product | Mobile app | New revenue channel | Q3 2026 | | DevOps/SRE | Infrastructure | Performance & reliability | Cut infra costs by 25% | Q2 2026 | ### Ramp-Up Timeline Show you've thought about the reality that new hires aren't productive on day one: | Month | Productivity Level | Effective Capacity Added | |-------|-------------------|------------------------| | Month 1 | 10% (onboarding) | 0.5 FTE | | Month 2 | 40% (ramping) | 2.0 FTE | | Month 3 | 70% (contributing) | 3.5 FTE | | Month 4 | 85% (independent) | 4.25 FTE | | Month 6+ | 100% (full capacity) | 5.0 FTE | This shows the CFO that you understand the investment curve and aren't promising instant results. ### Total Cost Breakdown Don't make the CFO guess — provide the full picture: | Cost Category | Per Developer | Total (5 devs) | |---------------|--------------|-----------------| | Base salary | $120,000 | $600,000 | | Benefits & taxes (25%) | $30,000 | $150,000 | | Equipment & tooling | $5,000 | $25,000 | | Recruiting (20% of salary) | $24,000 | $120,000 | | Onboarding (reduced productivity) | $15,000 | $75,000 | | **Total Year 1** | **$194,000** | **$970,000** | | **Total Year 2+** | **$155,000** | **$775,000** | **Year 1 ROI:** ($826K benefit - $970K cost) = -$144K (investment year) **Year 2 ROI:** ($826K benefit - $775K cost) = +$51K net positive, plus compound effects Be honest about year 1 being an investment. CFOs respect honesty more than inflated projections. ## Step 4: Address the Alternatives A smart CFO will ask: "Have you considered alternatives to hiring?" Have answers ready. ### Alternative 1: Outsourcing / Contractors | Factor | Full-time Hire | Contractor | |--------|---------------|------------| | Hourly cost | ~$75 (fully loaded) | ~$120-180 | | Ramp-up time | 3-4 months | 2-3 months | | Knowledge retention | Permanent | Lost when contract ends | | Cultural fit | Develops over time | Limited | | Best for | Core product work | Short-term, defined projects | **Your answer:** "For the payment system refactor and SSO — core, long-term product work — full-time hires are more cost-effective. I'd consider contractors for the mobile app prototype as a time-boxed project." > According to Forbes Kazakhstan, switching to hourly tracking based on real activity data can reduce labor costs by 25-30% — making data-driven capacity planning essential before requesting new headcount. — [Forbes Kazakhstan, April 2026](https://forbes.kz) ### Alternative 2: Reduce Scope **Your answer:** "Here's the roadmap with reduced scope. These are the features we'd cut and their revenue impact: [table]. The board approved this roadmap — cutting these items means revising revenue projections." ### Alternative 3: Improve Current Team Productivity **Your answer:** "We've already done this. Here's the data showing our productivity improvements over the past 6 months: [Activity Time increased 15%, Focus Time increased 22%, PR cycle time decreased 35%]. We're past the point of optimization gains." This is where having historical engineering metrics is powerful. McKinsey's research on developer productivity confirms that even high-performing teams reach an optimization ceiling — after which adding capacity is the only way to increase output. If you can show a trend of improving efficiency, it's proof that you've already tried the "do more with less" approach and hit that ceiling. ## Step 5: Present the Risk Scenario CFOs think in terms of risk. Give them a risk matrix: ### If We Hire (5 developers) | Risk | Probability | Impact | Mitigation | |------|-------------|--------|------------| | Hires underperform | Medium | Medium | 90-day performance check with data | | Revenue projections miss | Low | High | Conservative 70% realization factor already applied | | Team integration issues | Low | Low | Structured onboarding; team-specific mentors | ### If We Don't Hire | Risk | Probability | Impact | Mitigation | |------|-------------|--------|------------| | Key developers leave (burnout) | High | Critical | None — replacing them costs more than hiring new | | Roadmap delays compound | High | High | None — already operating at capacity | | Competitors ship first | Medium | Critical | None — can't accelerate without capacity | | Technical debt incidents increase | High | High | Reactive patching only (more expensive) | **The attrition argument is your strongest card.** Industry research, including data from the Society for Human Resource Management (SHRM), estimates the replacement cost for a senior technical role at 1.5-2x their annual salary — covering recruiting, ramp-up, and lost productivity. If you lose 2 seniors because you didn't hire 5 juniors/mids, the CFO has a much bigger problem. ## The One-Page Executive Summary After building the full business case, distill it into a one-page summary for the CFO meeting. This is what they'll actually read: ``` ENGINEERING HEADCOUNT REQUEST — Q2 2026 Requested: 5 engineers (2 Senior BE, 1 Mid FE, 1 Mid FS, 1 SRE) CURRENT STATE: - Team of 20, operating at 85th percentile productivity - 6 months of optimization already captured - Key roadmap items delayed 4-8 months BUSINESS IMPACT (ANNUAL): - Revenue at risk from delays: $612K - Technical debt cost: $264K - Infrastructure waste: $90K - Total cost of inaction: $826K/year INVESTMENT: - Year 1 cost: $970K (includes recruiting + ramp-up) - Year 2+ cost: $775K - Payback period: 14 months ALTERNATIVES CONSIDERED: - Contractors: More expensive for core work ($120-180/hr vs. $75) - Scope reduction: Requires board approval; $612K revenue impact - Further optimization: Data shows diminishing returns RISK IF WE DON'T HIRE: - 40% probability of losing 2+ senior developers to burnout - Replacement cost per senior: $225K-300K - Roadmap delays compound; competitor risk increases ``` ## The Presentation Tips A few tactical tips for the actual CFO conversation: 1. **Lead with the cost of inaction**, not the cost of hiring. "$826K at risk" lands harder than "$970K investment needed." 2. **Bring the data, not slides full of text.** Show the engineering metrics dashboard. Let the CFO see that these are real measurements, not estimates. 3. **Offer a phased approach.** "If 5 is too many at once, let's start with 3 in Q2 and 2 in Q3. Here's how the impact changes..." 4. **Show you track ROI.** "After hiring, I'll measure the impact on delivery speed, incident rate, and revenue acceleration quarterly." This signals accountability. 5. **Know your numbers cold.** The CFO will drill into specifics. If you can't answer "what's the fully loaded cost per engineer including overhead?" without hesitating, you'll lose credibility. ## After Approval: Close the Loop If you get the headcount, your job isn't done. Track and report the results: - **Month 3:** Ramp-up progress per new hire (use Activity Time and Delivery Index) - **Month 6:** First delivery milestones hit - **Quarter 2:** Revenue impact of unblocked features - **Year 1:** Full ROI analysis vs. business case projections This builds credibility for future requests. A CTO who says "last year I asked for 5 engineers, projected $826K in value, and we delivered $910K" will get their next headcount request approved much faster. --- **Build the business case that wins approval.** [PanDev Metrics](https://pandev-metrics.com) gives you the capacity data, cost analytics, and productivity trends you need to speak the CFO's language. Show real utilization numbers, track cost per project and per team, and prove ROI after every hire. --- ## The CTO Dashboard 2026: 12 Engineering Metrics That Belong on Your Top View URL: https://pandev-metrics.com/docs/blog/cto-dashboard Date: 2026-02-23 Tags: engineering-management, cto, metrics, dashboard, leadership Description: What every CTO needs to see daily: engineering velocity, cost per feature, on-call health, hiring funnel — and how to build the CTO dashboard in 2026. Gartner estimates that fewer than 30% of engineering leaders have effective visibility into their team's actual performance. Every CTO has a dashboard — most of them are useless. They're either crammed with dozens of charts that nobody reads, or they're a single graph of velocity that tells you nothing actionable. **A good CTO dashboard answers three questions: Are we delivering? Are we healthy? Are we improving?** Here's how to build one that actually works. ## The Three Layers of a CTO Dashboard Your dashboard needs to serve three different audiences at three different cadences: | Layer | Audience | Cadence | Time Spent | |-------|----------|---------|------------| | **Executive Layer** | CEO, CFO, Board | Monthly/Quarterly | 2 minutes | | **Leadership Layer** | You + VP Engs | Weekly | 10 minutes | | **Operational Layer** | You + EMs | Daily/On-demand | As needed | The mistake most CTOs make is showing the operational layer to executives. Your CEO doesn't need to see PR cycle time per team. They need to know if engineering is delivering on commitments and if the investment is paying off. ## Layer 1: The Executive Dashboard This is what you show at the weekly leadership meeting, board reviews, and quarterly business reviews. Maximum 6 metrics. If an executive needs more than 2 minutes to understand engineering's status, you've failed. ### Metric 1: Delivery Index (Org-wide) **What it is:** A composite score (0.0 to 1.0) measuring how consistently engineering delivers against its commitments. **How to read it:** - **0.85+** — Engineering is highly predictable. Commitments are being met. Leadership can plan around engineering timelines with confidence. - **0.65-0.85** — Normal operating range. Some variance, but generally on track. Investigate specific teams or projects that are pulling the average down. - **Below 0.65** — Delivery is unreliable. This is a leadership problem, not just a process problem. Dig into root causes: over-commitment, unclear requirements, technical debt, team instability. **What to say at the weekly:** > "Delivery Index is at 0.81, up from 0.76 last month. The Platform team pulled us down with the database migration running 2 weeks over — we've since re-scoped the remaining milestones. Product teams are at 0.88." ### Metric 2: DORA — Lead Time for Changes **What it is:** The time from first commit to production deployment, measured in 4 stages: coding, PR review, CI/CD, and deployment. **How to read it** (thresholds aligned with DORA benchmarks from the *Accelerate* State of DevOps research): - **Under 1 day** — Elite. You're deploying fast and your pipeline is healthy. - **1 day to 1 week** — High. Solid performance for most organizations. - **1 week to 1 month** — Medium. Bottlenecks exist — find them in the 4-stage breakdown. - **Over 1 month** — Low. Serious process or technical issues. This is a strategic risk. **What to say at the weekly:** > "Lead time is 18 hours on average. The bottleneck is code review at 8 hours — we've started a working group to address reviewer availability." ### Metric 3: Planning Accuracy **What it is:** How closely actual delivery matches planned delivery for the sprint/cycle. **How to read it:** - **Above 80%** — Strong planning discipline. Teams understand their capacity. - **60-80%** — Room for improvement. Likely over-committing or dealing with unplanned work. - **Below 60%** — Planning is broken. Either estimates are wildly off, or scope changes constantly. **What to say at the weekly:** > "Planning accuracy is 73% this sprint. The gap is mainly from the unplanned security patch that consumed 3 days of the backend team. Without the incident, we'd be at 86%." ### Metric 4: Productivity Score (Org-wide) **What it is:** A normalized score combining Activity Time, Focus Time, and output metrics to give an overall picture of engineering productivity. **How to read it:** Track the trend, not the absolute number. A rising trend means your investments in tooling, process, and team health are paying off. A declining trend is an early warning signal. **What to say at the weekly:** > "Productivity Score is up 7% quarter-over-quarter. We attribute this to the IDE upgrade and the new no-meeting Wednesday policy." ### Metric 5: Engineering Cost per Feature/Project **What it is:** Total engineering cost (salaries, infrastructure, tooling) allocated to specific projects or features. **How to read it:** This is the metric your CFO cares about most. It answers: "Are we spending our engineering budget on the right things?" **What to say at the weekly:** > "Project Falcon consumed $180K in engineering cost this quarter — on budget. Project Atlas is at $95K against a $70K budget due to scope expansion; we're flagging this for a scope review." ### Metric 6: Team Health Indicator **What it is:** A composite of signals including overtime patterns, attrition risk, and developer satisfaction. **How to read it:** - **Green** — Team is sustainable. Normal hours, stable composition, positive trends. - **Yellow** — Warning signs. Overtime increasing, or Focus Time declining, or one team is struggling. - **Red** — Intervention needed. Burnout signals, key person risk, or team instability. **What to say at the weekly:** > "Overall team health is green. One yellow flag: the Infrastructure team has shown increasing after-hours work for 3 weeks. I'm meeting with their manager to redistribute load." ![Admin panel showing user roles and access management](https://pandev-metrics.com/img/blog/admin-panel-detail.png) *PanDev Metrics admin panel — manage who has access to what: Owner, Maintainer, and Viewer roles give you granular control over dashboard visibility.* > "As a CTO and for our tech leads, it's important to see not individual employees but the state of the development process: where it's efficient and where it breaks down. The product allows natively collecting metrics right from the IDE, without feeling controlled or surveilled." > — Maksim Popov, CTO ABR Tech ([Forbes Kazakhstan, April 2026](https://forbes.kz)) ## Layer 2: The Leadership Dashboard This is what you review weekly with your VP Engs and senior managers. It goes deeper than the executive layer but stays strategic. ### Team-Level Breakdown | Team | Delivery Index | Lead Time | Planning Accuracy | Focus Time Avg | Health | |------|---------------|-----------|-------------------|---------------|--------| | Product - Web | 0.88 | 14 hrs | 82% | 3.1 hrs | Green | | Product - Mobile | 0.79 | 22 hrs | 71% | 2.4 hrs | Yellow | | Platform | 0.72 | 31 hrs | 65% | 2.8 hrs | Yellow | | Infrastructure | 0.91 | 8 hrs | 88% | 3.4 hrs | Yellow | | Data | 0.85 | 19 hrs | 77% | 2.9 hrs | Green | **How to read this table:** - Look for **outliers**, not averages. Platform team's lead time at 31 hours is the story here. - **Correlate metrics.** Mobile's low Focus Time (2.4 hrs) and low planning accuracy (71%) are likely related — too many interruptions are breaking their ability to deliver on commitments. - **Health yellow + good metrics** (like Infrastructure: 0.91 delivery but yellow health) means the team is delivering through unsustainable effort. This is the most dangerous pattern — it looks fine until someone quits. ### DORA 4-Stage Breakdown | Stage | This Week | Last Week | Trend | Target | |-------|-----------|-----------|-------|--------| | Coding Time | 6.2 hrs | 5.8 hrs | ↑ | < 8 hrs | | PR Review | 8.1 hrs | 7.4 hrs | ↑ | < 4 hrs | | CI/CD | 0.8 hrs | 0.9 hrs | ↓ | < 1 hr | | Deploy | 2.9 hrs | 3.1 hrs | ↓ | < 2 hrs | | **Total Lead Time** | **18.0 hrs** | **17.2 hrs** | **↑** | **< 15 hrs** | **How to read this:** - Coding time increasing slightly — check if PRs are getting larger (bad) or if features are more complex (context-dependent). - PR review is the bottleneck and getting worse. This needs a specific action: reviewer rotation? Smaller PRs? More reviewers? - CI/CD and deploy are healthy and improving — good. ### Investment Allocation Track where engineering time is actually going vs. where you planned: | Category | Planned % | Actual % | Delta | |----------|-----------|----------|-------| | New Features | 60% | 48% | -12% | | Technical Debt | 15% | 12% | -3% | | Bug Fixes | 10% | 18% | +8% | | Unplanned / Incidents | 5% | 14% | +9% | | Process / Meetings | 10% | 8% | -2% | **How to read this:** You planned to spend 60% on new features but only achieved 48%. The gap was eaten by bugs (+8%) and unplanned work (+9%). This is your argument for investing in quality and reliability — you're paying for it regardless, just in an uncontrolled way. ## Layer 3: The Operational Dashboard This is for your daily check-ins and deep dives. It's not for presenting — it's for investigating. ### What to Monitor Daily - **Deployment frequency** — are teams shipping, or is something stuck? - **Failed deployment rate** — if it spikes, something is wrong in CI or testing - **Active incidents** — what's on fire right now? - **PR queue depth** — are reviews backing up? ### What to Investigate Weekly - **Individual developers with anomalous patterns** — sudden drops in Activity Time, sustained low Focus Time - **Project cost vs. budget** — catch overruns early - **Cross-team dependencies** — are teams blocked waiting on each other? ### What to Review Monthly - **Department-level trends** — compare this month to last month across all key metrics - **Role-based analysis** — are senior developers spending too much time on reviews? Are juniors getting enough Focus Time? - **Hiring impact** — are new hires ramping up on schedule? ![Coding activity heatmap for operational monitoring](https://pandev-metrics.com/img/blog/activity-heatmap.png) *Activity heatmap from PanDev Metrics — the operational layer drill-down. Yellow blocks show active coding by hour and day, helping identify patterns without micromanaging.* ## How to Read Your Dashboard Without Micromanaging This is the hardest part. The temptation with a good dashboard is to react to every fluctuation. Don't. ### The 3-Week Rule Never act on a single week of data. Engineering work is inherently variable. A team might have low delivery one week because they're in a design phase, and that's perfectly healthy. **Pattern to act on:** Three consecutive weeks of the same trend direction. **Pattern to ignore:** One bad week followed by recovery. ### The Context Check Before flagging a metric to your team, always ask: "Do I know the context?" - Low Activity Time might mean a design sprint, offsite, or holiday week - High lead time might mean a deliberately careful rollout of a critical feature - Low planning accuracy might mean the team absorbed unplanned work that was strategically important **Rule:** Ask the EM for context before forming conclusions. Your dashboard tells you *what*; the EM tells you *why*. ### The Right Altitude | You see... | Wrong response | Right response | |------------|---------------|----------------| | One developer's Activity Time dropped | Message the developer | Note it; check if their EM is aware at your next sync | | A team's delivery dipped for 2 weeks | Demand an explanation in the all-hands | Ask the EM in your 1:1 | | Org-wide lead time has been rising for a month | Ignore it (it's just a metric) | Start a working group to investigate | | Cost per project is over budget | Cut the project | Review scope with the PM and EM; understand the overrun | ## Building Your Dashboard: A Practical Guide ### Step 1: Start With the Executive Layer Don't try to build all three layers at once. Start with the 6 executive metrics. If you can't answer "Are we delivering? Are we healthy? Are we improving?" — nothing else matters. ### Step 2: Add Team-Level Breakdown Once executive metrics are stable, break them down by team. This is your leadership layer. ### Step 3: Enable Self-Service for Operational Data EMs should be able to drill into their own team's data without asking you. Developer dashboards should be accessible to the developers themselves. Your operational layer should be primarily for cross-team and org-level investigation. ### Step 4: Automate Reporting Set up weekly automated reports: - **Monday:** Dashboard snapshot emailed to your leadership team - **Monthly:** Executive summary generated for the leadership meeting - **Quarterly:** Full report with trends for board review Generating Excel or PDF reports from your engineering intelligence platform saves hours of manual number-crunching. ### Step 5: Iterate Based on Questions The best dashboards evolve based on the questions people ask. If every weekly meeting includes "but what about X?" — add X to the dashboard. If nobody ever looks at metric Y — remove it. Aim for signal, not noise. ## The Weekly Meeting Flow Here's how to actually present your dashboard in a 15-minute weekly leadership slot: **Minutes 1-2: Executive Summary** "Delivery Index is 0.81. Lead time is 18 hours. Planning accuracy is 73%. We're on track with one yellow flag." **Minutes 3-5: The Story** "The story this week is unplanned work. We absorbed a critical security patch that cost us 3 days on the backend team. Without it, planning accuracy would be 86%. I've asked the security team to add a buffer to sprint planning for exactly this scenario." **Minutes 6-8: Team Highlight** "I want to call out the Mobile team — they've improved lead time from 35 hours to 22 hours over the past month by splitting their monolith deploy into feature-based releases." **Minutes 9-12: Decisions Needed** "Platform team's lead time at 31 hours is a concern. I'd like to propose dedicating 2 engineers to pipeline automation for 4 weeks. Expected impact: reduce lead time to under 20 hours." **Minutes 13-15: Questions** Open floor. This structure respects executive time, highlights what matters, and drives decisions. It's consistent with the approach Nicole Forsgren recommends in *Accelerate*: lead with outcomes, explain the story behind the data, then focus on what needs to change. --- **Get a CTO dashboard that actually works.** [PanDev Metrics](https://pandev-metrics.com) provides all three layers out of the box — executive summaries, team breakdowns, and operational drill-downs. With DORA metrics, Delivery Index, cost analytics, and role-based access, every stakeholder sees exactly what they need. Export weekly reports to PDF or Excel for your leadership meetings. --- ## Engineering Metrics Without Toxicity: How to Track Productivity Without Creating a Panopticon URL: https://pandev-metrics.com/docs/blog/metrics-without-toxicity Date: 2026-02-20 Tags: engineering-management, metrics, developer-experience, culture, leadership Description: How to implement engineering metrics that improve outcomes without destroying trust. A guide for CTOs and HR leaders who want data without surveillance. The Stack Overflow Developer Survey consistently shows that developer autonomy and trust are among the strongest predictors of job satisfaction — yet most metrics implementations ignore this entirely. On one side, leaders who want to understand and improve their teams' performance. On the other, developers who hear "we're implementing metrics" and immediately think "Big Brother." **Both sides have valid concerns.** The question isn't whether to measure — it's how to measure without destroying the culture you're trying to improve. ## The Toxicity Spectrum Not all metrics implementations are equal. Here's the spectrum from healthy to toxic: | Level | Description | Example | Impact | |-------|-------------|---------|--------| | **Healthy** | Team-level trends inform decisions | "Our team's Focus Time dropped — let's review the meeting calendar" | Positive: better environment | | **Cautious** | Individual data discussed collaboratively | "Your PR cycle time is up — what's blocking you?" | Neutral to positive if done with trust | | **Risky** | Individual rankings shared with management | "Here's the developer productivity leaderboard" | Negative: competition over collaboration | | **Toxic** | Metrics used punitively | "Your coding hours are below average — we need to discuss your performance" | Destructive: gaming, fear, attrition | | **Panopticon** | Always-on surveillance with consequences | Keystroke logging, screenshot capture, activity alerts to managers | Catastrophic: mass exodus | Most companies that fail with metrics jump straight to "Risky" or "Toxic" without realizing it. The difference between healthy and toxic often isn't which metrics you track — it's **how you use them**. ## Why Developers Fear Metrics (And Why They're Right) Let's take the developer perspective seriously, because it's grounded in real experience: ### Fear 1: "They'll reduce my work to a number" **Valid because:** Software development is creative, complex work. A developer who spends a week designing an elegant solution that prevents months of technical debt has created enormous value — but their "coding hours" that week might be near zero. **How to address it:** Never use a single metric in isolation. Always combine quantitative data with qualitative context. Make it explicit: "Activity Time tells us how much time you spent in the IDE, not how much value you created." ### Fear 2: "They'll use it to justify firing me" **Valid because:** It has happened. Companies have used monitoring tools to build cases for termination, circumventing proper performance management. **How to address it:** Establish a clear written policy: metrics data cannot be the sole basis for any disciplinary action. Period. Put it in the employee handbook. Have HR enforce it. ### Fear 3: "I'll be optimizing for the metric instead of doing my best work" **Valid because:** Goodhart's Law is real — and well-documented in engineering contexts. Stripe's "Developer Coefficient" research showed that a significant share of developer time is already lost to working around bad code. Adding metric-driven pressure can make this worse. If you reward lines of code, you get bloated code. If you reward PR count, you get tiny, meaningless PRs. **How to address it:** Never set individual targets for engineering metrics. Use metrics for observation and conversation, not for compensation or ranking. ### Fear 4: "It'll be used to compare me unfairly" **Valid because:** A staff engineer doing architecture work will have different Activity Time than a mid-level developer cranking out features. A developer on a legacy codebase will have longer PR cycle times than one on a greenfield project. **How to address it:** Compare individuals only to their own historical trends. Compare teams only to teams with similar contexts. Make this a hard rule. ## The Seven Principles of Non-Toxic Metrics Real-world experience confirms that metrics can work without toxicity. Here's how one CTO describes the approach: > "As a CTO and for our tech leads, it's important to see not individual employees but the state of the development process: where it's efficient and where it breaks down. The product allows natively collecting metrics right from the IDE, without feeling controlled or surveilled. Implementation was very simple." > — Maksim Popov, CTO ABR Tech ([Forbes Kazakhstan, April 2026](https://forbes.kz)) ### Principle 1: Transparency by Default Every developer should be able to see exactly the same data about themselves that their manager sees. No hidden dashboards. No secret reports. **Implementation:** - Give developers access to their own metrics dashboards - Show them the same views their managers use - If a manager can see a developer's Activity Time, the developer can see it too **Why it works:** Surveillance requires secrecy. When everything is visible, it's not surveillance — it's shared context. A developer who can see their own Focus Time trend is empowered to advocate for fewer meetings. A developer who discovers their manager is secretly tracking their keystrokes is looking for a new job. ![Admin panel showing user management with roles and access rights](https://pandev-metrics.com/img/blog/admin-panel-detail.png) The admin panel lets you control who sees what — assigning Owner, Maintainer, or Viewer roles ensures metrics visibility is transparent and appropriately scoped. ### Principle 2: Team Metrics Over Individual Metrics Default to showing team-level aggregates. Individual data should be accessible but never the primary view for leadership. **Implementation:** - Executive dashboards show department and team metrics only - Manager dashboards show team aggregates with ability to drill into individual data when investigating specific patterns - Individual dashboards are primarily for the developer themselves **Why it works:** Team-level metrics create collective ownership. "Our team's lead time is too long" is a problem everyone can work on. "Your lead time is too long" is an accusation. ### Principle 3: Context Before Conclusions Every metric anomaly has a story behind it. The data tells you *what* happened; only the person can tell you *why*. **Implementation:** - Never act on a metric without asking the person or team for context - Build "annotation" capabilities — let teams mark events (deployments, incidents, offsites) that explain metric changes - Train managers to lead with questions: "I noticed X — what's happening?" not "Your X is bad." **Why it works:** A developer whose Activity Time dropped to zero for two days might have been doing design work, attending a conference, handling a family emergency, or debugging a production issue that required reading logs, not writing code. Jumping to conclusions is toxic. Asking is not. ### Principle 4: Trends Over Snapshots A single data point is noise. A trend is a signal. Never react to a single measurement. **Implementation:** - Show all metrics with at least 4-week trend lines - Set alerts on sustained trends (3+ weeks), not individual data points - When discussing metrics in 1:1s, always show the trend chart, never a single number **Why it works:** Engineering work is inherently variable. Some weeks you write a lot of code; some weeks you review, plan, and design. Only sustained patterns indicate real issues or improvements. ### Principle 5: Metrics Inform Conversations, Not Decisions Data should generate questions, not answers. The answer always comes from the human conversation. **Implementation:** - No automated alerts to managers when individual metrics drop below thresholds - No automated performance flags based on metrics - Metrics feed into 1:1 agendas, not HR systems **Why it works:** When metrics directly trigger consequences (alerts, warnings, performance actions), people optimize for the metric. When metrics trigger conversations, people engage honestly with the underlying issues. ### Principle 6: Developers Own Their Data Developers should be able to use their own metrics to advocate for better working conditions, demonstrate impact, and guide their own growth. **Implementation:** - Personal dashboards that only the developer and their direct manager can see - Self-service data export so developers can use their metrics in self-reviews and promotion cases - Developer-facing features: "Your Focus Time is highest on Wednesdays and lowest on Tuesdays. Here's your meeting schedule on Tuesdays." **Why it works:** When metrics are a tool *for* developers rather than a tool *about* developers, adoption is natural. A developer who uses their own data to justify a schedule change is an empowered developer, not a surveilled one. ### Principle 7: Measure What Matters, Not What's Easy Lines of code, commit count, and hours logged are easy to measure but meaningless at best and harmful at worst. Measure outcomes and patterns that actually inform better decisions. **Implementation:** | Measure This | Not This | |-------------|----------| | Focus Time (uninterrupted blocks) | Hours logged | | Delivery Index (commitment vs. actual) | Story points completed | | Lead Time (commit to production) | Number of deployments | | Activity Time trends | Daily coding minutes | | Team health patterns | Individual productivity scores | ## The Rollout Playbook: How to Introduce Metrics Without Revolt ### Phase 1: Leadership Alignment (Week 1-2) Before showing anything to developers, align your leadership team: 1. **Define the purpose** — Write it down: "We're implementing engineering metrics to identify systemic bottlenecks and improve working conditions, not to evaluate individual performance." 2. **Set usage policies** — What data can be used in reviews? In promotions? In terminations? Get clear, get it in writing. 3. **Train managers** — Every manager who will see individual data needs training on the seven principles above. This is not optional. ### Phase 2: Developer Communication (Week 3) Hold an all-hands or team meetings (not an email — this deserves face time): 1. **Explain the why** — "We want to make better decisions about meetings, process, and tooling. We need data to do that." 2. **Show what you'll measure** — No surprises. List every metric and explain what it means. 3. **Show what developers will see** — Demo the developer dashboard. Show them their own data first. 4. **Explain what it won't be used for** — "This will not be used for individual performance rankings. This policy is in writing." 5. **Take questions** — Every single one. Honestly. If you don't have an answer, say so and commit to getting one. ### Phase 3: Soft Launch (Week 4-6) Roll out with guardrails: - Developers get their own dashboards first (before managers) - Managers see only team aggregates initially - No metrics appear in any reviews or evaluations during this period - Collect feedback actively — "Is anything about this making you uncomfortable?" ### Phase 4: Full Launch (Week 7+) Based on feedback from the soft launch: - Enable manager access to individual metrics (with the developer's knowledge) - Begin using team-level metrics in planning and retrospectives - Start incorporating data into 1:1 conversations (collaboratively, not evaluatively) - Monthly feedback check: "How are we doing with this?" ## What to Do When Metrics Reveal Problems The real test of non-toxic metrics comes when the data shows something concerning. ### Scenario: A Developer's Activity Time Drops Significantly **Toxic response:** Message the developer: "Your Activity Time dropped 60% this week. Please explain." **Non-toxic response:** Note it. Check if it's a one-week anomaly. If it persists for 2-3 weeks, bring it up in a 1:1 with genuine curiosity: "I noticed you've had less coding time recently — is everything okay? Are you working on something that doesn't show up in IDE time, like design or research?" ### Scenario: A Team's Delivery Index Is Consistently Low **Toxic response:** Rank the team members and identify the "low performers" dragging the team down. **Non-toxic response:** Look at the systemic factors. Is the team over-committed? Are requirements unclear? Is there technical debt slowing them down? Are they under-staffed? Discuss with the EM and the team together. The fix is almost always structural, not individual. ### Scenario: One Developer's Metrics Are Great, but Peer Feedback Is Negative **Toxic response:** Ignore the peer feedback because "the numbers look good." **Non-toxic response:** Recognize that metrics capture only one dimension of performance. A developer who ships fast but writes unmaintainable code, doesn't review others' PRs, or creates a hostile environment is not a high performer, regardless of what the Activity Time says. Metrics are a complement to, not a replacement for, human judgment. ## The Role of HR in Non-Toxic Metrics HR should be a partner in this, not an afterthought: ### HR Responsibilities 1. **Policy enforcement** — Ensure metrics usage policies are followed. If a manager uses Activity Time as the sole basis for a negative review, HR should flag it. 2. **Training** — Help develop and deliver manager training on ethical metrics usage. 3. **Feedback channel** — Provide a safe channel for developers to report concerns about how metrics are being used. 4. **Review integration** — Define how (and if) metrics appear in formal review processes. 5. **Legal compliance** — Ensure metrics collection complies with local labor laws and data protection regulations (GDPR and others). ### What HR Should NOT Do - Use engineering metrics to build termination cases independently - Create org-wide "productivity rankings" - Set minimum thresholds for individual metrics - Access individual developer data without a specific, documented reason ## The Long Game: Metrics as a Cultural Asset When done right, metrics become something developers actually want. Here's what mature, non-toxic metrics culture looks like: - **Developers proactively check their own dashboards** and bring insights to 1:1s - **Teams use metrics in retrospectives** to identify process improvements - **Managers use data to advocate for their teams** — "My team needs fewer meetings; here's the Focus Time data to prove it" - **Hiring conversations include metrics context** — "Here's the data showing we're at capacity" - **The word 'metrics' doesn't trigger anxiety** in the engineering org This doesn't happen overnight. It takes 3-6 months of consistent, principled usage. But once the trust is established, it's a genuine competitive advantage — because most engineering organizations are flying blind. The *Accelerate* research confirms this finding: teams that use metrics transparently and without punitive intent consistently rank among the highest performers in both delivery and culture. ## A Checklist for Ethical Metrics Implementation Use this checklist to audit your current (or planned) metrics program: - [ ] Developers can see all data collected about them - [ ] No individual metrics are used in compensation decisions - [ ] Managers are trained on ethical data usage - [ ] Written policy exists defining how metrics can and cannot be used - [ ] Team-level data is the default view for leadership - [ ] Individual data is used for 1:1 conversations, not rankings - [ ] Trends are emphasized over snapshots - [ ] Context is always sought before conclusions are drawn - [ ] HR has reviewed and approved the metrics program - [ ] Regular feedback is collected from developers about their experience - [ ] The metrics program has a documented purpose statement If you can't check all of these, you're not ready to implement engineering metrics. Fix the gaps first. --- **Measure engineering with trust, not surveillance.** [PanDev Metrics](https://pandev-metrics.com) is built on the principle that developers should see their own data. With role-based access control (from Admin to Developer), personal dashboards, and team-level aggregates for leadership, PanDev gives you engineering intelligence without the panopticon. On-premise deployment available for organizations that need full data control. --- ## Scaling Your Engineering Org From 10 to 100 With Data URL: https://pandev-metrics.com/docs/blog/scaling-10-to-100 Date: 2026-02-17 Tags: engineering-management, scaling, startup, cto, leadership, metrics Description: A data-driven playbook for CTOs scaling their engineering team from 10 to 100. What breaks at each stage and how metrics help you see it coming. As Matthew Skelton and Manuel Pais document in *Team Topologies*, the communication overhead between engineers grows quadratically: at 10 people there are 45 potential communication channels; at 100, there are nearly 5,000. At 10 engineers, you know everyone, you hear every conversation, you review most PRs. Things just work — because you're the glue holding it all together. At 100, that's impossible. The CTO who tries to manage 100 engineers the way they managed 10 will burn out, create bottlenecks, and watch quality collapse. **The transition from 10 to 100 is the hardest organizational challenge a startup CTO faces**, and data is the only way to navigate it without losing your mind. ## The Growth Phases (And What Breaks at Each One) Scaling doesn't happen linearly. There are phase transitions — points where the old way of working suddenly stops working and you need to restructure. ### Phase 1: The Squad (5-10 engineers) **How it works:** One team, one product, one codebase. Everyone talks to everyone. The CTO is the tech lead, architect, and manager. **What works at this stage:** - Informal communication (Slack, hallway conversations) - CTO reviews all code personally - Hiring is "hire great people, give them problems" - No formal process needed — velocity is high because overhead is zero **What data to track:** At this stage, you barely need formal metrics. But start collecting data early so you have a baseline when you scale. | Metric | Purpose at This Stage | |--------|----------------------| | Activity Time per developer | Establish individual baselines | | Lead Time (commit to deploy) | Set your performance benchmark | | Deployment frequency | Track how fast you ship | **The trap:** Everything is so smooth that you think process is unnecessary and data is overkill. Then you hire engineer #11, and the cracks appear. ![Teams management page](https://pandev-metrics.com/img/blog/teams.png) As you grow past 10 engineers, structured team management becomes essential for maintaining clarity and ownership. ### Phase 2: Two Teams (10-25 engineers) **How it works:** You split into 2-3 teams. You hire your first Engineering Managers (or promote senior developers). You still know everyone, but you can't be in every conversation. **What breaks:** - **Communication overhead explodes.** With 10 people, there are 45 communication channels. With 20, there are 190. Information stops flowing naturally. - **Coordination costs emerge.** Two teams working on the same codebase step on each other. The first integration conflicts appear. - **The CTO bottleneck.** If you're still reviewing all code and making all technical decisions, you're the bottleneck. **Critical data to start tracking:** | Metric | Why Now | |--------|---------| | **Focus Time per team** | Detect early communication overhead | | **PR cycle time** | Spot review bottlenecks as team splits | | **Delivery Index** | Measure if teams can deliver independently | | **Cross-team dependencies** | Track how often Team A blocks Team B | **What the data tells you:** If Focus Time drops after the team split, your team boundaries are wrong — people are spending too much time coordinating across teams instead of building within their team. If PR cycle time increases, you haven't established clear code ownership. PRs are sitting because the right reviewer isn't on the same team. **Actions:** 1. Hire or promote 2 Engineering Managers. Give them real authority — not the title without power. 2. Establish team boundaries aligned with product architecture — Conway's Law is real, and *Team Topologies* provides a practical framework for this alignment. 3. Implement basic sprint planning so teams can make and track commitments. 4. Start running 1:1s with data — you now have enough history to make them meaningful. ![Departments view](https://pandev-metrics.com/img/blog/departments.png) At the department stage, you need a dedicated view to manage multiple teams and their organizational hierarchy. ### Phase 3: The Department (25-50 engineers) **How it works:** 4-8 teams, organized into groups. You need a layer of management between you and the teams. Architecture decisions need formal processes. You can't personally onboard new hires anymore. **What breaks:** - **Knowledge silos form.** Teams develop their own conventions, tools, and tribal knowledge. Nobody has the full picture. - **Hiring quality varies.** Different managers have different bars. Without calibration, you get inconsistency. - **Planning becomes a nightmare.** Dependencies between teams mean one team's delay cascades to three others. - **Invisible work appears.** You can no longer see who's doing what. Quiet high performers become invisible; loud underperformers appear more productive. **Essential data at this stage:** | Metric | Purpose | |--------|---------| | **Delivery Index per team** | Compare team predictability | | **Planning Accuracy** | Measure organizational planning capability | | **Activity Time + Focus Time** | Detect overloaded teams and individuals | | **DORA metrics (full 4-stage)** | Identify pipeline and process bottlenecks | | **Cost per project** | Understand where engineering investment goes | | **Team health indicators** | Early warning on burnout and attrition risk | **What the data tells you:** At this scale, you're looking for **systemic patterns**, not individual issues: - If three teams all have low Focus Time, you have an organization-wide meeting problem, not a team problem - If Delivery Index varies wildly between teams (0.5 to 0.9), your planning process needs standardization - If cost per project is trending up without corresponding scope increases, you have growing coordination overhead - If DORA Lead Time is increasing quarter over quarter, your architecture or release process can't support your scale **Actions:** 1. Introduce VP Eng or Group EM roles to manage multiple teams. 2. Standardize engineering processes: PR guidelines, deploy practices, sprint cadence. 3. Implement formal onboarding — data shows new hires at 50+ person orgs take 30% longer to ramp without structured onboarding. 4. Start running calibration sessions for performance reviews. 5. Build your CTO dashboard (executive layer + leadership layer). ### Phase 4: The Organization (50-100 engineers) **How it works:** Multiple departments or divisions. Engineering Managers manage managers. You're setting strategy, not writing code. Culture is no longer something that "just happens" — it must be deliberately maintained. **What breaks:** - **Culture dilution.** Half the org has been there less than a year. They didn't absorb your values osmotically; they need explicit culture-building. - **Decision velocity drops.** More people means more stakeholders, more meetings, more alignment needed before anything ships. - **Metrics gaming appears.** As you grow, the incentive to look good on dashboards increases. People start optimizing for the metric, not the outcome. - **Inter-team politics emerge.** Teams compete for resources, priority, and recognition. Without objective data, the loudest team wins. **Data infrastructure at this stage:** | Capability | Purpose | |------------|---------| | **Department-level dashboards** | CTO-level visibility into each division | | **Team-level dashboards** | EM and VP Eng visibility into their teams | | **Developer dashboards** | Self-service data for every engineer | | **Automated reporting** | Weekly/monthly reports to leadership (Excel, PDF) | | **Role-based access control** | Right data to the right people (Admin, Maintainer, Manager, Viewer, Developer) | | **Cost analytics** | Per-project, per-team, per-employee cost tracking | | **AI-assisted analysis** | Pattern detection across the org that humans would miss | **What the data tells you at 100 engineers:** You're now looking at **organizational health and strategic alignment**: - Which departments are consistently delivering? Which are struggling? Why? - Are we spending our engineering budget on the right things? (Cost per project + strategic priority alignment) - Is our hiring keeping pace with demand? (Capacity utilization + delivery trends) - Are we losing people? Where? Why? (Health indicators + exit data) - Is our engineering efficiency improving or degrading as we scale? (Productivity Score trend) ## The Metrics That Matter at Each Phase Here's a consolidated view: | Metric | 10 eng | 25 eng | 50 eng | 100 eng | |--------|--------|--------|--------|---------| | Activity Time | Baseline | Per team | Per team + individual drill-down | Dept aggregate | | Focus Time | Nice to have | Important | Essential | Critical | | Lead Time | Baseline | Per team | 4-stage breakdown | By dept + team | | Delivery Index | Not needed | Per team | Per team + org | Per dept/team | | Planning Accuracy | Not needed | Start tracking | Essential | Critical | | Cost per project | Not tracked | Nice to have | Important | Essential | | Productivity Score | Not tracked | Not needed | Per team | Per dept + team | | Team Health | Gut feeling | 1:1 conversations | Composite indicator | Automated monitoring | | Role-based access | Everyone sees everything | 2 levels | 3 levels | 5 levels | ## Common Scaling Mistakes (And the Data That Catches Them) ### Mistake 1: Scaling Teams Too Late **Symptom:** One team of 12 developers with overlapping responsibilities and constant merge conflicts. **Data signal:** Focus Time declining, Lead Time increasing, and Delivery Index dropping — all simultaneously. The team is spending more time coordinating than building. **Fix:** Split the team earlier than you think you need to. The threshold is usually 6-8 developers per team. Watch Focus Time after the split — if it improves, you made the right call. ### Mistake 2: Promoting Without Training **Symptom:** Your best developer becomes a manager, stops coding, and is miserable. The team loses their best engineer and gains a bad manager. **Data signal:** The new manager's team shows declining metrics across the board in the first 2-3 months. Not because the team is bad, but because they're getting no support. **Fix:** Invest in management training before the promotion. Use data to help new managers — give them a dashboard and teach them how to use it in 1:1s. It's easier to learn management when you have objective data instead of relying on intuition you haven't developed yet. ### Mistake 3: Hiring Faster Than You Can Onboard **Symptom:** You hired 15 engineers in one quarter. Three months later, half of them are still struggling to make meaningful contributions. **Data signal:** New hire Activity Time ramp-up is much slower than historical baseline. Time-to-first-meaningful-PR is 2-3x longer than previous cohorts. **Fix:** Limit concurrent new hires to what your team can absorb. A good rule of thumb: no more than 1 new hire per 4-5 existing engineers per quarter. Use onboarding metrics to track ramp-up speed and identify where your onboarding process breaks down. ### Mistake 4: Ignoring Conway's Law **Symptom:** Your team structure doesn't match your architecture. The "Platform" team owns code that three product teams need to modify daily. **Data signal:** Cross-team PR reviews are high. Lead Time is inflated because PRs wait for reviews from other teams. Focus Time is low because of constant context switching between team priorities. **Fix:** Reorganize teams around architecture boundaries. Track cross-team dependencies and minimize them. When you see two teams constantly needing each other's code, either merge them or refactor the architecture. ### Mistake 5: No Visibility Into Costs **Symptom:** At 10 engineers, costs are simple: salaries plus AWS. At 50+, you have no idea which project is consuming what resources, and the CFO is asking uncomfortable questions. **Data signal:** You can't answer the question "how much did Feature X cost us?" and that's the data signal — the absence of data. **Fix:** Implement cost tracking per project and per team early. By the time you're at 50 engineers, this should be automated and part of your standard dashboard. ## The Scaling Timeline: A Realistic Roadmap Here's a quarter-by-quarter playbook for scaling from 10 to 100 over roughly 2 years: ### Quarters 1-2 (10 → 20 engineers) | Action | Data Required | |--------|---------------| | Hire first 2 EMs | Activity Time baselines to hand off | | Split into 2-3 teams | Team-level Focus Time and Lead Time to validate split | | Implement basic sprint planning | Start tracking Planning Accuracy | | Begin regular 1:1s with data | Per-developer Activity Time and Focus Time | | Establish coding standards | PR cycle time baseline | ### Quarters 3-4 (20 → 40 engineers) | Action | Data Required | |--------|---------------| | Add 2-3 more teams | Cross-team dependency tracking | | Hire/promote VP Eng or Group EM | Department-level dashboards | | Standardize engineering processes | DORA metrics to benchmark | | Implement structured onboarding | New hire ramp-up metrics | | Start performance calibration | Delivery Index and peer data | | Implement cost tracking | Per-project cost analytics | ### Quarters 5-6 (40 → 70 engineers) | Action | Data Required | |--------|---------------| | Full management hierarchy in place | Role-based access control for dashboards | | Architecture review board | Lead Time by team to spot structural issues | | Formal career ladders | Metrics integrated into review frameworks | | Automated reporting | Weekly team reports, monthly exec reports | | Dedicated recruitment team | Capacity utilization data for hiring justification | ### Quarters 7-8 (70 → 100 engineers) | Action | Data Required | |--------|---------------| | Multiple departments/divisions | Department-level analytics | | Engineering-wide OKRs | Planning Accuracy and Delivery Index per OKR | | Internal developer platform | Developer self-service dashboards | | Data-driven budgeting | Cost per team, per project, per employee | | AI-assisted analysis | Org-wide pattern detection | | Culture programs | Team health monitoring at scale | ## The CTO's Evolving Role As you scale, your job changes fundamentally. Data helps you manage each transition: | Scale | CTO Role | How Data Helps | |-------|----------|---------------| | 10 | Tech Lead + Manager | Baseline data collection; personal code review | | 25 | Architect + People Leader | Team dashboards replace personal observation | | 50 | Strategy + Organization | Department dashboards drive structural decisions | | 100 | Executive + Culture | Organizational analytics inform company strategy | The hardest part isn't the metrics — it's letting go. Will Larson captures this well in *An Elegant Puzzle*: the CTO's job is to build systems that make their own involvement unnecessary. At 10 engineers, you knew everything. At 100, you need to trust your data, your managers, and your systems. The data isn't a replacement for trust; it's what makes trust possible at scale. --- **Scale with confidence, not chaos.** [PanDev Metrics](https://pandev-metrics.com) grows with your engineering org — from startup to enterprise. With department and team management, role-based access (Admin, Maintainer, Manager, Viewer, Developer), per-developer dashboards, cost analytics, and AI-assisted insights, you get the visibility you need at every stage of growth. Available on-premise or cloud. --- ## OKRs for Engineering Teams: Templates That Actually Work (2026 Examples) URL: https://pandev-metrics.com/docs/blog/okr-engineering Date: 2026-02-16 Tags: engineering-management, okr, metrics, leadership, planning Description: Engineering OKR templates that ship: how to align dev velocity with business metrics. Real examples from 50+ teams running OKRs in 2026 — with sample dashboards. McKinsey research on engineering effectiveness found that the highest-performing organizations share one trait: their engineering goals are explicitly connected to business outcomes. Yet most engineering teams write OKRs like "Improve code quality" with a key result of "Increase test coverage to 80%." That's not an OKR. That's a task with a number next to it. **Good engineering OKRs connect technical work to business outcomes**, and the right metrics make them actually measurable. ![Team dashboard providing real-time visibility into engineering OKR progress](https://pandev-metrics.com/img/blog/dashboard-clean.png) *Team dashboard providing real-time visibility into engineering OKR progress.* ## Why Engineering OKRs Fail Before writing good OKRs, let's understand why most engineering OKRs are bad. ### Failure Mode 1: Output OKRs ``` Objective: Improve engineering productivity KR1: Close 150 Jira tickets per sprint KR2: Increase deployment frequency to 5x/week KR3: Reduce average PR size to under 200 lines ``` **Why it fails:** These are outputs, not outcomes. You can close 150 tickets by splitting one task into 150 subtasks. You can deploy 5x/week by deploying trivial changes. You can reduce PR size by creating meaningless micro-PRs. None of this creates value. ### Failure Mode 2: Activity OKRs ``` Objective: Invest in technical excellence KR1: Conduct 4 tech talks per quarter KR2: Each developer spends 20% time on tech debt KR3: Complete 3 architecture documents ``` **Why it fails:** These are activities, not results. You can conduct 4 terrible tech talks. You can spend 20% on tech debt that doesn't matter. You can write architecture documents nobody reads. Where's the outcome? ### Failure Mode 3: Unmeasurable OKRs ``` Objective: Build a world-class engineering culture KR1: Improve developer happiness KR2: Attract top talent KR3: Be recognized as an engineering-led company ``` **Why it fails:** How do you know when you've succeeded? "Improve developer happiness" — by how much? Measured how? "Attract top talent" — what's top talent? How many? These are wishes, not key results. ### Failure Mode 4: Irrelevant OKRs ``` Objective: Modernize the tech stack KR1: Migrate 100% of services to Kubernetes KR2: Adopt TypeScript across all frontend projects KR3: Implement GraphQL for all APIs ``` **Why it fails:** Maybe all of these are good technical decisions. But the OKR doesn't explain why any of it matters to the business. If the CEO asks "why should I care about Kubernetes?" and you can't answer with a business outcome, the OKR is irrelevant. ## The Framework: Outcome-Driven Engineering OKRs Good engineering OKRs follow a framework: ``` Objective: [Business or user outcome that engineering enables] Key Result 1: [Measurable change in a metric that proves progress] Key Result 2: [Measurable change in a different dimension] Key Result 3: [Measurable change that prevents unintended consequences] ``` **The key principles:** 1. **Objectives describe outcomes**, not activities. "Reduce customer-facing downtime" not "Improve infrastructure." 2. **Key Results are measurable and time-bound.** "Reduce P1 incidents from 6/quarter to 2/quarter" not "Reduce incidents." 3. **At least one KR prevents gaming.** If your objective is speed, include a quality KR. If your objective is quality, include a delivery KR. 4. **Engineering OKRs connect to company OKRs.** If the company objective is "Expand to enterprise market," the engineering OKR might be about reliability (enterprise customers demand 99.9% uptime) or security (SOC2 compliance). ## Engineering OKR Templates Here are complete, usable OKR templates for common engineering objectives. Adapt the specific numbers to your context. ### Template 1: Delivery Speed **When to use:** The business needs engineering to ship faster — product roadmap is bottlenecked by engineering capacity or process. ``` Objective: Accelerate feature delivery to support Q3 revenue targets KR1: Reduce average Lead Time from commit to production from 5 days to 2 days Measured by: DORA Lead Time (4-stage breakdown) KR2: Increase Planning Accuracy from 65% to 80% Measured by: Sprint commitment vs. actual delivery KR3: Maintain or improve change failure rate (currently 8%, target ≤ 8%) Measured by: DORA Change Failure Rate Why KR3 exists: Prevents gaming KR1 by shipping untested code. If speed increases but quality drops, the OKR isn't met. ``` **How to track progress:** | Week | Lead Time | Planning Accuracy | Change Failure Rate | On Track? | |------|-----------|-------------------|---------------------|-----------| | 1 | 4.8 days | 67% | 7% | Starting | | 4 | 4.1 days | 71% | 8% | Yes | | 8 | 3.2 days | 75% | 7% | Yes | | 12 | 2.1 days | 79% | 6% | Achieved | ### Template 2: Reliability & Uptime **When to use:** Customer trust is at stake, or you're moving upmarket to enterprise customers who demand SLAs. ``` Objective: Achieve enterprise-grade reliability to close the Fortune 500 pipeline KR1: Reduce P1 production incidents from 6/quarter to 2/quarter or fewer Measured by: Incident tracking system KR2: Improve mean time to recovery (MTTR) from 4 hours to under 1 hour Measured by: Incident resolution timestamps KR3: Achieve 99.95% uptime for core customer-facing services Measured by: Monitoring and SLA tracking KR4: Ship at least 85% of planned roadmap features (Delivery Index ≥ 0.85) Measured by: Delivery Index from sprint tracking Why KR4 exists: Prevents "we can't ship anything because we're focused on reliability." Reliability AND delivery must coexist. ``` ### Template 3: Developer Productivity **When to use:** Engineering feels slow but you're not sure why. Teams are busy but output doesn't match effort. ``` Objective: Remove systemic blockers so engineers can do their best work KR1: Increase average Focus Time from 1.8 hours/day to 3.0 hours/day across engineering Measured by: Focus Time metric (engineering platform) KR2: Reduce average PR review time from 12 hours to 4 hours Measured by: PR cycle time (review stage) KR3: Improve developer satisfaction score from 6.2/10 to 8.0/10 on "I have enough uninterrupted time to do deep work" Measured by: Quarterly developer survey Why this works: KR1 is the quantitative measure, KR3 is the qualitative validation. If Focus Time improves but developers don't feel the difference, something is wrong with the measurement or the intervention. ``` **Specific initiatives that might achieve these KRs:** | Initiative | Expected Impact on KRs | |-----------|----------------------| | No-meeting Wednesdays | KR1: +0.5 hrs Focus Time on Wednesdays | | Auto-assign PR reviewers | KR2: -3 hrs review wait time | | Reduce recurring meetings by 30% | KR1: +0.3 hrs Focus Time org-wide | | Improve CI pipeline speed | KR2: indirect (faster feedback loops) | Note: The initiatives are *how* you achieve the OKR, not the OKR itself. The OKR is the outcome. Track both. ### Template 4: Technical Debt Reduction **When to use:** Technical debt is measurably impacting delivery speed, reliability, or developer experience. ``` Objective: Eliminate the technical debt that's slowing down feature delivery KR1: Reduce deployment time for the monolith from 45 minutes to under 10 minutes Measured by: CI/CD stage in Lead Time breakdown KR2: Reduce time spent on bug fixes from 25% of engineering capacity to under 15% Measured by: Project/category allocation tracking KR3: Improve Lead Time for the Platform team from 8 days to 3 days (the team most affected by debt) Measured by: Team-level Lead Time Why this works: Instead of "reduce tech debt" (unmeasurable), these KRs target the specific impacts of tech debt: slow deployments, high bug load, slow delivery. Fix the impacts, and you've fixed the debt that matters. ``` ### Template 5: Scaling & Growth **When to use:** You're hiring rapidly and need to ensure the organization scales without losing efficiency. ``` Objective: Scale engineering from 40 to 65 developers without losing delivery efficiency KR1: Maintain Delivery Index above 0.80 org-wide throughout the hiring period Measured by: Delivery Index trend KR2: New hires reach productive contribution (Activity Time within 20% of team average) within 8 weeks Measured by: New hire ramp-up tracking KR3: Keep engineering cost per delivered feature within 10% of pre-hiring baseline (adjusted for team size) Measured by: Cost per project analytics KR4: Maintain Productivity Score within 5% of pre-hiring baseline during scaling Measured by: Org-wide Productivity Score Why KR3 and KR4 exist: Hiring more people doesn't help if each person delivers proportionally less. These KRs ensure you're scaling output, not just headcount. ``` ### Template 6: Security & Compliance **When to use:** SOC2 audit, enterprise customer requirements, or proactive security investment. ``` Objective: Achieve SOC2 Type II compliance to unblock enterprise sales pipeline KR1: Zero critical or high-severity security findings in the SOC2 audit Measured by: Audit report KR2: Reduce average time-to-patch for critical vulnerabilities from 14 days to 48 hours Measured by: Vulnerability tracking system KR3: 100% of production deployments pass automated security scanning Measured by: CI/CD pipeline enforcement KR4: Deliver all planned Q3 features on schedule (Planning Accuracy ≥ 75%) Measured by: Planning Accuracy metric Why KR4 exists: Security work often becomes an excuse for not delivering features. This KR ensures security improvements don't come at the cost of all other work. ``` ## How to Set the Right Targets The hardest part of writing OKRs is choosing the right numbers. Too easy and they're not ambitious. Too hard and they're demoralizing. ### The Baseline Method 1. **Measure the current state** — you can't set a target without knowing where you are 2. **Research benchmarks** — what do similar organizations achieve? 3. **Set a stretch target** — aim for 70% achievement probability (Google's recommendation) **Example:** ``` Current Lead Time: 5 days Industry benchmark (DORA "High"): 1 day to 1 week Stretch target: 2 days (60% improvement) Comfortable target: 3 days (40% improvement) Chosen target: 2 days (ambitious but achievable in one quarter with focused investment) ``` ### The "So What" Test For every KR, ask: "If we achieve this, so what? What changes for the business?" | KR | "So What?" | Valid? | |----|-----------|--------| | Reduce Lead Time to 2 days | Features reach customers faster, competitive advantage | Yes | | Increase test coverage to 80% | ??? | Not unless tied to an outcome | | Reduce P1 incidents to 2/quarter | Better uptime, fewer customer complaints, less firefighting | Yes | | Migrate to Kubernetes | ??? | Not unless tied to deployment speed or cost reduction | If you can't answer "so what?" with a business outcome, the KR isn't ready. ## Aligning Engineering OKRs With Company OKRs Engineering doesn't exist in a vacuum. Here's how to cascade company objectives into engineering OKRs: ### Example: E-Commerce Company **Company Objective:** Grow revenue by 40% YoY | Company KR | Engineering OKR Connection | |-----------|--------------------------| | Launch mobile app by Q3 | Eng Objective: Deliver mobile app MVP. KRs: feature completeness, performance, launch date | | Reduce churn by 20% | Eng Objective: Improve reliability. KRs: uptime, incident count, page load time | | Expand to 3 new markets | Eng Objective: Enable internationalization. KRs: i18n framework, launch timeline, no regression in existing markets | ### Example: B2B SaaS Company **Company Objective:** Move upmarket to enterprise customers | Company KR | Engineering OKR Connection | |-----------|--------------------------| | Close 10 enterprise deals | Eng Objective: Build enterprise features. KRs: SSO, audit logs, SLA compliance | | Achieve SOC2 certification | Eng Objective: Security compliance. KRs: audit readiness, vulnerability response time | | Reduce support tickets by 30% | Eng Objective: Improve product stability. KRs: bug rate, API reliability, documentation coverage | ## The OKR Cadence for Engineering ### Quarterly Cycle | When | Activity | |------|----------| | **Week -2 (before quarter)** | CTO drafts engineering OKRs aligned with company OKRs | | **Week -1** | VP Engs and EMs cascade into team-level OKRs | | **Week 1** | All OKRs finalized and shared org-wide | | **Week 4** | First check-in: are we on track? Early data available | | **Week 7** | Mid-quarter review: course-correct if needed | | **Week 10** | Pre-close: final push, identify at-risk KRs | | **Week 12-13** | Quarter close: score OKRs, write retrospective | ### Weekly Check-in Template Use this in your leadership meeting: ``` OKR Progress — Week [X] of Q[X] 2026 Objective: [Name] | Key Result | Target | Current | Trend | Status | |------------|--------|---------|-------|--------| | KR1: ... | X | Y | ↑/↓/→ | On track / At risk / Off track | | KR2: ... | X | Y | ↑/↓/→ | On track / At risk / Off track | | KR3: ... | X | Y | ↑/↓/→ | On track / At risk / Off track | Notes: - [What happened this week] - [Blockers or risks] - [Decisions needed] ``` ### Scoring OKRs At the end of the quarter, score each KR on a 0.0-1.0 scale: | Score | Meaning | |-------|---------| | 1.0 | Fully achieved or exceeded | | 0.7-0.9 | Strong progress, nearly there | | 0.4-0.6 | Partial progress, worth investigating why | | 0.1-0.3 | Minimal progress — was the KR realistic? | | 0.0 | No progress or not started | **Healthy scoring pattern:** If your team consistently scores 1.0 on all OKRs, your targets are too easy. The ideal average is 0.6-0.7 (a benchmark originally established by Google and now widely adopted). Some misses mean you're being ambitious enough. The DORA State of DevOps research further validates this: elite teams set ambitious targets and learn from partial misses rather than playing it safe. ## Common Questions ### "Should individual developers have OKRs?" **Generally no.** OKRs work best at the team and department level. Individual developers should have personal goals (career growth, skill development) tracked in 1:1s, but tying individual OKRs to engineering metrics creates perverse incentives. **Exception:** Staff+ engineers who own org-wide technical initiatives can have individual OKRs tied to those initiatives. ### "How many OKRs should an engineering team have?" **1-2 objectives with 3-4 key results each.** More than that, and you're not focused. If a team has 5 objectives, they effectively have none — everything is a priority, which means nothing is. ### "What if our OKR becomes irrelevant mid-quarter?" **Update it.** OKRs are not sacred commitments — they're strategic alignment tools. If the market shifts, a competitor launches something, or priorities change, update the OKR. Document why, and adjust the end-of-quarter scoring accordingly. ### "How do OKRs relate to sprint planning?" OKRs set the direction; sprints execute the work. Each sprint should contain tasks that move at least one KR forward. If a sprint is full of work that doesn't connect to any OKR, you have an alignment problem. | Level | Time Horizon | Purpose | |-------|-------------|---------| | OKRs | Quarterly | Strategic direction | | Roadmap | Monthly | Feature sequencing | | Sprint | Bi-weekly | Execution planning | | Daily standup | Daily | Tactical coordination | ### "What metrics platform do we need for engineering OKRs?" At minimum, you need automated tracking for: - **Lead Time and DORA metrics** (for delivery speed OKRs) - **Focus Time and Activity Time** (for productivity OKRs) - **Delivery Index and Planning Accuracy** (for predictability OKRs) - **Cost per project/team** (for efficiency OKRs) Manual tracking breaks down by week 3 of the quarter. Automated, always-current metrics are what make OKR check-ins useful instead of stale. ## The Anti-Gaming Principle Every OKR system is vulnerable to gaming. The best defense is the "balanced KR" approach shown in every template above: always include a counter-metric. | If You're Optimizing For... | Include a Counter-Metric For... | |----------------------------|-------------------------------| | Speed (Lead Time) | Quality (Change Failure Rate) | | Quality (Bug Rate) | Delivery (Planning Accuracy) | | Efficiency (Cost) | Output (Delivery Index) | | Output (Features Shipped) | Sustainability (Team Health) | If speed improves but quality tanks, the OKR is not achieved. If quality improves but nothing ships, the OKR is not achieved. Balance prevents gaming and ensures real progress. --- **Set engineering OKRs you can actually measure.** [PanDev Metrics](https://pandev-metrics.com) provides automated tracking for every metric in this guide — Lead Time, Focus Time, Delivery Index, Planning Accuracy, Productivity Score, and cost analytics. Set your targets, track progress weekly, and score your OKRs with real data instead of gut feeling. --- ## How Outsourcing Companies Prove 160 Hours Are Actually 160 Hours URL: https://pandev-metrics.com/docs/blog/outsource-prove-hours Date: 2026-02-12 Tags: outsourcing, time-tracking, billing, client-trust, engineering-metrics Description: Outsourcing clients doubt logged hours. Here's how top companies prove every billed minute with real IDE activity data instead of screenshots. The Deloitte Global Outsourcing Survey consistently identifies "lack of visibility" as one of the top reasons outsourcing relationships fail. Your client pays for 160 hours per month per developer. But deep down, they wonder: **were those really 160 hours of productive work?** This single doubt has killed more outsourcing contracts than missed deadlines. The problem isn't trust — it's the absence of proof. ## The 160-Hour Problem Every outsourcing CEO knows this scenario. You invoice the client for a full-time developer. The client looks at the deliverables and thinks: "This doesn't look like 160 hours of work." Maybe the feature was smaller than expected. Maybe there were bugs. Maybe the developer spent 40 hours on refactoring that's invisible to a non-technical stakeholder. Without evidence, you're stuck in a "he said, she said" situation. And every time you say "trust us," you lose a little credibility. ### Why traditional time tracking fails Most outsourcing companies rely on one of these approaches: | Method | What the client sees | The trust problem | |--------|---------------------|-------------------| | **Self-reported timesheets** | "8 hours — worked on feature X" | Anyone can write anything | | **Screenshot tools** | Random screenshots every 10 minutes | Invasive, easy to game, doesn't prove productivity | | **Jira/ticket tracking** | Task moved to "Done" | Doesn't show how long it actually took | | **Honor system** | Nothing | Maximum doubt | None of these answer the fundamental question: **was the developer actually writing code during those hours?** ## What "Proof" Actually Means to a Client Before building a proof system, you need to understand what clients actually want to see. After working with dozens of outsourcing companies, we've identified three levels of proof: ### Level 1: Activity Existence The developer was active in the IDE on specific dates and times. This is the bare minimum — evidence that someone opened an editor and did something. ### Level 2: Activity Depth How much time was spent coding vs. idle. Which projects and files were touched. What languages and frameworks were used. This level gives the client confidence that work was happening on their project specifically. ### Level 3: Activity Context Correlation between coding activity and delivered results. Cost per feature, sprint, or time period. Trends over weeks and months. This is the gold standard — it turns raw activity into a business narrative the client can understand. ## The IDE Heartbeat Approach Modern engineering intelligence platforms track developer activity through **IDE heartbeats** — lightweight signals sent from the developer's code editor every few minutes while they're actively working. Here's how it works: 1. **A plugin runs inside the IDE** (VS Code, IntelliJ, WebStorm, etc.) 2. **While the developer types, navigates, or debugs**, the plugin sends a heartbeat with metadata: timestamp, project name, language, file type 3. **When the developer is idle** (no keyboard/mouse activity), no heartbeat is sent 4. **The platform aggregates heartbeats** into daily, weekly, and monthly activity summaries This is fundamentally different from screenshot monitoring: | | Screenshots | IDE Heartbeats | |---|------------|----------------| | **What's captured** | Screen image | Activity metadata only | | **Privacy** | Low — captures personal data | High — no screen content | | **Accuracy** | Point-in-time snapshot | Continuous tracking | | **Gameable?** | Yes (mouse jigglers, fake screens) | Extremely difficult | | **Developer acceptance** | Low — feels like surveillance | High — runs silently | ## Building a Proof System: Step by Step ### Step 1: Deploy IDE Plugins Across Your Team The first step is getting every developer on a standardized tracking setup. With PanDev Metrics, this means installing an IDE plugin that takes under 2 minutes. The plugin supports all major editors: VS Code, Cursor, all JetBrains IDEs, Visual Studio, Vim, and others. Key consideration: **developers must understand this is about billing proof, not surveillance.** Frame it as a tool that protects them too — when a client questions hours, the data speaks for itself. ![Projects list showing project names and total time](https://pandev-metrics.com/img/blog/projects.png) The Projects view shows tracked time per project — exactly the data clients need to verify billed hours. ### Step 2: Map Developers to Projects and Clients Configure your system so every developer's activity is associated with the correct client project. In PanDev Metrics, this happens automatically through project name detection — the IDE plugin reads the project/workspace name and maps it accordingly. For teams working on multiple client projects, this separation is critical. You need to prove not just that a developer worked 160 hours, but that they worked 160 hours **on this specific client's project**. ### Step 3: Set Hourly Rates and Cost Tracking Once activity is tracked per project, attach hourly rates to each developer. This gives you: - **Actual cost per project per month** — based on real hours, not estimates - **Cost per developer per client** — useful when one developer splits time between clients - **Budget burn rate** — how fast the client's monthly budget is being consumed ### Step 4: Generate Client-Ready Reports The report your client receives should include: - **Total active hours per developer** for the billing period - **Daily breakdown** showing when work happened - **Project-specific hours** if the developer works on multiple projects - **Activity summary** — languages used, relative intensity of work PanDev Metrics offers one-click Excel export for exactly this purpose. You download the report, attach it to the invoice, and the client has complete visibility. ### Step 5: Provide Ongoing Dashboard Access (Optional) Some companies go further and give clients read-only access to a real-time dashboard. This is a bold move, but it eliminates doubt entirely. The client can log in at any time and see: - Which developers are currently active - How many hours have been logged this month so far - Activity trends and patterns ## Real-World Example: Before vs. After Consider a mid-sized outsourcing company with 40 developers serving 8 clients. **Before implementing activity tracking:** - 2-3 billing disputes per quarter - Average time to resolve a dispute: 2 weeks - Client retention rate: 70% annually - Sales cycle for new clients: 3+ months (trust was a barrier) **After implementing IDE-based activity tracking:** - Billing disputes dropped to near zero — the data spoke for itself - Client retention improved significantly — clients felt they had full visibility - Sales cycle shortened — the transparency pitch became a differentiator - Developer satisfaction increased — no more screenshot surveillance These results are consistent with IAOP (International Association of Outsourcing Professionals) findings showing that outsourcing providers who invest in transparency mechanisms retain clients at materially higher rates than those relying on traditional reporting. ## Handling Developer Concerns When you introduce activity tracking, developers will have questions. Here are honest answers: **"Are you spying on me?"** No. IDE heartbeat tracking captures metadata — project name, language, timestamps. It doesn't record screen content, keystrokes, or file contents. It's less invasive than a Git log. **"What if I'm thinking, not typing?"** Good point. Coding isn't 100% typing. The system tracks active IDE time, which naturally includes short pauses for thinking. However, extended breaks (15+ minutes without activity) won't be counted. This is by design — you're tracking work time, not total sitting time. **"Will this be used against me?"** Set a clear policy. Activity data is for client billing and project management — not for ranking or punishing individual developers. Put this in writing. **"What about non-IDE work?"** Code reviews, architecture discussions, and Slack conversations aren't captured by IDE tracking. Make this clear to clients too — the tracked hours represent coding time specifically, and total work time is higher. ## The Financial Impact > According to Forbes Kazakhstan, switching to hourly tracking based on real IDE activity data can reduce labor costs by 25-30%. — [Forbes Kazakhstan, April 2026](https://forbes.kz) Let's do some math. A typical outsourcing company billing $50/hour per developer with a 40-person team: - **Monthly revenue:** 40 × 160 × $50 = **$320,000** - **Revenue at risk from 1 lost client (5 devs):** $40,000/month = **$480,000/year** - **Cost of implementing activity tracking:** a fraction of one month's revenue from a single developer Even if tracking prevents the loss of just one small client per year, the ROI is overwhelming. But the real value isn't defensive. Companies that lead with transparency **win new deals faster**. When your sales pitch includes "you'll see real-time activity data for every developer we assign to your project," you immediately stand out from competitors who say "trust us." ## Common Mistakes to Avoid ### Mistake 1: Tracking without explaining why If developers learn about tracking from IT rather than management, they'll assume the worst. Hold a team meeting. Explain the business reason. Show them what the client sees. ### Mistake 2: Treating tracked hours as the only metric IDE activity is one dimension of productivity. A senior developer who codes 4 hours a day but architects solutions that save 100 hours of rework is more valuable than someone who types for 8 hours. Use activity data for billing proof, not performance evaluation. ### Mistake 3: Hiding the data from developers Give developers access to their own dashboards. When they can see their own patterns, they self-optimize. This turns tracking from a surveillance tool into a self-improvement tool. ### Mistake 4: Over-reporting to clients Clients want a clear summary, not a minute-by-minute log. A one-page monthly report with total hours, daily averages, and project breakdown is enough. Too much data creates noise. ## Making Transparency Your Standard Operating Procedure The companies that thrive in outsourcing are the ones that make transparency automatic, not optional. Here's how to make it part of your DNA: 1. **Onboarding:** Every new developer installs the IDE plugin on day one 2. **Monthly billing:** Every invoice includes an activity report as a standard attachment 3. **Quarterly reviews:** Use trend data to show clients how their team has grown and improved 4. **Sales process:** Demo your tracking dashboard during the pitch When transparency is the default, clients stop questioning hours. They start questioning why their previous vendor didn't offer this. ## Key Takeaways - The 160-hour trust gap is the biggest silent killer of outsourcing contracts - Self-reported timesheets and screenshot tools don't provide credible proof - IDE heartbeat tracking offers non-invasive, continuous, accurate activity data - The proof system should cover activity existence, depth, and business context - Transparency doesn't just retain clients — it wins new ones faster - Developers accept heartbeat tracking far more readily than screenshot surveillance --- **Stop losing clients to doubt.** [PanDev Metrics](https://pandev-metrics.com) gives your outsourcing company IDE-based activity tracking, automated cost calculation, and one-click Excel reports — so every billed hour has proof behind it. --- ## Transparency as Competitive Advantage: Why Clients Choose Companies With Metrics URL: https://pandev-metrics.com/docs/blog/transparency-competitive-advantage Date: 2026-02-09 Tags: outsourcing, transparency, competitive-advantage, client-trust, engineering-metrics Description: Outsourcing companies that offer real-time metrics win more deals and retain clients longer. Here's why transparency beats promises. The Deloitte Global Outsourcing Survey found that lack of transparency is the primary driver of client dissatisfaction in outsourcing relationships. Two companies pitch the same client. Same tech stack, similar rates, comparable portfolios. One says: "We deliver quality work on time." The other says: "Here's a live dashboard showing exactly what your developers are doing right now." **Which one wins?** In 2026, the answer is obvious. Transparency isn't a nice-to-have — it's the differentiator. ![Project-level time tracking that clients can access for full transparency](https://pandev-metrics.com/img/blog/projects.png) *Project-level time tracking that clients can access for full transparency.* ## The Outsourcing Trust Deficit Outsourcing has a trust problem baked into its business model. You're asking a company to pay $40–$100 per hour for developers they can't see, working in an office they'll never visit, on code they might not fully understand. Every outsourcing CEO knows the unspoken client fears: - "Are the developers actually working full-time on my project?" - "Am I paying senior rates for a junior developer?" - "Why did this feature take 3 weeks when it seemed like a 3-day task?" - "Is my project their priority, or am I subsidizing someone else's project?" These fears don't go away with a good first impression. They simmer. And when deliverables slow down or a bug appears in production, those fears become accusations. The traditional outsourcing response is **more communication**: weekly status calls, detailed Jira updates, PM reports. But communication is still a narrative — someone telling the client a story. What clients actually want is **evidence**. ## Why Metrics Beat Promises There's a fundamental difference between promising transparency and delivering it: | Promise-Based Transparency | Metrics-Based Transparency | |---------------------------|---------------------------| | "Your team is working hard" | Activity dashboard shows 7.2 hours of IDE time today | | "We're on track for the sprint" | Burn-down correlated with actual coding hours | | "The developer is dedicated to your project" | Project-level breakdown: 142 hours on your project, 18 on internal tasks | | "Here's our monthly report" | Client has 24/7 access to real-time data | The first column requires the client to trust you. The second column requires them to trust math. ### The psychology of verifiable data When a client can verify claims independently, something powerful happens: **they stop verifying.** This is counterintuitive but well-documented in behavioral economics research on trust and verification. When people know they *can* check, they feel less need to actually check. Give a client a real-time dashboard, and after the first month of spot-checking, most will rarely log in. But take that dashboard away, and the anxiety returns immediately. The dashboard isn't about monitoring — it's about **peace of mind**. ## Five Ways Transparency Wins Deals ### 1. Shorter Sales Cycles The biggest friction in outsourcing sales is trust-building. Prospects want references, trial periods, and proof-of-concepts — all because they can't verify what happens after they sign. When your sales deck includes a live demo of your activity tracking system, you compress weeks of trust-building into a single meeting. The prospect thinks: "If they're this transparent before the deal, they'll be transparent after." Companies using engineering metrics in their sales process report significantly faster deal closures. The reason is simple: you're removing the biggest objection (lack of visibility) before the prospect even raises it. ### 2. Higher Win Rates Against Competitors In competitive bids, transparency is a concrete differentiator that's hard to copy overnight. Your competitor can match your hourly rate. They can claim similar expertise. But they can't instantly replicate a mature metrics infrastructure. When a prospect is comparing three vendors and only one offers real-time activity dashboards, automated reports, and per-project cost tracking — that vendor has an unfair advantage. ### 3. Premium Pricing Justified Transparency supports premium pricing because it eliminates the value perception gap. When a client can see that their developer coded 6.5 hours today across 12 files in 3 different services, the $85/hour rate feels justified. Without that visibility, the same rate feels like a gamble. Companies that implement comprehensive metrics often find they can price higher than the market average without losing deals. The transparency premium is real. ### 4. Faster Ramp-Up on New Engagements When a new client engagement starts, there's always an awkward period: the client is watching closely, the team is still ramping up, and deliverables are sparse. This is when most trust damage happens. With activity metrics, you can show the client that developers are actively working from day one — even before the first deliverable lands. "Your developers logged 35 hours of coding in the first week, primarily in the authentication service and database layer." That single sentence buys you weeks of patience. ### 5. Easier Upselling and Expansion Expanding an existing engagement — adding more developers, extending the contract, starting new workstreams — requires the client to feel good about the current arrangement. If they have lingering doubts about value, they won't expand; they'll look for alternatives. Metrics make the business case for expansion tangible. "Your current team of 3 developers delivered an average of 450 coding hours per month across 6 microservices. To hit the Q3 roadmap, we recommend adding 2 more developers to maintain velocity." ## Building Your Transparency Stack A credible transparency offering has four layers: ### Layer 1: Activity Tracking The foundation. You need non-invasive, continuous tracking of developer activity. IDE heartbeat-based solutions like PanDev Metrics capture when developers are coding, which projects they're working on, and how many active hours they log — without screenshots or invasive monitoring. Key features to look for: - Per-project time breakdown - Support for all major IDEs - Minimal developer friction (install and forget) - Activity data, not surveillance data ### Layer 2: Cost Intelligence Raw activity hours are useful, but clients think in dollars, not hours. Layer cost intelligence on top of activity tracking: - **Hourly rate configuration** per developer or role - **Per-project cost calculation** — how much the client is actually spending per project - **Cost trend analysis** — is the project getting more expensive or more efficient over time? - **Budget tracking** — how much of the monthly/quarterly budget has been consumed? PanDev Metrics handles this natively — you set hourly rates per employee, and the platform calculates costs per project automatically based on real tracked hours. ### Layer 3: Reporting Data is only useful if it's presentable. You need reporting that serves two audiences: **For internal use (PMs, Engineering Managers):** - Real-time dashboards with drill-down capability - Team-level and individual-level views - Multi-project comparisons **For clients:** - Clean, one-page monthly summaries - Excel exports they can forward to their finance team - Visual charts that non-technical stakeholders can understand The one-click Excel report export is particularly important — clients often need to attach activity data to internal procurement or accounting workflows. ### Layer 4: Access Control Some clients want dashboard access. Others just want the monthly report. Your platform should support both: - **Client dashboards** with read-only access to their projects only - **Role-based permissions** so the client's CTO sees different data than their finance director - **Data isolation** ensuring one client can never see another client's data ## Case Study: The Transparency Pivot Consider an outsourcing company with 60 developers and a client retention challenge. Their annual churn rate was around 25% — one in four clients would leave each year, usually citing "unclear value for money" or "communication issues." Their turnaround strategy had three pillars: **Step 1: Instrument everything.** Every developer installed IDE tracking plugins. Every project was mapped in the system. Hourly rates were configured per developer. **Step 2: Lead with data.** Monthly client reports shifted from narrative ("the team worked on features X and Y") to data-driven ("the team logged 640 coding hours across 4 developers, primarily in the payment service, at a total cost of $48,000"). Trend charts showed month-over-month patterns. **Step 3: Make it a sales asset.** The sales team started demoing the tracking dashboard in prospect meetings. The pitch became: "You'll never wonder what you're paying for." The results after 12 months of this approach were transformative: - Client churn dropped significantly - Average contract value increased — clients were willing to scale up because they felt confident - New client acquisition accelerated - The company repositioned from "affordable outsourcing" to "transparent engineering partner" and raised rates accordingly ## The Transparency Maturity Model Not every company needs to jump to full transparency immediately. Here's a progressive approach: ### Stage 1: Internal Visibility (Month 1) Start by tracking activity internally. Get your PMs and engineering managers comfortable with the data. Identify any team issues before exposing them to clients. ### Stage 2: Enhanced Reporting (Month 2-3) Add activity summaries to your existing client reports. Don't change the format dramatically — just add a section with tracked hours and project breakdowns. ### Stage 3: On-Demand Access (Month 4-6) Offer interested clients read-only dashboard access. Start with your most trusted client relationships as pilots. ### Stage 4: Transparency as Standard (Month 6+) Make metrics a standard part of every engagement. Include it in contracts. Feature it in sales materials. Make it a core part of your brand identity. ## Objections and How to Handle Them ### "What if the data makes us look bad?" Valid concern. What if a developer only shows 4 hours of IDE time on a day they billed 8? First, remember that IDE time isn't total work time. Code reviews, architecture discussions, debugging without an IDE, client calls — these are legitimate work activities that aren't captured by editor tracking. Set this expectation clearly with clients. Second, if there genuinely is a productivity issue, wouldn't you rather catch it yourself than have the client catch it through missed deadlines? ### "Developers will resist tracking" They'll resist screenshot monitoring. IDE heartbeat tracking is different — it's non-invasive, doesn't capture screen content, and runs silently. In practice, developers forget it's there after the first week. Frame it as billing protection, not surveillance. ### "Our competitors don't do this — why should we?" That's exactly the point. Your competitors don't do this, which means you can be the first. By the time they catch up, you'll have years of historical data and a reputation built on transparency. ### "It's an additional cost" Compare the cost of an engineering intelligence platform to the cost of losing a single client. For most outsourcing companies, one retained client per year pays for the tooling many times over. > "The main thing that stands out is their responsiveness and client orientation. If questions or bugs arise, the team reacts quickly. Our improvement requests are always heard and considered." > — Rauan Bozabaev, CTO Chocofood ([Forbes Kazakhstan, April 2026](https://forbes.kz)) ## The Market Is Moving Toward Transparency This isn't just our opinion. The outsourcing industry is shifting: - **Clients are more sophisticated.** CTOs and VPs of Engineering who buy outsourcing services increasingly come from data-driven engineering cultures. They expect metrics. - **Remote work raised the bar.** Post-pandemic, even in-house teams use activity tracking. Outsourced teams are held to at least the same standard. - **AI is changing the conversation.** With AI coding assistants changing how developers work, clients want to understand what "productive time" actually means now. IAOP (International Association of Outsourcing Professionals) data reinforces this shift: their recent analyses highlight "data-driven client management" as a defining characteristic of top-performing outsourcing providers. Companies that wait for transparency to become the industry standard will find themselves playing catch-up. Companies that lead with transparency today are building a moat. ## Key Takeaways - The biggest barrier to outsourcing growth is the trust deficit — and transparency is the cure - Metrics-based transparency beats promise-based transparency because it's verifiable - Transparency shortens sales cycles, increases win rates, justifies premium pricing, and improves retention - A complete transparency stack includes activity tracking, cost intelligence, reporting, and access control - Start internally, then progressively expose data to clients as you get comfortable - The market is moving toward transparency — early movers build a lasting competitive advantage --- **Make transparency your edge.** [PanDev Metrics](https://pandev-metrics.com) gives outsourcing companies real-time activity tracking, automated cost intelligence, and client-ready reports — everything you need to turn visibility into revenue. --- ## Automated Billing by Real Hours: How to Stop Manual Time Tracking URL: https://pandev-metrics.com/docs/blog/billing-real-hours Date: 2026-02-06 Tags: outsourcing, billing, time-tracking, automation, project-management Description: Manual timesheets waste PM time and invite billing disputes. Here's how to automate billing with real IDE activity data — step-by-step tutorial. Research on self-reported time tracking shows a consistent pattern: professionals underestimate their non-productive time and overestimate their output by 10-40%, depending on the methodology. It's Friday afternoon. Your PM opens a spreadsheet, pings 12 developers for their weekly hours, cross-references Jira tickets, rounds up some numbers, rounds down others, and sends the client an invoice that everyone vaguely agrees is "close enough." **This process is broken, and everyone knows it.** Manual time tracking costs outsourcing companies real money — in PM hours wasted, in billing disputes, and in revenue leaked through underreporting. ![Real project hours tracked via IDE — replacing manual timesheets](https://pandev-metrics.com/img/blog/projects.png) *Real project hours tracked via IDE — replacing manual timesheets.* ## The True Cost of Manual Time Tracking Let's quantify how much manual timesheets actually cost your outsourcing business. ### PM Time Wasted A typical PM managing a 5-developer team spends 3–5 hours per week on time tracking administration: | Task | Time per week | |------|:------------:| | Chasing developers for timesheets | 45 min | | Reviewing and correcting entries | 60 min | | Cross-referencing with Jira/tickets | 45 min | | Formatting reports for clients | 60 min | | Handling client questions about hours | 30 min | | **Total** | **~4 hours** | That's 4 hours per PM per week, or roughly **200 hours per year** — more than a month of working time spent on administrative time tracking instead of actual project management. McKinsey's research on developer productivity found that administrative overhead is one of the largest hidden drains on engineering output. ### Revenue Leakage Here's a less obvious cost: developers systematically underreport their hours. Not intentionally — but when you fill out a timesheet from memory at the end of the day (or worse, the end of the week), you forget things: - The 45 minutes you spent debugging a CI pipeline issue - The 30-minute code review for a colleague - The 20 minutes of refactoring before starting a new feature Studies on self-reported time tracking consistently show underreporting of 10–15%. For a team billing $50/hour, that's significant: - **10 developers × 160 hours × 12% underreporting = 192 lost hours/month** - **192 hours × $50/hour = $9,600/month in leaked revenue** - **Annual impact: $115,200** That's revenue your developers earned but your company never billed. ### Billing Disputes When your timesheet says 160 hours and the client's perception says "that feature shouldn't have taken that long," you have a dispute. Each dispute costs: - PM time to investigate and respond (2-4 hours) - Management time for escalation (1-2 hours) - Goodwill damage that's impossible to quantify - Occasionally, writing off hours to "make the client happy" (direct revenue loss) ## How Automated Billing Works Automated billing replaces the manual timesheet-to-invoice pipeline with a system that captures actual work time and converts it directly into billable data. Here's the architecture: ``` Developer's IDE → Heartbeat Plugin → Activity Platform → Cost Calculation → Report/Invoice ``` Each step is automated: ### Step 1: IDE Heartbeats Capture Activity A lightweight plugin runs inside each developer's IDE (VS Code, IntelliJ, WebStorm, etc.). While the developer works, the plugin sends heartbeats — small metadata packets containing: - Timestamp - Project name - Programming language - Activity type (coding, debugging, reviewing) No screen content. No keystrokes. No file contents. Just activity metadata. The heartbeats are sent only during active work. When the developer steps away, browses the web, or switches to a non-IDE app — no heartbeats, no tracked time. ### Step 2: Activity Platform Aggregates Data The platform (like PanDev Metrics) collects heartbeats and aggregates them into structured activity records: - **Per developer:** Daily, weekly, monthly hours - **Per project:** Hours spent on each client project - **Per team:** Combined hours across all developers on a project This gives you an accurate, uneditable record of when each developer worked and on which project. ### Step 3: Cost Calculation Applies Rates Configure hourly rates per developer (or per role, or per client contract): | Developer | Role | Hourly Rate | Project | |-----------|------|:-----------:|---------| | Alex K. | Senior Backend | $75 | Client A — API | | Maria S. | Frontend | $60 | Client A — Web App | | James T. | Full-stack | $65 | Client B — Platform | | Olga P. | QA Engineer | $50 | Client A — QA | The platform multiplies tracked hours by rates automatically: ``` Alex K.: 156.5 hours × $75 = $11,737.50 Maria S.: 162.0 hours × $60 = $9,720.00 James T.: 148.5 hours × $65 = $9,652.50 Olga P.: 155.0 hours × $50 = $7,750.00 ``` No spreadsheets. No rounding. No "I think I worked about 8 hours today." ### Step 4: One-Click Report Generation When billing day arrives, the PM clicks "Export" and gets a client-ready Excel report containing: - Developer-level hour breakdown - Project-level cost summary - Daily activity chart - Total amount due Attach it to the invoice. Done. ## Tutorial: Setting Up Automated Billing With PanDev Metrics Here's a practical, step-by-step walkthrough. ### Prerequisites - PanDev Metrics account (cloud or on-premise) - Admin or PM access role - Developer team willing to install IDE plugins ### Part 1: Deploy IDE Plugins (15 minutes per developer) Each developer installs the PanDev Metrics plugin for their IDE: 1. Open IDE extensions/plugins marketplace 2. Search for "PanDev" or "Activity Tracker" 3. Install and authenticate with the team's workspace 4. Verify: the plugin status indicator shows "Active" The plugin runs silently in the background. Developers don't need to start/stop timers, tag tasks, or do anything manual. **Pro tip:** Do this during a team meeting. Walk through the installation together. It takes 2-3 minutes per person and eliminates weeks of "I'll install it later." ### Part 2: Configure Projects (10 minutes) In the PanDev Metrics admin panel: 1. Navigate to **Projects** section 2. Verify that projects are being auto-detected from IDE workspace names 3. Map any projects that need renaming (e.g., map the folder name "client-a-backend" to the display name "Client A — Backend API") 4. Group related projects under client accounts if needed ### Part 3: Set Hourly Rates (5 minutes) 1. Go to **Team → Members** 2. For each developer, set their hourly rate 3. If a developer works for multiple clients at different rates, configure per-project rates This is the key step that turns activity tracking into cost tracking. Once rates are set, every hour of tracked activity automatically has a dollar value. ### Part 4: Configure Reporting (5 minutes) 1. Go to **Reports → Settings** 2. Choose the billing period (weekly, bi-weekly, monthly) 3. Select which data fields to include in client reports 4. Set up the Excel export template ### Part 5: Generate Your First Report (2 minutes) 1. Navigate to **Reports** 2. Select the date range and project/client 3. Click **Export to Excel** 4. Review the report — check that hours and costs look correct 5. Send it with your invoice That's it. Total setup time: under an hour for the entire team. ## Handling Edge Cases ### Developer works on multiple projects in one day The IDE plugin tracks project context automatically. If a developer switches from Client A's project to Client B's project, the hours are recorded separately. The PM doesn't need to do anything — the separation happens at the data level. ### Non-IDE work (meetings, code reviews in browser) IDE heartbeat tracking captures IDE time specifically. For non-IDE work like meetings or browser-based code reviews, you have two options: 1. **Include a fixed overhead** — agree with the client that billed hours include a percentage for non-IDE work (e.g., tracked IDE hours × 1.2) 2. **Bill IDE time only** — some companies bill only for verified coding time and offer it at a slightly higher rate Both approaches work. The key is to agree on the methodology upfront so there are no surprises. ### Developer forgets to install or enable the plugin Set up alerts for developers who show zero activity for more than one business day. This catches both forgotten installations and disabled plugins before the billing period ends. ### Discrepancy between tracked hours and expected hours If a developer is contracted for 160 hours/month but tracks only 120 hours of IDE time, investigate before the invoice goes out: - Were there meetings or non-IDE work not captured? - Was the developer on PTO or sick leave? - Is there a technical issue with the plugin? Address discrepancies proactively — don't let the client discover them. ## Comparison: Manual vs. Automated Billing | Dimension | Manual Timesheets | Automated (IDE-Based) | |-----------|:-----------------:|:---------------------:| | PM time per billing cycle | 4-8 hours | 15-30 minutes | | Accuracy | ±15% (self-reported) | ±2% (system-tracked) | | Revenue leakage | 10-15% underreporting | Near zero | | Billing disputes | 2-3 per quarter | Rare | | Client confidence | Based on trust | Based on verified data | | Developer friction | High (fill out forms daily) | None (plugin runs silently) | | Audit trail | Paper trail | Digital, timestamped | | Setup effort | Ongoing | One-time (under 1 hour) | ## The ROI Calculation Let's calculate ROI for a 20-developer outsourcing team billing an average of $60/hour: **Costs saved:** - PM time: 200 hours/year × $40/hour = **$8,000** - Recovered revenue from underreporting: 12% × 20 devs × 160 hours × $60 × 12 months = **$138,240** (theoretical maximum) - Even at a conservative 5% recovery: **$57,600/year** - Dispute resolution savings: 8 disputes/year × 6 hours × $40 = **$1,920** **Conservative total annual benefit: $67,520** Against a platform cost that's a fraction of that, the ROI typically exceeds 10x in the first year. ## Migration Plan: From Manual to Automated You don't have to switch everything at once. Here's a phased approach: ### Week 1-2: Parallel Tracking Install IDE plugins across the team but continue using manual timesheets. Compare the two datasets at the end of two weeks. You'll likely find discrepancies — the automated data almost always shows different (usually higher) totals than self-reported sheets. ### Week 3-4: Internal Validation Use automated data as the primary source internally. Have PMs review the data and compare it against project delivery. Build confidence that the numbers make sense. ### Month 2: Client Pilot Pick one client with a good relationship and introduce the automated report. Say: "We've upgraded our time tracking system. Here's your report based on actual IDE activity data — it's more accurate than our previous manual process." ### Month 3+: Full Rollout Roll the automated system out to all clients. Update your invoicing process. Archive the manual timesheet templates. Never look back. ## Common Questions **"What if automated tracking shows fewer hours than we've been billing?"** This is possible if your team has been rounding up. It's better to discover this yourself than to have a client discover it. Adjust your billing to match reality, and consider the transparency gain a long-term investment. **"Can we still bill for non-IDE work?"** Absolutely. IDE tracking provides the verifiable baseline. You can add agreed-upon overhead for meetings, planning, and code reviews. The key is that the core hours are now backed by data. **"What about on-premise deployment?"** PanDev Metrics supports on-premise installation for companies with strict data policies. All activity data stays on your own servers — important for clients in regulated industries. **"Do we need to change our invoicing software?"** No. The Excel export integrates with any invoicing workflow. Generate the report, attach it to your existing invoice, and reference the totals. ## Key Takeaways - Manual time tracking costs outsourcing companies thousands in wasted PM time and leaked revenue - Self-reported hours are 10-15% inaccurate — consistently underreported - IDE heartbeat tracking captures real activity without developer effort - Automated cost calculation turns tracked hours into billable amounts with zero spreadsheet work - One-click Excel exports replace hours of report formatting - Migration from manual to automated can happen in under a month with a phased approach --- **Automate your billing.** [PanDev Metrics](https://pandev-metrics.com) captures real IDE activity, calculates costs automatically, and exports client-ready reports in one click. Stop chasing timesheets — start billing with confidence. --- ## Managing 5 Projects for 5 Clients Simultaneously: A Data-Driven Approach URL: https://pandev-metrics.com/docs/blog/manage-5-projects Date: 2026-02-04 Tags: outsourcing, project-management, multi-project, engineering-metrics, productivity Description: Outsourcing PMs juggle multiple client projects at once. Here's a data-driven framework for managing 5+ projects without losing control. Research on context switching shows that it takes an average of 23 minutes to fully regain focus after an interruption. Now multiply that by five projects, each with its own Slack channel, Jira board, and stakeholder expectations. You're an outsourcing PM managing five projects for five different clients. Each client thinks their project is your top priority. And every Monday morning, you spend the first two hours trying to remember where each project left off on Friday. **Sound familiar?** This is the multi-project management problem — and it's the defining challenge of outsourcing project management. ## Why Multi-Project Management Is Uniquely Hard in Outsourcing In-house PMs have it tough, but outsourcing PMs have a fundamentally different problem. Here's why: ### Different stakeholders with competing expectations Each client has their own definition of "urgent," their own communication preferences, and their own ideas about how much of your attention they deserve. Client A wants daily standups. Client B wants a weekly email. Client C calls whenever they feel like it. ### Shared developer resources In an ideal world, every developer would be dedicated to one project. In reality, outsourcing economics often require developers to split time across multiple clients. Managing a developer who spends Monday-Wednesday on Client A and Thursday-Friday on Client B requires careful coordination that single-project PMs never deal with. ### No tolerance for "wrong project" mistakes If a developer accidentally pushes code to the wrong repository, or if a client's proprietary approach leaks into another client's codebase, you have a serious contractual and trust issue. Multi-project isolation isn't just organizational — it's a business requirement. ### Context-switching tax Every time you shift focus from one project to another, you pay a cognitive tax. For PMs managing five projects, this tax is enormous. You can lose an hour per day just re-loading context about where each project stands. ## The Data-Driven Framework The solution isn't working harder or hiring more PMs. It's building a system where data replaces memory, and dashboards replace mental juggling. Here's the framework we've seen work at outsourcing companies managing 5+ simultaneous client projects. ### Principle 1: Single Source of Truth for All Projects Every project's key metrics should live in one place — not spread across five Jira instances, three Slack channels, and your memory. What you need in that single view: | Metric | Why it matters | |--------|---------------| | **Active hours this week** (per project) | Shows where effort is actually going | | **Developer allocation** | Who's working on what, and how much | | **Cost burn rate** | Are you on track for the monthly budget? | | **Activity trend** | Is the project ramping up, stable, or winding down? | | **Last active day** | Catches projects that have gone silent | PanDev Metrics provides a multi-project dashboard that shows all of this in one screen. Instead of checking five separate tools, you check one. ![Projects list showing project names and total time](https://pandev-metrics.com/img/blog/projects.png) A single multi-project view lets you see all client projects, their tracked hours, and time allocation at a glance. ### Principle 2: Track Actual Hours, Not Planned Hours Planned allocation says Developer X should spend 80 hours on Client A this month. But what actually happened? Without real data, you're managing based on assumptions. With IDE activity tracking, you know exactly how many hours each developer spent on each project — down to the day. This matters for three reasons: 1. **Budget accuracy.** If Client A's budget allows 320 developer-hours this month and you've burned 280 by week three, you know to slow down before overrunning. 2. **Allocation drift.** Developers naturally gravitate toward interesting problems. Without tracking, Developer X might spend 60% of their time on Client A's challenging microservice architecture and only 40% on Client B's routine CRUD work — the opposite of what was planned. 3. **Evidence for difficult conversations.** When Client B asks why progress is slow, you can show that their allocated developer spent 35% of the week on emergency bug fixes for Client B's own production issues — not a planning failure, but a priority shift they initiated. ### Principle 3: Automated Per-Project Cost Tracking When you manage five projects, manual cost tracking breaks down. You can't spend an hour per project per week reconciling timesheets against budgets. Set up automated cost tracking: 1. **Assign hourly rates** to each developer (or per-project rates if they differ by client) 2. **Let the platform calculate costs** based on real tracked hours 3. **Set budget alerts** — get notified when a project reaches 75% and 90% of monthly budget 4. **Review weekly** — a 5-minute scan of all five projects' cost dashboards Example weekly cost overview: | Project | Budget | Spent | Remaining | Status | |---------|:------:|:-----:|:---------:|:------:| | Client A — E-commerce | $32,000 | $18,400 | $13,600 | On track | | Client B — FinTech App | $24,000 | $22,100 | $1,900 | Over-burning | | Client C — SaaS Backend | $16,000 | $9,200 | $6,800 | Under-burning | | Client D — Mobile App | $20,000 | $14,500 | $5,500 | On track | | Client E — Data Pipeline | $12,000 | $7,800 | $4,200 | On track | This five-line table tells you everything. Client B needs attention immediately. Client C might have a blocked developer. The other three are fine. Total time to assess: 30 seconds. ### Principle 4: Developer Dashboards for Self-Management You can't micromanage 15-25 developers across five projects. You shouldn't even try. Instead, give developers access to their own activity dashboards. When developers can see their own data: - They notice when they've been under-contributing to a project and self-correct - They can report blockers with evidence ("I spent 6 hours debugging the auth service — there's a deeper architectural issue") - They take ownership of their time allocation instead of waiting for you to tell them what to do This shifts the PM role from **time police** to **strategic coordinator** — which is where your value actually lies. ### Principle 5: Standardized Client Reporting When you manage five clients, you can't write five custom reports every month. You need a reporting template that works for everyone. The report structure that works: **Page 1: Executive Summary** - Total hours billed - Total cost - Key deliverables this period - Health status (green/yellow/red) **Page 2: Hour Breakdown** - Developer-by-developer hours - Daily activity chart - Comparison to previous period **Page 3: Cost Analysis** - Cost by developer - Cost by activity type (if available) - Budget utilization percentage PanDev Metrics generates this as an Excel export with one click. Five projects × one click each = five client reports in under five minutes. ## Practical Tactics for the Multi-Project PM Beyond the data framework, here are tactical approaches that work: ### The Monday Morning Scan (15 minutes) Every Monday, before anything else, do a 15-minute scan of all projects: 1. Open your multi-project dashboard (3 minutes) 2. Check last week's actual hours vs. planned for each project (3 minutes) 3. Check budget burn rates (2 minutes) 4. Identify the top risk — which project needs intervention this week? (2 minutes) 5. Check developer allocation — is anyone overloaded or underutilized? (3 minutes) 6. Draft your priorities for the week (2 minutes) This ritual replaces the 2-hour Monday morning confusion with a structured, data-informed start. ### The Traffic Light System Assign a daily status to each project based on data, not feelings: - **Green:** Tracked hours match plan, budget on track, no client escalations - **Yellow:** Minor deviation — hours 10-20% off plan, or budget burn slightly high - **Red:** Major issue — developer went silent, budget overrun, client escalation Check the traffic lights once daily. Only invest deep attention in yellow and red projects. Green projects don't need you today. ### Developer Rebalancing When tracking shows that Project A is over-burning while Project C is under-burning, rebalance: 1. Identify which developers on Project A have transferable skills for Project C 2. Check that the developer's daily activity on Project A is genuinely complete (not just paused) 3. Move 1-2 days of the developer's week from A to C 4. Monitor the impact in the next week's data Without real activity data, rebalancing is guesswork. With data, it's a precision operation. ### The Friday Snapshot Every Friday afternoon, capture the state of all five projects: - Current week's hours per project - Any client communications that need follow-up Monday - Any developers who will be unavailable next week (PTO, sick, moved to another project) - Budget status Store this in a simple document or dashboard bookmark. When Monday comes, you don't start from zero. ## Managing Developer Allocation Across Projects Developer allocation is the hardest part of multi-project management. Here's a data-driven approach: ### The Allocation Matrix Maintain a clear view of who works on what: | Developer | Mon | Tue | Wed | Thu | Fri | |-----------|:---:|:---:|:---:|:---:|:---:| | Alex K. | A | A | A | B | B | | Maria S. | C | C | D | D | D | | James T. | A | A | A | A | A | | Olga P. | B | B | C | C | E | | Denis R. | E | E | E | D | D | Then compare it to actual tracked hours each week. The gap between planned and actual allocation reveals: - **Scope creep:** Client A's project is consuming more developer time than planned - **Context switching:** A developer supposed to be on one project is bouncing between three - **Underutilization:** A developer is tracking fewer hours than expected — possibly blocked or disengaged ### The Split Developer Problem Developers who split across multiple client projects face extreme context-switching costs. Best practices: 1. **Minimize splits.** If possible, dedicate developers to single projects. A developer at 100% on one project is more effective than at 50% on two. The *Accelerate* research (Forsgren, Humble, Kim) confirms that reducing work-in-progress is one of the strongest predictors of team performance. 2. **When splits are necessary, use full-day blocks.** Mon-Wed on Project A, Thu-Fri on Project B is far better than alternating projects daily. 3. **Track the cost of splitting.** Compare a split developer's total output to a dedicated developer's output. The difference is your context-switching tax — and it can inform your pricing for shared resources. ## Scaling Beyond Five Projects The framework above works for 5 projects. But what about 10? 20? The principles stay the same, but you need additional structure: ### Tier your projects Not all projects need the same attention: - **Tier 1 (high-touch):** Large contracts, strategic clients, complex projects — weekly deep review - **Tier 2 (standard):** Stable projects with experienced teams — bi-weekly review - **Tier 3 (low-touch):** Small, stable engagements — monthly review unless something triggers an alert ### Use budget alerts as your early warning system Configure alerts for every project: - 75% budget consumed → Review pace and plan for the remainder - 90% budget consumed → Alert the client and discuss options - 100% budget consumed → Stop work until the client approves additional budget With alerts in place, you don't need to check every project every day — the system tells you when to pay attention. ### Delegate with data As you take on more projects, you'll need to delegate some to junior PMs or team leads. Data makes delegation safer: - The junior PM has the same dashboard you do - You can audit their projects in minutes by checking the numbers - Escalation triggers are objective (budget alerts, activity drops) not subjective ## Key Takeaways - Multi-project management in outsourcing requires a data-driven system, not heroic multitasking - A single multi-project dashboard replaces mental juggling with clear visibility - Track actual hours per project — the gap between planned and actual reveals allocation problems early - Automated cost tracking and budget alerts prevent overruns before they happen - Standardized one-click reports save hours of weekly PM time - Developer self-management through personal dashboards reduces PM micromanagement - Scale by tiering projects and delegating with objective data --- **Manage all your projects in one place.** [PanDev Metrics](https://pandev-metrics.com) gives outsourcing PMs a multi-project dashboard with real-time developer activity, per-project cost tracking, and one-click client reports — so you stay in control, no matter how many clients you juggle. --- ## The Perfect Client Report in One Click: What Should Be Inside URL: https://pandev-metrics.com/docs/blog/excel-report-one-click Date: 2026-02-02 Tags: outsourcing, reporting, client-management, excel, project-management Description: A guide to building the perfect outsourcing client report — what to include, what to skip, and how to generate it in one click with real data. The Deloitte Global Outsourcing Survey found that reporting quality is a top factor in outsourcing client satisfaction — yet most clients don't read past the first page. Your client skims the executive summary, glances at the total hours, checks the cost, and closes the file. **Yet you spend 2-3 hours every month crafting that report.** Something doesn't add up. The perfect client report isn't the longest or the most detailed. It's the one that answers all the client's questions in 60 seconds — and takes you 60 seconds to generate. ![Project data that populates one-click Excel reports](https://pandev-metrics.com/img/blog/projects.png) *Project data that populates one-click Excel reports.* ## Why Client Reports Matter More Than You Think Before we talk about what goes into a report, let's talk about why it matters. A client report in outsourcing isn't just a summary of work done. It serves four critical business functions: ### 1. Invoice Justification The report is attached to the invoice. It says: "Here's what you're paying for." Without it, the invoice is an opaque request for money. With it, the invoice becomes a transparent exchange of value. ### 2. Trust Maintenance Between monthly meetings, the report is your primary trust signal. A clear, data-backed report says: "We're professional, organized, and have nothing to hide." A vague, narrative-only report says: "Just trust us." ### 3. Stakeholder Communication Your client contact isn't the only person who sees the report. It gets forwarded to their finance team, their CTO, sometimes their CEO. The report needs to work for all audiences — technical and non-technical alike. ### 4. Dispute Prevention Most billing disputes start with vague reporting. IAOP data consistently shows that disputes decrease sharply when reporting transitions from narrative ("the team worked on features") to quantitative ("the team logged 642.5 hours across 4 developers, with 68% on backend development and 32% on frontend"). Specific numbers are much harder to argue with. ## What Clients Actually Want to See We've collected feedback from dozens of outsourcing clients about what they look for in reports. Here's the hierarchy of needs: ### Must-Have (clients will ask if missing) 1. **Total hours per developer** — How much did each person work? 2. **Total cost** — What's the bottom line? 3. **Date range** — What period does this cover? 4. **Project/service breakdown** — Where did the hours go? ### Should-Have (increases satisfaction) 5. **Daily activity chart** — Visual proof that work happened consistently 6. **Comparison to previous period** — Are things trending up or down? 7. **Cost per developer** — Breakdown of who costs what 8. **Budget utilization** — Percentage of monthly budget consumed ### Nice-to-Have (impresses but not expected) 9. **Technology breakdown** — Languages and frameworks used 10. **Activity patterns** — Peak productivity times 11. **Key deliverables list** — What was actually shipped 12. **Recommendations** — Data-backed suggestions for next period ## The Report Template Here's the template that covers all client needs in a clean, scannable format. This is what PanDev Metrics generates as an Excel export with one click. ### Section 1: Executive Summary (One Screen) This is the section 90% of readers will see. Make it count. ``` Report Period: March 1 – March 31, 2026 Client: TechCorp Inc. Project: E-Commerce Platform v3 Total Hours: 642.5 Total Cost: $44,975 Developers: 4 active Budget Used: 89% of $50,000 monthly allocation Status: ✓ On Track ``` Six lines. The client's CFO gets what they need without scrolling. ### Section 2: Developer Breakdown | Developer | Role | Hours | Rate | Cost | |-----------|------|:-----:|:----:|-----:| | Alex K. | Senior Backend | 168.0 | $75 | $12,600 | | Maria S. | Frontend | 162.5 | $65 | $10,562 | | James T. | Full-stack | 158.0 | $70 | $11,060 | | Olga P. | QA Engineer | 154.0 | $55 | $8,470 | | | | | | | | **Total** | | **642.5** | | **$42,692** | Note: costs don't include project management overhead in this example. Adjust based on your billing model. This table answers the most common client question: "What am I paying each person?" It also helps the client understand the cost structure — if they want to reduce the budget, they can see where the biggest line items are. ### Section 3: Daily Activity Chart A visual chart showing hours per day across the reporting period. This is enormously effective because it provides at-a-glance proof of consistent work. What the client sees: - Work happened every business day (no unexplained gaps) - Weekends show minimal or zero activity (the team isn't artificially inflating hours) - There's natural variation (real data, not fabricated round numbers) In Excel, this renders as a simple bar chart with date on the X-axis and hours on the Y-axis. PanDev Metrics includes this chart automatically in the export. ### Section 4: Project/Service Breakdown If the team works on multiple services or modules within the same project: | Service/Module | Hours | % of Total | Cost | |----------------|:-----:|:----------:|-----:| | Backend API | 245.0 | 38% | $17,150 | | Frontend (React) | 178.5 | 28% | $11,603 | | Database & Migrations | 87.0 | 14% | $6,090 | | Testing & QA | 98.0 | 15% | $5,390 | | DevOps/CI | 34.0 | 5% | $2,380 | | **Total** | **642.5** | **100%** | **$42,613** | This breakdown prevents the "where did all the hours go?" question. It also surfaces insights — if 14% of hours went to database migrations, the client understands why feature delivery might have seemed slower. ### Section 5: Period Comparison | Metric | February | March | Change | |--------|:--------:|:-----:|:------:| | Total Hours | 612.0 | 642.5 | +5.0% | | Total Cost | $42,840 | $44,975 | +5.0% | | Avg Hours/Developer/Day | 6.8 | 7.2 | +5.9% | | Developers Active | 4 | 4 | — | Trend data builds long-term confidence. If the client sees consistent, steady output month after month, they stop worrying. ### Section 6: Notes and Recommendations (Optional) This is the only narrative section. Keep it brief: ``` Notes: - Sprint velocity increased due to completion of the authentication refactoring in week 1 - Database migration effort (87 hours) was a one-time investment; expect this to drop to ~10 hours/month going forward - Recommend adding a part-time DevOps resource in Q2 as deployment frequency increases ``` This section transforms the report from a timesheet into a strategic document. The client sees that you're not just billing hours — you're thinking about their project's future. ## What NOT to Include Knowing what to leave out is as important as knowing what to include. ### Don't include: Individual file-level detail "Edited auth.controller.ts for 2.3 hours" is too granular. Clients don't care about files — they care about features and services. ### Don't include: Minute-by-minute logs A 40-page printout of timestamps doesn't demonstrate transparency — it demonstrates that you haven't synthesized the data. Give summaries, not raw logs. ### Don't include: Jira ticket numbers without context "PROJ-2847: 14 hours" means nothing to a non-technical stakeholder. Either map tickets to feature names or skip the ticket-level detail. ### Don't include: Internal metrics Developer velocity scores, individual performance rankings, or internal team communications don't belong in client reports. The report is about what the client is paying for, not how you manage your internal team. ### Don't include: Vanity metrics "1,247 Git commits this month" sounds impressive but means nothing. Commits can be tiny or massive. Lines of code written is equally meaningless. Stick to hours, cost, and deliverables. ## The One-Click Generation Process Here's how the report generation actually works in practice with PanDev Metrics: ### Before (Manual Process) 1. PM asks each developer for their hours (30 min of chasing) 2. PM opens spreadsheet template (5 min) 3. PM enters hours, calculates costs, builds charts (60-90 min) 4. PM writes narrative summary (30 min) 5. PM formats and reviews (20 min) 6. PM sends to client (5 min) **Total: 2.5 – 3 hours per client per month** For 5 clients: **12-15 hours per month** on reporting alone. ### After (Automated Process) 1. PM opens PanDev Metrics, selects client and date range (30 sec) 2. PM clicks "Export to Excel" (10 sec) 3. PM reviews the auto-generated report (5 min) 4. PM adds optional narrative notes (5 min) 5. PM sends to client (1 min) **Total: ~12 minutes per client per month** For 5 clients: **1 hour per month** on reporting. That's a 12x reduction in reporting time. The PM gets 10+ hours per month back for actual project management. ## Report Delivery Best Practices How you deliver the report matters almost as much as what's in it. ### Attach it to the invoice Don't send the report separately from the invoice. The psychological effect of receiving an invoice with an attached activity report is powerful — it says "this invoice is backed by data." ### Send it consistently Same day every month. If you invoice on the 1st, send the report on the 1st. Consistency builds trust. Inconsistency creates anxiety ("why is the report late this month?"). ### Include a one-line summary in the email Don't make the client open the attachment to get the headline. Put it in the email body: > "Attached: March activity report. Your team logged 642.5 hours ($44,975) across 4 developers. Full breakdown in the attached Excel file." ### Offer a call to walk through it Once a quarter, offer a 15-minute call to walk through the report together. Most clients will decline — but the offer itself signals transparency and confidence. ### Make the format non-editable Send as PDF for the visual report and Excel for the data. The Excel allows clients to run their own analysis (some finance teams want this). The PDF prevents accidental modifications. ## Adapting for Different Client Types Not all clients need the same report: ### The Hands-Off CEO Wants: Executive summary only. Total hours, total cost, status indicator. Strategy: Lead with the one-screen summary. Include detail pages for their CTO to review if needed, but don't expect the CEO to go past page one. ### The Detail-Oriented CTO Wants: Everything. Developer breakdown, technology split, daily patterns, service-level hours. Strategy: Give them the full report. Consider offering dashboard access so they can explore on their own. ### The Finance-First CFO Wants: Numbers that tie to the contract and budget. Cost breakdown, budget utilization, comparison to contracted rates. Strategy: Emphasize the cost sections. Include a row showing "contracted hours vs. actual hours" and "contracted cost vs. actual cost." ### The Metrics-Savvy VP of Engineering Wants: Trends, patterns, efficiency indicators. Week-over-week comparisons, utilization rates, technology breakdown. Strategy: Add the comparison section and any trend data you have. This stakeholder appreciates context and recommendations. ## Building Long-Term Reporting Value Individual monthly reports are useful. A year of monthly reports is strategic. After 6-12 months of consistent reporting, you can offer the client: - **Annual review:** Total hours, total cost, cost per feature area, team growth over time - **Efficiency analysis:** How the team's velocity changed as they gained domain knowledge - **Forecasting:** Based on 12 months of data, project next quarter's resource needs - **Benchmarking:** How this project compares to similar projects (with anonymized data) This transforms reporting from an administrative task into a strategic service — and gives you a powerful reason for contract renewals. ## Key Takeaways - Client reports serve four functions: invoice justification, trust maintenance, stakeholder communication, and dispute prevention - The must-have elements are: total hours, total cost, date range, and project breakdown - A daily activity chart is the single most effective visual — it proves consistency at a glance - Leave out raw logs, file-level detail, and internal metrics — they create noise, not clarity - One-click report generation reduces reporting time from 3 hours to 12 minutes per client - Deliver reports attached to invoices, on a consistent schedule, with a one-line email summary - After 12 months of consistent reporting, you gain strategic value through trends and forecasting --- **Generate client reports in one click.** [PanDev Metrics](https://pandev-metrics.com) automatically tracks developer activity, calculates costs, and exports client-ready Excel reports — so you spend minutes on reporting, not hours. --- ## Developer Utilization in Outsourcing: How to Calculate and Optimize URL: https://pandev-metrics.com/docs/blog/developer-utilization Date: 2026-01-30 Tags: outsourcing, developer-utilization, engineering-metrics, cost-optimization, productivity Description: Developer utilization directly impacts outsourcing profitability. Learn how to measure it accurately, identify waste, and optimize without burning out your team. McKinsey's research on developer productivity found that software engineers spend only 25-30% of their working hours on active coding. The rest goes to meetings, planning, waiting, and context switching. In outsourcing, where every hour has a direct revenue implication, this split matters enormously. Your company has 40 developers. You bill clients for their time. But how much of each developer's available time is actually billable? If the answer is "I'm not sure," you have a profitability blind spot that could be costing you hundreds of thousands of dollars annually. **Developer utilization is the single most important financial metric in outsourcing.** And most companies measure it wrong — or don't measure it at all. ## What Is Developer Utilization? Developer utilization is the ratio of billable (productive) time to total available time. In outsourcing, the formula is: ``` Utilization Rate = (Billable Hours / Available Hours) × 100% ``` For example, if a developer is available 160 hours per month (standard full-time) and bills 136 hours to client projects: ``` Utilization Rate = (136 / 160) × 100% = 85% ``` This seems simple. But the devil is in how you define "billable hours" and "available hours." ### What Counts as Billable Hours? In outsourcing, billable hours are the hours you can charge to a client. This typically includes: - Active coding on client projects - Code reviews for client project code - Bug fixing and debugging - Technical documentation for the client - Client-specific meetings (standups, planning, demos) ### What Counts as Non-Billable Hours? These are hours the developer works but you can't charge a client for: - Bench time (waiting for a project assignment) - Internal company meetings and training - Interview participation (hiring other developers) - Internal tool development - General professional development - Context switching between projects - Administrative tasks (timesheets, expense reports) ### What Counts as Available Hours? Total available hours = working days × hours per day, minus: - Paid time off (vacation, sick days) - Public holidays - Company-mandated training days For a standard month: 22 working days × 8 hours = 176 hours. Minus 2 days average PTO = 160 hours. This is the denominator most outsourcing companies use. ![Working calendar settings defining work days and hours](https://pandev-metrics.com/img/blog/calendar-settings.png) The calendar settings in PanDev define your organization's working days and hours (e.g., Mon-Fri, 09:00-18:00) — this baseline is what utilization calculations are measured against. ## Why Most Companies Measure Utilization Wrong ### Mistake 1: Using self-reported hours If developers fill out timesheets, they round to 8 hours per day. Every day. This creates a false 100% utilization rate that masks the truth. Nobody bills exactly 8 hours every day — there are meetings, breaks, context switches, and interruptions. Real utilization measured by IDE activity tracking is typically 15-25% lower than self-reported utilization. That gap is where your hidden costs live. ### Mistake 2: Measuring only billable hours, not productive hours A developer might be "billable" (assigned to a client project) but not productive (stuck in meetings, blocked by dependencies, or context-switching between tasks). True utilization has two layers: - **Billing utilization:** Hours assigned to a client / Available hours - **Productive utilization:** Hours of actual coding activity / Available hours The gap between these two numbers reveals organizational inefficiency. ### Mistake 3: Ignoring the bench When a developer finishes one project and hasn't started another, they're "on the bench." Bench time is a direct cost with zero revenue. Some companies exclude bench developers from utilization calculations — which makes the numbers look better but hides the problem. Always include bench time in your company-wide utilization calculation. If 5 out of 40 developers are on the bench, that's a 12.5% hit to company utilization that directly impacts profitability. ### Mistake 4: Treating 100% as the target A developer at 100% utilization has zero time for: - Learning new technologies (making them more valuable long-term) - Mentoring junior developers (reducing overall team dependency) - Internal process improvement (making everyone more efficient) - Buffer for unexpected urgent requests Industry benchmarks — consistent with data from the Deloitte Global Outsourcing Survey and professional services benchmarking — suggest **75-85% utilization is the healthy range for outsourcing companies.** Below 75%, you have too much idle time. Above 85%, you're likely sacrificing long-term team health for short-term billing. ## How to Measure Utilization Accurately ### Step 1: Track Actual Coding Activity Replace self-reported timesheets with IDE-based activity tracking. Tools like PanDev Metrics capture actual time spent in the code editor through IDE heartbeats. This gives you: - **Objective data:** No rounding, no guessing, no forgetting - **Per-project granularity:** Know exactly how much time went to each client - **Daily resolution:** See patterns day by day, not just monthly totals ### Step 2: Categorize Time Not all tracked time is billable. Set up your tracking system to categorize: | Category | Example | Billable? | |----------|---------|:---------:| | Client Project A | Coding on client A's repo | Yes | | Client Project B | Coding on client B's repo | Yes | | Internal Tools | Working on company tooling | No | | Training Project | Following a course/tutorial | No | | No Activity | No tracked IDE time | No | PanDev Metrics categorizes automatically by project name. Client projects are mapped to client accounts, and internal projects are flagged accordingly. ### Step 3: Calculate Individual and Team Utilization **Individual utilization:** ``` Developer Alex K. Available hours: 160 (March 2026) Client project hours (tracked): 134.5 Internal hours (tracked): 12.0 Untracked hours: 13.5 Billing utilization: 134.5 / 160 = 84.1% Productive utilization: (134.5 + 12.0) / 160 = 91.6% ``` **Team utilization (10-person team):** ``` Total available hours: 1,600 Total client project hours: 1,180 Total internal hours: 95 Total untracked: 325 Team billing utilization: 1,180 / 1,600 = 73.8% ``` The team is at 73.8% billing utilization — slightly below the healthy range. Time to investigate what's eating those 325 untracked hours. ### Step 4: Calculate the Financial Impact Here's where utilization becomes a profitability story. Assumptions: - 40 developers - Average billing rate: $60/hour - Average developer cost (salary + overhead): $35/hour - Available hours per developer per month: 160 | Scenario | Billing Utilization | Billable Hours/Month | Revenue | Cost | Profit | |----------|:------------------:|:--------------------:|--------:|-----:|-------:| | Current state | 75% | 4,800 | $288,000 | $224,000 | $64,000 | | +5% improvement | 80% | 5,120 | $307,200 | $224,000 | $83,200 | | +10% improvement | 85% | 5,440 | $326,400 | $224,000 | $102,400 | A 5% improvement in utilization generates an additional **$19,200/month** or **$230,400/year** in profit. With the same team. No new hires. No rate increases. This is why utilization is the most important metric in outsourcing finance. ## What Drives Low Utilization (and How to Fix It) ### Driver 1: Bench Time **Symptom:** Developers with zero or near-zero billable hours. **Root causes:** - Project ended, no new project lined up - Mismatch between developer skills and available projects - Slow sales pipeline **Fixes:** - Start sales conversations 4-6 weeks before a project ends - Cross-train developers in high-demand technologies - Use bench time productively — internal tools, open-source contributions, training - Track bench duration and set targets (e.g., no developer on bench for more than 2 weeks) ### Driver 2: Over-Meeting **Symptom:** Developers with high available hours but low IDE time. The gap is filled with meetings. **Root causes:** - Client requires too many meetings - Internal process overhead (multiple standups, retrospectives, planning sessions) - Developer included in meetings they don't need to attend **Fixes:** - Audit meeting load per developer — compare meeting hours to coding hours - Set a team policy: no more than 2 hours of meetings per developer per day - Negotiate with clients to consolidate meetings - Remove developers from meetings where they're observers, not participants ### Driver 3: Context Switching **Symptom:** Developer assigned to multiple projects shows lower total productive hours than developers on single projects. **Root causes:** - Developer splitting time across 2-3 client projects - Frequent interruptions from different project stakeholders - Lack of dedicated focus blocks **Fixes:** - Minimize project splits — dedicate developers to single projects when possible - When splitting is necessary, use full-day blocks (not half-days or hourly switches) - Track the utilization difference between split and dedicated developers to quantify the cost ### Driver 4: Poor Onboarding **Symptom:** New developers show very low utilization in their first 2-4 weeks on a project. **Root causes:** - Inadequate project documentation - No buddy/mentor assigned - Complex local development setup - Unclear first tasks **Fixes:** - Create standardized onboarding checklists per project - Track time-to-productivity: how many days until a new developer's utilization matches the team average? - Assign a technical buddy for the first two weeks ### Driver 5: Technical Blockers **Symptom:** Developer activity drops mid-week, then recovers — suggesting they were blocked and had to wait for resolution. **Root causes:** - Waiting for code reviews - Blocked by environment/infrastructure issues - Dependency on another team's deliverable **Fixes:** - Monitor daily activity patterns — a sudden drop in a developer's tracked hours is a signal - Implement SLA for code reviews (e.g., all PRs reviewed within 4 hours) - Reduce environment dependencies with containerization and infrastructure-as-code ## Utilization Benchmarks for Outsourcing Based on industry data and our observations across outsourcing companies: | Utilization Range | Assessment | Typical Causes | |:-----------------:|------------|----------------| | **Below 65%** | Critical — profitability at risk | High bench time, many internal projects, process overhead | | **65% – 74%** | Below target — room for improvement | Some bench time, meeting overload, onboarding gaps | | **75% – 84%** | Healthy — target range | Well-managed allocation with room for non-billable work | | **85% – 90%** | High — watch for burnout | Efficient but potentially unsustainable | | **Above 90%** | Danger zone — unsustainable | No time for learning, no buffer for unexpected work | Your target depends on your business model. Staff augmentation companies can aim for the higher end (80-85%) because developers are dedicated to one client. Project-based outsourcing typically lands in the 70-80% range because of project transitions and internal coordination. ## Building a Utilization Dashboard Your utilization dashboard should show: ### Company-Level View - Overall billing utilization rate (current month and trend) - Number of developers on bench - Revenue at risk from under-utilization (calculated in dollars) - Distribution: how many developers are in each utilization bracket ### Team/Project Level View - Per-project utilization rates - Allocation efficiency: planned vs. actual hours per project - Budget burn rate: are projects consuming resources as planned? ### Individual Level View - Per-developer utilization rate - Billable vs. non-billable hours breakdown - Activity pattern (daily hours chart) - Project allocation (what percentage of time goes where) PanDev Metrics provides these views out of the box — with per-employee dashboards showing activity time, project breakdown, and cost data based on configured hourly rates. ## The Utilization Review Cadence ### Weekly (PM Level) - Check individual utilization for developers you manage - Identify anyone below 60% and investigate - Flag bench developers and escalate to sales/management ### Monthly (Management Level) - Review company-wide utilization rate - Calculate the financial impact of current utilization vs. target - Identify systemic issues (meeting overload, slow onboarding, bench backlog) - Set improvement targets for next month ### Quarterly (Executive Level) - Utilization trend over the quarter - Correlation between utilization and revenue - Utilization by client/project type — which engagements are most efficient? - Strategic decisions: hiring, training investments, service portfolio adjustments ## Key Takeaways - Developer utilization is the ratio of billable hours to available hours — and it directly drives outsourcing profitability - Self-reported timesheets create a false picture; IDE-based tracking reveals the truth - The healthy utilization target for outsourcing is 75-85% — not 100% - A 5% improvement in utilization can generate over $200,000 in annual profit for a 40-developer company - The top utilization killers are bench time, over-meeting, context switching, poor onboarding, and technical blockers - Each killer has specific, measurable fixes — but you need data to diagnose them - Build a utilization dashboard at company, team, and individual levels with weekly, monthly, and quarterly review cadences --- **Measure what matters.** [PanDev Metrics](https://pandev-metrics.com) tracks real developer activity across all your projects, calculates costs with configurable hourly rates, and gives you the utilization visibility you need to maximize outsourcing profitability. --- ## Staff Augmentation: How Clients Can See Augmented Developer Activity in Real Time URL: https://pandev-metrics.com/docs/blog/staff-augmentation-visibility Date: 2026-01-27 Tags: staff-augmentation, outsourcing, client-visibility, engineering-metrics, remote-teams Description: Hiring augmented developers but can't see what they do? Here's how CTOs get real-time visibility into outsourced developer activity without micromanaging. Staff augmentation is now the fastest-growing segment of the outsourcing market, according to the Deloitte Global Outsourcing Survey. Yet the model introduces a paradox that most buyers discover too late. You've augmented your engineering team with external developers. They attend your standups, push to your repos, and bill you monthly. But when the invoice arrives, you have an uncomfortable thought: **"I have no idea how these people actually spend their days."** You trust your in-house team because you see them in Slack, in code reviews, in the office. The augmented developers? They're a black box. And that black box is costing you tens of thousands of dollars a month. ## The Staff Augmentation Visibility Problem The model is simple: you "rent" developers from a vendor, and they work as part of your team. Unlike project-based outsourcing, you manage them directly. But this creates a paradox: **you have management responsibility without full management visibility.** With in-house developers, you accumulate informal signals: - You see who's online in the office or Slack - You notice who's active in code reviews - You hear who's asking smart questions in architecture discussions - You get a gut feeling for who's productive With augmented developers — especially remote ones — most of these signals disappear. You're left with: - Git commits (lagging indicator, easy to game) - Jira ticket movement (tells you what was done, not how long it took) - Self-reported status updates (subjective, infrequent) This information gap creates three problems: ### Problem 1: You Can't Justify the Cost When your CFO asks "are these external developers worth $10,000/month each?", you need more than "they seem to be doing good work." You need data showing hours worked, projects contributed to, and output consistency. ### Problem 2: You Can't Compare Performance Your in-house developer and the augmented developer work on similar tasks. You think the in-house developer is more productive, but is that perception or reality? Without comparable metrics, you can't make fair assessments. ### Problem 3: You Can't Manage Effectively If an augmented developer is struggling — blocked by unclear requirements, fighting unfamiliar tooling, or simply underperforming — you won't know until deliverables slip. By then, you've lost weeks of time and budget. ## What Real-Time Visibility Looks Like "Real-time visibility" doesn't mean watching a developer's screen. That's surveillance, and it destroys the trust that makes staff augmentation work. Real-time visibility means having access to **activity metrics** that update continuously: ![Employee list showing status, source, access rights, and last activity](https://pandev-metrics.com/img/blog/employee-list-online.png) The employee list view shows each developer's status (Active/Inactive), access rights, and last activity timestamp — giving you instant visibility into augmented developer activity without invasive monitoring. ### Activity Dashboard A dashboard showing each augmented developer's: - **Hours coded today** — How much active IDE time has been logged so far? - **Hours coded this week/month** — Are they on pace for the contracted hours? - **Project activity** — Which repositories and services are they working on? - **Activity pattern** — When do they typically start and end their coding day? - **Technology breakdown** — What languages and frameworks are they working in? This isn't surveillance data. It's the same kind of data your in-house developers generate when they push commits, update tickets, and appear in Slack. The difference is it's automated, consistent, and objective. ### How It Works Technically The augmented developer installs a lightweight IDE plugin (takes 2 minutes). The plugin sends activity heartbeats — metadata about coding activity — to a platform like PanDev Metrics. What the heartbeat contains: - Timestamp - Project name - Programming language - Activity type What the heartbeat does NOT contain: - Screen content - File contents - Keystrokes - Personal browsing data The plugin runs silently inside the IDE. It doesn't affect performance, doesn't pop up notifications, and doesn't require any manual action from the developer. They install it once and forget about it. As the client, you get a read-only dashboard showing aggregated activity for your augmented developers. You can see daily hours, weekly trends, and project-level breakdowns — all updated in real time. ## Setting Up Client Visibility: A Step-by-Step Guide ### Step 1: Negotiate Visibility in the Contract Visibility should be discussed before the engagement starts, not after problems arise. Add a clause to your staff augmentation agreement: > "The vendor agrees to provide real-time activity tracking for all augmented developers assigned to the client's projects. Tracking will be limited to IDE activity metadata (timestamps, project names, languages) and will not include screen capture or keystroke logging." Most modern outsourcing vendors will agree to this. Many already have tracking in place for their own internal management. ### Step 2: Choose the Tracking Platform You have two options: **Option A: Vendor's Platform** The outsourcing vendor already uses PanDev Metrics (or similar). They grant you read-only access to view your augmented developers' dashboards. This is the fastest path — no setup on your side. **Option B: Client's Platform** You deploy PanDev Metrics yourself (cloud or on-premise) and ask the augmented developers to install plugins connected to your workspace. This gives you full control over the data and ensures it meets your security requirements. For most engagements, Option A is sufficient. For security-sensitive projects (fintech, healthcare, government), Option B with on-premise deployment is recommended. ### Step 3: Configure Developer Profiles For each augmented developer, set up: - **Name and role** — Senior Backend Developer, Frontend Engineer, etc. - **Hourly rate** — as per the contract - **Project assignment** — which of your projects they're working on - **Expected hours** — contracted hours per month (e.g., 160) This allows the platform to calculate: - Cost per developer - Budget utilization - Hours worked vs. contracted ### Step 4: Establish a Baseline (Week 1-2) Don't jump to conclusions from the first day of data. Give the system two weeks to establish a baseline: - What's the typical daily coding time for each developer? - What's their natural work pattern (early start? late finish? lunch break visible?) - How many hours per week are they consistently delivering? Use this baseline as the "normal" against which you measure future activity. ### Step 5: Set Up Alerts Configure alerts for situations that need attention: - **Low activity alert:** Developer logs less than 4 hours of IDE time for 2 consecutive days - **Budget alert:** Spending reaches 75% or 90% of monthly budget - **Inactivity alert:** No activity recorded for a full business day (might indicate a blocker or unreported PTO) Alerts turn the dashboard from something you have to check into something that notifies you when it matters. ## What to Do With the Data Having data is one thing. Using it well is another. Here's how to act on augmented developer activity data without being a micromanager. ### Weekly Glance (2 minutes) Once a week, pull up the dashboard and check: 1. **Are contracted hours on pace?** If you're paying for 160 hours/month, by week 2 they should be around 80 hours. If they're at 60, ask why. 2. **Are they working on the right project?** If your augmented backend developer is spending 30% of their time on a project you don't recognize, clarify. 3. **Is the pattern consistent?** Sudden drops in activity suggest blockers or disengagement. ### Monthly Review (15 minutes) At the end of each month: 1. **Compare actual hours to contracted hours.** Are you getting what you're paying for? 2. **Calculate effective cost.** If you're paying $10,000/month for a developer who logged 140 hours, your effective rate is $71.43/hour. Compare this to your contracted rate. 3. **Review the trend.** Is activity increasing (developer ramping up), stable (fully productive), or declining (possible disengagement)? 4. **Share with the vendor.** If there are issues, bring data to the conversation. "Your developer logged 120 hours against a 160-hour contract" is a much more productive conversation starter than "we feel like we're not getting enough output." ### Quarterly Strategic Review (30 minutes) Zoom out and evaluate: 1. **Is staff augmentation delivering ROI?** Compare the cost of augmented developers to the value of their output. 2. **Should you convert any augmented developers to full-time?** High-performing, consistently utilized developers might be cheaper in-house long-term. 3. **Should you scale up or down?** Activity data shows whether your current team is at capacity or has room for more work. ## Comparing In-House and Augmented Developer Metrics One of the most powerful uses of activity tracking is comparing in-house and augmented developers on the same metrics. | Metric | In-House Team (avg) | Augmented Devs (avg) | |--------|:------------------:|:-------------------:| | Daily IDE time | 6.2 hours | 6.8 hours | | Active coding days/month | 20 | 21 | | Primary project focus | 85% | 92% | | Code review participation | 4.5 hours/week | 2.1 hours/week | | Technologies used | 3.2 | 2.1 | *Example data — not from a specific company.* This comparison might reveal that augmented developers log more hours but participate less in code reviews — suggesting they're productive but not fully integrated into the team's workflows. That's an actionable insight: pair them more frequently in code reviews to increase integration. ## Privacy and Trust: Getting the Balance Right Activity tracking can strengthen or destroy the augmented relationship depending on how you implement it. ### Do: - **Be transparent about tracking.** Tell augmented developers exactly what's tracked and what isn't. Show them the dashboard they'll appear on. - **Track metadata, not content.** Timestamps, project names, and languages — not screen content, keystrokes, or file contents. - **Use data for management, not punishment.** Low hours for a day should trigger a "are you blocked?" conversation, not a reprimand. - **Track everyone equally.** If you track augmented developers, track in-house developers too. Unequal tracking creates resentment. - **Respect time zones.** Augmented developers may work in different time zones. Judge their output by daily totals, not by whether they're online during your business hours. ### Don't: - **Don't use screenshots.** Screenshot monitoring is invasive, easy to game, and signals distrust. It's counterproductive. - **Don't share individual data widely.** Activity data should be visible to the developer's direct manager, not broadcast to the entire company. - **Don't micro-react to daily fluctuations.** A developer having a 4-hour day after three 8-hour days is normal — they might be doing research, attending meetings, or simply recovering from deep work. Look at weekly and monthly patterns instead. - **Don't equate IDE time with output.** A senior developer who codes for fewer hours but solves a critical architecture problem is more valuable than a junior developer who writes boilerplate all day. This is consistent with the SPACE framework (Forsgren et al., 2021), which emphasizes that productivity must be measured across multiple dimensions. Use activity data as one input, not the only input. ## The Vendor's Perspective: Why This Benefits Them Too If you're an outsourcing vendor reading this, real-time visibility isn't a threat — it's a selling tool. ### It reduces churn Clients who can verify activity stay longer. The ones who leave are usually the ones who built up doubt over months without any way to resolve it. ### It justifies your rates When a client sees their augmented developer logging 7+ hours of active coding daily, your $80/hour rate feels like a bargain compared to the cost of hiring full-time. ### It differentiates you from competitors Offer real-time dashboards to clients and watch your close rates improve. When a prospect is choosing between you and a competitor who only offers monthly reports, the visibility advantage is decisive. ### It protects you from unfair accusations If a client claims your developer isn't working, you have timestamped data to prove otherwise. Data is your shield. ## Implementation Checklist For CTOs considering activity tracking for augmented developers: - [ ] Evaluate tracking platforms (PanDev Metrics, etc.) - [ ] Decide on deployment model (vendor's cloud, your cloud, on-premise) - [ ] Add visibility clause to staff augmentation contracts - [ ] Brief augmented developers on what's tracked and why - [ ] Configure developer profiles with rates and project assignments - [ ] Establish a 2-week baseline before drawing conclusions - [ ] Set up automated alerts for low activity and budget thresholds - [ ] Schedule weekly dashboard check (2 minutes) and monthly review (15 minutes) - [ ] If tracking augmented devs, consider tracking in-house devs equally - [ ] Share anonymized metrics in quarterly vendor reviews ## Key Takeaways - Staff augmentation creates a visibility gap — you manage the developers but can't see their daily work patterns - Real-time visibility through IDE activity tracking closes this gap without surveillance - Activity data helps justify cost, compare performance, and detect problems early - Track metadata (timestamps, projects, languages), never screen content or keystrokes - Use data for weekly glances, monthly reviews, and quarterly strategic decisions - Treat augmented and in-house developers equally in tracking policies - For vendors: real-time visibility is a competitive advantage, not a threat --- **See what your augmented team actually does.** [PanDev Metrics](https://pandev-metrics.com) gives CTOs real-time IDE activity dashboards for augmented developers — hours tracked, projects identified, costs calculated — all without screenshots or invasive monitoring. --- ## PanDev + GitLab: Complete Setup in 15 Minutes URL: https://pandev-metrics.com/docs/blog/setup-gitlab-15-minutes Date: 2026-01-23 Tags: integration, gitlab, setup, tutorial Description: Step-by-step guide to connecting GitLab with PanDev Metrics via webhooks. Track merge requests, commits, and repo events in under 15 minutes. Setting up a Git integration shouldn't take a sprint. With GitLab and PanDev Metrics, it takes about 15 minutes — then every commit, merge request, and pipeline event flows into your engineering dashboard automatically. This guide covers both GitLab SaaS (gitlab.com) and self-managed instances. No plugins, no complex OAuth flows — just [webhooks](https://docs.gitlab.com/ee/user/project/integrations/webhooks.html) and a [personal access token](https://docs.gitlab.com/ee/user/profile/personal_access_tokens.html). ## What You'll Get Once the integration is live, PanDev Metrics will track: - **Commits** — who committed, when, what changed, and how many lines - **Merge Requests** — time to open, review duration, merge cycle time - **MR Reviews** — comments, approvals, change requests per reviewer - **Repository events** — branch creation, tag pushes, pipeline triggers All of this feeds into your DORA metrics, cycle time dashboards, and individual contributor profiles. ## Prerequisites Before you begin, make sure you have: | Requirement | Details | |-------------|---------| | GitLab account | Owner or Maintainer role on the projects you want to track | | PanDev Metrics account | Admin or Manager role | | Network access | Your GitLab instance must be able to reach PanDev's webhook endpoint (or your on-premise PanDev instance) | ## Step 1: Generate a GitLab Personal Access Token PanDev needs read access to your repositories and merge requests. A Personal Access Token (PAT) is the simplest way to grant this. 1. In GitLab, go to **User Settings → Access Tokens** 2. Click **Add new token** 3. Configure the token: ``` Token name: pandev-metrics-integration Expiration date: (set to 1 year or your security policy) Scopes: ✅ read_api ✅ read_repository ``` 4. Click **Create personal access token** 5. **Copy the token immediately** — you won't see it again If you're connecting multiple projects under one group, consider using a **Group Access Token** instead. Go to **Group → Settings → Access Tokens** and follow the same steps. This avoids tying the integration to a specific user account. ![Git General settings showing integration mode and branch configuration](https://pandev-metrics.com/img/blog/settings-git-detail.png) The Git General settings page lets you enable Git integration, configure project filtering, and define your main branch flow (dev, test, prod, stable). ## Step 2: Add the Token to PanDev Metrics 1. Log in to PanDev Metrics 2. Navigate to **Settings → Integrations → GitLab** 3. Click **Add GitLab Connection** 4. Fill in the connection details: ``` GitLab URL: https://gitlab.com (or your self-managed URL) Access Token: glpat-xxxxxxxxxxxxxxxxxxxx ``` 5. Click **Test Connection** You should see a green checkmark and a list of available groups and projects. If the test fails, double-check your token scopes and network connectivity. ## Step 3: Select Projects to Track After a successful connection, PanDev displays all projects your token can access. 1. Use the search bar or browse the group tree 2. **Check the boxes** next to projects you want to track 3. Click **Save Selection** If you have 50+ projects, you can select entire groups. PanDev will automatically pick up new projects added to that group later. ## Step 4: Configure Webhooks Webhooks are what make the integration real-time. Without them, PanDev would have to poll the GitLab API — slower and rate-limited. PanDev can create webhooks automatically, but here's how to do it manually if your security policy requires it. ### Automatic Setup (Recommended) In the PanDev integration page, click **Setup Webhooks Automatically**. PanDev will create a webhook on each selected project with the correct URL and events. ### Manual Setup If you prefer to create webhooks yourself: 1. In GitLab, go to your **Project → Settings → Webhooks** 2. Click **Add new webhook** 3. Configure: ``` URL: https://hooks.pandev-metrics.com/api/v1/gitlab/webhook Secret token: (copy from PanDev Settings → Integrations → GitLab → Webhook Secret) Trigger events: ✅ Push events ✅ Merge request events ✅ Comments ✅ Pipeline events (optional — for DORA deployment tracking) SSL verification: ✅ Enable SSL verification ``` 4. Click **Add webhook** 5. Test it by clicking the **Test** dropdown → **Push events** You should see a `200 OK` response. If you get a timeout, check your firewall rules. ### Group-Level Webhooks (GitLab Premium) GitLab Premium and Ultimate editions support [group-level webhooks](https://docs.gitlab.com/ee/user/project/integrations/webhooks.html#group-webhooks), which let you set up a single webhook for all projects in a group: 1. Go to **Group → Settings → Webhooks** 2. Use the same URL and secret as above 3. This covers all current and future projects in the group ## Step 5: Verify the Data Flow Give it a minute, then check PanDev Metrics: 1. Go to **Dashboard → Activity Feed** 2. You should see recent commits and merge requests appearing 3. Open any project in PanDev — the **Commits** and **Merge Requests** tabs should show data If data isn't flowing: | Symptom | Fix | |---------|-----| | No data at all | Check webhook delivery logs in GitLab (Project → Settings → Webhooks → Edit → Recent Deliveries) | | Commits appear but no MRs | Ensure `Merge request events` is enabled in the webhook | | 401 errors in webhook logs | Regenerate the webhook secret in PanDev and update it in GitLab | | Timeout errors | Check if your firewall allows outbound traffic to `hooks.pandev-metrics.com` on port 443 | ## Step 6: Map GitLab Users to PanDev Profiles For accurate per-developer metrics, PanDev needs to know which GitLab user corresponds to which team member. 1. Go to **Settings → Team Management** 2. PanDev will show a list of detected GitLab usernames 3. **Map each username** to the correct team member profile 4. If a developer uses multiple email addresses for commits, add all aliases under their profile This step is critical for: - Accurate individual productivity metrics - Correct cycle time attribution - Cross-platform identity resolution (if the same person uses GitLab + Jira) ## Step 7: Configure Metric Preferences (Optional) Fine-tune what PanDev tracks: ### Working Hours ``` Settings → Organization → Working Hours Default: Mon-Fri, 09:00-18:00 Timezone: Auto-detected per user, or set organization default ``` Cycle time calculations use working hours by default. A merge request opened Friday at 17:00 and merged Monday at 10:00 counts as **1 working hour**, not 65 calendar hours. ### Excluded Paths Filter out noise from auto-generated files: ``` Settings → Projects → [Your Project] → Excluded Paths Examples: - package-lock.json - yarn.lock - *.generated.ts - vendor/** - dist/** ``` ### Branch Filters Track only branches that matter: ``` Settings → Projects → [Your Project] → Branch Filters Include: main, master, develop, release/*, feature/* Exclude: dependabot/*, renovate/* ``` ## What Your Dashboard Looks Like After Setup Within 24 hours of setup (or less, if your team is active), you'll see: - **Cycle Time breakdown** — from first commit to merge, split by coding, review, and waiting time - **MR Throughput** — how many merge requests ship per day/week - **Review Load** — who reviews the most, and how fast - **Commit Patterns** — when your team is most active - **DORA Metrics** — deployment frequency, lead time, MTTR, and change failure rate (requires pipeline webhooks) ## Troubleshooting ### "Token expired" error after a few months GitLab PATs have expiration dates. Set a calendar reminder to rotate the token before it expires. Update it in **PanDev → Settings → Integrations → GitLab → Edit Connection**. ### Self-managed GitLab behind a VPN Two options: 1. **Allow-list PanDev's IP range** — contact support@pandev-metrics.com for the current IP list 2. **Deploy PanDev on-premise** — run PanDev inside your network via Docker or Kubernetes (see our on-premise deployment guide) ### Webhook delivery failures after GitLab upgrade After major GitLab upgrades, webhook signing may change. Re-test your webhooks and regenerate the secret if needed. > "As a CTO and for our tech leads, it's important to see not individual employees but the state of the development process: where it's efficient and where it breaks down. The product allows natively collecting metrics right from the IDE, without feeling controlled or surveilled. Implementation was very simple." > — Maksim Popov, CTO ABR Tech ([Forbes Kazakhstan, April 2026](https://forbes.kz)) ## Next Steps Your GitLab integration is live. Here's what to do next: - **Add IDE plugins** — install the VS Code or JetBrains plugin for coding time tracking - **Connect Jira or ClickUp** — link coding activity to tasks and sprints - **Set up team dashboards** — create views for each team lead - **Enable the AI assistant** — ask questions like "What was our average cycle time last sprint?" --- **Ready to connect GitLab?** [Start with PanDev Metrics](https://pandev-metrics.com) — setup takes 15 minutes, and the first insights arrive within hours. --- ## PanDev + GitHub: Integration via GitHub App URL: https://pandev-metrics.com/docs/blog/setup-github Date: 2026-01-22 Tags: integration, github, setup, tutorial Description: How to connect GitHub to PanDev Metrics using the official GitHub App and OAuth. Full walkthrough with screenshots and troubleshooting. Managing personal access tokens and manual webhooks for every repo gets old fast. PanDev Metrics integrates with GitHub through a dedicated **[GitHub App](https://docs.github.com/en/apps/creating-github-apps/about-creating-github-apps/about-creating-github-apps)** — no tokens to rotate, fine-grained permissions out of the box, and automatic webhook management. This guide walks you through installing the app, granting permissions, and verifying that commit and pull request data flows into your dashboards. ## GitHub App vs. Personal Access Token Before we start, let's clarify why PanDev uses a GitHub App instead of a PAT: | Feature | GitHub App | Personal Access Token | |---------|------------|----------------------| | Tied to a person | No — installed at org level | Yes — if the person leaves, integration breaks | | Permissions | Fine-grained, per-repository | Broad scopes | | Rate limits | Higher (5,000+ req/hour) | Lower (5,000 req/hour shared across all tools) | | Webhook management | Automatic | Manual | | OAuth for users | Built-in | Separate setup | The GitHub App approach is [GitHub's recommended integration pattern](https://docs.github.com/en/apps/creating-github-apps/about-creating-github-apps/about-creating-github-apps#github-apps-offer-enhanced-security) for third-party tools. ## Prerequisites | Requirement | Details | |-------------|---------| | GitHub account | **Organization Owner** role to install the app, or individual account for personal repos | | PanDev Metrics account | Admin or Manager role | | Repositories | At least one repo you want to track | ![Git General settings showing integration mode and branch configuration](https://pandev-metrics.com/img/blog/settings-git-detail.png) The Git General settings page shows integration toggles, project filtering, and branch flow configuration — your starting point for connecting GitHub to PanDev Metrics. ## Step 1: Start the Connection in PanDev 1. Log in to PanDev Metrics 2. Go to **Settings → Integrations → GitHub** 3. Click **Connect GitHub** PanDev redirects you to GitHub's app installation page. ## Step 2: Install the PanDev GitHub App On the GitHub installation page: 1. **Select the organization** (or your personal account) where you want to install the app 2. Choose repository access: ``` ◉ All repositories PanDev will automatically track new repos as they're created. ○ Only select repositories Pick specific repos from the list below. ``` For most teams, **"Only select repositories"** is the safer starting point. You can always add more later. 3. Review the permissions the app requests: ``` Repository permissions: Contents: Read-only (to read commits and files) Metadata: Read-only (basic repo info) Pull requests: Read-only (to track PRs, reviews, comments) Checks: Read-only (optional — for CI/CD metrics) Organization permissions: Members: Read-only (to map users to profiles) Events: ✅ Push ✅ Pull request ✅ Pull request review ✅ Pull request review comment ✅ Check run (optional) ``` 4. Click **Install & Authorize** GitHub redirects you back to PanDev. ## Step 3: Complete OAuth Authorization After the app is installed, PanDev asks you to authorize via OAuth. This is a separate step from app installation — it links your personal GitHub identity to your PanDev profile. 1. Click **Authorize PanDev Metrics** 2. GitHub shows the OAuth consent screen 3. Click **Authorize** You're redirected back to PanDev, and you should see a success message: ``` ✅ GitHub connected successfully Organization: your-org Repositories: 12 selected ``` ## Step 4: Verify Repository Discovery After connection, PanDev imports metadata from your selected repositories: 1. Go to **Settings → Integrations → GitHub** 2. You should see your organization listed with the connected repos 3. Each repo shows its sync status: ``` Repository Status Last Sync ─────────────────────────────────────────────────── your-org/frontend ✅ Active Just now your-org/backend-api ✅ Active Just now your-org/infra ✅ Active Just now your-org/docs ⏸ Paused — ``` If a repo shows as "Paused," it means PanDev detected it but you haven't enabled tracking. Click the toggle to activate it. ## Step 5: Historical Data Import PanDev automatically imports historical data for the last **90 days** when you first connect a repository. This includes: - All commits on the default branch and merged PR branches - All pull requests (open, closed, merged) - All PR reviews and comments - All check runs and pipeline statuses The import runs in the background. For a typical repo with a few thousand commits, it takes **2–5 minutes**. Large monorepos (100K+ commits) may take up to 30 minutes. Track progress at **Settings → Integrations → GitHub → Import Status**. ## Step 6: Map GitHub Users to Team Members For accurate metrics, PanDev needs to associate GitHub identities with team member profiles. 1. Go to **Settings → Team Management** 2. PanDev shows a list of detected GitHub usernames from your repos 3. For each user, either: - **Auto-match** — PanDev tries to match by email address - **Manual match** — select the correct team member from a dropdown - **Ignore** — for bots, service accounts, or external contributors you don't need to track ### Handling Multiple Identities Developers often commit with different email addresses or usernames: ``` Same person, different identities: - GitHub user: @jsmith - Commit email: john.smith@company.com - Commit email: john@personal.email - Git author: "John Smith" - Git author: "jsmith" ``` In PanDev, go to the team member's profile and add all aliases under **Identity Aliases**. PanDev will merge activity from all identities into a single profile. ## Step 7: Configure Tracking Preferences ### Exclude Noisy Files Prevent auto-generated files from inflating line-count metrics: ```yaml # Settings → Projects → [Repo] → Excluded Paths excluded_paths: - "package-lock.json" - "yarn.lock" - "Gemfile.lock" - "*.generated.*" - "vendor/**" - "node_modules/**" - "dist/**" - "__snapshots__/**" ``` ### Branch Strategy Tell PanDev how your team uses branches: ``` Settings → Projects → [Repo] → Branch Configuration Default branch: main Production branches: main, release/* Feature branch pattern: feature/*, fix/*, chore/* Ignored branches: dependabot/*, renovate/*, gh-pages ``` This affects cycle time calculations — PanDev measures the time from first commit on a feature branch to merge into the production branch. ### Working Hours ``` Settings → Organization → Working Hours Schedule: Monday–Friday Hours: 09:00–18:00 Timezone: America/New_York (or per-user) Exclude holidays: ✅ (upload your company holiday calendar) ``` ## Step 8: Explore Your Dashboard With data flowing, your dashboard populates within minutes. Here's what to look at first: ### Pull Request Metrics | Metric | What it shows | |--------|---------------| | **PR Cycle Time** | Total time from PR open to merge | | **Time to First Review** | How long PRs wait before someone reviews | | **Review Turnaround** | Time between review request and review submission | | **PR Size** | Lines changed per PR (smaller is usually better) | | **PR Throughput** | PRs merged per day/week/sprint | ### Commit Metrics | Metric | What it shows | |--------|---------------| | **Commit Frequency** | Commits per developer per day | | **Active Contributors** | Unique committers per week | | **Code Churn** | Lines added then modified within the same sprint | ### DORA Metrics If you enabled check run events: | DORA Metric | Source | |-------------|--------| | Deployment Frequency | Merged PRs to production branches | | Lead Time for Changes | First commit → production merge | | Mean Time to Recovery | Time between failure and fix deployments | | Change Failure Rate | Ratio of failed to total deployments | ## Managing the GitHub App ### Adding More Repositories 1. Go to **GitHub → Settings → Applications → PanDev Metrics → Configure** 2. Under "Repository access," add new repos 3. PanDev automatically detects the change and starts syncing ### Removing Repositories Same path as above — deselect repos you no longer want to track. Historical data is retained in PanDev for 90 days after disconnection. ### Uninstalling the App To completely remove the integration: 1. **GitHub side**: Settings → Applications → PanDev Metrics → Uninstall 2. **PanDev side**: Settings → Integrations → GitHub → Disconnect ## Troubleshooting ### No data appearing after installation 1. Check that webhooks are delivering: GitHub → Repo → Settings → Webhooks → Recent Deliveries 2. Verify the app has the correct permissions: GitHub → Settings → Applications → PanDev Metrics → Permissions 3. Ensure the repo is enabled in PanDev (not paused) ### "Insufficient permissions" error The GitHub App needs to be installed by an **Organization Owner**. If you're a member, ask an owner to install it, then authorize with your own account via OAuth. ### Rate limiting during historical import For very large organizations (1,000+ repos), PanDev staggers the import to stay within GitHub's rate limits. The import may take a few hours. You'll see progress in the import status page. ### GitHub Enterprise Server (self-hosted) PanDev supports [GitHub Enterprise Server](https://docs.github.com/en/enterprise-server/admin/overview/about-github-enterprise-server). During setup, select **"GitHub Enterprise"** and enter your instance URL: ``` GitHub Enterprise URL: https://github.yourcompany.com ``` The GitHub App installation flow works the same way. Ensure your GitHub Enterprise instance can reach PanDev's webhook endpoint, or deploy PanDev on-premise. ## Next Steps Your GitHub integration is live. Consider these follow-up actions: - **Connect your project tracker** — link Jira or ClickUp to correlate coding activity with tasks - **Install IDE plugins** — add VS Code or JetBrains plugins for coding time data - **Share dashboards** — invite team leads to PanDev and create per-team views - **Set up alerts** — get notified when cycle time exceeds your team's threshold --- **Connect GitHub in 5 minutes.** [Start tracking your engineering metrics](https://pandev-metrics.com) with PanDev Metrics — no tokens to rotate, no webhooks to manage manually. --- ## PanDev + Jira: Linking Tasks to Real Coding Time URL: https://pandev-metrics.com/docs/blog/setup-jira Date: 2026-01-19 Tags: integration, jira, setup, tutorial, project-management Description: Connect Jira to PanDev Metrics and see how much actual coding time each task, sprint, and epic requires. A guide for PMs and Engineering Managers. Your Jira board says a task took 3 days. But how much of that was actual coding? How much was waiting for review? How much was context switching between other tickets? PanDev Metrics bridges Jira's task management with real developer activity data — commits, IDE time, code reviews — so you see the full picture. Not just "in progress" and "done," but what happened in between. The integration uses [Jira's REST API and OAuth 2.0](https://developer.atlassian.com/cloud/jira/platform/rest/v3/intro/) for secure, read-only access to your project data. ![Integration settings panel in PanDev Metrics](https://pandev-metrics.com/img/blog/settings-git-detail.png) *Integration settings panel in PanDev Metrics.* ## Why Connect Jira to PanDev? Jira tracks **workflow states** — To Do, In Progress, In Review, Done. PanDev tracks **actual engineering activity** — commits, code reviews, IDE coding sessions. When you connect the two, you unlock insights that neither tool provides alone: | Insight | Jira alone | PanDev + Jira | |---------|-----------|---------------| | Task status | ✅ | ✅ | | Time in each status | ✅ (manual transitions) | ✅ (automatic) | | Actual coding time per task | ❌ | ✅ | | Code review time per task | ❌ | ✅ | | Wait time between coding and review | ❌ | ✅ | | Lines of code per story point | ❌ | ✅ | | Sprint velocity (in real effort, not estimates) | ❌ | ✅ | This is especially valuable for **Engineering Managers** who want to understand where time goes, and **Project Managers** who want better estimation data. ## Prerequisites | Requirement | Details | |-------------|---------| | Jira account | Jira Cloud or Jira Data Center. Admin role for the initial setup | | PanDev Metrics account | Admin or Manager role | | Git integration | At least one git provider (GitLab, GitHub, Bitbucket, or Azure DevOps) already connected to PanDev | The git integration is important — PanDev links commits to Jira issues by matching issue keys in commit messages and branch names. ## Step 1: Connect Jira to PanDev 1. In PanDev, go to **Settings → Integrations → Jira** 2. Click **Add Jira Connection** 3. Enter your Jira instance URL: ``` Jira URL: https://your-company.atlassian.net ``` 4. Click **Connect** 5. Jira's OAuth consent screen appears — review the requested permissions: ``` PanDev Metrics wants to: ✅ View Jira issues and projects ✅ View Jira worklogs ✅ View Jira sprint and board data ✅ View user profiles ``` 6. Click **Accept** You're redirected back to PanDev with a success confirmation. ## Step 2: Select Projects to Sync After connecting, PanDev lists all Jira projects your account can access: 1. Browse the project list or search by name/key 2. **Enable** the projects you want to track 3. Click **Save** ``` Project Key Issues Status ───────────────────────────────────────────── Frontend App FE 1,247 ✅ Enabled Backend API API 3,891 ✅ Enabled Mobile App MOB 682 ✅ Enabled Internal Tools INT 156 ⬜ Disabled Design System DS 94 ⬜ Disabled ``` If you have dozens of Jira projects, start with 2-3 active engineering projects. You can add more later without losing data. ## Step 3: Configure Issue Key Matching This is the magic link between Jira and your git activity. PanDev matches Jira issue keys found in: 1. **Commit messages** — `FE-1234: Fix login button alignment` 2. **Branch names** — `feature/FE-1234-login-fix` 3. **Pull request titles** — `[FE-1234] Fix login button alignment` 4. **Pull request descriptions** — any mention of `FE-1234` PanDev detects these patterns automatically. No configuration needed if your team follows standard naming conventions. ### Custom Matching Rules If your team uses non-standard patterns, you can add custom rules: ``` Settings → Integrations → Jira → Matching Rules Default patterns (always active): ✅ [PROJECT_KEY]-[NUMBER] in commit messages ✅ [PROJECT_KEY]-[NUMBER] in branch names ✅ [PROJECT_KEY]-[NUMBER] in PR titles and descriptions Custom patterns: + Add pattern: "task/([A-Z]+-\d+)" → extract issue key from branch names like task/FE-1234-description + Add pattern: "closes #(\d+)" → match numeric-only references (requires project context) ``` ## Step 4: Sync Worklogs (Optional) If your team logs time in Jira, PanDev can import worklog data and compare it with actual IDE activity: 1. Go to **Settings → Integrations → Jira → Worklog Sync** 2. Toggle **Enable Worklog Sync** 3. Choose sync frequency: ``` Sync frequency: ○ Every hour ◉ Every 4 hours (recommended) ○ Once daily ``` Once enabled, PanDev creates a comparison view: | Task | Jira Logged | IDE Active | Git Active | Difference | |------|:-----------:|:----------:|:----------:|:----------:| | FE-1234 | 4h | 2h 15m | 1h 48m | Jira overestimated by 1h 45m | | FE-1235 | 2h | 3h 30m | 2h 52m | Jira underestimated by 1h 30m | | API-891 | 8h | 6h 10m | 5h 22m | Jira overestimated by 1h 50m | This isn't about catching people — it's about **improving estimation accuracy** over time. Research consistently shows that self-reported time logs diverge from actual activity by [20-40%](https://ieeexplore.ieee.org/document/8813289), making automated tracking a practical upgrade for any team that relies on time data for planning. ## Step 5: Map Jira Users to PanDev Profiles For cross-platform analytics, PanDev needs to know which Jira user is which team member: 1. Go to **Settings → Team Management** 2. PanDev shows detected Jira usernames alongside any existing GitHub/GitLab mappings 3. Confirm or correct the auto-matches ``` Team Member GitHub GitLab Jira ─────────────────────────────────────────────────────────── Anna Chen @achen @anna.chen anna.chen@company.com ✅ Boris Kim @bkim — boris.kim@company.com ✅ Carlos Diaz @cdiaz @carlos.d carlos@company.com ⚠️ Review ``` If a team member's Jira email differs from their git email, add both as aliases. ## Step 6: Explore the Jira Dashboard With data flowing, PanDev creates several Jira-specific views: ### Task-Level Metrics Click any Jira issue in PanDev to see its full engineering timeline: ``` FE-1234: Fix login button alignment ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Jira Status Flow: To Do ──(2d)──▸ In Progress ──(1d 3h)──▸ In Review ──(4h)──▸ Done Actual Engineering Activity: Mar 5, 10:23 First commit (anna.chen) +45 / -12 lines Mar 5, 11:07 Second commit (anna.chen) +23 / -8 lines Mar 5, 14:30 PR opened → backend-api#342 Mar 5, 16:15 Review comment (boris.kim) Mar 6, 09:45 Fix commit (anna.chen) +7 / -3 lines Mar 6, 10:12 PR approved (boris.kim) Mar 6, 10:30 PR merged Total coding time (IDE): 2h 15m Total review time: 45m Wait time (coding → review): 1h 45m Wait time (review → merge): 17m ``` ### Sprint Analytics PanDev's sprint view goes beyond velocity charts: | Sprint Metric | What it shows | |---------------|---------------| | **Planned vs. Delivered** | Story points committed vs. completed | | **Real Effort Distribution** | How coding time splits across tasks in the sprint | | **Carry-over Analysis** | Tasks that spilled into the next sprint and their actual progress | | **Review Bottleneck** | Tasks that spent more time waiting for review than being coded | | **Scope Creep** | Tasks added mid-sprint and their impact on delivery | ### Epic-Level Rollup For longer-term planning, PanDev aggregates data at the epic level: ``` Epic: User Authentication Revamp (AUTH) ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Tasks: 23 total, 19 completed, 4 in progress Total coding: 127 hours across 6 developers Total reviews: 34 hours Avg cycle time: 2.3 days per task Avg PR size: +142 / -67 lines Story points: 89 (estimated) → 97 (actual) ``` ## Step 7: Set Up Alerts and Reports ### Automated Alerts Configure alerts for common Jira workflow issues: ``` Settings → Alerts → Jira Available alerts: ✅ Task in "In Progress" with no commits for 48+ hours ✅ Task in "In Review" with no PR review activity for 24+ hours ✅ Sprint at risk — less than 60% of points completed by mid-sprint ⬜ Task cycle time exceeds 2x team average Notification channel: Slack #engineering-leads ``` ### Weekly Sprint Reports PanDev generates a weekly report combining Jira and git data: ``` Settings → Reports → Sprint Report Recipients: engineering-managers@company.com Frequency: Every Monday at 09:00 Include: ✅ Sprint progress vs. plan ✅ Top contributors by coding time ✅ Review bottleneck analysis ✅ Cycle time trend ✅ Carry-over tasks ``` ## Common Patterns and Tips ### Pattern 1: The "In Progress but Idle" Detector One of the most valuable alerts. If a Jira task has been "In Progress" for 2+ days but PanDev shows zero commits, branches, or IDE activity, something is wrong: - The developer is blocked and hasn't communicated it - The task was moved to "In Progress" prematurely - The developer is working on it but forgot to push commits This isn't micromanagement — it's early detection of blockers. ### Pattern 2: Estimation Calibration After 3-4 sprints of combined Jira + PanDev data, you have enough data to calibrate estimates: ``` Historical data for "Small" tasks (1-2 story points): Average actual coding time: 3.2 hours Average review time: 1.1 hours Average total cycle time: 1.4 days Historical data for "Medium" tasks (3-5 story points): Average actual coding time: 8.7 hours Average review time: 2.3 hours Average total cycle time: 3.1 days ``` Use this data in sprint planning to make more realistic commitments. ### Pattern 3: Review Load Balancing PanDev shows which team members handle the most code reviews relative to their coding time. If one person spends 40% of their time reviewing while others spend 5%, you have a bottleneck. ## Troubleshooting | Issue | Solution | |-------|----------| | No issues syncing | Check that Jira OAuth token hasn't expired. Re-authorize in Settings → Integrations → Jira | | Issues sync but no commit links | Ensure your team uses Jira issue keys in commit messages or branch names | | Worklog times don't match | PanDev and Jira may use different timezone settings. Align them in Settings → Organization | | Missing sprint data | PanDev requires Jira board access. Ensure the connected account can view boards, not just backlogs | ## Next Steps With Jira connected, you've built a bridge between project management and engineering reality. Here's what to explore: - **Sprint retrospectives** — use PanDev's sprint report as a data-driven input - **Estimation workshops** — show historical coding time per story point size - **Cross-team comparisons** — compare cycle time patterns across teams (carefully and with context) - **AI assistant** — ask "Which tasks took longer than estimated last sprint?" in natural language --- **See where your sprint time really goes.** [Connect Jira to PanDev Metrics](https://pandev-metrics.com) and turn status updates into engineering intelligence. --- ## PanDev + ClickUp: Task and Time Tracking in One Place URL: https://pandev-metrics.com/docs/blog/setup-clickup Date: 2026-01-16 Tags: integration, clickup, setup, tutorial, project-management Description: Connect ClickUp to PanDev Metrics for unified task tracking, time entries, and engineering analytics. Step-by-step integration guide. Every team lead asks the same question: **how much real effort does each task actually take?** ClickUp tracks work organization; PanDev Metrics tracks engineering activity. Together, they close the gap between "assigned" and "done." This guide walks you through connecting ClickUp to PanDev via the [ClickUp API](https://clickup.com/api/), syncing tasks and time entries, and using the combined data to make better planning decisions. ![Integration settings panel where ClickUp connection is configured](https://pandev-metrics.com/img/blog/settings-git-detail.png) *Integration settings panel where ClickUp connection is configured.* ## What the Integration Gives You ClickUp tracks tasks, statuses, and time entries. PanDev tracks commits, pull requests, IDE activity, and code reviews. The integration connects the two: - **Tasks linked to commits** — see exactly which code changes relate to which ClickUp task - **Time entries vs. IDE time** — compare logged time in ClickUp with actual coding sessions - **Sprint analytics** — real engineering effort per sprint, not just status transitions - **Cycle time** — from task creation to last commit, measured automatically ## Prerequisites | Requirement | Details | |-------------|---------| | ClickUp account | Workspace Owner or Admin for the API token | | PanDev Metrics account | Admin or Manager role | | Git integration | At least one git provider already connected to PanDev | ## Step 1: Generate a ClickUp API Token PanDev connects to ClickUp using a [personal API token](https://clickup.com/api/developer-tools/authentication/) or OAuth. The API token approach is simpler for most teams. 1. In ClickUp, click your **avatar** (bottom-left) → **Settings** 2. Go to **Apps** in the left sidebar 3. Under **API Token**, click **Generate** 4. **Copy the token** ``` Your ClickUp API token: pk_12345678_ABCDEFGHIJKLMNOPQRSTUVWXYZ1234567890 ``` The personal API token inherits **all permissions** of the user who generates it. For production use, consider creating a dedicated service account with read-only access to the workspaces you want to track. ## Step 2: Add the Connection in PanDev 1. In PanDev, go to **Settings → Integrations → ClickUp** 2. Click **Add ClickUp Connection** 3. Paste your API token 4. Click **Test Connection** PanDev verifies the token and shows your available workspaces: ``` ✅ Connection successful Available workspaces: • Acme Engineering (ID: 12345678) • Acme Design (ID: 87654321) ``` 5. Select the workspace(s) you want to sync 6. Click **Save** ## Step 3: Select Spaces and Folders After connecting, PanDev shows the workspace hierarchy: ``` Acme Engineering ├── Backend │ ├── API Development │ ├── Infrastructure │ └── Database ├── Frontend │ ├── Web App │ └── Mobile App └── DevOps ├── CI/CD └── Monitoring ``` 1. **Check the boxes** next to Spaces or Folders you want to track 2. Click **Save Selection** You don't need to track everything. Focus on spaces where engineering work happens — skip design, marketing, or HR spaces. ## Step 4: Configure Task-to-Code Linking PanDev links ClickUp tasks to git activity by matching task IDs in commit messages, branch names, and pull requests. ### Default Matching Patterns PanDev looks for ClickUp task IDs in these formats: ``` Commit message: "Fix pagination bug CU-abc123def" Branch name: "feature/CU-abc123def-pagination-fix" PR title: "[CU-abc123def] Fix pagination bug" PR description: "Resolves https://app.clickup.com/t/abc123def" ``` The `CU-` prefix and the ClickUp URL format are both recognized automatically. ### Enabling the ClickUp-Git Integration For the best linking, also enable ClickUp's native GitHub/GitLab integration. This creates bidirectional links — ClickUp shows the linked PRs, and PanDev shows the linked tasks. But even without ClickUp's native integration, PanDev can link tasks to code based on the patterns above. ### Custom ID Prefix If your team uses a custom task ID prefix, configure it in PanDev: ``` Settings → Integrations → ClickUp → Matching Rules Default prefix: CU- Custom prefixes: TASK-, T- (add your own) ``` ## Step 5: Sync Time Entries ClickUp has built-in time tracking. PanDev imports these time entries and compares them with actual IDE activity. 1. Go to **Settings → Integrations → ClickUp → Time Tracking** 2. Toggle **Enable Time Entry Sync** 3. Configure sync settings: ``` Sync direction: ClickUp → PanDev (read-only) Sync frequency: Every 2 hours Historical import: Last 90 days ``` Once synced, you can compare: | Task | ClickUp Logged | IDE Active | Git Active | |------|:--------------:|:----------:|:----------:| | CU-abc123 – API endpoint | 5h 30m | 3h 45m | 3h 12m | | CU-def456 – Frontend form | 3h 00m | 4h 20m | 3h 55m | | CU-ghi789 – Bug fix | 1h 00m | 0h 45m | 0h 38m | The gap between "logged" and "IDE active" isn't about honesty — it includes meetings, research, planning, and context switching. These are real work hours that don't show up in code but still consume engineering budget. ## Step 6: Map ClickUp Users to PanDev Profiles 1. Go to **Settings → Team Management** 2. PanDev displays ClickUp users alongside any existing git platform mappings 3. Confirm the auto-matches or manually link users ``` Team Member GitHub ClickUp Status ────────────────────────────────────────────────────────── Alice Wong @awong alice.wong@co.com ✅ Matched Bob Park @bpark bob.park@co.com ✅ Matched Chen Li @chenli chen@co.com ⚠️ Review ``` ## Step 7: Explore the Dashboard ### Task View Click any ClickUp task in PanDev to see its engineering timeline: ``` CU-abc123: Build user profile API endpoint ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ ClickUp Status Flow: To Do ──(1d)──▸ In Progress ──(2d 4h)──▸ Review ──(6h)──▸ Closed Engineering Activity: Mar 8, 09:15 First commit (alice.wong) +156 / -23 lines Mar 8, 11:42 Second commit (alice.wong) +89 / -34 lines Mar 8, 14:30 PR opened → backend-api#215 Mar 8, 16:00 Third commit (alice.wong) +12 / -8 lines Mar 9, 10:20 Review started (bob.park) Mar 9, 11:15 Review comment: "Consider caching" Mar 9, 14:00 Fix commit (alice.wong) +34 / -5 lines Mar 9, 14:45 PR approved (bob.park) Mar 9, 15:00 PR merged ClickUp time logged: 5h 30m IDE time (PanDev): 3h 45m Review time: 55m Total cycle time: 1d 5h 45m (working hours) ``` ### Sprint Dashboard If you use ClickUp Sprints, PanDev creates a sprint-level view: | Metric | Value | |--------|-------| | Tasks planned | 18 | | Tasks completed | 15 (83%) | | Total coding time | 67h across 5 developers | | Total review time | 18h | | Avg cycle time per task | 1.8 working days | | Tasks with no commits | 2 (flagged) | | Carry-over tasks | 3 | ### Time Entry Analysis The time comparison report helps teams calibrate their tracking habits: ``` Team Time Tracking Accuracy (last 30 days) ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Average ClickUp logged time: 5.2h / day Average IDE active time: 3.8h / day Average ratio: 1.37x (ClickUp logs 37% more than IDE) This is normal — the gap represents: • Code research and documentation reading • Slack discussions about implementation • Local testing without IDE activity • Architecture and planning meetings ``` ## Automating Task Updates PanDev can push status updates back to ClickUp based on git activity: ### Auto-Status Transitions ``` Settings → Integrations → ClickUp → Automation Rules: ✅ When first commit is pushed → Move task to "In Progress" ✅ When PR is opened → Move task to "In Review" ✅ When PR is merged → Move task to "Done" ⬜ When PR is closed without merge → Move task back to "In Progress" ``` These automations reduce manual status updates and keep your ClickUp board accurate without developer effort. ### Adding Commit Links to Tasks PanDev can post a summary comment on linked ClickUp tasks: ``` Settings → Integrations → ClickUp → Comments ✅ Post a summary when PR is merged Comment template: "🔗 PR merged: {pr_title} ({pr_url}) Changes: +{lines_added} / -{lines_removed} Coding time: {coding_time} Review time: {review_time}" ``` ## Troubleshooting | Issue | Solution | |-------|----------| | No tasks syncing | Verify the API token hasn't been revoked. Regenerate if needed | | Tasks sync but no code links | Ensure developers include ClickUp task IDs (CU-xxxxx) in commit messages or branch names | | Time entries not importing | Check that time tracking is enabled in the ClickUp workspace settings | | Wrong user mappings | Go to Team Management and manually correct the associations | | Automation not triggering | Verify the automation rules match your ClickUp status names exactly (case-sensitive) | ## Tips for Getting the Most Out of the Integration 1. **Standardize branch naming** — agree on a format like `feature/CU-xxxxx-short-description` so every branch auto-links to a task 2. **Use ClickUp time tracking consistently** — the comparison data is only useful if the team actually logs time 3. **Review the sprint report in retros** — use PanDev's sprint analysis as objective data for retrospectives 4. **Don't optimize for metrics** — the goal is better planning, not faster coding. Use the data to remove bottlenecks, not to pressure developers ## Next Steps With ClickUp connected, your task management and engineering data live in one place. Consider: - **Adding more integrations** — connect your git provider if you haven't already - **Installing IDE plugins** — get coding time data directly from VS Code, IntelliJ, or other editors - **Setting up weekly reports** — automated sprint summaries sent to team leads - **Using the AI assistant** — ask "What tasks took the longest in the last sprint?" and get instant answers --- **Unify task tracking and engineering metrics.** [Connect ClickUp to PanDev Metrics](https://pandev-metrics.com) and see the real effort behind every task. --- ## IDE Plugins: How to Track Activity in VS Code, IntelliJ, Eclipse, Xcode, and More URL: https://pandev-metrics.com/docs/blog/ide-plugins-all Date: 2026-01-14 Tags: ide-plugins, setup, tutorial, developer-productivity, vscode, jetbrains Description: Install PanDev IDE plugins for VS Code, JetBrains, Eclipse, Xcode, Visual Studio, PL/SQL Developer, and CLI. Track real coding time automatically. Commits and pull requests tell you what was delivered. But they miss the hours of debugging, refactoring, and research that happen between pushes. IDE plugins capture that missing layer — how much time was spent coding, which files were touched, and when developers were most active. PanDev Metrics offers plugins for **VS Code, JetBrains (IntelliJ, PhpStorm, WebStorm), Eclipse, Xcode, Visual Studio, PL/SQL Developer**, a **Chrome extension**, and a **CLI** for everything else. This guide covers installation and configuration for all of them. ![Coding activity heatmap by hour and day](https://pandev-metrics.com/img/blog/activity-heatmap.png) Once IDE plugins are installed, PanDev visualizes your team's coding activity as a heatmap — showing exactly when developers are most active throughout the week. ## How IDE Tracking Works Every PanDev IDE plugin works the same way under the hood: 1. The plugin detects **coding activity** — keystrokes, file saves, file switches, debugging sessions 2. It records **heartbeats** — lightweight events with a timestamp, file path, project name, language, and activity type 3. Heartbeats are batched and sent to the PanDev API every **2 minutes** 4. PanDev aggregates heartbeats into **coding sessions** — continuous activity windows with gaps of less than 5 minutes No code content is ever sent. PanDev only tracks metadata: file names, project names, timestamps, and languages. ### What Counts as "Active" Time | Activity | Tracked? | |----------|:--------:| | Typing code | Yes | | Navigating between files | Yes | | Using the debugger | Yes | | Running tests from IDE | Yes | | Reading code (scrolling, no keystrokes for 5+ min) | No | | IDE open but minimized | No | | Meetings on a different screen | No | The 5-minute inactivity threshold is configurable per organization. ## Before You Start: Get Your API Key Every plugin needs an API key to authenticate with PanDev: 1. Log in to PanDev Metrics 2. Go to **Profile → API Key** 3. Click **Generate Key** (or copy your existing key) ``` Your API key: pdm_k_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx ``` You'll use this key during plugin setup. It's tied to your personal account — each developer generates their own. ## VS Code The most popular IDE in our user base. Installation takes 30 seconds. ### Install 1. Open VS Code 2. Go to **Extensions** (Ctrl+Shift+X / Cmd+Shift+X) 3. Search for **"PanDev Metrics"** 4. Click **Install** Alternatively, install via command line: ```bash code --install-extension pandev.pandev-metrics ``` ### Configure After installation, VS Code prompts for your API key: 1. A notification appears: "PanDev Metrics: Enter your API key" 2. Paste your API key and press Enter Or configure manually in `settings.json`: ```json { "pandev.apiKey": "pdm_k_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx", "pandev.apiUrl": "https://api.pandev-metrics.com" } ``` For on-premise deployments, change `apiUrl` to your internal PanDev instance. ### Verify 1. Open any project and type a few characters 2. Check the VS Code status bar — you should see a PanDev icon with a green dot 3. In PanDev Metrics, go to **Dashboard → Activity Feed** — your coding session should appear within 2 minutes ### VS Code-Specific Settings ```json { "pandev.apiKey": "pdm_k_xxxx", "pandev.apiUrl": "https://api.pandev-metrics.com", "pandev.excludeFiles": [ "*.log", "*.lock", "node_modules/**" ], "pandev.projectDetection": "git", "pandev.debug": false } ``` | Setting | Description | |---------|-------------| | `excludeFiles` | Glob patterns for files to ignore | | `projectDetection` | How to detect the project name: `git` (from remote URL), `folder` (from folder name), or `custom` | | `debug` | Enable verbose logging in the Output panel | ## JetBrains (IntelliJ IDEA, PhpStorm, WebStorm, PyCharm, GoLand, Rider) One plugin covers the entire JetBrains family. ### Install 1. Open your JetBrains IDE 2. Go to **Settings → Plugins → Marketplace** 3. Search for **"PanDev Metrics"** 4. Click **Install** → **Restart IDE** Or install via JetBrains Toolbox CLI: ```bash # Example for IntelliJ IDEA idea installPlugins pandev.pandev-metrics ``` ### Configure After restart, a setup dialog appears: 1. Paste your API key 2. (Optional) Set the API URL for on-premise deployments 3. Click **Save** The configuration is stored in: ``` ~/.config/JetBrains/IntelliJIdea2025.3/options/pandev.xml ``` ### Verify 1. Open a project, make some edits 2. Check the bottom-right status bar for the PanDev icon 3. Click it to see your current session stats: coding time today, current project, last heartbeat sent ### JetBrains-Specific Settings ``` Settings → Tools → PanDev Metrics API Key: pdm_k_xxxx API URL: https://api.pandev-metrics.com Timeout (sec): 30 Exclude patterns: *.log, *.lock, build/**, .idea/** Log level: INFO ``` ## Eclipse Eclipse users aren't forgotten. The PanDev plugin works with Eclipse 2023-03 and later. ### Install 1. Open Eclipse 2. Go to **Help → Eclipse Marketplace** 3. Search for **"PanDev Metrics"** 4. Click **Install** → follow the wizard → **Restart Eclipse** Or install via update site: ``` Help → Install New Software → Add... Name: PanDev Metrics URL: https://plugins.pandev-metrics.com/eclipse/ ``` ### Configure 1. Go to **Window → Preferences → PanDev Metrics** 2. Enter your API key 3. Click **Apply and Close** ### Verify Check the Eclipse status bar (bottom) for the PanDev icon. Hover to see connection status. ## Xcode For iOS and macOS developers. ### Install The Xcode plugin is distributed as a **macOS app** that runs as a background service: ```bash brew install --cask pandev-metrics ``` Or download from [pandev-metrics.com/downloads](https://pandev-metrics.com/downloads). ### Configure 1. Launch **PanDev Metrics** from Applications 2. The app appears in your menu bar 3. Click the menu bar icon → **Settings** 4. Enter your API key 5. Grant accessibility permissions when prompted (required to detect Xcode activity) ``` System Settings → Privacy & Security → Accessibility ✅ PanDev Metrics ``` ### How It Works Unlike traditional IDE plugins, the Xcode integration monitors the active Xcode process at the OS level. It detects: - File open/save events - Active file changes - Build and run events - Debugging sessions ### Verify 1. Open an Xcode project and start coding 2. Click the PanDev menu bar icon — it shows current session info 3. Check PanDev Metrics dashboard for activity within 2 minutes ## Visual Studio (Windows) For .NET, C++, and other Visual Studio developers. ### Install 1. Open Visual Studio 2. Go to **Extensions → Manage Extensions** 3. Search for **"PanDev Metrics"** 4. Click **Download** → Restart Visual Studio to complete installation Or install via the VSIX package: ```powershell # Download from pandev-metrics.com/downloads code --install-extension pandev-metrics.vsix ``` ### Configure 1. Go to **Tools → Options → PanDev Metrics** 2. Enter your API key 3. Click **OK** ### Visual Studio-Specific Notes - Supports Visual Studio 2019 and later - Tracks C#, C++, F#, VB.NET, and all other Visual Studio languages - Solution name is used as the project name by default ## PL/SQL Developer For Oracle database developers using PL/SQL Developer. ### Install 1. Download the PanDev plugin DLL from [pandev-metrics.com/downloads](https://pandev-metrics.com/downloads) 2. Copy it to the PL/SQL Developer plugins directory: ``` C:\Program Files\PLSQL Developer\PlugIns\pandev-metrics.dll ``` 3. Restart PL/SQL Developer 4. Go to **Tools → Configure Plug-Ins** → enable PanDev Metrics ### Configure After enabling, a configuration dialog appears: 1. Enter your API key 2. Set the API URL (default or on-premise) 3. Click **Save** ### What Gets Tracked - Active editing in SQL windows - Package, procedure, and function editing - Time spent in the SQL beautifier and query builder ## Chrome Extension The Chrome extension tracks time spent on developer-related web activities: ### Install 1. Visit the [Chrome Web Store](https://chrome.google.com/webstore) and search for "PanDev Metrics" 2. Click **Add to Chrome** 3. Click the extension icon → enter your API key ### What Gets Tracked The extension tracks time on **developer-related sites only**: ``` Tracked domains (default): ✅ github.com ✅ gitlab.com ✅ bitbucket.org ✅ stackoverflow.com ✅ developer.mozilla.org (MDN) ✅ docs.microsoft.com ✅ Your Jira / ClickUp instance (configurable) Not tracked: ❌ Social media ❌ Email ❌ Shopping sites ❌ Everything else ``` You can customize the domain list in the extension settings. ### Privacy The Chrome extension sends only the domain name and page title to PanDev — never the full URL, page content, or any sensitive data. It can be fully disabled for specific domains. ## CLI (Command Line) For editors without plugin support (Vim, Neovim, Emacs, nano) or custom development environments. ### Install ```bash # macOS / Linux curl -fsSL https://get.pandev-metrics.com/cli | sh # Or via package managers brew install pandev-cli # macOS sudo apt install pandev-cli # Debian/Ubuntu sudo yum install pandev-cli # RHEL/CentOS ``` ### Configure ```bash pandev-cli setup # Enter your API key when prompted # Configuration saved to ~/.pandev/config.toml ``` Configuration file: ```toml # ~/.pandev/config.toml api_key = "pdm_k_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx" api_url = "https://api.pandev-metrics.com" exclude_patterns = ["*.log", "*.lock", "node_modules/**"] ``` ### Usage with Vim/Neovim Add a file-save hook to your `.vimrc` or `init.vim`: ```vim autocmd BufWritePost * silent! execute '!pandev-cli heartbeat --file ' . shellescape(expand('%:p')) . ' --project ' . shellescape(fnamemodify(getcwd(), ':t')) . ' &' ``` For Neovim, a dedicated Lua plugin is available: ```lua -- ~/.config/nvim/lua/plugins/pandev.lua return { "pandev-metrics/pandev.nvim", config = function() require("pandev").setup({ api_key = os.getenv("PANDEV_API_KEY"), }) end, } ``` ### Usage with Emacs ```elisp ;; ~/.emacs.d/init.el (use-package pandev :ensure t :config (setq pandev-api-key (getenv "PANDEV_API_KEY")) (global-pandev-mode 1)) ``` ### Manual Heartbeats For custom integrations, send heartbeats directly: ```bash pandev-cli heartbeat \ --file /path/to/file.py \ --project my-project \ --language python \ --activity coding ``` ## Verifying Everything Works After installing plugins on your team's machines, verify data flow: ### Individual Check Each developer can verify at **Profile → Activity → Today**: ``` Today's Activity ━━━━━━━━━━━━━━━ Total coding time: 2h 34m Projects: backend-api (1h 48m), frontend (46m) Languages: Python (1h 12m), TypeScript (52m), SQL (30m) Editors: VS Code (1h 48m), IntelliJ IDEA (46m) Last heartbeat: 12 seconds ago ✅ ``` ### Admin Check As an admin, verify at **Settings → Team → Plugin Status**: ``` Developer Plugin Version Last Heartbeat Status ────────────────────────────────────────────────────────────────────── Alice Wong VS Code 2.4.1 2 min ago ✅ Active Bob Park IntelliJ IDEA 2.4.0 5 min ago ✅ Active Chen Li VS Code 2.3.8 3 days ago ⚠️ Stale Diana Ray Eclipse 2.4.1 1 min ago ✅ Active Erik Svensson — — Never ❌ Not installed ``` Follow up with developers who show "Stale" or "Not installed" — common issues are expired API keys or corporate proxy blocking. ## Troubleshooting | Issue | Solution | |-------|----------| | Plugin installed but no data in PanDev | Check the API key. Regenerate if unsure | | "Connection timeout" in plugin logs | Corporate proxy or firewall blocking `api.pandev-metrics.com`. Configure proxy settings in the plugin or whitelist the domain | | Activity shows 0 minutes despite coding | Check excluded file patterns — you might be excluding the files you're editing | | Wrong project name | Adjust `projectDetection` setting. For git-based detection, ensure the folder has a `.git` directory with a remote URL | | Multiple editors counting double | PanDev deduplicates overlapping heartbeats. If both VS Code and Chrome are active simultaneously, each gets its own activity type | > "As a CTO and for our tech leads, it's important to see not individual employees but the state of the development process: where it's efficient and where it breaks down. The product allows natively collecting metrics right from the IDE, without feeling controlled or surveilled." > — Maksim Popov, CTO ABR Tech ([Forbes Kazakhstan, April 2026](https://forbes.kz)) ## Privacy and Data PanDev IDE plugins collect **metadata only**: - File path and name - Project name (from git remote or folder name) - Programming language - Timestamp - Editor name and version - Activity type (coding, debugging, building) **Never collected**: file contents, code snippets, clipboard data, keystrokes, screenshots, or anything that could expose source code. All data is encrypted in transit (TLS 1.3) and at rest (AES-256). For maximum control, deploy PanDev on-premise and keep all data within your network. For details on the VS Code extension API model, see the [VS Code Extension API documentation](https://code.visualstudio.com/api). JetBrains plugin architecture is documented in the [IntelliJ Platform Plugin SDK](https://plugins.jetbrains.com/docs/intellij/welcome.html). --- **Start tracking real coding time.** Install PanDev plugins across your team in minutes. [Get started at PanDev Metrics](https://pandev-metrics.com). --- ## On-Premise Deployment: PanDev Metrics With Docker and Kubernetes in 30 Minutes URL: https://pandev-metrics.com/docs/blog/on-premise-docker-k8s Date: 2026-01-12 Tags: on-premise, docker, kubernetes, devops, setup, tutorial Description: Deploy PanDev Metrics on-premise using Docker Compose or Kubernetes. Full guide with Helm charts, LDAP, TLS, and custom certificates. Not every company can send engineering data to the cloud. Regulated industries, government contractors, and security-conscious organizations need their metrics platform on-premise — inside their own network, on their own servers. According to the [CNCF Annual Survey](https://www.cncf.io/reports/cncf-annual-survey-2023/), over 80% of organizations now run Kubernetes in production, making container-based on-premise deployment a well-understood operational pattern. PanDev Metrics supports full on-premise deployment via **Docker Compose** (for small teams) and **Kubernetes with Helm** (for larger organizations). This guide covers both paths, including LDAP authentication, TLS certificates, and persistent storage. ## Architecture Overview PanDev Metrics on-premise consists of these components: ``` ┌─────────────────────────────────────────────┐ │ Load Balancer │ │ (nginx / traefik) │ └──────────────────┬──────────────────────────┘ │ ┌─────────┴─────────┐ │ │ ┌────────▼──────┐ ┌───────▼───────┐ │ Web App │ │ API Server │ │ (frontend) │ │ (backend) │ │ Port 3000 │ │ Port 8080 │ └───────────────┘ └───────┬───────┘ │ ┌─────────────┼─────────────┐ │ │ │ ┌────────▼──┐ ┌──────▼─────┐ ┌───▼────────┐ │ PostgreSQL │ │ Redis │ │ Webhook │ │ (primary │ │ (cache + │ │ Worker │ │ database) │ │ queues) │ │ (async │ │ Port 5432 │ │ Port 6379 │ │ processing│ └────────────┘ └────────────┘ └────────────┘ ``` | Component | Purpose | Resources (minimum) | |-----------|---------|-------------------| | Web App | Frontend UI | 512 MB RAM, 0.5 CPU | | API Server | REST API, webhook receiver | 1 GB RAM, 1 CPU | | Webhook Worker | Async processing of git events | 1 GB RAM, 1 CPU | | PostgreSQL | Primary data store | 2 GB RAM, 1 CPU, 20 GB disk | | Redis | Caching, job queues | 512 MB RAM, 0.5 CPU | **Minimum total**: 5 GB RAM, 4 CPU cores, 25 GB disk for a team of up to 50 developers. ## Option A: Docker Compose (Quick Start) Best for teams under 50 developers or proof-of-concept deployments. ### Prerequisites - Docker Engine 24+ and Docker Compose v2 - A Linux server with 8 GB RAM and 4 CPU cores - A domain name pointing to the server (for TLS) ### Step 1: Download the Compose File ```bash mkdir -p /opt/pandev && cd /opt/pandev curl -fsSL https://get.pandev-metrics.com/docker/docker-compose.yml -o docker-compose.yml curl -fsSL https://get.pandev-metrics.com/docker/.env.example -o .env ``` ![Mail settings showing SMTP configuration for on-premise deployment](https://pandev-metrics.com/img/blog/settings-mail-detail.png) Mail settings let you configure SMTP host, port, protocol, and sender email — essential for on-premise deployments where email notifications need to route through your internal mail server. ### Step 2: Configure Environment Variables Edit the `.env` file: ```bash # .env — PanDev Metrics On-Premise Configuration # === Required === PANDEV_LICENSE_KEY=your-license-key-here PANDEV_DOMAIN=pandev.internal.company.com PANDEV_ADMIN_EMAIL=admin@company.com PANDEV_ADMIN_PASSWORD=change-me-immediately # === Database === POSTGRES_PASSWORD=strong-random-password-here POSTGRES_DB=pandev REDIS_PASSWORD=another-strong-password # === TLS === TLS_CERT_PATH=/opt/pandev/certs/fullchain.pem TLS_KEY_PATH=/opt/pandev/certs/privkey.pem # === Optional: LDAP === # LDAP_ENABLED=true # LDAP_URL=ldaps://ldap.company.com:636 # LDAP_BASE_DN=dc=company,dc=com # LDAP_BIND_DN=cn=pandev-svc,ou=service-accounts,dc=company,dc=com # LDAP_BIND_PASSWORD=ldap-service-password # LDAP_USER_FILTER=(uid={username}) # LDAP_CA_CERT_PATH=/opt/pandev/certs/ldap-ca.pem ``` Generate strong passwords: ```bash openssl rand -base64 32 # Use for POSTGRES_PASSWORD openssl rand -base64 32 # Use for REDIS_PASSWORD ``` ### Step 3: Add TLS Certificates ```bash mkdir -p /opt/pandev/certs # Option 1: Copy your corporate certificates cp /path/to/fullchain.pem /opt/pandev/certs/ cp /path/to/privkey.pem /opt/pandev/certs/ # Option 2: Generate self-signed (for testing only) openssl req -x509 -nodes -days 365 \ -newkey rsa:2048 \ -keyout /opt/pandev/certs/privkey.pem \ -out /opt/pandev/certs/fullchain.pem \ -subj "/CN=pandev.internal.company.com" ``` ### Step 4: Start the Stack ```bash cd /opt/pandev docker compose up -d ``` Watch the logs: ```bash docker compose logs -f ``` You should see: ``` pandev-api | ✅ Database connected pandev-api | ✅ Redis connected pandev-api | ✅ Migrations applied pandev-api | ✅ API server listening on :8080 pandev-web | ✅ Web app listening on :3000 pandev-worker | ✅ Webhook worker started, processing queue... pandev-nginx | ✅ HTTPS on :443 → web:3000, api:8080 ``` ### Step 5: Verify Open `https://pandev.internal.company.com` in your browser. Log in with the admin email and password from your `.env` file. ### Docker Compose Commands Reference ```bash # Start docker compose up -d # Stop docker compose down # Update to latest version docker compose pull && docker compose up -d # View logs docker compose logs -f [service-name] # Backup database docker compose exec postgres pg_dump -U pandev pandev > backup.sql # Restore database docker compose exec -T postgres psql -U pandev pandev < backup.sql ``` ## Option B: Kubernetes with Helm (Production) Best for larger organizations, high availability requirements, or existing Kubernetes infrastructure. ### Prerequisites - [Kubernetes](https://kubernetes.io/docs/setup/) 1.26+ - [Helm](https://helm.sh/docs/intro/install/) 3.12+ - `kubectl` configured for your cluster - A StorageClass for persistent volumes - An Ingress controller (nginx-ingress or Traefik) ### Step 1: Add the Helm Repository ```bash helm repo add pandev https://charts.pandev-metrics.com helm repo update ``` ### Step 2: Create a Values File ```yaml # values-production.yaml global: domain: pandev.internal.company.com licenseKey: "your-license-key-here" api: replicas: 2 resources: requests: memory: "1Gi" cpu: "1000m" limits: memory: "2Gi" cpu: "2000m" web: replicas: 2 resources: requests: memory: "512Mi" cpu: "500m" limits: memory: "1Gi" cpu: "1000m" worker: replicas: 2 resources: requests: memory: "1Gi" cpu: "1000m" limits: memory: "2Gi" cpu: "2000m" postgresql: enabled: true # Set to false if using external database auth: password: "strong-random-password" database: pandev primary: persistence: size: 50Gi storageClass: "gp3" # Adjust for your cloud provider resources: requests: memory: "2Gi" cpu: "1000m" redis: enabled: true auth: password: "another-strong-password" master: persistence: size: 5Gi ingress: enabled: true className: nginx annotations: cert-manager.io/cluster-issuer: letsencrypt-prod tls: - secretName: pandev-tls hosts: - pandev.internal.company.com # LDAP Configuration (optional) ldap: enabled: false # url: "ldaps://ldap.company.com:636" # baseDN: "dc=company,dc=com" # bindDN: "cn=pandev-svc,ou=service-accounts,dc=company,dc=com" # bindPassword: "ldap-service-password" # userFilter: "(uid={username})" # caCert: | # -----BEGIN CERTIFICATE----- # ... your LDAP CA certificate ... # -----END CERTIFICATE----- ``` ### Step 3: Create the Namespace and Secrets ```bash kubectl create namespace pandev # Create the license secret kubectl create secret generic pandev-license \ --namespace pandev \ --from-literal=license-key=your-license-key-here # If using external TLS certificates (not cert-manager) kubectl create secret tls pandev-tls \ --namespace pandev \ --cert=/path/to/fullchain.pem \ --key=/path/to/privkey.pem ``` ### Step 4: Install ```bash helm install pandev pandev/pandev-metrics \ --namespace pandev \ --values values-production.yaml ``` Watch the rollout: ```bash kubectl -n pandev get pods -w ``` Expected output: ``` NAME READY STATUS RESTARTS AGE pandev-api-7d4b8f9c6-abcde 1/1 Running 0 2m pandev-api-7d4b8f9c6-fghij 1/1 Running 0 2m pandev-web-5c6d7e8f9-klmno 1/1 Running 0 2m pandev-web-5c6d7e8f9-pqrst 1/1 Running 0 2m pandev-worker-3a4b5c6d7-uvwxy 1/1 Running 0 2m pandev-worker-3a4b5c6d7-zabcd 1/1 Running 0 2m pandev-postgresql-0 1/1 Running 0 2m pandev-redis-master-0 1/1 Running 0 2m ``` ### Step 5: Verify ```bash # Check the ingress kubectl -n pandev get ingress # Test API health curl -k https://pandev.internal.company.com/api/health # Expected response: # {"status":"ok","version":"2.14.0","database":"connected","redis":"connected"} ``` ![LDAP/AD settings with Integration Connected badge](https://pandev-metrics.com/img/blog/settings-ldap.png) The LDAP settings page shows your Active Directory integration status and configuration options. ## LDAP Authentication Both Docker and Kubernetes deployments support LDAP and LDAPS for user authentication. ### Basic LDAP Setup Enable LDAP in your configuration: ```bash # Docker (.env) LDAP_ENABLED=true LDAP_URL=ldaps://ldap.company.com:636 LDAP_BASE_DN=dc=company,dc=com LDAP_BIND_DN=cn=pandev-svc,ou=service-accounts,dc=company,dc=com LDAP_BIND_PASSWORD=ldap-service-password LDAP_USER_FILTER=(uid={username}) LDAP_EMAIL_ATTR=mail LDAP_DISPLAY_NAME_ATTR=displayName ``` ### Custom CA Certificates If your LDAP server uses a certificate signed by an internal CA: ```bash # Docker: mount the CA cert # In docker-compose.yml, add to the api service: volumes: - /opt/pandev/certs/ldap-ca.pem:/etc/ssl/certs/ldap-ca.pem:ro # Set the environment variable LDAP_CA_CERT_PATH=/etc/ssl/certs/ldap-ca.pem ``` For Kubernetes, include the CA certificate directly in `values-production.yaml`: ```yaml ldap: enabled: true url: "ldaps://ldap.company.com:636" caCert: | -----BEGIN CERTIFICATE----- MIIDXTCCAkWgAwIBAgIJAJC1HiIAZAiUMA0Gcz... (paste your full CA certificate here) -----END CERTIFICATE----- ``` ### LDAP Group Mapping Map LDAP groups to PanDev roles: ```bash LDAP_GROUP_BASE_DN=ou=groups,dc=company,dc=com LDAP_ADMIN_GROUP=cn=engineering-leads,ou=groups,dc=company,dc=com LDAP_MANAGER_GROUP=cn=team-leads,ou=groups,dc=company,dc=com LDAP_USER_GROUP=cn=developers,ou=groups,dc=company,dc=com ``` ## Configuring Webhooks for On-Premise When running on-premise, your git provider needs to send webhooks to your internal PanDev instance. ### GitLab (Self-Managed) If both GitLab and PanDev are on the same network, use the internal URL: ``` Webhook URL: https://pandev.internal.company.com/api/v1/gitlab/webhook ``` If GitLab can't reach PanDev directly, set up a network route or reverse proxy. ### GitHub Enterprise Same approach — point webhooks to your internal PanDev URL: ``` Webhook URL: https://pandev.internal.company.com/api/v1/github/webhook ``` ### Firewall Rules Ensure these network paths are open: ``` Git Provider → PanDev API (port 443) # Webhooks Developer machines → PanDev API (port 443) # IDE plugins PanDev API → Git Provider API (port 443) # Data fetching PanDev API → LDAP server (port 636) # Authentication ``` ## Backup and Recovery ### Database Backup Schedule daily backups: ```bash # Docker 0 2 * * * docker compose -f /opt/pandev/docker-compose.yml exec -T postgres \ pg_dump -U pandev pandev | gzip > /opt/pandev/backups/pandev-$(date +\%Y\%m\%d).sql.gz # Kubernetes 0 2 * * * kubectl -n pandev exec pandev-postgresql-0 -- \ pg_dump -U pandev pandev | gzip > /backups/pandev-$(date +\%Y\%m\%d).sql.gz ``` ### Full Recovery ```bash # Docker gunzip < /opt/pandev/backups/pandev-20260308.sql.gz | \ docker compose exec -T postgres psql -U pandev pandev # Kubernetes gunzip < pandev-20260308.sql.gz | \ kubectl -n pandev exec -i pandev-postgresql-0 -- psql -U pandev pandev ``` ## Upgrading ### Docker ```bash cd /opt/pandev docker compose pull docker compose up -d ``` Database migrations run automatically on startup. ### Kubernetes ```bash helm repo update helm upgrade pandev pandev/pandev-metrics \ --namespace pandev \ --values values-production.yaml ``` Check the release notes before upgrading — major versions may require manual migration steps. ## Monitoring ### Health Endpoints ```bash # API health curl https://pandev.internal.company.com/api/health # Detailed status curl https://pandev.internal.company.com/api/health/detailed # Returns: database latency, redis latency, queue depth, worker status ``` ### Prometheus Metrics PanDev exposes a `/metrics` endpoint for Prometheus: ```yaml # prometheus.yml scrape_configs: - job_name: pandev static_configs: - targets: ['pandev.internal.company.com:443'] scheme: https metrics_path: /api/metrics ``` Key metrics to monitor: | Metric | Alert threshold | |--------|----------------| | `pandev_webhook_queue_depth` | > 1000 | | `pandev_api_response_time_p99` | > 2s | | `pandev_database_connections_active` | > 80% of pool | | `pandev_worker_error_rate` | > 5% | ## Troubleshooting | Issue | Solution | |-------|----------| | Database connection refused | Check `POSTGRES_PASSWORD` matches in both the database and API config | | LDAP authentication fails | Test with `ldapsearch` from the PanDev server to verify connectivity and credentials | | Webhooks timing out | Verify firewall rules allow inbound traffic from your git provider | | IDE plugins can't connect | Ensure developers configure `apiUrl` to point to your on-premise instance, not the cloud URL | | High memory usage | Increase PostgreSQL `shared_buffers` and `work_mem` in the Helm values or Docker Compose | | Slow webhook processing | Scale up the worker replicas: `helm upgrade --set worker.replicas=4` or adjust Docker Compose | --- **Keep your engineering data on your infrastructure.** [Deploy PanDev Metrics on-premise](https://pandev-metrics.com) with Docker or Kubernetes — full control, full privacy, same powerful dashboards. The [Flexera 2024 State of the Cloud Report](https://info.flexera.com/CM-REPORT-State-of-the-Cloud) confirms that hybrid and on-premise deployments remain a top priority for enterprises managing sensitive data. --- ## AI Assistant: Ask Your Metrics Questions in Natural Language URL: https://pandev-metrics.com/docs/blog/ai-assistant-natural-language Date: 2026-01-09 Tags: ai, gemini, feature, tutorial, engineering-metrics Description: PanDev's AI assistant, powered by Google Gemini, lets you query engineering metrics in plain English. See real examples and learn what you can ask. Dashboards are great — until you need an answer that doesn't fit any pre-built chart. "What was our average PR review time last month, excluding the infra team?" That query doesn't have a button. It requires filtering, grouping, and calculating across multiple dimensions. PanDev's **AI assistant** lets you ask questions like this in plain English. Powered by **Google Gemini**, it understands your engineering data and returns answers, charts, and tables in seconds. [Gartner predicts](https://www.gartner.com/en/articles/beyond-chatgpt-the-future-of-generative-ai-for-enterprises) that by 2026, over 80% of enterprises will have used generative AI APIs or deployed AI-augmented applications — natural-language analytics is part of that shift. ![PanDev dashboard — the data the AI assistant queries in natural language](https://pandev-metrics.com/img/blog/dashboard-clean.png) *PanDev dashboard — the data the AI assistant queries in natural language.* ## How It Works The AI assistant sits between you and PanDev's data layer: ``` You type a question in natural language │ ▼ ┌─────────────────────┐ │ Google Gemini │ │ (language model) │ │ Understands intent │ │ Generates query │ └──────────┬──────────┘ │ ▼ ┌─────────────────────┐ │ PanDev Query │ │ Engine │ │ Runs structured │ │ query against │ │ your data │ └──────────┬──────────┘ │ ▼ ┌─────────────────────┐ │ Formatted Response │ │ Tables, charts, │ │ summaries │ └─────────────────────┘ ``` The AI model never sees your raw data. It translates your question into a structured query, PanDev's engine executes it against your database, and the results come back formatted. ### What the AI Can Access The AI assistant queries the same data available in your PanDev dashboards: - Commits, branches, and code changes - Pull requests / merge requests — open, merged, closed, review activity - IDE activity — coding time per developer, project, language - Task data from Jira, ClickUp, or Yandex.Tracker - Sprint and epic metrics - DORA metrics - Team structure and user profiles It **cannot** access source code, file contents, or anything outside PanDev's metrics database. ## Getting Started ### Access the Assistant 1. Log in to PanDev Metrics 2. Click the **AI Assistant** icon in the top navigation bar (or press `Ctrl+K` / `Cmd+K`) 3. Type your question and press Enter That's it. No setup, no API keys, no configuration. ### Your First Questions Start simple to see how the assistant works: ``` You: "How many PRs did we merge last week?" AI: Last week (Mar 3–9), your organization merged 47 pull requests across 12 repositories. Top repositories: │ Repository │ PRs Merged │ │ backend-api │ 14 │ │ frontend-app │ 11 │ │ mobile-ios │ 8 │ │ infrastructure │ 6 │ │ shared-libs │ 5 │ │ other (3 repos) │ 3 │ ``` ``` You: "What was our average cycle time this month?" AI: Average PR cycle time for March 2026: 18.4 hours (working hours). Breakdown: • Coding time (first commit → PR open): 6.2h avg • Time to first review: 4.8h avg • Review and iteration: 5.1h avg • Merge after approval: 2.3h avg Compared to February: cycle time decreased by 12% (from 20.9h). ``` ## Real-World Examples Here are questions real PanDev users ask the AI assistant, organized by role. ### For Engineering Managers **Team performance overview:** ``` You: "Show me each developer's coding time and PR count for the last sprint" AI: Sprint 24 (Feb 24 – Mar 7): │ Developer │ Coding Time │ PRs Merged │ Avg PR Size │ │ Anna Chen │ 28h 15m │ 8 │ +142 lines │ │ Boris Kim │ 22h 30m │ 6 │ +203 lines │ │ Carlos Diaz │ 31h 45m │ 11 │ +87 lines │ │ Diana Ray │ 19h 20m │ 5 │ +312 lines │ │ Erik Svensson│ 25h 10m │ 7 │ +156 lines │ ``` **Identifying bottlenecks:** ``` You: "Which PRs have been open for more than 5 days?" AI: 3 PRs have been open for more than 5 days: 1. backend-api#342 — "Refactor auth middleware" (Anna Chen) Opened: Mar 4 | Last activity: Mar 6 | Reviews: 1 comment, no approval ⚠️ Waiting for review from Boris Kim 2. frontend-app#891 — "Migrate to React 19" (Carlos Diaz) Opened: Feb 28 | Last activity: Mar 7 | Reviews: 3 rounds, changes requested ⚠️ Large PR (+2,341 lines) — consider splitting 3. infrastructure#156 — "Upgrade PostgreSQL to 16" (Erik Svensson) Opened: Mar 3 | Last activity: Mar 3 | Reviews: none ⚠️ No reviewer assigned ``` **Review load balance:** ``` You: "Who does the most code reviews on the backend team?" AI: Code review distribution for the Backend team (last 30 days): │ Reviewer │ Reviews │ Avg Time to Review │ Approval Rate │ │ Boris Kim │ 23 │ 3.2h │ 78% │ │ Anna Chen │ 14 │ 5.7h │ 85% │ │ Diana Ray │ 6 │ 8.4h │ 92% │ Boris Kim handles 53% of all backend reviews. Consider distributing review load more evenly to reduce their bottleneck risk. ``` ### For Project Managers **Sprint progress:** ``` You: "Are we on track for the current sprint?" AI: Sprint 25 progress (Mar 10–21, day 4 of 10): Planned: 34 story points (18 tasks) Completed: 11 points (6 tasks) — 32% In Progress: 13 points (7 tasks) Not Started: 10 points (5 tasks) Pace: 2.75 points/day (need 3.4/day to finish on time) ⚠️ Slightly behind pace. 3 tasks in "In Progress" have no commits in the last 48 hours — worth checking in standup. ``` **Estimation accuracy:** ``` You: "How accurate were our estimates last quarter?" AI: Q1 2026 Estimation Accuracy: │ Story Points │ Tasks │ Avg Actual Time │ Accuracy │ │ 1 point │ 42 │ 3.1h coding │ ±15% │ │ 2 points │ 38 │ 6.8h coding │ ±22% │ │ 3 points │ 29 │ 12.4h coding │ ±31% │ │ 5 points │ 17 │ 22.1h coding │ ±45% │ │ 8 points │ 8 │ 41.3h coding │ ±62% │ Smaller tasks are estimated more accurately. Tasks rated 5+ points have high variance — consider breaking them down further. ``` ### For CTOs and VPs **DORA metrics:** ``` You: "What are our DORA metrics for Q1?" AI: DORA Metrics — Q1 2026: │ Metric │ Value │ Rating │ │ Deployment Frequency │ 4.2/week │ ⭐ High │ │ Lead Time for Changes │ 2.1 days │ ⭐ High │ │ Mean Time to Recovery │ 4.3 hours │ ⭐ High │ │ Change Failure Rate │ 8.7% │ ⭐ Medium │ Trend: All metrics improved from Q4 2025 except Change Failure Rate, which increased from 6.2% to 8.7%. This correlates with the frontend migration project (12 reverts in February). ``` **Cross-team comparison:** ``` You: "Compare cycle time across all teams for the last month" AI: Average PR cycle time by team (February 2026): │ Team │ Cycle Time │ PRs │ Trend vs Jan │ │ Backend │ 14.2h │ 68 │ ↓ 18% │ │ Frontend │ 22.7h │ 45 │ ↑ 31% │ │ Mobile │ 16.8h │ 32 │ ↓ 5% │ │ Infrastructure │ 28.4h │ 19 │ ↑ 12% │ │ Data │ 11.3h │ 24 │ ↓ 22% │ Frontend cycle time spiked due to the React 19 migration — large PRs averaging +890 lines (vs. team norm of +210). ``` ### For Individual Developers **Personal stats:** ``` You: "How much did I code last week?" AI: Your activity for Mar 3–9: Total coding time: 22h 45m Projects: backend-api (14h), shared-libs (6h), docs (2h 45m) Languages: Go (12h), TypeScript (8h), Markdown (2h 45m) PRs opened: 4 | PRs merged: 3 | Reviews given: 6 Most active day: Wednesday (5h 20m) Most active time: 10:00–12:00 ``` ## Advanced Queries The AI handles complex, multi-condition questions: ``` "Show me developers who reviewed more than 10 PRs last month but wrote fewer than 5 PRs themselves" ``` ``` "What percentage of our PRs are merged without any review comments?" ``` ``` "List all tasks from Sprint 23 that were carried over to Sprint 24, and show how much coding time was spent on each before carry-over" ``` ``` "Compare our Monday vs Friday deployment frequency over the last quarter" ``` ``` "Which repositories have the highest code churn rate?" ``` ## Follow-Up Questions The assistant maintains context within a conversation. You can drill down: ``` You: "What was our cycle time last month?" AI: Average cycle time in February: 18.4 working hours. You: "Break that down by PR size" AI: │ PR Size │ Cycle Time │ Count │ │ Small (under 50) │ 8.2h │ 42 │ │ Medium (50-200)│ 16.7h │ 35 │ │ Large (200-500)│ 28.9h │ 18 │ │ XL (500+) │ 52.3h │ 7 │ You: "What about only the backend team?" AI: Backend team cycle time by PR size (February): │ PR Size │ Cycle Time │ Count │ │ Small (under 50) │ 6.1h │ 22 │ │ Medium (50-200)│ 13.4h │ 19 │ │ Large (200-500)│ 24.2h │ 8 │ │ XL (500+) │ 38.7h │ 2 │ ``` ## Tips for Better Results ### Be Specific About Time Ranges ``` ❌ "How are we doing?" ✅ "What was our PR throughput for the last 2 weeks?" ``` ### Name Teams and Projects Explicitly ``` ❌ "Show review stats" ✅ "Show review stats for the backend team in the frontend-app repo" ``` ### Ask for Comparisons ``` ✅ "Compare this sprint's velocity with the previous 3 sprints" ✅ "How does our cycle time this quarter compare to last quarter?" ``` ### Request Specific Formats ``` ✅ "Show me a table of coding time by developer and language" ✅ "Give me a weekly trend of PR merge count for the last 8 weeks" ``` ## Privacy and Security The AI assistant is designed with data boundaries: | What the AI sees | What the AI never sees | |------------------|----------------------| | Aggregated metrics | Source code | | Developer names (within your org) | File contents | | Repository names | Commit diffs | | Task titles and IDs | Credentials or tokens | | Time and count data | Data from other organizations | The Google Gemini model processes your natural language question and generates a structured query. Your actual metrics data stays within PanDev's infrastructure — it's never sent to the language model. For on-premise deployments, the AI assistant connects to Google Gemini's API for language processing only. If your security policy doesn't allow external AI API calls, contact us about self-hosted LLM options. ## What the AI Can't Do (Yet) To set expectations: - **Can't modify data** — it's read-only. You can't create tasks, close PRs, or reassign reviews through the assistant - **Can't predict the future** — it can show trends and patterns, but won't forecast sprint completion dates (yet) - **Can't explain "why"** — it can tell you that cycle time increased 30%, but the root cause analysis is still on you - **Can't access external tools** — it only queries PanDev's database, not Jira or GitHub directly These limitations will shrink over time as we expand the assistant's capabilities. [Forrester's research on AI in software engineering](https://www.forrester.com/report/the-state-of-ai-in-software-development-2024/) shows that AI-assisted analytics tools are evolving rapidly — predictive capabilities and root-cause analysis are the next frontier. ## Getting Started The AI assistant is available on all PanDev Metrics plans. Open it with `Ctrl+K` (or `Cmd+K` on Mac) from any PanDev page, type your question, and get answers in seconds. No dashboards to configure. No SQL to write. Just ask. --- **Ask your data anything.** [Try the AI assistant in PanDev Metrics](https://pandev-metrics.com) — powered by Google Gemini, built for engineering teams. --- ## How Much Does Your Feature Cost? Calculating Cost Per Feature URL: https://pandev-metrics.com/docs/blog/cost-per-feature Date: 2026-01-06 Tags: financial-analytics, cost-management, engineering-metrics, product-management Description: Learn how to calculate the true cost of every feature your team builds. A practical guide for CPOs and CFOs with formulas and examples. Your product team just shipped a new reporting dashboard. It took three sprints, involved four developers, a designer, and a QA engineer. **How much did it actually cost?** If your answer is "I don't know" or "somewhere between $20K and $80K," you're not alone. Most engineering organizations cannot answer this question with any precision. According to [Stripe's Developer Coefficient report](https://stripe.com/reports/developer-coefficient-2018), companies collectively spend over $300 billion annually on developer time — yet few can attribute those costs to individual features. That disconnect turns every product decision into a guess. ## Why Cost Per Feature Matters Every quarter, product and engineering leaders sit in planning meetings making decisions about what to build next. These decisions involve tradeoffs: build Feature A or Feature B? Invest in tech debt reduction or new functionality? Hire two more developers or outsource? Without knowing how much features actually cost, these decisions are made on gut feeling. With cost-per-feature data, they become investment decisions backed by numbers. **Who benefits from cost-per-feature tracking:** - **CPOs and Product Managers** — prioritize features based on ROI, not just user requests - **CFOs** — forecast engineering spend with accuracy, tie development costs to business outcomes - **CTOs and VPs of Engineering** — justify headcount, identify cost overruns early, benchmark team efficiency - **CEOs** — understand where the engineering budget actually goes ## The Formula: Breaking Down Cost Per Feature At its simplest, the cost of a feature is: ``` Cost Per Feature = Σ (Hours_per_developer × Hourly_rate_per_developer) + Infrastructure + Overhead ``` But "simple" doesn't mean "easy." Let's break this down into components. ### Component 1: Direct Labor Cost This is where most of the money goes — typically 70-85% of total feature cost. ``` Direct Labor Cost = Σ (Hours_developer_i × Rate_developer_i) ``` **Example:** | Team Member | Role | Hours | Hourly Rate | Cost | |-------------|------|:-----:|:-----------:|-----:| | Alex | Senior Backend Dev | 120h | $85/h | $10,200 | | Maria | Frontend Dev | 80h | $65/h | $5,200 | | James | QA Engineer | 40h | $55/h | $2,200 | | Sarah | Designer | 24h | $60/h | $1,440 | | **Total** | | **264h** | | **$19,040** | ### Component 2: Overhead Multiplier Developers don't spend 100% of their time coding features. They attend meetings, do code reviews, mentor juniors, and handle on-call duties. A typical overhead multiplier is 1.3x to 1.6x. ``` Effective Cost = Direct Labor Cost × Overhead Multiplier ``` For our example: $19,040 × 1.4 = **$26,656** ### Component 3: Infrastructure and Tooling This includes CI/CD costs, cloud resources for development and staging environments, and tooling licenses. For most teams, this adds 5-15% on top of labor costs. ``` Total Feature Cost = Effective Cost × (1 + Infrastructure_Rate) ``` For our example: $26,656 × 1.10 = **$29,322** ### The Complete Formula ``` Total Cost = Σ(Hours_i × Rate_i) × Overhead_Multiplier × (1 + Infra_Rate) ``` ## Where Traditional Tracking Falls Apart The formula is straightforward. The hard part is getting accurate **hours per developer per feature**. Here's where most organizations fail: ### Problem 1: Self-Reported Time Is Inaccurate Self-reported time tracking consistently shows a 20-40% error margin. Developers round up, forget to log, or batch-report at the end of the week. [McKinsey's research on engineering productivity](https://www.mckinsey.com/industries/technology-media-and-telecommunications/our-insights/yes-you-can-measure-software-developer-productivity) confirms that most organizations lack reliable data on how engineering time is actually spent. If your cost calculation relies on Jira time logs, your numbers could be off by thousands of dollars per feature. ### Problem 2: Context Switching Is Invisible A developer might be assigned to Feature A but spend 30% of their time on bug fixes for Feature B. Sprint boards don't capture this — they show assignment, not actual effort. ### Problem 3: Non-Coding Work Gets Lost Code reviews, architecture discussions, debugging, and deployment work are rarely tracked at the feature level. Yet they can account for 30-50% of the total effort. ### Problem 4: Different Rates, Same Bucket When a senior architect ($120/h) and a junior developer ($45/h) both log 40 hours on a feature, the cost difference is $3,000. Flat "developer hour" calculations miss this entirely. ![Projects list showing project names and total time](https://pandev-metrics.com/img/blog/projects.png) The Projects view aggregates tracked time and cost per project — the foundation for calculating accurate cost per feature. ## Automated Cost Tracking: A Better Approach The solution is to combine automated activity tracking with financial data. Here's the methodology: ### Step 1: Track Actual Coding Time Per Developer IDE plugins can capture exactly how much time each developer spends writing, reviewing, and debugging code — tied to specific branches, repositories, and projects. No manual logging required. ### Step 2: Map Activity to Features By linking Git branches and commits to project identifiers (Jira tickets, Linear issues, etc.), you can automatically attribute coding time to specific features. ### Step 3: Apply Individual Hourly Rates Each developer has a different cost. Applying individual hourly rates (or at minimum, role-based rates) produces accurate cost figures instead of averages. ### Step 4: Calculate in Real Time Don't wait until a feature ships to discover it cost 3x the estimate. Track costs as they accumulate so you can course-correct mid-sprint. ## Real-World Example: The $47K Login Redesign Let's walk through a realistic scenario. A mid-size SaaS company decides to redesign their login flow. The product manager estimates it at "2-3 weeks, maybe 2 developers." **What actually happened:** | Phase | Who | Actual Hours | Rate | Cost | |-------|-----|:------------:|:----:|-----:| | Initial implementation | Senior Frontend Dev | 96h | $80/h | $7,680 | | Backend auth changes | Backend Dev | 64h | $75/h | $4,800 | | OAuth integration issues | Senior Backend Dev | 48h | $90/h | $4,320 | | QA and bug fixes | QA Engineer | 56h | $55/h | $3,080 | | Design iterations | UX Designer | 32h | $65/h | $2,080 | | Code reviews | 3 developers | 24h | $80/h avg | $1,920 | | Deployment and monitoring | DevOps Engineer | 16h | $85/h | $1,360 | | **Subtotal** | | **336h** | | **$25,240** | | Overhead (1.4x) | | | | $10,096 | | Infrastructure (10%) | | | | $2,524 | | **Total** | | | | **$37,860** | The original estimate? "Maybe $15-20K." The actual cost was nearly double. The OAuth integration alone — an unplanned scope expansion — added $4,320. Without automated tracking, this company would have never known the true cost. The next time a similar feature comes up, the estimate would still be wrong. ## Using Cost Per Feature Data for Better Decisions Once you have accurate cost data, you can make dramatically better product decisions. ### Prioritization by ROI Instead of prioritizing features by "customer demand" alone, you can calculate expected ROI: ``` Feature ROI = (Expected Annual Revenue Impact - Feature Cost) / Feature Cost × 100% ``` | Feature | Est. Revenue Impact | Est. Cost | ROI | |---------|:-------------------:|:---------:|:---:| | Advanced reporting | $200K/year | $45K | 344% | | Mobile app | $150K/year | $120K | 25% | | SSO integration | $300K/year | $25K | 1100% | SSO integration wins — not because it generates the most revenue, but because it has the best return on engineering investment. ### Historical Benchmarking Over time, cost-per-feature data reveals patterns: - "Authentication features cost us 2.1x the initial estimate on average" - "Team Alpha delivers features at $180/point; Team Beta at $240/point" - "Features involving our legacy billing system cost 40% more than the platform average" These insights feed directly into better estimation and planning. ### Budget Forecasting With 6-12 months of cost data, CFOs can forecast engineering spend for the next quarter with significantly higher accuracy: ``` Forecasted Spend = Σ (Planned_Features × Historical_Cost_Per_Feature_Type) + Buffer ``` ## Getting Started: A Practical Roadmap If you're starting from zero, here's a phased approach: **Month 1: Establish Baselines** - Deploy IDE tracking across the engineering team - Set up hourly rates by role or by individual - Map repositories to projects/products **Month 2: Collect and Validate** - Gather one full month of automated tracking data - Compare automated data against sprint estimates - Identify the biggest gaps between estimated and actual effort **Month 3: Operationalize** - Build cost-per-feature reports for product planning meetings - Set up real-time cost dashboards for in-progress features - Introduce ROI-based prioritization into the roadmap process ## How PanDev Metrics Handles Cost Per Feature PanDev Metrics is designed with financial analytics at its core. Here's what makes the approach work: - **Automatic time tracking** via 10+ IDE plugins — no manual logging, no timesheets - **Individual hourly rates** — set different rates per developer, contractor, or role - **Project-level cost aggregation** — costs roll up from commits to branches to features to projects - **Real-time cost dashboards** — see how much a feature has cost so far, not just after it ships - **On-premise deployment** — your financial data (hourly rates, project costs) stays on your infrastructure The combination of automated activity tracking and financial analytics means you get accurate cost-per-feature data without adding any burden to your engineering team. > According to Forbes Kazakhstan, companies using data-driven cost tracking report "a 30% productivity increase, while release quality improves by 25%" — confirming that visibility into feature costs leads to meaningful budget savings. — [Forbes Kazakhstan, April 2026](https://forbes.kz) ## Key Takeaways 1. **Cost per feature is a formula, not a mystery** — Direct Labor × Overhead × Infrastructure gives you the true number 2. **Self-reported time tracking is unreliable** — automated IDE tracking is more accurate and less disruptive 3. **Individual hourly rates matter** — a "developer hour" is not a standard unit; rates vary 2-3x across roles 4. **Track costs in real time** — discovering a feature went 2x over budget after launch is too late 5. **Use cost data for ROI-based prioritization** — the most requested feature isn't always the most valuable one --- **Ready to see what your features actually cost?** [PanDev Metrics](https://pandev-metrics.com) gives you automated cost tracking with zero manual time logging. Start with the free tier. --- ## Engineering Team ROI: How to Calculate and Present to Business URL: https://pandev-metrics.com/docs/blog/engineering-roi Date: 2026-01-02 Tags: financial-analytics, engineering-metrics, leadership, roi Description: A CTO's guide to calculating and presenting engineering team ROI to the CEO and board. Includes formulas, frameworks, and presentation tips. Every quarter, CTOs face the same uncomfortable meeting. The CEO asks: "We spent $2.4M on engineering last quarter. What did we get for it?" And the answer is usually a list of shipped features — not a financial return. Engineering is the largest cost center in most technology companies, yet it's the one with the least financial accountability. Marketing can show customer acquisition cost. Sales can show revenue per rep. Engineering shows... velocity points? [McKinsey's analysis of software developer productivity](https://www.mckinsey.com/industries/technology-media-and-telecommunications/our-insights/yes-you-can-measure-software-developer-productivity) highlights this gap: engineering output is measurable, but most organizations haven't built the systems to do it. It's time to change that. ![Engineering dashboard showing team activity — the numerator in ROI calculations](https://pandev-metrics.com/img/blog/dashboard-clean.png) *Engineering dashboard showing team activity — the numerator in ROI calculations.* ## Why Engineering ROI Is Hard (But Not Impossible) Engineering ROI is genuinely harder to calculate than sales or marketing ROI. Here's why: 1. **Indirect value creation** — Engineering doesn't close deals directly; it builds the product that enables sales 2. **Long feedback loops** — A feature built in Q1 might not generate measurable revenue until Q3 3. **Maintenance is invisible** — Keeping systems running and secure creates enormous value but generates no new revenue 4. **Attribution is complex** — When revenue grows 20%, how much was engineering vs. sales vs. marketing? These are real challenges, but they're not excuses. CFOs and CEOs don't need perfect attribution — they need a defensible framework that shows engineering investment connects to business outcomes. ## The Engineering ROI Framework Here's a practical framework that works for board-level conversations. ### The Core Formula ``` Engineering ROI = (Value Generated - Engineering Cost) / Engineering Cost × 100% ``` The engineering cost side is relatively straightforward. The value generated side requires breaking engineering output into categories. ### Calculating Engineering Cost Total engineering cost includes: ``` Engineering Cost = Salaries + Benefits + Contractors + Tools + Infrastructure + Facilities_Allocation ``` **Example for a 30-person engineering team:** | Cost Category | Annual Cost | |---------------|------------:| | Salaries (30 engineers, avg $140K) | $4,200,000 | | Benefits (25% of salaries) | $1,050,000 | | Contractors / outsourcing | $360,000 | | Tools and licenses | $180,000 | | Cloud infrastructure | $480,000 | | Office / facilities allocation | $270,000 | | **Total Engineering Cost** | **$6,540,000** | ### Calculating Value Generated Engineering value falls into four categories: #### 1. Revenue-Enabling Features Features that directly enable new revenue or expand existing revenue. This is the most straightforward category. ``` Revenue Feature Value = New ARR Attributed to Feature × Attribution_Percentage ``` **Example:** Your team built an enterprise SSO feature. Since launch, 12 enterprise deals worth $720K ARR cited SSO as a requirement. If engineering gets 40% attribution (sales and marketing get the rest): Value = $720,000 × 0.40 = **$288,000** #### 2. Retention and Churn Prevention Engineering work that prevents customers from leaving. Performance improvements, reliability upgrades, and requested features that retain at-risk accounts. ``` Retention Value = Saved_ARR × Churn_Prevention_Rate × Attribution_Percentage ``` **Example:** Performance improvements reduced page load time from 4s to 1.2s. Customer success reports that 8 accounts ($340K ARR) were considering leaving due to performance issues and are now satisfied. Value = $340,000 × 0.70 × 0.50 = **$119,000** #### 3. Efficiency Gains Internal tools, automation, and process improvements that reduce costs elsewhere in the organization. ``` Efficiency Value = Hours_Saved × Hourly_Cost_of_Saved_Labor ``` **Example:** Engineering built an automated billing reconciliation tool. The finance team previously spent 60 hours/month on manual reconciliation ($75/h loaded cost). Value = 60h × 12 months × $75 = **$54,000/year** #### 4. Platform and Infrastructure Value This is the hardest to quantify but often the most valuable. Includes: keeping systems running (uptime), security compliance, scalability that enables growth, and technical debt reduction that accelerates future development. ``` Platform Value = Downtime_Prevention_Value + Compliance_Value + Velocity_Impact ``` **Example approach:** If your platform generates $50K/day in revenue and your SRE team maintains 99.95% uptime (vs. industry average of 99.5%), the prevented downtime is: Prevented downtime = (99.95% - 99.5%) × 365 days = 1.64 days/year Value = 1.64 × $50,000 = **$82,000/year** ### Putting It All Together | Value Category | Annual Value | |----------------|------------:| | Revenue-enabling features | $1,440,000 | | Retention / churn prevention | $595,000 | | Efficiency gains | $216,000 | | Platform / infrastructure value | $820,000 | | **Total Value Generated** | **$3,071,000** | ``` Engineering ROI = ($3,071,000 - $6,540,000) / $6,540,000 × 100% = -53% ``` Wait — negative ROI? Yes, and that's okay for this example. Here's why. ## Interpreting Engineering ROI: The Nuances A raw ROI calculation for engineering will almost always look negative or modest because: 1. **Revenue attribution is conservative** — giving engineering 30-40% credit for features that enable 100% of the revenue understates the contribution 2. **Compounding value isn't captured** — the SSO feature doesn't just generate $288K in year one; it generates recurring revenue for years 3. **Counterfactual value is missing** — what would happen to the business with no engineering? Revenue goes to zero ### The Lifetime ROI Adjustment For a more accurate picture, apply a lifetime multiplier to revenue-enabling features: ``` Adjusted Revenue Value = Annual Revenue Impact × Expected Customer Lifetime (years) × NPV_Factor ``` If the average customer stays 4 years and you use a 10% discount rate: Adjusted value = $1,440,000 × 3.17 (NPV of 4-year stream at 10%) = **$4,564,800** With this adjustment: ``` Adjusted ROI = ($6,245,800 - $6,540,000) / $6,540,000 × 100% = -4.5% ``` Still slightly negative, but much closer to breakeven. And this is a conservative estimate for a 30-person team at a growing SaaS company. Higher-performing teams with better product-market fit routinely achieve positive engineering ROI. ## How to Present Engineering ROI to the CEO Calculating ROI is half the battle. Presenting it effectively is the other half. Here's a framework that works. ### Slide 1: The Investment Summary Keep it simple. Show total engineering spend and break it into categories the CEO cares about. ``` Total Engineering Investment: $6.54M ├── New Feature Development: 45% ($2.94M) ├── Maintenance and Reliability: 25% ($1.64M) ├── Technical Debt / Platform: 20% ($1.31M) └── Support and Incidents: 10% ($0.65M) ``` ### Slide 2: The Value Created Map engineering output to business outcomes, not technical deliverables. **Instead of:** "Shipped 47 features, closed 312 bugs, deployed 1,247 times" **Say:** "Engineering directly enabled $1.44M in new ARR, prevented $595K in churn, and saved $216K in operational costs. Total measurable impact: $3.07M against $6.54M investment." ### Slide 3: Efficiency Trends Show that engineering is getting more efficient over time. Key metrics: - **Cost per feature point** (trending down = good) - **Revenue per engineering dollar** (trending up = good) - **Lead time for revenue-critical features** (trending down = good) ### Slide 4: Forward-Looking Investment Case End with what the next quarter's investment will produce. Tie the engineering roadmap to specific revenue opportunities. "The Q2 roadmap targets $2.1M in ARR opportunity. Key bets: Enterprise API ($800K pipeline), Advanced Analytics ($600K pipeline), Mobile App ($700K pipeline). Required engineering investment: $1.8M." ## Tracking the Metrics You Need To calculate and present engineering ROI consistently, you need: 1. **Accurate time allocation data** — how engineering time splits across features, maintenance, and debt 2. **Cost per developer** — individual hourly rates, not averages 3. **Feature-to-revenue mapping** — connecting shipped features to business outcomes 4. **Trend data** — quarter-over-quarter improvements in efficiency ### What to Track Monthly | Metric | Formula | Target Trend | |--------|---------|:------------:| | Cost per shipped feature | Total eng cost / Features shipped | ↓ | | Revenue per eng dollar | Revenue enabled / Eng spend | ↑ | | Allocation ratio | New features / Total eng time | 60-70% | | Cost variance | Actual cost / Estimated cost | → 1.0 | | Engineering cost ratio | Eng spend / Total revenue | ↓ as you scale | ### Industry Benchmarks For context when presenting to the board ([Gartner IT Spending Forecast](https://www.gartner.com/en/newsroom/press-releases/gartner-forecasts-worldwide-it-spending-to-grow-9-percent-in-2025) and [Deloitte CFO Survey data](https://www.deloitte.com/us/en/insights/topics/economy/cfo-survey.html) provide additional framing): | Company Stage | Eng Cost as % of Revenue | Eng Team as % of Headcount | |---------------|:------------------------:|:--------------------------:| | Early-stage startup | 40-60% | 60-80% | | Growth stage | 25-35% | 40-50% | | Mature SaaS | 15-25% | 25-35% | | Enterprise software | 10-20% | 20-30% | If your engineering cost ratio is within range for your stage, that's a data point in your favor. If it's above range, you need the ROI data to justify the investment. ## Common Mistakes When Calculating Engineering ROI ### Mistake 1: Using Average Developer Cost A team with 5 senior engineers ($160K) and 5 juniors ($80K) has an average cost of $120K. But if the seniors are doing 80% of the revenue-critical work, your cost attribution is wrong. **Use individual rates.** ### Mistake 2: Ignoring Maintenance Value Teams often present only new feature value, making maintenance look like wasted money. Frame it differently: "Our 25% maintenance allocation prevents an estimated $1.2M in annual churn by keeping the platform reliable." ### Mistake 3: One-Time Value Instead of Lifetime A feature that generates $100K in its first quarter might generate $400K+ over its lifetime. Presenting only the first-quarter value dramatically understates engineering contribution. ### Mistake 4: No Comparison Baseline ROI in isolation means little. Compare against: last quarter, last year, industry benchmarks, or the cost of not building (opportunity cost of lost deals). ## How PanDev Metrics Enables ROI Tracking Calculating engineering ROI requires data that most organizations don't have. PanDev Metrics provides the foundation: - **Automated time tracking** across 10+ IDEs — know exactly how time splits between features, maintenance, and debt - **Individual hourly rates** — set per-developer rates for accurate cost attribution - **Project-level financial analytics** — see cost per project, per team, per developer in real time - **4-stage Lead Time breakdown** — understand not just how much features cost, but where time is spent - **On-premise deployment** — financial data (salaries, rates, project costs) stays within your infrastructure - **AI assistant** — generates insights and summaries ready for executive presentations The goal isn't perfect ROI attribution. It's going from "we don't know" to "here's a defensible number backed by real data." That shift alone changes how the C-suite views engineering investment. ## Key Takeaways 1. **Engineering ROI is calculable** — use the four-category framework: revenue features, retention, efficiency, platform 2. **Conservative attribution is fine** — a defensible 30-40% attribution beats a questionable 100% 3. **Show trends, not snapshots** — quarter-over-quarter improvement matters more than absolute numbers 4. **Frame maintenance as value preservation** — it's not waste; it's revenue protection 5. **Connect the roadmap to revenue** — every engineering investment should map to a business outcome --- **Want to calculate your engineering team's ROI with real data?** [PanDev Metrics](https://pandev-metrics.com) gives you automated cost tracking, financial analytics, and the data foundation to make the business case for engineering. --- ## Hourly Rates and Cost Tracking: Transparent Financial Analytics for Your Team URL: https://pandev-metrics.com/docs/blog/hourly-rates-cost-tracking Date: 2026-01-01 Tags: financial-analytics, cost-management, tutorial, engineering-metrics Description: Step-by-step tutorial on setting up hourly rates and cost tracking for engineering teams. For CFOs and engineering leaders. Your engineering team has 40 developers across three offices, a mix of full-time employees and contractors, salary ranges from $60K to $190K, and contractor rates from $45/h to $150/h. Someone asks: "How much did Project X cost last month?" You open a spreadsheet. You check Jira. You send three Slack messages. An hour later, you have a rough guess. With [global IT spending projected to exceed $5 trillion in 2025](https://www.gartner.com/en/newsroom/press-releases/gartner-forecasts-worldwide-it-spending-to-grow-9-percent-in-2025), that level of imprecision is expensive at any scale. ![Project time data that feeds into hourly rate cost calculations](https://pandev-metrics.com/img/blog/projects.png) *Project time data that feeds into hourly rate cost calculations.* ## Why Hourly Rate Tracking Matters Every developer on your team has a different cost to the organization. When you track engineering costs using averages — "we have 40 developers at roughly $130K average" — you lose critical financial visibility. Consider two scenarios: **Scenario A:** A critical security fix requires 80 hours of work. Your two senior security engineers ($95/h loaded) handle it. - Actual cost: 80h × $95 = **$7,600** **Scenario B:** The same fix is routed to a team of mid-level developers ($65/h loaded) who need 120 hours because they lack domain expertise. - Actual cost: 120h × $65 = **$7,800** The costs are similar, but the outcomes are different. Scenario A took less calendar time, and the senior engineers produced more robust code. Without hourly rate tracking, both scenarios look identical in your sprint reports. Now scale this to hundreds of decisions per quarter. The cumulative impact of assigning the wrong-cost resources to the wrong projects is significant. [Stripe's Developer Coefficient research](https://stripe.com/reports/developer-coefficient-2018) found that companies lose a substantial portion of engineering capacity to inefficiency — and misallocated resources are a core driver. ## The Building Blocks of Cost Tracking Effective cost tracking requires three data inputs: ``` Project Cost = Σ (Tracked_Hours_per_person × Loaded_Hourly_Rate_per_person) ``` Let's break down each component. ### Component 1: Loaded Hourly Rate The loaded hourly rate includes everything the company pays for a developer's time, not just their salary. ``` Loaded Hourly Rate = (Annual Salary + Benefits + Taxes + Equipment + Allocated_Overhead) / Annual_Working_Hours ``` **Step-by-step calculation for a full-time employee:** | Component | Amount | Notes | |-----------|-------:|-------| | Annual salary | $140,000 | Base compensation | | Benefits (health, dental, 401k) | $28,000 | ~20% of salary | | Payroll taxes (employer portion) | $10,710 | FICA, state taxes | | Equipment and licenses | $4,000 | Laptop, monitors, IDE licenses | | Office / remote stipend allocation | $6,000 | Per-person facility cost | | Training and development | $2,000 | Conferences, courses | | **Total loaded cost** | **$190,710** | | | Annual working hours | 1,880 | 52 weeks × 40h - PTO - holidays | | **Loaded hourly rate** | **$101.44/h** | | A developer with a $140K salary actually costs the company **$101/h** when fully loaded. This is the number that matters for project costing. **For contractors, the calculation is simpler:** ``` Contractor Loaded Rate = Invoice Rate × (1 + Management_Overhead_Percentage) ``` A contractor billing $85/h with a 10% management overhead has a loaded rate of $93.50/h. ### Component 2: Tracked Hours Per Person This is where most cost tracking systems fail. There are three approaches: **Approach 1: Manual time logging (least accurate)** Developers fill out timesheets or log hours in Jira/Linear. Typical accuracy: 60-70%. **Approach 2: Allocation-based (moderate accuracy)** Assign developers to projects at a percentage level: "Alex is 80% Project A, 20% Project B." Typical accuracy: 70-80%. **Approach 3: Automated IDE tracking (most accurate)** IDE plugins capture actual coding time per repository, branch, and project. No manual input required. Typical accuracy: 90-95%. **Accuracy comparison:** | Method | Accuracy | Developer Burden | Granularity | |--------|:--------:|:----------------:|:-----------:| | Manual timesheets | 60-70% | High (15-30 min/day) | Task level | | Allocation-based | 70-80% | None | Project level | | Automated IDE tracking | 90-95% | None | Branch/commit level | The accuracy gap between manual and automated tracking compounds quickly. On a multi-million-dollar annual engineering budget, even a moderate accuracy difference translates to hundreds of thousands in misattributed costs. ### Component 3: Project Mapping Hours need to map to projects, features, or cost centers. This mapping can happen through: - **Repository → Project** — each repo belongs to a project - **Branch naming conventions** — branches prefixed with ticket IDs map to features - **Commit messages** — parsed for ticket references - **Manual tagging** — for cross-project work The most reliable approach combines automatic repository-to-project mapping with branch-level feature attribution. ## Setting Up Hourly Rates: A Practical Tutorial Here's a step-by-step guide to implementing hourly rate tracking for your engineering organization. ### Step 1: Define Rate Tiers You have two options: individual rates or role-based tiers. **Option A: Individual rates (highest accuracy)** Every developer has their own loaded hourly rate calculated from their actual compensation package. This gives you the most accurate cost data but requires maintaining individual rate records. Best for: organizations with fewer than 100 engineers, or those with significant rate variation (mix of FTEs and contractors across multiple regions). **Option B: Role-based tiers (simpler to maintain)** Define rate tiers by role and level: | Tier | Roles | Loaded Rate | |------|-------|:-----------:| | Tier 1 | Junior developers, junior QA | $55/h | | Tier 2 | Mid-level developers, designers | $75/h | | Tier 3 | Senior developers, senior QA | $95/h | | Tier 4 | Staff/Principal engineers, architects | $120/h | | Tier 5 | Engineering managers (coding time) | $110/h | | Contractor A | Offshore contractors | $45/h | | Contractor B | Domestic contractors | $100/h | Best for: organizations with 100+ engineers, or those with standardized compensation bands. ### Step 2: Calculate Loaded Rates For each tier or individual, calculate the fully loaded rate using the formula from Component 1. Important details to include: - **Don't forget employer taxes** — these add 7-10% on top of salary in the US - **Include equity if material** — for startups, equity grants can add 10-30% to total compensation - **Use actual working hours** — don't assume 2,080 (52 × 40). After PTO, holidays, and sick days, most US companies see 1,800-1,920 actual hours - **Update rates quarterly or annually** — after raise cycles, benefits changes, or contractor renegotiations ### Step 3: Map Developers to Rates Create a mapping between each team member and their rate. In PanDev Metrics, this is a straightforward configuration: 1. Navigate to the Financial Analytics section 2. For each developer, set their hourly rate (or assign them to a rate tier) 3. Set effective dates — rates can change over time, and historical costs should use the rate that was active at the time ### Step 4: Verify Project Mapping Ensure that repositories and branches map correctly to projects and cost centers: - Each repository should belong to at least one project - Cross-project repositories should have branch-level mapping rules - Shared infrastructure repositories can be allocated proportionally across projects ### Step 5: Set Up Reporting Configure the reports your stakeholders need: **For CFOs:** - Monthly cost by project / product line - Cost variance: actual vs. budget - Contractor vs. FTE cost split - Quarter-over-quarter cost trends **For Engineering Leaders:** - Cost per team per sprint - Cost per feature (linked to roadmap items) - Resource allocation by project - Cost efficiency: cost per story point or per deployment **For Project Managers:** - Real-time project cost tracker - Burn rate and projected total cost - Cost by team member (for resource planning) ## Common Pitfalls and How to Avoid Them ### Pitfall 1: Using Salary Instead of Loaded Rate A $140K developer doesn't cost $67/h ($140K / 2,080h). They cost $101/h when you include benefits, taxes, overhead, and actual working hours. Using salary-based rates underestimates project costs by 30-50%. ### Pitfall 2: Ignoring Part-Time Allocations A developer split 60/40 between two projects doesn't always work 24h on one and 16h on the other each week. Automated tracking reveals the actual split, which often differs significantly from the planned allocation. ### Pitfall 3: Forgetting to Update Rates After annual raises, a $95/h developer might now cost $102/h. If you don't update rates, your cost tracking drifts further from reality every month. Set a calendar reminder to update rates after every compensation cycle. ### Pitfall 4: Over-Engineering the System You don't need perfect cost attribution from day one. Start with role-based tiers, project-level mapping, and automated time tracking. Refine to individual rates and feature-level attribution once the basics are working. ### Pitfall 5: Making It Punitive Cost tracking should inform decisions, not punish developers. If a senior developer's project costs more because their rate is higher, that's expected — they're likely tackling harder problems. Cost data is for resource allocation and budgeting, not performance management. ## What Transparent Cost Tracking Looks Like in Practice Here's what a mature cost tracking setup produces: **Monthly Project Cost Report:** | Project | FTE Hours | Contractor Hours | FTE Cost | Contractor Cost | Total | vs. Budget | |---------|:---------:|:----------------:|---------:|----------------:|------:|-----------:| | Platform v3 | 1,240h | 320h | $117,800 | $28,800 | $146,600 | +8% | | Mobile App | 680h | 0h | $57,800 | $0 | $57,800 | -3% | | Internal Tools | 360h | 160h | $30,600 | $12,000 | $42,600 | +22% | | Customer Fixes | 480h | 80h | $40,800 | $6,400 | $47,200 | -11% | At a glance, the CFO can see that Internal Tools is 22% over budget (worth investigating) while Mobile App is slightly under. **Team Cost Efficiency:** | Team | Members | Monthly Cost | Deployments | Cost per Deploy | |------|:-------:|------------:|:-----------:|----------------:| | Platform | 8 | $92,000 | 47 | $1,957 | | Frontend | 6 | $58,200 | 62 | $939 | | Data | 5 | $61,000 | 23 | $2,652 | | Mobile | 4 | $41,800 | 18 | $2,322 | This doesn't mean the Data team is "worse" — their deployments are likely more complex. But it gives leadership a starting point for conversations about resource allocation and process improvement. ## How PanDev Metrics Makes This Easy Setting up comprehensive cost tracking typically requires cobbling together data from HR systems, time tracking tools, project management platforms, and spreadsheets. PanDev Metrics consolidates this: - **Built-in hourly rate management** — set individual or tier-based rates with effective dates - **Automatic time tracking** — 10+ IDE plugins capture coding time without any manual logging - **Multi-level cost aggregation** — costs roll up from developer → team → project → product line - **Financial dashboards** — pre-built reports for CFOs, engineering leaders, and project managers - **On-premise deployment** — salary data, hourly rates, and project costs never leave your infrastructure - **Free tier available** — start tracking costs without any upfront investment The most important advantage: your developers don't need to change anything about their workflow. They code as usual, and the financial data appears automatically. ## Key Takeaways 1. **Use loaded hourly rates, not salaries** — the true cost of a developer is 30-50% higher than their salary alone 2. **Automate time tracking** — manual timesheets waste developer time and produce inaccurate data 3. **Start with role-based tiers** — you can refine to individual rates once the system is running 4. **Update rates after every compensation cycle** — stale rates produce stale data 5. **Keep it transparent but not punitive** — cost data is for better decisions, not surveillance --- **Ready to set up transparent cost tracking for your engineering team?** [PanDev Metrics](https://pandev-metrics.com) includes financial analytics with hourly rates, project costing, and automated time tracking. --- ## How to Reduce Cost of Delivery by 30% Without Losing Quality URL: https://pandev-metrics.com/docs/blog/cut-delivery-cost-30-percent Date: 2025-12-29 Tags: financial-analytics, cost-management, case-study, engineering-efficiency Description: A case-study-style guide showing how engineering teams reduce delivery costs by 30% using data-driven optimization, not layoffs. A Series B SaaS company with a 35-person engineering team was spending nearly $800K per month on software delivery. The CEO wanted to cut costs. The board suggested reducing headcount. The CTO proposed a different approach: **find the waste first, then eliminate it**. Six months later, monthly delivery cost dropped to roughly $540K — a reduction of more than 30% — while deployment frequency actually increased. No layoffs. No quality regression. [McKinsey's research on developer productivity](https://www.mckinsey.com/industries/technology-media-and-telecommunications/our-insights/yes-you-can-measure-software-developer-productivity) supports this pattern: the biggest efficiency gains come from eliminating process friction, not cutting headcount. Here's the playbook. ![Project-level time tracking revealing cost distribution across the engineering portfolio](https://pandev-metrics.com/img/blog/projects.png) *Project-level time tracking revealing cost distribution across the engineering portfolio.* ## The Starting Point: Understanding Where Money Goes Before cutting costs, you need to know where the money is being spent. This sounds obvious, but most engineering organizations cannot answer the question with precision. The CTO's first step was deploying automated activity tracking across the team. After 30 days of data collection, the picture became clear. ### The Baseline: Where 35 Engineers Spent Their Time | Activity | % of Total Time | Monthly Cost | |----------|:---------------:|------------:| | New feature development | 38% | $296,400 | | Bug fixes and regressions | 22% | $171,600 | | Code reviews and waiting | 15% | $117,000 | | Meetings and planning | 12% | $93,600 | | Deployment and release process | 8% | $62,400 | | Context switching / idle | 5% | $39,000 | | **Total** | **100%** | **$780,000** | The numbers told a story the CTO already suspected: only 38% of engineering cost went toward building new features. The rest — 62% — was overhead, rework, and process friction. The question shifted from "who do we cut?" to **"which of these categories can we shrink?"** ## Phase 1: Eliminate Rework (Months 1-2) ### The Problem Bug fixes and regressions consumed 22% of total engineering time — $171,600/month. That's over $2M per year spent fixing things that were already built. ### The Investigation Analyzing the bug data revealed patterns: | Bug Source | % of Total Bugs | Avg. Fix Cost | |------------|:---------------:|:-------------:| | Missing edge cases in original implementation | 35% | $1,800 | | Integration issues between services | 28% | $3,200 | | Regressions from unrelated changes | 22% | $2,100 | | Environment-specific issues | 15% | $900 | Integration bugs were the most expensive per incident. Missing edge cases were the most common. Regressions were the most preventable. ### The Actions **Action 1: Introduce mandatory integration test coverage for inter-service calls.** Cost to implement: 2 weeks of one senior engineer's time (~$7,600). Result: Integration bugs dropped 55% within two months. **Action 2: Expand automated regression test suite.** Cost: 3 weeks across two QA engineers (~$9,900). Result: Regressions from unrelated changes dropped 60%. **Action 3: Implement structured code review checklist focused on edge cases.** Cost: Essentially free — a document and a 30-minute team meeting. Result: Missing edge case bugs dropped 25%. ### Phase 1 Results | Metric | Before | After | Change | |--------|:------:|:-----:|:------:| | Bug fix time allocation | 22% | 13% | -9 points | | Monthly bug fix cost | $171,600 | $101,400 | -$70,200 | | Bug escape rate | 4.2 per sprint | 1.8 per sprint | -57% | | Investment to achieve | | $17,500 | One-time | **Monthly savings: $70,200** with a one-time investment of $17,500. Payback period: 8 days. ## Phase 2: Reduce Review and Wait Time (Months 2-3) ### The Problem Code reviews and waiting consumed 15% of total time — $117,000/month. The data showed the issue wasn't the reviews themselves but the waiting between stages. ### The Investigation Using PanDev Metrics' 4-stage Lead Time breakdown, the team measured each phase: ``` Total Lead Time: 8.4 days average ├── Coding Time: 2.1 days (25%) ← actual work ├── Pickup Time: 2.8 days (33%) ← waiting for review ├── Review Time: 1.9 days (23%) ← actual review work └── Merge-to-Deploy: 1.6 days (19%) ← waiting for deployment ``` A third of lead time was pure waiting — PRs sitting in a queue with no reviewer assigned. This wasn't just a time cost; it also caused context switching when developers came back to address review comments days later. The [DORA State of DevOps Report](https://dora.dev/research/) consistently identifies review wait time as one of the key bottlenecks separating elite performers from the rest. ### The Actions **Action 1: Implement review SLAs.** Rule: Every PR must receive its first review within 4 business hours. Automated reminders ping reviewers after 3 hours. Result: Pickup time dropped from 2.8 days to 0.8 days. **Action 2: Limit PR size.** Guideline: PRs should be under 400 lines of changed code. Larger changes must be split. Result: Review time dropped from 1.9 days to 1.1 days (smaller PRs are faster to review). **Action 3: Automate deployment pipeline.** Investment: 3 weeks of DevOps engineering ($11,400). Result: Merge-to-deploy time dropped from 1.6 days to 0.3 days. ### Phase 2 Results | Metric | Before | After | Change | |--------|:------:|:-----:|:------:| | Average lead time | 8.4 days | 4.3 days | -49% | | Review/waiting cost allocation | 15% | 9% | -6 points | | Monthly review/waiting cost | $117,000 | $70,200 | -$46,800 | | Deployment frequency | 8/month | 22/month | +175% | **Monthly savings: $46,800.** The faster feedback loops also improved developer satisfaction — a benefit that's hard to quantify but real. ## Phase 3: Optimize Meeting Culture (Months 3-4) ### The Problem Meetings and planning consumed 12% of engineering time — $93,600/month. The team averaged 11.2 hours of meetings per developer per week. ### The Investigation Not all meetings are waste. The team categorized their meetings: | Meeting Type | Hours/Week/Dev | Value Assessment | |-------------|:--------------:|:----------------:| | Daily standup | 2.5h | Medium — too long | | Sprint planning | 1.5h | High — necessary | | Sprint retro | 1.0h | High — necessary | | Cross-team syncs | 2.2h | Low — most are FYI | | 1:1s with manager | 1.0h | High — necessary | | Ad-hoc discussions | 3.0h | Mixed — some necessary | Daily standups at 2.5 hours/week (30 min/day) were too long. Cross-team syncs were mostly status updates that could be async. ### The Actions **Action 1: Cap standups at 10 minutes.** Use async updates (Slack/written) for anything that needs discussion, then schedule focused follow-ups. Result: Standup time dropped from 2.5h to 1.0h/week. **Action 2: Replace cross-team syncs with async written updates.** Monthly in-person syncs replaced weekly 30-minute calls. Result: Cross-team meeting time dropped from 2.2h to 0.5h/week. **Action 3: Implement "Maker's Schedule" — no-meeting blocks on Tuesday and Thursday mornings.** Result: Ad-hoc meeting time dropped from 3.0h to 1.8h/week as people batched discussions. ### Phase 3 Results | Metric | Before | After | Change | |--------|:------:|:-----:|:------:| | Meeting hours per dev per week | 11.2h | 6.8h | -39% | | Meeting cost allocation | 12% | 7.3% | -4.7 points | | Monthly meeting cost | $93,600 | $56,940 | -$36,660 | **Monthly savings: $36,660** — and engineers got 4.4 more hours of focused work time per week. ## Phase 4: Right-Size Resource Allocation (Months 4-6) ### The Problem With improved visibility into per-project costs, the CTO discovered that resource allocation was significantly misaligned with business priorities. ### The Investigation | Project | Business Priority | % of Eng Cost | Gap | |---------|:-----------------:|:-------------:|:---:| | Core Platform | Critical (70% of revenue) | 30% | **Under-invested** | | New Market Product | High (growth bet) | 15% | Appropriate | | Internal Tools | Medium | 25% | **Over-invested** | | Legacy System | Low (sunset in 6 months) | 20% | **Over-invested** | | Misc / unattributed | N/A | 10% | Unknown | 25% of engineering cost going to internal tools was disproportionate. 20% going to a system being sunset in 6 months was clearly wasteful. ### The Actions **Action 1: Reduce legacy system team from 7 to 3 engineers.** Move 4 engineers to the core platform team. Remaining 3 handle critical maintenance only. **Action 2: Consolidate internal tools effort.** Replace two custom internal tools with off-the-shelf solutions. Reduce internal tools team from 9 to 5 engineers. **Action 3: Redirect freed-up capacity to Core Platform and New Market Product.** Note: No one was laid off. Engineers were reassigned to higher-priority projects where their skills were needed. ### Phase 4 Results | Metric | Before | After | |--------|:------:|:-----:| | Core Platform investment | 30% | 45% | | Legacy System cost | $156,000/mo | $54,000/mo | | Internal Tools cost | $195,000/mo | $90,000/mo | | Revenue from Core Platform | grew 12% in 2 months | | **Monthly savings from reallocation: $102,000** (the savings are real even though headcount didn't change — the same cost produced higher-value output). ## The Combined Result: 6 Months Later | Optimization Area | Monthly Savings | % of Total Savings | |-------------------|----------------:|:------------------:| | Rework elimination | $70,200 | 29% | | Review/wait time reduction | $46,800 | 19% | | Meeting optimization | $36,660 | 15% | | Resource reallocation | $102,000 | 42% | | **Total monthly savings** | **$240,000** | | ``` Original monthly cost: $780,000 Optimized monthly cost: $540,000 Reduction: $240,000 (30.7%) ``` **Annualized savings: $2.88M** And the quality metrics? They improved: | Quality Metric | Before | After | |----------------|:------:|:-----:| | Bug escape rate | 4.2/sprint | 1.8/sprint | | Deployment frequency | 8/month | 22/month | | Lead time | 8.4 days | 4.3 days | | Customer-reported incidents | 12/month | 5/month | The 30% cost reduction came from eliminating waste and friction, not from reducing capacity or cutting corners. > Forbes Kazakhstan reports similar findings across the industry: "Results showed a 30% productivity increase, while release quality improves by 25%." — [Forbes Kazakhstan, April 2026](https://forbes.kz) ## The Playbook: How to Replicate This ### Prerequisites 1. **Automated activity tracking** — you cannot optimize what you cannot measure. Deploy IDE tracking across the team. 2. **Hourly rate data** — set up individual or role-based loaded hourly rates so you can convert time into money. 3. **Project mapping** — ensure every repository and branch maps to a project or cost center. 4. **Lead time breakdown** — you need to see where time is spent across the delivery pipeline, not just total cycle time. ### Sequence **Month 1:** Deploy tracking, collect baseline data. Do not make changes yet — just observe. **Month 2:** Analyze the data. Identify the top 3 cost categories that can be reduced. Start with the quickest wins (usually rework elimination and meeting optimization). **Month 3-4:** Implement changes. Measure the impact weekly. **Month 5-6:** Tackle resource allocation — this takes longer because it involves team restructuring, but it often produces the largest savings. ### What Not to Do - **Don't cut headcount as step 1.** You'll lose institutional knowledge and likely just shift the remaining work to slower, more expensive contractors later. - **Don't use cost data to micromanage.** Developers who feel surveilled will game the metrics or leave. - **Don't expect overnight results.** Rework reduction takes a few sprints to show up. Meeting culture changes take weeks to stick. - **Don't ignore quality metrics.** If bug rates or customer incidents increase, your cost reduction is actually a cost shift to the future. ## How PanDev Metrics Supports This Process Each phase of the cost optimization playbook requires specific data. PanDev Metrics provides: - **Automated time tracking** (10+ IDE plugins) — baseline activity data without manual logging - **Financial analytics with hourly rates** — convert developer time into actual costs per project, team, and feature - **4-stage Lead Time breakdown** — identify where time is wasted in the delivery pipeline - **DORA metrics** — track deployment frequency, lead time, and failure rate to ensure quality isn't degrading - **AI assistant** — surface optimization opportunities from your data - **On-premise deployment** — keep all financial and activity data within your infrastructure The cost of not knowing is always higher than the cost of tracking. When you can see exactly where $780K per month goes, the path to $540K becomes visible. ## Key Takeaways 1. **Measure before you cut** — 30 days of automated tracking reveals where the real waste is 2. **Rework is the lowest-hanging fruit** — fixing your quality processes saves money immediately 3. **Wait time is hidden cost** — developers waiting for code reviews is expensive idle capacity 4. **Meeting culture is a cost lever** — every unnecessary meeting hour costs $75-120 per person 5. **Resource reallocation beats layoffs** — moving people to higher-priority work produces more value without reducing capacity 6. **30% savings is achievable** — but it takes 4-6 months of sustained, data-driven effort --- **Want to find the waste hidden in your engineering spend?** [PanDev Metrics](https://pandev-metrics.com) gives you the visibility to optimize delivery costs with data, not guesswork. --- ## IT Budget Planning With Data, Not Guesswork URL: https://pandev-metrics.com/docs/blog/it-budgeting-with-data Date: 2025-12-26 Tags: financial-analytics, budgeting, engineering-metrics, leadership Description: How to build IT budgets using real engineering data instead of last-year-plus-15%. A practical guide for CFOs and CTOs. It's budget season. The CTO submits an engineering budget request: $8.2M for next year, up 18% from this year. The CFO asks for justification. The CTO points to headcount growth, salary inflation, and a list of planned projects. The CFO pushes back: "Can we do it for $7M?" The CTO says no. They compromise at $7.5M. **Neither number is based on data.** The CTO added a buffer to last year's spend. The CFO cut it by a round number. The compromise has no analytical basis. Both sides walk away slightly unhappy. A [Deloitte CFO Survey](https://www.deloitte.com/us/en/insights/topics/economy/cfo-survey.html) found that technology spending is consistently one of the hardest budget categories for finance teams to evaluate — largely because the inputs are opaque. This is how most IT budgets are built. It doesn't have to be. ![Projects with tracked time — the data foundation for engineering budgets](https://pandev-metrics.com/img/blog/projects.png) *Projects with tracked time — the data foundation for engineering budgets.* ## The Problem with Traditional IT Budgeting Most engineering budgets are built using one of two methods: **Method 1: Last Year Plus Inflation** Take last year's spend, add 10-20% for growth and salary inflation, submit. This is fast but ignores changes in project scope, team composition, and efficiency. **Method 2: Headcount-Based** Multiply planned headcount by average cost per head, add infrastructure and tooling. This captures team size but treats all developers as interchangeable units with identical output. Both methods share the same fundamental flaw: **they budget for inputs (people, infrastructure) without connecting to outputs (features, products, business outcomes).** [Gartner's IT spending forecasts](https://www.gartner.com/en/newsroom/press-releases/gartner-forecasts-worldwide-it-spending-to-grow-9-percent-in-2025) project continued growth in technology budgets, which makes the lack of output-based justification even more consequential. The result? Engineering budgets that are disconnected from business strategy, difficult to justify to the board, and impossible to hold accountable mid-year. ## A Data-Driven Budgeting Framework Here's an alternative approach that connects engineering spend to business outcomes. It requires historical data, which is why tracking engineering costs throughout the year (not just at budget time) is essential. ### Step 1: Understand Historical Cost Patterns Before projecting forward, look back. You need to know how last year's budget was actually spent. **Historical cost breakdown example:** | Category | Planned | Actual | Variance | |----------|--------:|-------:|---------:| | New feature development | $2,800,000 | $2,340,000 | -16% | | Maintenance and reliability | $1,200,000 | $1,680,000 | +40% | | Technical debt / platform | $800,000 | $620,000 | -22% | | Support and incidents | $400,000 | $580,000 | +45% | | Infrastructure (cloud) | $600,000 | $720,000 | +20% | | Tooling and licenses | $200,000 | $190,000 | -5% | | **Total** | **$6,000,000** | **$6,130,000** | **+2.2%** | Several things stand out in this example: 1. **Maintenance was 40% over budget** — either the estimate was too low or the systems are more fragile than expected 2. **New features came in 16% under** — either the team was more efficient or (more likely) features were deprioritized to handle maintenance and support overflow 3. **Support and incidents were 45% over** — unplanned work consumed planned capacity These patterns repeat year after year in most organizations. If you budget the same way again, you'll get the same variances. ### Step 2: Calculate Unit Costs Turn historical data into unit economics that can be projected forward. **Key unit costs to calculate:** ``` Cost per feature point = Total feature development cost / Total feature points delivered Cost per deployment = Total delivery cost / Number of deployments Cost per supported customer = Total support/incident cost / Number of customers Infrastructure cost per user = Total cloud spend / Active users Maintenance cost per service = Total maintenance cost / Number of production services ``` **Example unit costs:** | Unit Cost | This Year | Last Year | Trend | |-----------|:---------:|:---------:|:-----:| | Cost per feature point | $4,200 | $4,800 | ↓ 12.5% (improving) | | Cost per deployment | $1,100 | $1,450 | ↓ 24% (improving) | | Cost per customer (support) | $48 | $42 | ↑ 14% (worsening) | | Infrastructure per user | $3.20 | $2.80 | ↑ 14% (worsening) | | Maintenance per service | $32,000 | $28,000 | ↑ 14% (worsening) | Now you can have specific conversations: "Our maintenance cost per service is growing 14% per year. With 5 new services planned, that's an additional $160K in maintenance budget." ### Step 3: Build the Budget Bottom-Up Instead of starting with headcount, start with planned output and work backward to required investment. **The formula:** ``` Required Budget = Σ (Planned_Output_i × Unit_Cost_i) × (1 + Risk_Buffer) ``` **Budget model example:** | Budget Line | Calculation | Amount | |-------------|-------------|-------:| | **New features** | 180 feature points × $4,000/point | $720,000 | | **Platform improvements** | 3 major initiatives × $85,000 avg | $255,000 | | **Maintenance** | 57 services × $33,000/service | $1,881,000 | | **Support capacity** | 15,000 customers × $50/customer | $750,000 | | **Infrastructure** | 45,000 users × $3.40/user | $153,000 | | **Tooling** | 42 engineers × $4,800/engineer | $201,600 | | **Subtotal** | | **$3,960,600** | | **Risk buffer (10%)** | | $396,060 | | **Total budget** | | **$4,356,660** | Then convert back to headcount to validate: ``` Required headcount = Budget / Average loaded cost per engineer $4,356,660 / $195,000 = ~22 engineers ``` If you currently have 20 engineers, you need 2 more hires. If you have 25, you have capacity to spare (or can invest in tech debt reduction, training, etc.). ### Step 4: Tie Budget to Business Outcomes The budget request should explicitly connect to revenue targets. This is what the board wants to see. **Budget-to-revenue mapping:** | Budget Category | Investment | Expected Business Outcome | |-----------------|----------:|--------------------------| | New features | $720,000 | Enable $3.2M in new ARR pipeline | | Platform improvements | $255,000 | Reduce churn by 8% ($440K ARR saved) | | Maintenance | $1,881,000 | Maintain 99.9% uptime for $18M ARR base | | Support capacity | $750,000 | Handle 25% customer growth | Now the CFO can evaluate engineering spend as an investment portfolio, not a cost center. ### Step 5: Define Checkpoints and Reforecast Triggers A budget is a plan. Plans change. Build in quarterly checkpoints and define what triggers a reforecast. **Reforecast triggers:** - Unit costs deviate more than 15% from projections for two consecutive months - Planned headcount changes by more than 10% - A major unplanned project is added (e.g., security incident remediation, acquisition integration) - Revenue targets change by more than 20%, requiring adjusted engineering investment ## The Budget Presentation: What CFOs Want to See ### Page 1: Executive Summary ``` Requested FY2027 Engineering Budget: $4.36M (+12% vs FY2026) Key investments: - Feature development supporting $3.2M ARR pipeline - Platform reliability maintaining $18M ARR base - Scaling support for 25% customer growth Efficiency improvement: Cost per feature point down 12.5% YoY ROI: $21.6M revenue supported by $4.36M engineering investment (5:1) ``` ### Page 2: Historical Performance Show that last year's budget was spent responsibly and that the team is becoming more efficient. | Metric | FY2025 | FY2026 | FY2027 Target | |--------|:------:|:------:|:-------------:| | Total engineering spend | $5.4M | $6.1M | $4.4M | | Revenue supported | $14M | $18M | $23.4M | | Revenue per eng dollar | $2.59 | $2.95 | $5.36 | | Cost per feature point | $4,800 | $4,200 | $4,000 | | Engineers | 35 | 42 | 22 | ### Page 3: Budget Breakdown by Category Show where every dollar goes and why. Use the output-based model from Step 3. ### Page 4: Risk Analysis | Risk | Probability | Budget Impact | Mitigation | |------|:-----------:|:------------:|------------| | Higher-than-expected maintenance | 40% | +$200K | Invest in automated testing (already budgeted) | | Key hire delays | 30% | -$100K (underspend) | Contractor backfill budgeted in risk buffer | | Cloud cost overrun | 25% | +$75K | Reserved instances negotiation in progress | | Major security incident | 10% | +$300K | Covered by risk buffer + insurance | ### Page 5: Quarterly Milestones | Quarter | Planned Spend | Key Deliverables | Revenue Impact | |---------|:------------:|------------------|:--------------:| | Q1 | $1.05M | Enterprise SSO, API v3 | $800K pipeline | | Q2 | $1.10M | Mobile app, Advanced Analytics | $1.2M pipeline | | Q3 | $1.10M | Platform migration, Scale infra | $600K saved (churn) | | Q4 | $1.06M | AI features, 2028 planning | $600K pipeline | ## Common Budgeting Mistakes ### Mistake 1: Budgeting for Capacity, Not Output "We need 5 more engineers" is a capacity request. "We need $720K to deliver 180 feature points supporting $3.2M in pipeline" is an investment case. The second one gets approved. ### Mistake 2: Treating Infrastructure as Fixed Cloud costs are variable and often grow faster than revenue. Budget cloud infrastructure per user or per transaction, not as a fixed line item. Re-evaluate quarterly. ### Mistake 3: Zero Budget for Technical Debt If you don't explicitly budget for tech debt reduction, it won't happen. Then maintenance costs grow 10-15% per year until something breaks. Budget 15-20% of engineering capacity for platform health. ### Mistake 4: Ignoring the Cost of Context Switching When engineers are split across too many projects, their effective output drops significantly — [research on multitasking in knowledge work](https://ieeexplore.ieee.org/document/8813289) puts the penalty at 20% or more per additional concurrent project. A budget that plans for 42 engineers working at 100% efficiency across 12 projects is fiction. Plan for 70-80% effective capacity. ### Mistake 5: Annual Budget with No Mid-Year Adjustment The technology landscape changes faster than an annual budget cycle. Build in quarterly reforecast points and define clear triggers for budget adjustments. ## The Data Foundation: What You Need to Track Year-Round Data-driven budgeting requires year-round data collection, not a scramble in Q4. Here's what to track continuously: | Data Point | Source | Update Frequency | |------------|--------|:----------------:| | Developer time per project | Automated IDE tracking | Real-time | | Loaded hourly rates | HR / Finance | Quarterly | | Feature points delivered | Project management tool | Per sprint | | Deployment frequency | CI/CD pipeline | Real-time | | Cloud infrastructure costs | Cloud provider billing | Monthly | | Incident volume and resolution time | Incident management tool | Real-time | | Customer count and growth | CRM / billing system | Monthly | ## How PanDev Metrics Provides the Data Foundation Building a data-driven IT budget requires continuous tracking of engineering costs and output. PanDev Metrics provides the essential data layer: - **Automated activity tracking** via 10+ IDE plugins — accurate time-per-project data without manual logging - **Financial analytics with hourly rates** — calculate cost per project, per team, per feature automatically - **Historical trend data** — unit costs, efficiency metrics, and allocation patterns over time - **Project-level cost reporting** — see exactly how budget is being spent against plan - **Multi-provider git support** — track work across GitHub, GitLab, Bitbucket, and self-hosted repos - **On-premise deployment** — budget data, salary information, and project costs stay within your infrastructure - **AI assistant** — generates insights, anomaly detection, and forecasting from your historical data The companies that build the best budgets are the ones that track engineering costs all year, not just during budget season. ## Key Takeaways 1. **Budget for outputs, not inputs** — connect engineering spend to features, products, and business outcomes 2. **Calculate unit costs** — cost per feature point, per deployment, per customer enables bottom-up budgeting 3. **Use historical data** — last year's actuals (not last year's plan) should drive next year's projections 4. **Tie budget to revenue** — every engineering investment should map to a revenue outcome or risk mitigation 5. **Build in checkpoints** — quarterly reforecasts keep the budget relevant as conditions change 6. **Track costs year-round** — data-driven budgeting requires continuous data collection, not a Q4 sprint --- **Want to build your next IT budget on real data?** [PanDev Metrics](https://pandev-metrics.com) provides automated cost tracking, financial analytics, and the historical data you need for bottom-up budgeting. --- ## PanDev Metrics vs WakaTime: Team Analytics vs Personal Tracker URL: https://pandev-metrics.com/docs/blog/pandev-vs-wakatime Date: 2025-12-24 Tags: comparison, wakatime, developer-productivity, engineering-metrics Description: An honest comparison of PanDev Metrics and WakaTime — two different tools for two different problems. Feature-by-feature breakdown. WakaTime is one of the most well-known developer time tracking tools, with over 500K users, 40+ IDE plugins, and an annual "Yearly Wrapped" report that has become a community tradition. At $9/month for the Premium plan, it is one of the best values in developer tooling. PanDev Metrics is an Engineering Intelligence platform built for teams and organizations. They both track coding activity via IDE plugins — but that is where the similarity ends. If you are evaluating both tools, this comparison will help you understand which one fits your needs. ## The Fundamental Difference **WakaTime** is a personal productivity tracker for individual developers. It answers: "How much time did I spend coding today?" **PanDev Metrics** is an Engineering Intelligence platform for teams and organizations, recently featured in Forbes Kazakhstan (April 2026) with ~40 companies currently in pilot — including ABR Tech, Chocofood, Biometric, Neo Code, Parqour, and Zeely. It answers: "How is my engineering organization performing, and what does it cost?" This isn't a subtle difference — it shapes every feature and design decision in both products. ## Feature-by-Feature Comparison ### IDE Tracking and Activity Monitoring Both tools track coding activity through IDE plugins. Here's how they compare: | Feature | PanDev Metrics | WakaTime | |---------|:--------------:|:--------:| | IDE plugins supported | 10+ | 30+ | | Time tracking | Yes | Yes | | Language detection | Yes | Yes | | Project detection | Yes | Yes | | Branch/commit tracking | Yes | Limited | | Offline tracking | Yes | Yes (Premium) | | Activity categorization | Yes (coding, reviewing, debugging) | Basic (coding time only) | WakaTime has broader IDE support — it covers virtually every editor and IDE, including niche ones. If you use an unusual IDE, WakaTime likely has a plugin for it. PanDev Metrics covers all major IDEs (VS Code, JetBrains family, Vim, Neovim, and others) but doesn't aim for the same breadth. ### Team and Organization Features This is where the tools diverge significantly. | Feature | PanDev Metrics | WakaTime | |---------|:--------------:|:--------:| | Team dashboards | Yes — multi-level | Basic (Premium) | | Organization management | Yes — roles, permissions, departments | Minimal | | Cross-team comparisons | Yes | No | | Manager views | Yes — team-level aggregation | No | | Department/division rollups | Yes | No | | Org-wide analytics | Yes | No | | SSO/SAML | Yes | No | WakaTime added basic team features in its Premium plan, allowing team members to share dashboards. But it wasn't designed for organizational analytics — there are no manager views, no cross-team comparisons, no department rollups. PanDev Metrics was built from the ground up for team and organizational use cases. Every metric can be viewed at the individual, team, department, or organization level. ### Engineering Metrics (DORA, Lead Time, etc.) | Feature | PanDev Metrics | WakaTime | |---------|:--------------:|:--------:| | DORA metrics | Yes — full suite | No | | Deployment frequency | Yes | No | | Lead time for changes | Yes — 4-stage breakdown | No | | Change failure rate | Yes | No | | Mean time to recovery | Yes | No | | PR cycle time | Yes | No | | Code review analytics | Yes | No | | Sprint analytics | Yes | No | WakaTime doesn't provide DORA metrics or any delivery pipeline analytics. It tracks time in the IDE — it doesn't connect to your Git platform, CI/CD pipeline, or issue tracker for delivery metrics. PanDev Metrics provides a full DORA metrics suite with a unique 4-stage Lead Time breakdown (Coding → Pickup → Review → Deploy) that shows exactly where bottlenecks occur in your delivery pipeline. ### Financial Analytics | Feature | PanDev Metrics | WakaTime | |---------|:--------------:|:--------:| | Hourly rate tracking | Yes — per developer | No | | Cost per project | Yes | No | | Cost per feature | Yes | No | | Cost per team | Yes | No | | Budget tracking | Yes | No | | ROI analytics | Yes | No | | Financial dashboards for CFOs | Yes | No | This is PanDev Metrics' most distinctive capability. WakaTime has no financial analytics — it's a time tracker, not a cost tracker. PanDev Metrics lets you assign individual hourly rates and automatically calculates cost per project, per team, and per feature in real time. ### Git and DevOps Integration | Feature | PanDev Metrics | WakaTime | |---------|:--------------:|:--------:| | GitHub integration | Yes | Yes (basic) | | GitLab integration | Yes | No | | Bitbucket integration | Yes | No | | Self-hosted Git | Yes | No | | Jira integration | Yes | No | | CI/CD integration | Yes | No | | Multi-provider support | Yes | No | PanDev Metrics connects to multiple Git providers simultaneously — useful for organizations that use GitHub for some projects and GitLab for others. WakaTime's GitHub integration is limited to basic commit tracking. ### Deployment and Security | Feature | PanDev Metrics | WakaTime | |---------|:--------------:|:--------:| | Cloud hosted | Yes | Yes | | On-premise / self-hosted | Yes | No | | Data residency options | Yes (on-prem) | No | | SOC 2 compliance | Yes | Unknown | For organizations with strict data residency requirements or security policies that prohibit sending developer activity data to third-party cloud services, PanDev Metrics' on-premise deployment option is a significant differentiator. WakaTime is cloud-only. ### AI and Automation | Feature | PanDev Metrics | WakaTime | |---------|:--------------:|:--------:| | AI assistant | Yes — insights and recommendations | No | | Automated reports | Yes | Limited | | Anomaly detection | Yes | No | | Gamification | Yes | No | PanDev Metrics includes an AI assistant that surfaces insights from your engineering data — identifying bottlenecks, suggesting optimizations, and generating executive-ready reports. It also includes gamification features to drive developer engagement. ### Pricing | | PanDev Metrics | WakaTime | |--|:--------------:|:--------:| | Free tier | Yes | Yes (limited) | | Individual plan | N/A | ~$9/month | | Team plan | Contact for pricing | ~$9/user/month (Premium) | | Enterprise | Contact for pricing | N/A | WakaTime's pricing is simple and affordable for individuals: free for basic features, ~$9/month for premium. PanDev Metrics offers a free tier and scales pricing for teams and organizations. ## When to Choose WakaTime WakaTime is the right choice if: - **You're an individual developer** tracking your own productivity - **You want a lightweight tool** that just tracks coding time without complexity - **You use a niche IDE** that PanDev Metrics doesn't support - **You don't need team analytics** — it's just for your personal dashboard - **Budget is minimal** — $9/month for a full-featured personal tracker is excellent value WakaTime does what it does very well. It is the most popular personal coding tracker for a reason — simple, reliable, supported across a huge range of editors, with a thriving open-source plugin ecosystem and annual "Yearly Wrapped" reports that developers genuinely look forward to. ## When to Choose PanDev Metrics PanDev Metrics is the right choice if: - **You manage an engineering team** and need team-level, not just individual, analytics - **You need DORA metrics** — deployment frequency, lead time, change failure rate, MTTR - **Financial analytics matter** — you need to know cost per project, cost per feature, or engineering ROI - **You have compliance requirements** that require on-premise deployment or data residency control - **You use multiple Git providers** — GitHub and GitLab, or self-hosted Git alongside cloud providers - **You need executive-ready reporting** — dashboards and reports for CTOs, CFOs, and CEOs - **You want an all-in-one platform** instead of cobbling together multiple tools ## The Migration Path: WakaTime to PanDev Metrics Many PanDev Metrics users started with WakaTime for personal tracking and graduated to PanDev Metrics when they needed team and organizational capabilities. The transition is straightforward: 1. **Install PanDev Metrics IDE plugins** alongside (or replacing) WakaTime plugins 2. **Historical data imports** — PanDev Metrics can import historical data, so you don't lose your tracking history 3. **Set up team structure** — add team members, departments, and organizational hierarchy 4. **Configure financial analytics** — add hourly rates, map projects, set up cost tracking 5. **Enable DORA metrics** — connect your Git provider(s) and CI/CD pipeline The two tools can coexist during transition if developers want to keep WakaTime for personal use while the organization uses PanDev Metrics for team analytics. ## Summary | Dimension | PanDev Metrics | WakaTime | |-----------|:--------------:|:--------:| | Best for | Teams and organizations | Individual developers | | Core strength | Engineering Intelligence platform | Personal time tracking | | DORA metrics | Yes | No | | Financial analytics | Yes | No | | On-premise option | Yes | No | | IDE coverage | 10+ major IDEs | 30+ IDEs | | Pricing | Free tier + team plans | Free + $9/mo individual | | AI features | Yes | No | Both are good tools — for different jobs. WakaTime is an excellent personal productivity tracker. PanDev Metrics is an Engineering Intelligence platform for organizations that need team analytics, financial visibility, and delivery metrics. If you're a solo developer who wants to track their coding habits, WakaTime is great. If you're an engineering leader who needs to understand team performance, delivery efficiency, and engineering costs, PanDev Metrics is built for that. --- *[PanDev Metrics](https://pandev-metrics.com) — team analytics, DORA metrics, financial analytics, and on-premise deployment. Free tier available.* --- ## PanDev Metrics vs LinearB: Enterprise Features Without Enterprise Pricing URL: https://pandev-metrics.com/docs/blog/pandev-vs-linearb Date: 2025-12-22 Tags: comparison, linearb, engineering-metrics, dora-metrics Description: PanDev Metrics vs LinearB — a detailed comparison of features, pricing, deployment, and approach to engineering intelligence. LinearB is one of the more established players in the Engineering Intelligence space, known for strong DORA metrics implementation and workflow automation. PanDev Metrics is a newer platform that takes a broader approach — combining engineering metrics with financial analytics and on-premise deployment. Both platforms aim to help engineering leaders make better decisions. But they differ significantly in pricing, deployment options, and the types of insights they provide. Here's a detailed, honest comparison. ## Company and Product Overview **LinearB** was founded in 2019 and has raised significant venture funding. The platform focuses on software delivery metrics, workflow automation, and developer experience. It's used primarily by mid-market and enterprise engineering teams. LinearB offers strong DORA metrics based on analysis of over 8.1 million PRs, automated workflow improvements (like PR routing and review reminders via WorkerB), and the "Dev Interrupted" podcast and blog that have become a go-to resource for engineering leaders. **PanDev Metrics** is an Engineering Intelligence platform that combines developer activity tracking, delivery metrics, and financial analytics — recently featured in Forbes Kazakhstan (April 2026). It differentiates through on-premise deployment, IDE-level activity tracking, financial cost attribution, and multi-provider Git support. PanDev Metrics targets organizations that need both engineering metrics and financial visibility. ## Feature-by-Feature Comparison ### DORA Metrics Both platforms take DORA metrics seriously. Here's how they compare: | DORA Feature | PanDev Metrics | LinearB | |-------------|:--------------:|:-------:| | Deployment Frequency | Yes | Yes | | Lead Time for Changes | Yes — 4-stage breakdown | Yes — multi-stage | | Change Failure Rate | Yes | Yes | | Mean Time to Recovery | Yes | Yes | | DORA benchmarking | Yes | Yes — industry benchmarks | | Custom metric definitions | Yes | Limited | Both platforms provide a full DORA metrics suite. LinearB has been in the market longer and has benchmarking data drawn from over 8.1 million PRs — one of the largest engineering datasets in the industry. PanDev Metrics offers a detailed 4-stage Lead Time breakdown (Coding → Pickup → Review → Deploy) that makes bottleneck identification actionable. **Verdict: Comparable.** Both platforms handle DORA metrics well. LinearB has a meaningful edge in benchmarking due to its larger data set. ### Developer Activity Tracking | Feature | PanDev Metrics | LinearB | |---------|:--------------:|:-------:| | IDE time tracking | Yes — 10+ IDE plugins | No | | Coding time per developer | Yes (automated) | No (Git-derived estimates) | | Activity categorization | Yes (coding, reviewing, debugging) | No | | Language-level breakdown | Yes | No | | Non-coding activity tracking | Yes | No | This is a significant differentiator. PanDev Metrics tracks actual coding activity through IDE plugins — it knows exactly how much time each developer spends coding, in which language, in which project, at a granular level. LinearB derives activity data from Git commits and PR activity. This gives a good picture of delivery output but doesn't capture the actual time and effort behind that output. A developer who spends 6 hours on a complex 20-line change looks the same as one who dashed it off in 30 minutes. **Verdict: PanDev Metrics.** IDE-level tracking provides fundamentally different (and more granular) data than Git-derived estimates. ### Financial Analytics | Feature | PanDev Metrics | LinearB | |---------|:--------------:|:-------:| | Hourly rate tracking | Yes — per developer | No | | Cost per project | Yes | No | | Cost per feature | Yes | No | | Cost per team | Yes | No | | Engineering ROI analytics | Yes | No | | Budget tracking | Yes | No | | CFO-ready financial reports | Yes | No | PanDev Metrics includes comprehensive financial analytics — you can assign individual hourly rates, track cost per project/feature/team, and generate financial reports suitable for CFO and board presentations. LinearB does not include financial analytics. It's focused on engineering efficiency and delivery metrics, not on translating those metrics into dollars. **Verdict: PanDev Metrics.** Financial analytics is a core differentiator that LinearB doesn't offer. ### Workflow Automation | Feature | PanDev Metrics | LinearB | |---------|:--------------:|:-------:| | Automated PR routing | No | Yes | | Review reminders | No | Yes — WorkerB bot | | Automated team notifications | Limited | Yes | | CI/CD integration | Yes | Yes | | Custom automation rules | Limited | Yes | LinearB has invested heavily in workflow automation through its WorkerB bot, which can automatically assign reviewers, send reminders for stale PRs, and enforce team agreements (like PR size limits). This is a genuinely more mature workflow automation engine than what PanDev or most other competitors currently offer — it goes beyond measurement into active process improvement. PanDev Metrics focuses more on measurement, analytics, and insights. It provides the data to identify problems but relies more on human decision-making to fix them (supported by its AI assistant for recommendations). **Verdict: LinearB.** Workflow automation is LinearB's strongest differentiator, and PanDev Metrics has not matched it. ### Deployment Options | Feature | PanDev Metrics | LinearB | |---------|:--------------:|:-------:| | Cloud hosted | Yes | Yes | | On-premise / self-hosted | Yes | No | | Air-gapped deployment | Yes | No | | Data residency control | Full (on-prem) | Limited (cloud regions) | | SOC 2 | Yes | Yes | For organizations in regulated industries (finance, healthcare, defense, government) or those with strict data policies, on-premise deployment is often a hard requirement. Developer activity data, code-level metrics, and especially financial data (salary rates, project costs) are sensitive. LinearB is cloud-only. PanDev Metrics offers full on-premise deployment, including air-gapped environments. **Verdict: PanDev Metrics.** On-premise deployment is either irrelevant or a dealbreaker — there's no middle ground. ### Git Provider Support | Feature | PanDev Metrics | LinearB | |---------|:--------------:|:-------:| | GitHub | Yes | Yes | | GitLab | Yes | Yes | | Bitbucket | Yes | Yes | | Azure DevOps | Yes | Yes | | Self-hosted Git | Yes | Limited | | Multi-provider simultaneous | Yes | Limited | Both platforms support major Git providers. PanDev Metrics has stronger support for self-hosted Git instances and for organizations that use multiple Git providers simultaneously (e.g., GitHub for open-source, self-hosted GitLab for proprietary code). **Verdict: Slight edge to PanDev Metrics** for multi-provider and self-hosted scenarios. ### AI and Insights | Feature | PanDev Metrics | LinearB | |---------|:--------------:|:-------:| | AI assistant | Yes | Yes | | Automated insights | Yes | Yes | | Natural language queries | Yes | Yes | | Executive summaries | Yes | Yes | Both platforms have invested in AI-powered insights. LinearB uses AI for benchmarking insights and team health assessments. PanDev Metrics' AI assistant covers engineering metrics plus financial analytics insights. **Verdict: Comparable.** Both offer AI-powered insights, with different areas of focus. ### Gamification and Developer Experience | Feature | PanDev Metrics | LinearB | |---------|:--------------:|:-------:| | Developer gamification | Yes | No | | Achievement system | Yes | No | | Developer self-service dashboards | Yes | Yes | | Developer satisfaction surveys | No | Yes (TeamLens) | PanDev Metrics includes gamification features (achievements, leaderboards) designed to engage developers positively with the metrics platform. LinearB takes a different approach with TeamLens developer experience surveys. **Verdict: Different approaches.** Gamification vs. surveys — both aim to improve developer engagement. ## Pricing Comparison This is where the difference is most stark. | | PanDev Metrics | LinearB | |--|:--------------:|:-------:| | Free tier | Yes | Yes (limited) | | Starting price (team) | $300/mo (under 20 engineers) | ~$420/dev/year | | Mid-tier | $700/mo (20-50 engineers) | ~$549/dev/year | | Enterprise | $1,500/mo (50-100 engineers) | Custom | | Minimum commitment | None | Annual | **LinearB's pricing for a 50-developer team:** - Business tier: 50 × $420 = **$21,000/year** - Enterprise tier: 50 × $549 = **$27,450/year** LinearB's pricing is transparent and well-documented, but it adds up quickly for larger teams. A 200-developer organization would pay $84K-$110K per year. PanDev Metrics pricing starts at $300/month for teams under 20 engineers, $700/month for 20-50, and $1,500/month for 50-100 — flat rates, not per-developer. **PanDev Metrics' cost for a 50-developer team:** - $700/month = **$8,400/year** Compare that to LinearB's $21,000-$27,450/year for the same team size. PanDev Metrics delivers enterprise features at a fraction of the per-developer cost. **Verdict: PanDev Metrics** offers a more accessible pricing structure, especially for growing teams. ## Decision Framework ### Choose LinearB if: - **Workflow automation is your priority** — you want automated PR routing, review reminders, and team agreements - **You need extensive benchmarking data** — LinearB's larger customer base provides richer industry benchmarks - **Cloud-only is fine** — you have no on-premise requirements - **You don't need financial analytics** — your focus is purely on engineering efficiency, not cost tracking - **Your budget supports $420-549/dev/year** — and the ROI justifies the investment ### Choose PanDev Metrics if: - **You need financial analytics** — cost per project, cost per feature, hourly rate tracking, engineering ROI - **On-premise deployment is required** — regulatory, compliance, or policy requirements mandate self-hosted - **IDE-level tracking matters** — you want to know actual coding time, not just Git-derived activity - **You use multiple Git providers** — especially self-hosted instances alongside cloud providers - **Budget efficiency matters** — you want enterprise-grade features without enterprise-grade pricing - **You want gamification** — to drive positive developer engagement with metrics ### Consider both if: - **You're in evaluation mode** — try the free tiers of both platforms with a pilot team - **Different teams have different needs** — engineering leadership might benefit from LinearB's automation while finance teams need PanDev Metrics' cost analytics ## Summary Table | Dimension | PanDev Metrics | LinearB | |-----------|:--------------:|:-------:| | DORA metrics | Strong | Strong | | IDE activity tracking | Yes (native) | No | | Financial analytics | Yes (core feature) | No | | Workflow automation | Limited | Strong | | On-premise deployment | Yes | No | | Multi-provider Git | Strong | Good | | AI insights | Yes | Yes | | Gamification | Yes | No | | Industry benchmarks | Growing | Extensive | | Pricing | Free tier + affordable plans | $420-549/dev/year | | Market maturity | Newer | Established | Both are serious Engineering Intelligence platforms. LinearB is more mature in workflow automation and benchmarking. PanDev Metrics brings financial analytics, IDE tracking, and on-premise deployment to the table — capabilities that LinearB doesn't offer. The right choice depends on whether your primary need is delivery optimization (LinearB) or comprehensive engineering intelligence with financial visibility (PanDev Metrics). --- *[PanDev Metrics](https://pandev-metrics.com) — free tier available for evaluation with your actual team data. No commitment required.* --- ## PanDev Metrics vs Jellyfish: When You Don't Need a $250K Platform URL: https://pandev-metrics.com/docs/blog/pandev-vs-jellyfish Date: 2025-12-19 Tags: comparison, jellyfish, engineering-metrics, financial-analytics Description: PanDev Metrics vs Jellyfish — comparing two engineering analytics platforms with very different price tags and approaches. Jellyfish is an enterprise Engineering Management Platform with a price tag to match — typically $50K to $250K per year. It claims over 50,000 teams on its platform, hosts GLOWLive events for engineering leaders, and provides an ROI calculator to help justify the investment. It's designed for large engineering organizations (200+ developers) that need portfolio-level visibility into engineering investment. PanDev Metrics offers many of the same capabilities — including financial analytics, team metrics, and delivery insights — at a lower price point, with some features Jellyfish does not have. But Jellyfish brings unique strengths too, particularly in strategic portfolio management. Here is an honest comparison to help you decide. ## Positioning: Enterprise Platform vs. Full-Stack Intelligence **Jellyfish** positions itself as an "Engineering Management Platform" — a strategic tool for VPs of Engineering and CTOs to align engineering work with business priorities. It excels at portfolio-level views: how engineering investment maps to strategic initiatives, which teams are working on what, and whether resource allocation matches business priorities. **PanDev Metrics** positions itself as an "Engineering Intelligence" platform — recently featured in Forbes Kazakhstan (April 2026), with client results showing a 30% productivity increase and 25% improvement in release quality. It combines developer-level activity tracking, delivery metrics, and financial analytics in a single tool, providing both the ground-level data (developer coding time, PR cycle time) and the strategic views (project costs, team efficiency, DORA metrics). The key difference: Jellyfish works top-down (strategic initiatives → teams → work). PanDev Metrics works bottom-up (developer activity → team metrics → project costs → strategic insights). ## Feature-by-Feature Comparison ### Engineering Investment and Resource Allocation | Feature | PanDev Metrics | Jellyfish | |---------|:--------------:|:---------:| | Resource allocation tracking | Yes | Yes — core strength | | Initiative/epic-level investment view | Yes | Yes — core strength | | Strategic initiative mapping | Basic | Advanced | | Portfolio management view | Basic | Yes — core strength | | What-if scenario modeling | No | Yes | | Board-level reporting | Yes | Yes — native templates | Jellyfish excels at strategic resource allocation. Its portfolio view shows how engineering investment maps to business initiatives, making it easier for VPs and CTOs to answer questions like "What percentage of our engineering effort goes to growth vs. maintenance vs. technical debt?" PanDev Metrics provides resource allocation data at the project and team level, but it doesn't have the same depth of strategic portfolio management features. **Verdict: Jellyfish** for strategic portfolio management. ### Developer Activity and IDE Tracking | Feature | PanDev Metrics | Jellyfish | |---------|:--------------:|:---------:| | IDE time tracking | Yes — 10+ plugins | No | | Actual coding time per developer | Yes | No | | Language breakdown | Yes | No | | Activity categorization | Yes | No | | Non-coding activity | Yes | No | Jellyfish does not track developer activity at the IDE level. It relies on Git, Jira, and calendar data to infer how developers spend their time. This means it can tell you what a developer delivered but not how long they actually spent coding. PanDev Metrics tracks actual coding time through IDE plugins, providing ground-truth data about developer activity. This data feeds into more accurate cost calculations and effort estimates. **Verdict: PanDev Metrics.** IDE tracking provides data Jellyfish simply doesn't have. ### Financial Analytics | Feature | PanDev Metrics | Jellyfish | |---------|:--------------:|:---------:| | Hourly rate per developer | Yes | Derived from salary data | | Cost per project | Yes — real-time | Yes | | Cost per feature | Yes — automated | Yes — estimated | | ROI calculator | Yes | Yes — core strength | | Engineering capitalization (CapEx/OpEx) | Basic | Yes — native | | Budget vs. actual tracking | Yes | Yes | Both platforms provide financial analytics, but with different approaches. Jellyfish uses salary data combined with Jira/Git activity to estimate cost allocation. PanDev Metrics uses actual IDE tracking time combined with individual hourly rates for more granular cost attribution. Jellyfish has stronger CapEx/OpEx capitalization features — important for companies that need to capitalize engineering work for financial reporting (common in publicly traded companies). **Verdict: Different strengths.** PanDev Metrics has more accurate cost data (IDE-based). Jellyfish has more mature strategic financial features (capitalization, ROI modeling). ### DORA and Delivery Metrics | Feature | PanDev Metrics | Jellyfish | |---------|:--------------:|:---------:| | DORA metrics suite | Yes — full | Limited | | Lead time breakdown | Yes — 4-stage | Basic | | Deployment frequency | Yes | Yes | | Change failure rate | Yes | Basic | | PR cycle time | Yes | Yes | | Code review analytics | Yes | Basic | PanDev Metrics provides a more comprehensive DORA metrics implementation with a granular 4-stage Lead Time breakdown. Jellyfish focuses more on strategic metrics (investment allocation, initiative velocity) than on developer-level delivery metrics. **Verdict: PanDev Metrics** for DORA and delivery metrics. ### Deployment and Security | Feature | PanDev Metrics | Jellyfish | |---------|:--------------:|:---------:| | Cloud hosted | Yes | Yes | | On-premise deployment | Yes | No | | Air-gapped deployment | Yes | No | | SOC 2 | Yes | Yes | | Data residency | Full (on-prem) | Cloud regions | Jellyfish is cloud-only. For organizations that need on-premise deployment — due to regulatory requirements, security policies, or data sensitivity concerns — this is a significant limitation. PanDev Metrics offers full on-premise deployment, including air-gapped environments. Given that both platforms handle sensitive financial data (salary information, project costs), where this data lives is a material consideration. **Verdict: PanDev Metrics** if on-premise matters (and for many enterprise buyers, it does). ### Integration Ecosystem | Feature | PanDev Metrics | Jellyfish | |---------|:--------------:|:---------:| | GitHub | Yes | Yes | | GitLab | Yes | Yes | | Bitbucket | Yes | Yes | | Self-hosted Git | Yes | Limited | | Jira | Yes | Yes — deep integration | | Calendar integration | No | Yes | | HR system integration | No | Yes (BambooHR, Workday) | | Finance system integration | No | Yes (limited) | Jellyfish has a broader integration ecosystem, particularly with HR and calendar systems. Its calendar integration is notable — it can factor meeting time into developer allocation analysis. HR integrations allow automatic salary data import for cost calculations. PanDev Metrics has stronger Git provider support (especially self-hosted and multi-provider scenarios) but fewer integrations with non-engineering systems. **Verdict: Jellyfish** for breadth of integrations, especially HR and calendar. ### AI and Insights | Feature | PanDev Metrics | Jellyfish | |---------|:--------------:|:---------:| | AI assistant | Yes | Yes | | Automated insights | Yes | Yes | | Natural language queries | Yes | Yes | | Executive summaries | Yes | Yes | | What-if modeling | No | Yes | Both platforms offer AI-powered insights. Jellyfish's what-if modeling capability is unique — it lets leaders simulate the impact of resource allocation changes before making them (e.g., "What happens to our Q3 roadmap if we move 3 developers from Team A to Team B?"). **Verdict: Jellyfish** for strategic planning scenarios. ## The Pricing Reality This is the elephant in the room. | | PanDev Metrics | Jellyfish | |--|:--------------:|:---------:| | Target company size | 10-500+ developers | 200+ developers | | Typical annual cost | $300-$1,500/month ($3,600-$18,000/year) | $50,000 - $250,000+ | | Minimum commitment | None | Annual contract | | Implementation time | Days to weeks | Weeks to months | | Professional services required | No | Often yes | **Jellyfish's total cost of ownership for a 300-developer organization:** | Cost Component | Estimated Annual Cost | |----------------|----------------------:| | Platform license | $150,000 - $200,000 | | Implementation services | $20,000 - $40,000 (year 1) | | Ongoing success management | Included or $15,000 | | **Total year 1** | **$170,000 - $240,000** | | **Total year 2+** | **$150,000 - $200,000** | For a well-funded enterprise with 500+ developers and a strong need for strategic portfolio management, Jellyfish can deliver meaningful ROI at this price point. But for organizations with 50-200 developers, or those that need financial analytics without a six-figure platform fee, the cost is prohibitive. PanDev Metrics provides financial analytics, DORA metrics, IDE tracking, and on-premise deployment starting at $300/month for teams under 20 engineers, $700/month for 20-50, and $1,500/month for 50-100. For most mid-market engineering organizations, this covers 80-90% of what Jellyfish offers at a fraction of the cost. ## Decision Framework ### Choose Jellyfish if: - **You have 300+ developers** and the budget to match ($150K+/year) - **Strategic portfolio management is the primary need** — mapping engineering investment to business initiatives - **You need CapEx/OpEx capitalization** for financial reporting - **Calendar and HR integrations are important** — you want meeting time and salary data automatically imported - **What-if scenario modeling** is a key requirement for resource planning - **Cloud-only is acceptable** — no on-premise requirement ### Choose PanDev Metrics if: - **Your team is 10-300 developers** — or you want enterprise features without enterprise pricing at any size - **You need actual coding time data** — IDE tracking provides ground-truth activity data - **Financial analytics with granular cost tracking** — individual hourly rates, cost per feature, real-time project costs - **On-premise deployment is required** — regulatory, security, or policy requirements - **DORA metrics are a priority** — more detailed delivery pipeline analytics - **Budget constraints are real** — you can't justify $150K+/year for engineering analytics - **You want to start small** — free tier lets you evaluate with zero commitment ### The 80/20 Analysis For most engineering organizations in the 50-300 developer range, PanDev Metrics provides roughly 80% of Jellyfish's value at roughly 20% (or less) of the cost. The 20% you give up: strategic portfolio management depth, HR/calendar integrations, what-if modeling, and CapEx/OpEx capitalization. If that 20% is critical to your use case, Jellyfish justifies its premium. If it's nice-to-have, PanDev Metrics is likely the better investment. ## Summary Table | Dimension | PanDev Metrics | Jellyfish | |-----------|:--------------:|:---------:| | IDE activity tracking | Yes | No | | DORA metrics | Comprehensive | Basic | | Financial analytics | Granular (IDE-based) | Strategic (allocation-based) | | Portfolio management | Basic | Advanced | | CapEx/OpEx capitalization | Basic | Native | | On-premise deployment | Yes | No | | HR/Calendar integration | No | Yes | | What-if modeling | No | Yes | | Target team size | 10-500+ | 200+ | | Typical cost | Free tier + affordable plans | $50K-$250K/year | | Implementation complexity | Low | Medium-High | | Gamification | Yes | No | Both are capable platforms. The right choice depends on your organization's size, budget, and whether you need strategic portfolio management (Jellyfish's strength) or granular engineering intelligence with financial analytics (PanDev Metrics' strength). --- *[PanDev Metrics](https://pandev-metrics.com) — financial analytics, DORA metrics, IDE tracking, and on-premise deployment. Free tier available.* --- ## PanDev Metrics vs Jira Reports: Why Ticket Metrics ≠ Development Metrics URL: https://pandev-metrics.com/docs/blog/pandev-vs-jira-reports Date: 2025-12-16 Tags: comparison, jira, engineering-metrics, developer-productivity Description: Why Jira reports don't tell you how your engineering team is actually performing. A comparison of ticket-based vs. development-based metrics. Jira is the most widely used project management tool in software development. It's where tickets live, sprints get planned, and work gets tracked. Naturally, engineering leaders turn to Jira reports for engineering metrics. The problem? **Jira measures ticket flow. It doesn't measure development.** A Jira ticket moving from "In Progress" to "Done" tells you that someone marked it complete. It doesn't tell you how long the actual coding took, how much the work cost, how many iterations the code review required, or whether the deployment went smoothly. These are the metrics that matter for engineering performance. ## What Jira Reports Actually Measure Let's be clear about what Jira does well. Jira is an excellent project management and issue tracking tool. Its built-in reports provide useful views of: - **Velocity charts** — story points completed per sprint - **Burndown charts** — remaining work within a sprint - **Control charts** — cycle time distribution for issues - **Cumulative flow diagrams** — work-in-progress across statuses - **Sprint reports** — completed vs. planned work These are legitimate project management metrics. They answer questions like: "Are we completing the planned work?" and "How much work flows through the system?" But they answer these questions **from the ticket perspective, not the engineering perspective.** And the gap between ticket movement and actual engineering work is larger than most leaders realize. ## The Five Blind Spots of Jira Reports ### Blind Spot 1: Ticket Time ≠ Coding Time When a Jira ticket spends 5 days in "In Progress," Jira records a 5-day cycle time. But what actually happened during those 5 days? **What Jira sees:** ``` Day 1: Status changed to "In Progress" Day 5: Status changed to "In Review" Cycle time: 5 days ``` **What actually happened:** ``` Day 1: Developer read the ticket, researched the codebase (2 hours coding) Day 2: Wrote the initial implementation (4 hours coding) Day 3: Waited for design clarification — sent Slack message, no response (0 hours coding) Day 4: Got clarification, rewrote approach, wrote tests (5 hours coding) Day 5: Fixed CI failures, addressed PR comments (2 hours coding) Total actual coding: 13 hours across 5 days ``` The Jira report says "5-day cycle time." The reality is 13 hours of coding spread across 5 days, including a full day of waiting for input. These are fundamentally different insights that lead to different optimization decisions. ### Blind Spot 2: Story Points Are Not Cost Velocity is Jira's flagship metric: story points completed per sprint. But story points are an estimation abstraction — they don't correspond to hours, dollars, or any consistent unit of value. Consider two teams: | Team | Velocity | Developers | Avg Salary | Sprint Cost | Cost per Point | |------|:--------:|:----------:|:----------:|:----------:|:--------------:| | Alpha | 45 points/sprint | 5 | $150K | $57,700 | $1,282 | | Beta | 60 points/sprint | 8 | $120K | $73,800 | $1,230 | Team Beta has 33% higher velocity but costs 28% more per sprint. The cost per point is similar — but Jira's velocity chart makes Beta look like the higher performer. Without financial data overlaid on velocity, sprint metrics can be misleading. ### Blind Spot 3: The "Done" Status Lies Jira tickets marked "Done" might not actually be deployed to production. In many organizations, there's a significant gap between "development complete" and "in production." ``` Jira says "Done": March 3 PR merged: March 5 Deployed to staging: March 7 QA approved: March 10 Deployed to production: March 14 ``` The Jira lead time shows 3 days. The actual lead time (code complete to production) is 14 days. The 11-day gap is invisible in Jira reports. ### Blind Spot 4: Code Review Is Invisible Jira has no native concept of code review. It can't tell you: - How long PRs wait for review (pickup time) - How many review iterations each PR requires - Which reviewers are bottlenecks - How review time correlates with bug rates Code review is a critical quality gate and a major source of lead time. In many teams, PRs wait 1-3 days for review. This wait time doesn't appear in any Jira report. ### Blind Spot 5: Developer Experience Is Unmeasured Jira tracks ticket movement, not developer experience. It can't tell you: - How many hours per day developers actually code - How much time is lost to context switching between tickets - Whether developers are blocked by environment issues - How meeting load affects coding output These factors directly impact team performance but are completely outside Jira's visibility. ## What Engineering Metrics Should Actually Capture A complete picture of engineering performance requires data from multiple sources: | Metric Category | Data Source | Jira Provides? | PanDev Provides? | |----------------|------------|:--------------:|:----------------:| | **Sprint progress** | Issue tracker | Yes | Yes (via integration) | | **Actual coding time** | IDE activity | No | Yes | | **Lead time (code to production)** | Git + CI/CD | No | Yes — 4-stage | | **Code review efficiency** | Git platform | No | Yes | | **DORA metrics** | Git + CI/CD | No | Yes | | **Developer activity patterns** | IDE | No | Yes | | **Cost per project/feature** | IDE + HR data | No | Yes | | **Deployment frequency** | CI/CD pipeline | No | Yes | | **Change failure rate** | CI/CD + incidents | No | Yes | Jira provides one layer of the picture — the project management layer. A complete engineering intelligence view requires at least three additional layers: IDE activity, Git/CI data, and financial data. ## Side-by-Side Comparison ### Sprint and Project Metrics | Feature | Jira Reports | PanDev Metrics | |---------|:------------:|:--------------:| | Velocity tracking | Yes | Yes (via Jira integration) | | Burndown charts | Yes | Yes | | Sprint planning tools | Yes — native | Via integration | | Backlog management | Yes — native | Via integration | | Custom JQL reports | Yes — powerful | N/A | | Cross-sprint trend analysis | Basic | Yes | Jira is purpose-built for sprint and backlog management. PanDev Metrics integrates with Jira to pull sprint data but doesn't replace Jira's planning capabilities. They serve different purposes. ### Delivery and Performance Metrics | Feature | Jira Reports | PanDev Metrics | |---------|:------------:|:--------------:| | DORA metrics | No | Yes — full suite | | Lead time (code to prod) | No (ticket-based only) | Yes — 4-stage breakdown | | Deployment frequency | No | Yes | | Change failure rate | No | Yes | | MTTR | No | Yes | | PR cycle time | No | Yes | | Code review analytics | No | Yes | ### Developer Activity Metrics | Feature | Jira Reports | PanDev Metrics | |---------|:------------:|:--------------:| | Actual coding hours | No | Yes | | Activity by language | No | Yes | | Activity by project/repo | No | Yes | | Coding patterns (time of day, day of week) | No | Yes | | Context switching frequency | No | Yes | ### Financial Metrics | Feature | Jira Reports | PanDev Metrics | |---------|:------------:|:--------------:| | Cost per ticket/feature | No | Yes | | Cost per sprint | No | Yes | | Cost per team | No | Yes | | Hourly rate tracking | No | Yes | | Budget vs. actual | No | Yes | | Engineering ROI | No | Yes | ### Deployment and Access | Feature | Jira Reports | PanDev Metrics | |---------|:------------:|:--------------:| | Cloud hosted | Yes | Yes | | On-premise (Data Center) | Yes (Jira DC) | Yes | | Pricing | Included with Jira | Free tier + paid plans | | Additional setup required | None (built-in) | IDE plugin deployment + Git connection | ## The Complementary Approach Here's the key insight: **Jira and PanDev Metrics are not competitors. They're complementary tools that serve different purposes.** Jira is your project management system. It's where work is defined, assigned, and tracked at the ticket level. You should continue using Jira for sprint planning, backlog management, and project tracking. PanDev Metrics is your engineering intelligence layer. It sits on top of Jira (and your Git platform, IDE data, and CI/CD pipeline) to provide the metrics Jira can't: actual coding time, delivery performance, code review efficiency, DORA metrics, and financial analytics. **The ideal stack:** ``` ┌─────────────────────────────────────┐ │ PanDev Metrics │ ← Engineering Intelligence │ (DORA, costs, activity, reviews) │ ├─────────────────────────────────────┤ │ Jira / Linear / Asana │ ← Project Management │ (tickets, sprints, backlog) │ ├─────────────────────────────────────┤ │ GitHub / GitLab / Bitbucket │ ← Source Code & CI/CD │ (code, PRs, deployments) │ ├─────────────────────────────────────┤ │ IDE (VS Code, JetBrains) │ ← Developer Activity │ (coding time, language, project) │ └─────────────────────────────────────┘ ``` PanDev Metrics integrates with Jira to pull ticket data and enrich it with engineering metrics. You don't replace Jira — you augment it with the data it can't provide on its own. ## Real-World Example: What the Combined View Reveals A team lead looks at their Jira sprint report: **Jira sprint report shows:** - Velocity: 42 points (target was 45) — slightly under - 3 tickets carried over to next sprint - Average cycle time: 4.2 days Conclusion from Jira: "We're close to target. A bit slow this sprint." **PanDev Metrics shows (for the same sprint):** - Average coding time per ticket: 6.8 hours (down from 8.2 last sprint — improving) - PR pickup time: 2.1 days average (way too high — bottleneck identified) - One developer reviewed 60% of all PRs (burnout risk) - Sprint cost: $48,200 (12% over budget due to senior developer overtime) - Two features deployed Monday, but four are still waiting in the deployment queue Conclusion from PanDev Metrics: "Developers are coding more efficiently, but PRs wait too long for review. One reviewer is overloaded. The deployment queue is the real bottleneck, not coding speed." Same sprint, completely different insights. The Jira report says "try harder." The engineering metrics say "fix the review bottleneck and deploy faster." ## Common Objections ### "Our Jira reports are good enough" If your only questions are "Did we finish the planned work?" and "How much work flows through sprints?" — then yes, Jira is sufficient. But if you're asking about engineering costs, developer productivity, delivery performance, or review efficiency, Jira reports genuinely cannot answer those questions. ### "We already have Jira plugins for metrics" Several Jira marketplace plugins add engineering metrics (e.g., velocity analytics, predictive estimation). These are useful incremental improvements but still operate within Jira's data model — they can't access IDE activity, individual Git commit data, or CI/CD pipeline metrics. ### "Adding another tool creates complexity" Fair concern. But PanDev Metrics doesn't replace any existing tool — it layers on top. Developers install an IDE plugin (5 minutes). Engineering leaders get a new dashboard. The Jira workflow doesn't change. ## Key Takeaways 1. **Jira reports measure ticket flow, not engineering performance** — they're project management metrics, not development metrics 2. **Ticket cycle time ≠ coding time** — the gap between "In Progress" and actual coding hours is significant 3. **Story points ≠ cost** — velocity tells you throughput but not whether it's efficient or expensive 4. **Code review is invisible in Jira** — PR pickup time and review iterations are major lead time components 5. **Jira and engineering intelligence are complementary** — use Jira for project management, PanDev Metrics for engineering performance 6. **The combined view changes decisions** — ticket-level data plus engineering-level data produces fundamentally better insights ## Who Should Choose What This is not a traditional "competitor vs. competitor" comparison. Jira and PanDev Metrics are not alternatives — they serve different purposes. The real question is whether Jira reports alone give you enough visibility. **Stick with Jira reports alone if:** - Your only questions are about sprint progress and ticket throughput - You do not need to know actual coding hours, engineering costs, or DORA metrics - Your team is small and the overhead of another tool is not justified - Project management metrics are sufficient for your leadership reporting **Add PanDev Metrics on top of Jira if:** - You need DORA metrics (lead time, deployment frequency, change failure rate, MTTR) - You want to know actual coding time, not just ticket cycle time - Financial visibility (cost per project, cost per team) is required for leadership or board reporting - Code review bottlenecks are suspected but invisible in your current tooling - On-premise deployment is needed for compliance - You want AI-powered queries to explore engineering data without building custom Jira dashboards - Your organization has outgrown ticket-level metrics and needs engineering-level intelligence The bottom line: Jira is your project management layer. PanDev Metrics is your engineering intelligence layer. Most mature engineering organizations need both. --- *[PanDev Metrics](https://pandev-metrics.com) integrates with Jira to add DORA metrics, IDE tracking, code review analytics, and financial visibility to your existing workflow. Free tier available — your Jira setup does not change.* --- ## Top 10 Engineering Intelligence Tools in 2026: Market Overview URL: https://pandev-metrics.com/docs/blog/top-10-engineering-intelligence-2026 Date: 2025-12-12 Tags: market-overview, engineering-metrics, developer-productivity, comparison Description: A comprehensive overview of the top 10 Engineering Intelligence platforms in 2026 — features, pricing, strengths, and ideal use cases. The Engineering Intelligence market has matured significantly. What started as simple developer time trackers and Git analytics dashboards has evolved into a diverse ecosystem of platforms — each with a different philosophy on how to measure, optimize, and manage engineering organizations. Whether you're evaluating your first engineering analytics tool or considering a switch, this overview covers the top 10 platforms in the space as of 2026. We've included pricing, key strengths, and ideal use cases for each. ## How We Categorized the Market The Engineering Intelligence market spans several overlapping categories: - **Developer Activity Tracking** — measuring how developers spend their time (IDE-level data) - **Delivery Metrics** — DORA metrics, lead time, deployment frequency, change failure rate - **Engineering Management** — resource allocation, portfolio management, team health - **Financial Analytics** — cost per project, engineering ROI, budget tracking - **Developer Experience** — surveys, sentiment analysis, friction identification No single tool covers every category equally well. The best choice depends on which dimensions matter most to your organization. ## 1. PanDev Metrics **Category:** Full-stack Engineering Intelligence **Overview:** PanDev Metrics combines developer activity tracking, DORA metrics, and financial analytics in a single platform. It stands out for its on-premise deployment option, IDE-level tracking across 10+ editors, and built-in financial analytics with individual hourly rate support. **Key Features:** - 10+ IDE plugins for automated activity tracking - DORA metrics with 4-stage Lead Time breakdown - Financial analytics: cost per project, per team, per feature, with individual hourly rates - On-premise and cloud deployment options - Multi-provider Git support (GitHub, GitLab, Bitbucket, self-hosted) - AI assistant for insights and recommendations - Gamification and developer engagement features **Strengths:** - Only platform offering both IDE tracking and financial analytics - Featured in Forbes Kazakhstan (April 2026); client results include 30% productivity increase and 25% improvement in release quality - On-premise deployment for regulated industries and security-conscious organizations - Hourly rate tracking enables accurate cost-per-feature calculations - Free tier available for evaluation **Best For:** Mid-market engineering teams (20-500 developers) that need both engineering metrics and financial visibility, organizations with on-premise requirements, and teams wanting a single platform for activity tracking + DORA + cost analytics. **Pricing:** Free tier available. Paid plans — contact for pricing. --- ## 2. LinearB **Category:** Delivery Metrics & Workflow Automation **Overview:** LinearB is one of the more established Engineering Intelligence platforms, known for strong DORA metrics implementation and workflow automation. Its WorkerB bot automates PR routing, review reminders, and team workflow agreements. **Key Features:** - Full DORA metrics suite with industry benchmarking (8.1M+ PRs analyzed) - WorkerB bot for automated workflow improvements - Team health and developer experience metrics - Git analytics and PR cycle time tracking - Sprint and project management integration **Strengths:** - Mature workflow automation that goes beyond measurement to active optimization — arguably the best in the market - Strong benchmarking data from one of the largest PR datasets (8.1M+) - "Dev Interrupted" podcast and community have become go-to resources for engineering leaders - Well-documented API and integrations **Limitations:** - Cloud-only — no on-premise option - No IDE-level activity tracking - No financial analytics (cost per project, hourly rates) - At $420-549/dev/year, pricing adds up for larger teams **Best For:** Engineering teams focused on delivery pipeline optimization and automated workflow improvements, organizations that prioritize benchmarking against industry standards. **Pricing:** ~$420-549 per developer per year. --- ## 3. Jellyfish **Category:** Engineering Management Platform **Overview:** Jellyfish is an enterprise-grade platform designed for VPs of Engineering and CTOs to manage engineering investment at a portfolio level. It excels at mapping engineering work to business initiatives and strategic resource allocation. **Key Features:** - Portfolio-level engineering investment tracking - Strategic initiative mapping and resource allocation - CapEx/OpEx engineering capitalization - HR and calendar integrations (BambooHR, Workday) - What-if scenario modeling for resource planning - Board-level reporting templates, ROI calculator **Strengths:** - Best-in-class strategic portfolio management - Claims 50,000+ teams, hosts GLOWLive events for engineering leaders - Strong financial reporting for publicly traded companies (CapEx/OpEx) - Extensive integration ecosystem (HR, calendar, finance) - Sophisticated scenario modeling capabilities **Limitations:** - Enterprise-only pricing: typically $50K-$250K per year - Cloud-only — no on-premise deployment - No IDE-level activity tracking - DORA metrics implementation is basic compared to dedicated platforms - Implementation can take weeks to months **Best For:** Large enterprise engineering organizations (300+ developers) with dedicated budget for engineering management tooling, publicly traded companies needing CapEx/OpEx capitalization. **Pricing:** $50,000-$250,000+ per year (enterprise contracts). --- ## 4. Swarmia **Category:** Developer Productivity & Experience **Overview:** Swarmia takes a developer experience-first approach to engineering metrics. It combines delivery metrics with developer survey data and focuses on reducing friction rather than measuring output. Swarmia has a strong philosophy around "healthy" metrics that don't incentivize gaming. **Key Features:** - Working agreements (team-level standards for PR size, review time, etc.) - Developer experience surveys and sentiment tracking - DORA-aligned delivery metrics - Investment balance tracking (feature vs. debt vs. support) - Slack integration for team notifications **Strengths:** - Thoughtful approach to metrics detailed in their published book "Build" - Customers include Miro, Bolt, and Chess.com - Good developer experience survey integration - Working agreements help teams self-improve - Free tier for teams up to 9 developers **Limitations:** - Cloud-only — no on-premise option - No IDE-level activity tracking - No financial analytics (no cost per project, no hourly rates) - Smaller market presence than some competitors **Best For:** Engineering teams that prioritize developer experience and team health, organizations that want metrics paired with developer satisfaction data. **Pricing:** ~$15-20 per developer per month. --- ## 5. Pluralsight Flow (formerly GitPrime) **Category:** Git Analytics **Overview:** Pluralsight acquired GitPrime in 2019 and rebranded it as Pluralsight Flow. The platform provides Git-based engineering analytics including code review metrics, coding patterns, and team efficiency data. However, Flow's future is uncertain — Pluralsight sold Flow to Appfire, and the product has seen limited updates and content in recent periods. **Key Features:** - Git-based code analytics (commits, PRs, reviews) - Developer activity patterns derived from Git data - Team comparison and trend tracking - Code review metrics **Strengths:** - Established Git analytics methodology (from GitPrime era) - Good visualization of coding patterns **Limitations:** - Product future uncertain after sale to Appfire - Limited recent updates and new feature development - No IDE tracking, no DORA metrics, no financial analytics - Pricing remains high (~$50/developer/month) despite limited investment - No on-premise option **Best For:** Existing customers evaluating alternatives. New evaluations should consider the product's uncertain roadmap. **Pricing:** ~$50 per developer per month. --- ## 6. WakaTime **Category:** Personal Developer Time Tracking **Overview:** WakaTime is the most popular personal coding time tracker, with over 500K users and plugins for 40+ IDEs and editors. It tracks coding time at the individual level with granular language, project, and editor breakdowns. The annual "Yearly Wrapped" reports have become a cultural moment in the developer community. **Key Features:** - 40+ IDE/editor plugins — broadest coverage in the market - Detailed personal coding dashboards - Language and project time breakdowns - Annual "Yearly Wrapped" reports, GitHub profile badges - Open-source plugin ecosystem **Strengths:** - Best IDE coverage — supports virtually every editor - Excellent personal productivity tool at $9/month - 500K+ users create strong community and network effects - Active open-source community **Limitations:** - Designed for individuals, not teams — minimal team features - No DORA metrics, no delivery pipeline analytics - No financial analytics - No organizational management features **Best For:** Individual developers who want to track their personal coding habits, freelancers tracking billable hours, developers who want a lightweight personal dashboard. **Pricing:** Free tier (limited). ~$9/month for premium. --- ## 7. Sleuth **Category:** DORA Metrics & Deploy Tracking **Overview:** Sleuth focuses specifically on DORA metrics and deployment tracking. Available on both GitHub Marketplace and Atlassian Marketplace, it provides a deploy-centric view of engineering performance — every metric connects back to what was deployed, when, and what happened after. It also offers a free tier. **Key Features:** - DORA metrics with deployment tracking - Change lead time visualization - Impact tracking (how deploys affect metrics) - Incident tracking integration - GitHub and Atlassian Marketplace presence **Strengths:** - Focused deployment analytics — does one thing well - Good DORA metrics implementation - Free tier available, easy marketplace installation - Clean, intuitive interface with quick setup **Limitations:** - Narrow scope — DORA and deploys only - No IDE tracking, no financial analytics - No developer activity or time tracking - Limited team management features **Best For:** Teams that need focused DORA metrics without the complexity of a full engineering intelligence platform. Good complement to other tools. **Pricing:** Free tier available. Paid plans vary. --- ## 8. Faros AI **Category:** Engineering Intelligence Data Platform **Overview:** Faros AI takes a data platform approach — essentially a commercially-backed alternative to Apache DevLake. It ingests data from 50+ engineering tools through open-source connectors and provides dashboards, metrics, and insights on top of a unified data model. Think of it as a data warehouse specifically designed for engineering metrics. **Key Features:** - 50+ tool integrations via open-source connectors (broadest in market) - Unified engineering data model - Custom dashboard and report builder - DORA metrics and delivery analytics - Grafana-based visualization - Self-hosted option available **Strengths:** - Open-source connector framework (Airbyte-based, alternative to Apache DevLake) - Extremely broad integration ecosystem - Flexible data model — can correlate data across many tools - Strong for organizations with complex toolchains and data engineering capacity **Limitations:** - Complexity — more of a data platform than a turn-key solution - Implementation requires data engineering expertise - No IDE-level tracking - Enterprise pricing - Cloud-only **Best For:** Large engineering organizations with complex, multi-tool environments that need a data unification layer across their entire toolchain. **Pricing:** Enterprise pricing (contact for details). --- ## 9. Waydev **Category:** Git Analytics & Engineering Metrics **Overview:** Waydev provides Git-based engineering analytics focused on helping engineering leaders understand team productivity and delivery performance. It combines Git analytics with project management data to provide a unified view. **Key Features:** - Git-based productivity analytics - DORA metrics - Sprint analytics and planning insights - Work log and time allocation tracking - Investment balance (feature vs. debt vs. bugs) **Strengths:** - Good balance of Git analytics and delivery metrics - Investment allocation tracking - Reasonable pricing for mid-market - Integration with major Git providers and project management tools **Limitations:** - No IDE-level tracking - No financial analytics with hourly rates - Cloud-only — no on-premise - Smaller market presence **Best For:** Mid-market engineering teams looking for Git analytics combined with delivery metrics at a reasonable price point. **Pricing:** Contact for pricing. --- ## 10. Amplitude DevTools / Cortex / DX **Category:** Developer Experience Platforms **Overview:** Rather than a single product, this slot represents the growing category of Developer Experience (DevEx) platforms. DX (getdx.com) leads this space with its DX Core 4 framework and quarterly AI impact reports that are widely cited. Other tools like Cortex (internal developer portal + scorecards) approach DevEx from the tooling side. **Key Features (varies by platform):** - Developer experience surveys and metrics (DX Core 4 framework) - Quarterly AI impact reports (DX) - Service catalogs and scorecards (Cortex) - Standards enforcement and tracking - Developer satisfaction measurement **Strengths:** - DX's research-backed methodology (SPACE framework, DX Core 4) has academic credibility - Help identify friction and process problems that quantitative data misses - Quarterly AI impact reports from DX are becoming industry-standard references **Limitations:** - Typically don't provide quantitative engineering metrics - No IDE tracking, no financial analytics - Often require pairing with a metrics platform for full visibility **Best For:** Organizations that have quantitative metrics covered and want to add qualitative developer experience measurement. **Pricing:** Varies widely by platform. --- ## Market Comparison Matrix | Platform | IDE Tracking | DORA Metrics | Financial Analytics | On-Premise | Typical Price | |----------|:----------:|:------------:|:------------------:|:----------:|:------------:| | **PanDev Metrics** | Yes | Yes | Yes | Yes | Free tier + paid | | **LinearB** | No | Yes | No | No | $420-549/dev/yr | | **Jellyfish** | No | Basic | Yes (strategic) | No | $50-250K/yr | | **Swarmia** | No | Yes | No | No | $15-20/dev/mo | | **Pluralsight Flow** | No | No | No | No | ~$50/dev/mo | | **WakaTime** | Yes | No | No | No | Free/$9/mo | | **Sleuth** | No | Yes | No | No | Free tier + paid | | **Faros AI** | No | Yes | Basic | No | Enterprise | | **Waydev** | No | Yes | No | No | Contact | | **DevEx platforms** | No | No | No | Varies | Varies | ## Key Market Trends in 2026 ### 1. Financial Analytics Is Becoming Table Stakes Two years ago, only Jellyfish offered engineering financial analytics. Today, PanDev Metrics has made cost-per-project and hourly rate tracking accessible to mid-market teams. Expect more platforms to add financial features as CFOs demand visibility into engineering spend. ### 2. On-Premise Is Making a Comeback After a decade of cloud-first, regulated industries and security-conscious organizations are pushing back. Engineering metrics platforms handle sensitive data — code patterns, developer activity, salary information. On-premise deployment options are increasingly a requirement for enterprise buyers. ### 3. AI-Powered Insights Are Standard Nearly every platform now includes some form of AI-powered insights. The differentiation is shifting from "has AI" to "how good is the AI" — specifically, whether it can surface actionable recommendations rather than just summarize dashboards. ### 4. Developer Experience Metrics Are Merging with Engineering Metrics The line between quantitative engineering metrics (DORA, lead time) and qualitative developer experience metrics (satisfaction, friction) is blurring. Platforms that combine both provide a more complete picture. ### 5. Consolidation Is Accelerating The Pluralsight Flow sale to Appfire is one example of consolidation in the space. Expect more M&A as the market matures and organizations prefer fewer, more comprehensive tools over a fragmented toolkit. ## How to Choose the Right Tool ### Step 1: Define Your Primary Use Case | If your primary need is... | Consider... | |---------------------------|-------------| | Personal productivity tracking | WakaTime | | DORA metrics and delivery optimization | LinearB, Sleuth, PanDev Metrics | | Financial analytics and cost tracking | PanDev Metrics, Jellyfish | | Strategic portfolio management | Jellyfish | | Developer experience measurement | Swarmia, DX platforms | | Data unification across tools | Faros AI | | All-in-one with on-premise option | PanDev Metrics | ### Step 2: Consider Your Constraints - **Budget:** Ranges from free to $250K+/year. Be realistic about what you'll invest. - **Team size:** Some platforms target enterprise (200+); others work for teams of 10. - **Security requirements:** If on-premise is a hard requirement, your options narrow significantly. - **Existing toolchain:** Check Git provider compatibility, Jira/Linear integration, CI/CD support. ### Step 3: Evaluate with Real Data Every platform on this list offers either a free tier or a trial. Don't choose based on demos alone — install the tool, connect your real data, and evaluate the insights for 2-4 weeks before committing. ## Key Takeaways 1. **No single tool does everything** — but some come closer than others to full-stack coverage 2. **Financial analytics is the biggest gap** — most platforms still don't connect engineering metrics to dollars 3. **On-premise deployment is rare** — only PanDev Metrics and self-hosted options offer this 4. **IDE tracking provides unique data** — only PanDev Metrics and WakaTime track actual coding time 5. **Price ranges vary 100x** — from free to $250K/year, with significant feature overlap in the middle 6. **Try before you buy** — use free tiers and trials with real team data --- *[PanDev Metrics](https://pandev-metrics.com) combines IDE tracking, DORA metrics, financial analytics, and on-premise deployment in a single platform. Free tier available.* --- ## Engineering Metrics in Fintech: Compliance, Speed, and Security URL: https://pandev-metrics.com/docs/blog/fintech-compliance-engineering-metrics Date: 2025-12-11 Tags: fintech, compliance, engineering-metrics, dora-metrics, security Description: How fintech CTOs use engineering metrics to balance regulatory compliance, delivery speed, and security without slowing teams down. Fintech CTOs live in a unique pressure cooker: regulators demand audit trails and compliance evidence, the business demands rapid feature delivery, and security teams demand zero vulnerabilities. These three forces constantly pull engineering organizations in different directions. The good news? Engineering metrics can help you satisfy all three — without turning your team into a bureaucratic machine. Research from the DORA State of DevOps Reports consistently shows that elite performers don't trade speed for stability — they achieve both simultaneously. ## The Fintech Engineering Trilemma Every fintech CTO faces the same impossible triangle: - **Compliance** — PCI DSS 4.0, SOC 2 Type II, PSD2, GDPR, and the EU's Digital Operational Resilience Act (DORA Regulation) require documented processes, audit trails, and provable controls - **Speed** — Competitors ship features weekly; your customers expect the same. The Bessemer Cloud Index shows top fintech companies deploy multiple times per day. - **Security** — A single breach can cost millions in fines and destroy customer trust overnight. The EBA Guidelines on ICT and Security Risk Management make security posture a board-level concern. Traditional management treats these as trade-offs. You can have two, but not all three. Engineering metrics change this equation by making all three dimensions visible and measurable simultaneously. ## Why Traditional Project Management Fails in Fintech Most fintech companies start with Jira boards and sprint velocity. These tools tell you *what* the team planned to do and *whether* tickets moved across columns. They don't tell you: - How long code actually sits in review waiting for a compliance-mandated second approval - Whether security fixes are being prioritized or perpetually pushed to the next sprint - How much developer time is spent on compliance-related work versus feature development - Whether your change failure rate is trending up as you accelerate delivery Without this visibility, CTOs make decisions based on gut feeling and team leads' subjective reports. In a regulated industry, that's not just inefficient — it's risky. ## The Five Metrics That Matter for Fintech ### 1. Deployment Frequency With Change Categorization Standard DORA metrics track how often you deploy. In fintech, *what* you deploy matters as much as *how often*. You need to categorize deployments: - **Feature releases** — new customer-facing functionality - **Compliance updates** — changes mandated by regulatory requirements - **Security patches** — vulnerability fixes and dependency updates - **Infrastructure changes** — platform and tooling updates When you can see deployment frequency broken down by category, patterns emerge. If compliance updates are consuming 40% of your deployment pipeline, that's a signal to invest in automation. If security patches are infrequent, that might indicate a backlog of unaddressed vulnerabilities. PanDev Metrics tracks deployment frequency across your GitLab, GitHub, Bitbucket, or Azure DevOps pipelines, giving you this breakdown without manual categorization overhead. ### 2. Lead Time for Changes — With Compliance Gates In most industries, lead time for changes measures the time from first commit to production deployment. In fintech, the pipeline includes mandatory gates: - Code review (often requiring two approvals for payment-related code) - Security scanning - Compliance review for regulated features - Staging environment testing with synthetic data Measuring the *total* lead time isn't enough. You need to see where time is spent at each gate. If code review takes 2 hours but compliance review takes 3 days, you know exactly where to focus improvement efforts. With PanDev Metrics, you can track each stage of your pipeline and identify bottlenecks that slow delivery without adding risk. ### 3. Change Failure Rate by Service Criticality Not all failures are equal. A bug in your marketing landing page is different from a bug in your payment processing engine. Fintech CTOs need change failure rate segmented by service criticality: - **Tier 1 (Critical)** — Payment processing, transaction engines, authentication systems - **Tier 2 (Important)** — Customer dashboards, reporting systems, internal tools - **Tier 3 (Standard)** — Marketing pages, documentation, non-customer-facing services A 5% change failure rate across the board might seem acceptable. But if your Tier 1 services have a 10% failure rate while Tier 3 services have 1%, you have a serious problem hiding behind an average. ### 4. Developer Activity Distribution Understanding how your engineering team's time is distributed across different types of work is critical in fintech. IDE heartbeat tracking and activity monitoring reveal the actual split between: - **Feature development** — building new capabilities - **Compliance work** — implementing regulatory requirements, documentation - **Security remediation** — fixing vulnerabilities, updating dependencies - **Maintenance** — bug fixes, technical debt reduction - **Code review** — reviewing others' work (often higher in fintech due to mandatory reviews) PanDev Metrics' IDE heartbeat tracking captures this data automatically from 10+ supported IDEs, showing you Focus Time and Activity Time broken down by project and repository. ### 5. Mean Time to Recovery (MTTR) In fintech, downtime isn't just lost revenue — it can trigger regulatory reporting requirements. Under PSD2, payment service providers must report major operational incidents to their national authority. The Basel III operational risk framework further quantifies downtime as a capital-impacting event. Tracking MTTR by service tier helps you: - Prove to regulators that you have effective incident response - Identify services that need better monitoring or redundancy - Justify investment in reliability engineering ## Building Your Compliance Evidence Trail Regulators don't just want you to be compliant — they want you to *prove* it. Engineering metrics create an automatic evidence trail: **For SOC 2 audits:** - Deployment logs showing consistent change management processes - Code review metrics proving mandatory review policies are followed - Lead time data demonstrating controlled, non-rushed releases **For PCI DSS compliance:** - Change failure rates showing payment systems are thoroughly tested - Activity logs demonstrating separation of duties - Recovery time metrics proving incident response capability **For regulatory reporting:** - Uptime and availability data from deployment and recovery metrics - Evidence of security patch deployment timelines - Documentation of development process controls PanDev Metrics supports on-premise deployment, which is often a requirement for fintech companies handling sensitive financial data. Your metrics data stays within your infrastructure, behind your firewall. ## Practical Implementation: A Phased Approach ### Phase 1: Foundation (Weeks 1-2) Start with the basics: 1. Connect your Git platform (GitLab, GitHub, Bitbucket, or Azure DevOps) to PanDev Metrics 2. Deploy IDE plugins to your development team (supports VS Code, JetBrains IDEs, Vim, and more) 3. Establish baseline measurements for DORA metrics Don't try to change anything yet. Just observe. ### Phase 2: Visibility (Weeks 3-4) Share dashboards with team leads: - Show deployment frequency trends - Highlight lead time bottlenecks (compliance gates will likely stand out) - Present change failure rates by service Let the team react to the data. Often, just making metrics visible drives improvement without any top-down mandates. ### Phase 3: Optimization (Month 2+) Now you have enough data to make informed decisions: - Automate compliance gates that cause the biggest delays - Invest in testing for services with high change failure rates - Rebalance team allocation if compliance work is crowding out feature development - Set targets based on your own baselines, not industry benchmarks ### Phase 4: Continuous Evidence (Ongoing) Use metrics dashboards as living compliance documentation: - Export reports for audit preparation - Set alerts for anomalies (sudden spike in change failure rate, drop in deployment frequency) - Review trends quarterly with leadership and compliance teams ## Common Pitfalls to Avoid **Don't use metrics as individual performance measures.** Fintech developers already deal with extra review requirements and compliance overhead. Using activity tracking to judge individuals will destroy trust and morale. Focus on team-level and system-level metrics. **Don't set targets before you have baselines.** Every fintech organization is different. A company processing millions of transactions daily has different constraints than one building a B2B lending platform. Measure first, then set realistic improvement targets. **Don't ignore the compliance cost.** If your metrics show that 30% of engineering time goes to compliance-related work, that's not a problem to fix — it's a reality to plan around. Use this data for capacity planning and roadmap discussions with the business. **Don't deploy metrics without team buy-in.** Explain to your team *why* you're tracking these metrics. In fintech, the answer is straightforward: regulators require evidence of controlled processes, and metrics automate that evidence collection. ## The ROI of Engineering Metrics in Fintech The return on investment for engineering intelligence in fintech comes from three sources: 1. **Reduced audit preparation time.** Companies using engineering metrics report spending ~40-60% less time preparing for SOC 2 and PCI DSS audits because evidence is continuously collected rather than manually assembled. 2. **Faster identification of bottlenecks.** When you can see that compliance review is your biggest lead time contributor, you can invest in automation (policy-as-code, automated compliance checks) rather than guessing. 3. **Better resource allocation.** Understanding the actual split between feature work, compliance, and security helps you staff teams appropriately and set realistic delivery expectations with the business. ![LDAP/AD settings with Integration Connected badge](https://pandev-metrics.com/img/blog/settings-ldap.png) LDAP/Active Directory integration ensures PanDev fits into your existing enterprise authentication infrastructure — a common requirement in fintech environments. ![Mail settings showing SMTP configuration](https://pandev-metrics.com/img/blog/settings-mail-detail.png) Enterprise mail configuration ensures notifications and alerts route through your organization's internal SMTP server — keeping all communication within your network perimeter. ## Security and Data Privacy Considerations Fintech companies rightfully worry about adding any new tool to their stack. Key considerations: - **On-premise deployment** — PanDev Metrics can be deployed entirely within your infrastructure, ensuring engineering data never leaves your network - **LDAP/SSO integration** — fits into your existing authentication infrastructure - **Multi-tenancy** — if you have multiple teams or business units, each can have isolated data - **Data minimization** — activity tracking captures patterns, not code content ## Conclusion Fintech engineering doesn't have to be a choice between compliance, speed, and security. With the right metrics infrastructure, these three dimensions become complementary rather than competing. Start by measuring what's actually happening. Then use that data to remove bottlenecks, automate compliance evidence, and build the kind of engineering organization that regulators trust and customers love. --- **Ready to bring engineering intelligence to your fintech team?** [PanDev Metrics](https://pandev-metrics.com) — on-premise deployment, DORA metrics, IDE activity tracking, and compliance-ready reporting for regulated industries. --- ## E-Commerce: How to Accelerate Feature Delivery Before High Season URL: https://pandev-metrics.com/docs/blog/ecommerce-accelerate-feature-delivery-high-season Date: 2025-12-08 Tags: ecommerce, engineering-metrics, delivery-speed, dora-metrics, seasonal-planning Description: How e-commerce CTOs use engineering metrics to ship critical features before Black Friday, holiday sales, and other peak traffic periods. In e-commerce, the calendar is your most demanding stakeholder. Black Friday, Cyber Monday, holiday seasons, summer sales — these dates don't move. If your new checkout flow, recommendation engine, or payment integration isn't ready by the freeze date, it waits until next year. According to the Salesforce Holiday Shopping Report, online sales during the 2024 Cyber Week exceeded $300 billion globally — a single percentage point of downtime translates to billions in lost revenue across the industry. Engineering metrics give you the visibility to spot delivery risks months in advance, not days before the deadline. ![Real-time team visibility during high-season feature sprints](https://pandev-metrics.com/img/blog/dashboard-clean.png) *Real-time team visibility during high-season feature sprints.* ## The E-Commerce Engineering Calendar E-commerce engineering teams operate on a rhythm that most other industries don't experience. The year looks something like this: - **January–March:** Post-mortem from last season, architecture improvements, technical debt reduction - **April–June:** Major feature development for the upcoming season - **July–September:** Feature completion, integration testing, performance optimization - **October:** Code freeze preparation, final stabilization - **November–December:** Code freeze, war room, firefighting The problem? Most teams don't realize they're behind until September. By then, it's too late to course-correct. ## Why E-Commerce Teams Miss Deadlines Having worked with engineering teams across multiple e-commerce companies, we see the same patterns: ### Invisible Dependencies The new product recommendation engine depends on the updated catalog API, which depends on the data pipeline migration, which depends on the infrastructure team. None of this is visible in sprint velocity charts. ### Optimistic Lead Times Teams estimate based on *coding time* but forget about code review queues, QA cycles, staging environment contention, and the back-and-forth with product on edge cases. The actual lead time from first commit to production is often 3-5x longer than the coding estimate. ### Unplanned Compliance Work PCI DSS 4.0 recertification, GDPR data subject requests, accessibility requirements — these land on engineering plates without warning and consume weeks of capacity. The Adobe Digital Economy Index notes that compliance-related engineering work spikes ~30% in Q3 as retailers prepare for peak season audits. ### Technical Debt Compounding That "quick fix" from last year's Black Friday is now a fragile component that breaks every time someone touches it. The team spends more time working around it than it would take to fix it, but there's never "time" for the fix. ## The Metrics Framework for Seasonal Delivery ### Deployment Frequency: Your Leading Indicator Deployment frequency is the single best leading indicator of delivery health. Here's why: - **Declining deployment frequency** in April–June means teams are struggling with large, complex changes that take longer to integrate - **Stable or increasing deployment frequency** means teams are shipping small, incremental changes — which is both faster and safer - **Sudden drops** signal blockers: environment issues, review bottlenecks, or team members pulled to other priorities Track deployment frequency weekly, broken down by team and service. If your checkout team's deployment frequency drops 40% in May, that's a signal to investigate *now*, not in September. PanDev Metrics tracks deployments across GitLab, GitHub, Bitbucket, and Azure DevOps, giving you real-time visibility without manual reporting. ### Lead Time for Changes: Predict Your Actual Delivery Date If your average lead time for changes is 5 days, and you have 30 features left to ship, you need at least 150 developer-days of capacity. But that assumes: - No increase in review time as more code is in flight - No staging environment contention - No context-switching between features and bug fixes In practice, lead time tends to *increase* as you approach the deadline because more changes are in flight simultaneously, review queues get longer, and testing environments become contested. Track lead time trends weekly. If lead time is increasing month over month, your delivery date is slipping even if sprint velocity looks stable. ### Change Failure Rate: The Quality Gate The temptation before high season is to cut corners on quality to meet deadlines. Engineering metrics make the cost of this visible: - A rising change failure rate means more rollbacks, more hotfixes, and more time spent on rework - Each failure during the pre-season adds unplanned work that pushes other features back - A high change failure rate going into code freeze means you'll spend November fixing bugs instead of monitoring performance Set a target: if change failure rate exceeds a threshold (many e-commerce teams use ~10-15%), slow down and invest in testing rather than pushing more features. This aligns with findings from the Shopify engineering blog, where teams enforce a hard quality gate before their Black Friday code freeze. ### Focus Time: Are Developers Actually Building? E-commerce companies are meeting-heavy. Product reviews, design syncs, stakeholder updates, cross-team coordination — by the time a developer sits down to code, half the day is gone. PanDev Metrics' IDE heartbeat tracking shows actual Focus Time — uninterrupted blocks of coding activity. If your developers are averaging 90 minutes of Focus Time per day, no amount of project management optimization will help. You need to protect their deep work time. Compare Focus Time across teams and time periods: - If Focus Time drops as you approach the deadline, meetings and context-switching are killing productivity - If Focus Time is consistently low for a specific team, investigate their meeting load and interrupt frequency - Track Activity Time alongside Focus Time to see the full picture of developer engagement ### MTTR: Your Black Friday Insurance Mean Time to Recovery during peak traffic determines whether a checkout bug costs you thousands or millions. Before high season: - Measure current MTTR for critical services (checkout, payments, product catalog, search) - Identify services with MTTR above your target - Invest in monitoring, runbooks, and automated rollback for those services If your payment service MTTR is 45 minutes, that's potentially 45 minutes of lost transactions during peak traffic. According to Salesforce data, top e-commerce sites process ~$1M+ per minute during Black Friday peak hours. Measure it, set targets, improve it. ## Building a Pre-Season Engineering Dashboard Create a dashboard that your entire leadership team can see, updated automatically: **Delivery Health:** - Deployment frequency by team (weekly trend) - Lead time for changes (weekly trend) - Features completed vs. planned (cumulative) **Quality:** - Change failure rate by service (weekly) - Open bugs by severity - Test coverage trends for critical services **Team Health:** - Focus Time averages by team - Activity distribution (feature work vs. bug fixes vs. maintenance) - On-call burden distribution **Readiness:** - MTTR for Tier 1 services - Deployment pipeline reliability - Rollback success rate PanDev Metrics provides these views out of the box, with integrations into Jira and ClickUp for correlating engineering metrics with project tracking data. ## The 6-Month Countdown: A Practical Timeline ### T-6 Months: Establish Baselines Connect PanDev Metrics to your development stack: - Git platforms (GitLab, GitHub, Bitbucket, Azure DevOps) - IDE plugins across all development teams - Project tracking (Jira, ClickUp) Measure everything for 2-4 weeks without making changes. Understand your current deployment frequency, lead time, change failure rate, and Focus Time baselines. ### T-5 Months: Identify Bottlenecks Analyze the baseline data: - Which teams have the longest lead times? Why? - Where does code wait the longest — review, QA, staging, or deployment? - Which services have the highest change failure rates? - Are there teams with significantly lower Focus Time? Address the biggest bottlenecks first. Often, the highest-impact improvements are organizational, not technical: reducing review queue times, allocating dedicated testing resources, or protecting developer Focus Time. ### T-4 Months: Optimize and Monitor Implement changes and track their impact: - If review was the bottleneck, have you reduced review wait time? - If staging environment was the bottleneck, did the new environment provisioning help? - Is deployment frequency increasing? - Is lead time decreasing? ### T-3 Months: Feature Completion Tracking Start mapping metrics to specific feature delivery: - Which features are on track based on current lead time trends? - Which features are at risk? - Where should you add resources or reduce scope? This is where financial analytics become valuable. PanDev Metrics' financial features help you understand the cost of each feature and make informed trade-off decisions. ### T-2 Months: Stabilization Focus Shift focus from features to stability: - Change failure rate should be declining - MTTR improvements should be in place for critical services - Performance testing results should validate capacity for peak traffic ### T-1 Month: Code Freeze Preparation Final metrics check: - All critical features deployed and validated - Change failure rate at or below target - MTTR within acceptable range for all Tier 1 services - Rollback procedures tested and documented ## What to Do When Metrics Show You're Behind It's month T-4 and the data clearly shows you won't deliver everything planned. Now what? **Option 1: Reduce scope.** Use your metrics to identify which features are furthest behind and negotiate with product on what can wait until next season. Data-driven scope discussions are far more productive than opinion-based arguments. **Option 2: Reduce lead time.** If lead time is your biggest problem, look for ways to parallelize work, reduce review wait times, or simplify deployment processes. Even a 20% reduction in lead time can recover weeks of delivery capacity. **Option 3: Increase Focus Time.** If developers are spending less than 2 hours per day in focused coding, every hour you reclaim has an outsized impact. Cancel recurring meetings, batch communications, and protect deep work blocks. **Option 4: Add capacity strategically.** If you're going to bring in additional engineers, use your metrics to identify exactly where they're needed. Adding developers to a team that's bottlenecked on review won't help — adding reviewers will. ## After the Season: The Post-Mortem That Matters Once the season is over, your metrics tell the real story: - How accurate were your delivery estimates? - Where did the biggest delays actually occur? - How did code quality hold up under deadline pressure? - Which teams maintained healthy metrics and which struggled? Use this data to plan next year. The e-commerce engineering calendar is predictable — the only question is whether you'll use data to navigate it better each year. --- **Ready to accelerate your e-commerce feature delivery?** [PanDev Metrics](https://pandev-metrics.com) — engineering intelligence for teams that can't afford to miss their deadlines. --- ## SaaS Startup: Engineering Metrics From Seed to Series B URL: https://pandev-metrics.com/docs/blog/saas-startup-engineering-metrics-seed-to-series-b Date: 2025-12-05 Tags: saas, startup, engineering-metrics, dora-metrics, fundraising, scaling Description: How SaaS startups should evolve their engineering metrics approach from Seed through Series A to Series B as the team and product mature. At seed stage, your CTO writes code and ships features. By Series B, you have 40 engineers across multiple teams, and the CTO hasn't pushed a commit in months. The engineering metrics that matter at each stage are completely different — and getting them wrong can mean building the wrong things, hiring the wrong way, or telling investors a story that doesn't match reality. The T2D3 framework (Triple, Triple, Double, Double, Double) that defines SaaS growth expectations demands engineering velocity that scales with revenue ambitions. Here's how to evolve your engineering metrics as your SaaS startup grows. ![Team dashboard showing the engineering metrics investors want to see](https://pandev-metrics.com/img/blog/dashboard-clean.png) *Team dashboard showing the engineering metrics investors want to see.* ## Why Startups Need Engineering Metrics (Earlier Than You Think) Most startup CTOs dismiss engineering metrics as "enterprise overhead." When you have 3 engineers sitting next to each other, you can see everything. You know who's shipping, what's blocked, and where the problems are. But this breaks down faster than you expect: - **At 5 engineers:** You can no longer observe everyone's work directly - **At 10 engineers:** You start missing things — blocked PRs, duplicated work, mounting technical debt - **At 20 engineers:** You're making hiring and resource allocation decisions based on incomplete information - **At 40+ engineers:** You're flying blind, relying on team leads who may or may not have the full picture The best time to establish engineering metrics is before you need them. Starting early means you have historical data when it matters — for fundraising, for scaling decisions, and for identifying problems before they become crises. ## Seed Stage (2-5 Engineers): Focus on Flow At seed stage, your only job is to find product-market fit as fast as possible. Your engineering metrics should reflect this singular focus. ### Metrics That Matter **Deployment Frequency:** How often are you shipping to customers? At seed stage, you should be deploying multiple times per day. If you're not, something is wrong — your deployment pipeline is too manual, your PRs are too large, or your testing process is too slow. **Lead Time for Changes:** From the moment a developer starts coding to the moment the feature is in production. At seed, this should be hours, not days. Track this to ensure your development process stays lean. **Cycle Time per Feature:** How long does it take to go from "we decided to build this" to "customers are using it"? This is your speed of learning, and it's the most important thing at seed stage. ### What to Skip Don't track individual developer activity metrics. Don't set up elaborate dashboards. Don't measure test coverage. At seed stage, overhead is the enemy. ### Implementation PanDev Metrics' IDE plugins are lightweight enough for a seed-stage team. Install them, connect your Git platform, and you'll have deployment frequency and lead time data with near-zero setup overhead. This costs you nothing today and gives you valuable historical data later. ## Post-Seed to Series A (5-15 Engineers): Build the Foundation You've found initial product-market fit and raised your Series A (or you're preparing to). The team is growing, and the CTO is transitioning from individual contributor to manager. ### Metrics That Matter **Everything from Seed, plus:** **Change Failure Rate:** As the team grows and moves faster, quality can slip. Track how often deployments cause issues — rollbacks, hotfixes, or incidents. If change failure rate is creeping up, it's a signal that your testing practices or review processes need to evolve. **Developer Focus Time:** With a growing team comes more meetings — standups, sprint planning, design reviews, one-on-ones. PanDev Metrics' IDE heartbeat tracking shows you how much uninterrupted coding time developers actually get. If your 10-person team averages less than 2 hours of Focus Time per day, you have a meeting culture problem. **Activity Distribution:** Where is engineering time going? At this stage, you need visibility into the split between: - New feature development - Bug fixes and maintenance - Infrastructure and tooling - Technical debt remediation If 50% of your time is going to bug fixes and maintenance, that's a signal that you took on too much technical debt during the seed stage. Better to know now than to discover it when you're trying to double the team. ### The Series A Investor Story When fundraising for Series A, investors want to see: 1. **You can ship fast.** Deployment frequency and lead time demonstrate this. 2. **Quality is maintained.** Change failure rate shows you're not sacrificing stability for speed. 3. **The team is productive.** Focus Time and activity distribution show your engineers are actually building, not drowning in process. 4. **You have a foundation for scaling.** Having metrics infrastructure in place signals engineering maturity. These aren't just vanity metrics for a pitch deck. They're evidence that your engineering organization can scale with the business. SaaStr benchmarks show that Series A investors increasingly evaluate engineering velocity alongside ARR growth — companies that can demonstrate both win higher valuations. ### Implementation At this stage, you should have: - PanDev Metrics connected to your Git platform and project tracker (Jira or ClickUp) - IDE plugins deployed to all developers - A weekly review of key metrics with your engineering leads - Basic dashboards showing deployment frequency, lead time, and change failure rate trends ## Series A to Series B (15-40 Engineers): Scale With Confidence This is where most startups hit their first engineering scaling crisis. The team has doubled or tripled, you're splitting into multiple squads, and the coordination overhead is growing exponentially. ### Metrics That Matter **Everything from before, plus:** **DORA Metrics by Team:** You now have multiple teams, and they'll perform differently. Comparing DORA metrics across teams helps you identify which teams need support and which practices should be shared. But be careful: different teams have different contexts. The team maintaining your core payment infrastructure *should* have a lower deployment frequency and longer lead times than the team building a new dashboard feature. Context matters. **Mean Time to Recovery (MTTR):** With more engineers deploying more frequently, incidents will happen. MTTR measures how quickly you recover. Track it by service to identify which parts of your system are fragile. **Financial Analytics:** At this stage, engineering is likely your largest cost center. PanDev Metrics' financial analytics help you understand: - Cost per feature or project - Engineering cost trends as you scale - Resource allocation efficiency across teams - Whether hiring is translating into proportional output increase **Cross-Team Dependencies:** As teams multiply, dependencies become the biggest source of delays. Track lead time for changes that require coordination across teams versus those that don't. If cross-team work takes 3x longer, you may need to restructure team boundaries. ### The Series B Investor Story Series B investors are evaluating your ability to scale efficiently. They want to see: 1. **Engineering output scales with headcount.** If you doubled the team but deployment frequency stayed flat, something is wrong. 2. **Quality doesn't degrade with growth.** Change failure rate should be stable or improving despite more engineers shipping more code. 3. **You understand your unit economics.** Financial analytics showing cost per feature and engineering ROI demonstrate business sophistication. 4. **You can manage complexity.** DORA metrics by team, cross-team dependency tracking, and MTTR trends show you have a handle on organizational complexity. ### The Scaling Trap: Adding Engineers Without Adding Output The most common pattern we see at this stage: the team grows from 15 to 35, but delivery speed feels the same or slower. Sprint velocity per developer drops. Features take longer. The board asks uncomfortable questions. The Bessemer Cloud Index confirms this pattern — engineering efficiency (measured as revenue per engineer) typically dips ~20-30% during rapid scaling before stabilizing. Engineering metrics illuminate what's happening: - **Focus Time per developer drops** as coordination overhead increases - **Lead time increases** because review queues get longer and deployment pipelines become contested - **Activity distribution shifts** toward maintenance and coordination, away from new development - **Deployment frequency per team may increase** while overall feature delivery slows because each feature requires more cross-team coordination Without metrics, the default response is "we need to hire more engineers." With metrics, you can identify the actual bottleneck — often it's organizational structure, not headcount. ### Implementation At 15-40 engineers, your metrics infrastructure should include: - PanDev Metrics with full DORA metrics tracking - IDE plugins across all teams (PanDev supports 10+ IDEs) - Integration with both your Git platform and project tracker - Team-level dashboards with weekly review cadence - Financial analytics for engineering cost visibility - LDAP/SSO integration for seamless team management If you're managing sensitive customer data, PanDev Metrics supports on-premise deployment — your engineering data stays within your infrastructure. ## Common Mistakes at Each Stage ### Seed Stage Mistakes - **Over-investing in metrics infrastructure.** Keep it simple. Plugin + Git integration. Nothing more. - **Tracking vanity metrics.** Lines of code, number of commits, hours logged — none of these tell you anything useful. - **Ignoring deployment frequency.** If you're not deploying daily at seed stage, fix your pipeline before worrying about anything else. ### Series A Stage Mistakes - **Using metrics to compare individual developers.** This destroys trust and drives gaming behavior. Keep metrics at the team level. - **Setting targets without baselines.** Measure first, improve second. Your baseline is your baseline — comparing to DORA industry benchmarks is misleading because context varies enormously. - **Ignoring Focus Time.** The meeting tax is the biggest hidden cost in growing engineering organizations. Measure it. ### Series B Stage Mistakes - **Optimizing team metrics without considering system-level impact.** Each team can have great DORA metrics while the overall system is getting worse due to integration complexity. - **Attributing problems to engineers instead of systems.** If one team is slower, the cause is almost always structural (dependencies, legacy code, unclear requirements), not individual performance. - **Delaying financial analytics.** By Series B, the board expects engineering cost visibility. Building this retroactively is painful. ## The Metrics Maturity Roadmap | Stage | Team Size | Key Metrics | Review Cadence | |-------|-----------|-------------|----------------| | Seed | 2-5 | Deployment frequency, lead time | Weekly glance | | Post-Seed | 5-10 | + Change failure rate, Focus Time | Weekly review | | Series A | 10-20 | + Activity distribution, MTTR | Weekly team reviews | | Pre-Series B | 20-35 | + Financial analytics, cross-team metrics | Weekly + monthly leadership review | | Series B+ | 35-50+ | Full DORA by team, multi-tenancy, department-level views | Weekly team + monthly exec dashboard | > Forbes Kazakhstan reports that ~40 companies are currently piloting engineering intelligence platforms, with early results showing "a 30% productivity increase, while release quality improves by 25%." — [Forbes Kazakhstan, April 2026](https://forbes.kz) ## Starting Today Regardless of your stage, the first step is the same: 1. Connect your Git platform to PanDev Metrics 2. Deploy IDE plugins to your team 3. Wait 2-4 weeks for baseline data 4. Review what you see and identify your biggest bottleneck 5. Improve one thing at a time The startups that build metrics infrastructure early don't just operate better — they tell a more compelling story to investors, make better hiring decisions, and identify problems before they become existential. --- **Building a SaaS startup and want engineering metrics that grow with you?** [PanDev Metrics](https://pandev-metrics.com) — from two engineers in a garage to 200+ across multiple teams. --- ## GameDev: How to Detect and Prevent Crunch Using Data URL: https://pandev-metrics.com/docs/blog/gamedev-detect-prevent-crunch-using-data Date: 2025-12-03 Tags: gamedev, crunch, developer-wellbeing, engineering-metrics, focus-time Description: How game studios use engineering metrics and IDE activity data to detect crunch patterns early and prevent burnout before it damages teams and projects. Crunch is the game industry's open secret. Despite decades of discussion, studio closures, and developer burnout, most studios still can't answer a basic question: is our team crunching right now? They find out when people start quitting. By then, the damage is done — to the team, the project, and the studio's reputation. The IGDA Developer Satisfaction Survey consistently reports that ~50-60% of game developers experience crunch, with many working 50+ hour weeks during peak periods. Engineering metrics make crunch visible before it becomes a crisis. Here's how. ![Activity heatmap revealing overtime patterns — late-night and weekend coding blocks signal crunch](https://pandev-metrics.com/img/blog/activity-heatmap.png) *Activity heatmap revealing overtime patterns — late-night and weekend coding blocks signal crunch.* ## Why Crunch Is Still a Problem in 2026 The game industry has talked about crunch for 20 years. Major studios have publicly committed to eliminating it. Jason Schreier's reporting for Bloomberg and his book *Press Reset* documented the human cost across dozens of studios. So why does it persist? **It's invisible to leadership.** When a producer asks "is the team crunching?", the answer is almost always "it's fine" — until it isn't. Nobody wants to be the person who raises the alarm, especially if overtime is seen as dedication. **It's gradual.** Crunch doesn't start with 80-hour weeks. It starts with an extra hour here, a weekend push there. By the time it's obviously excessive, the pattern has been established for months. **It's disguised as engagement.** A developer working late on a feature they're passionate about looks identical to a developer working late because the deadline is impossible. From the outside, both appear "committed." **There are no objective measurements.** Without data, the difference between healthy dedication and unsustainable overwork is a judgment call. And that judgment call is influenced by the pressure to ship. ## The Data That Reveals Crunch ### IDE Activity Patterns PanDev Metrics' IDE heartbeat tracking captures when developers are actively working in their development environment. This data reveals patterns that humans miss: **Normal pattern:** Activity concentrated in an 8-9 hour window with a lunch break. Weekends show minimal or no activity. **Early crunch pattern:** The activity window stretches to 10-11 hours. Weekend activity appears occasionally. This is the warning stage — intervention here is easy and effective. **Active crunch pattern:** Activity spans 12+ hours regularly. Weekends show consistent multi-hour sessions. Late night activity (after 10 PM) becomes common. This is already damaging. **Burnout pattern:** After weeks of active crunch, you'll see a paradoxical drop in activity. Developers are at their desks longer but producing less. Focus Time drops while total Activity Time stays high or increases. This is the crisis stage. The key insight: you don't need to monitor individuals (and you shouldn't). Aggregate team-level patterns tell you everything you need to know. ### Focus Time vs. Activity Time Divergence PanDev Metrics tracks both Activity Time (any IDE interaction) and Focus Time (sustained, uninterrupted coding blocks). The relationship between these two metrics tells a powerful story: **Healthy state:** Focus Time is roughly 50-70% of Activity Time. Developers are spending most of their coding time in productive, uninterrupted blocks. **Stress indicator:** Focus Time drops below 40% of Activity Time. Developers are in the IDE more but getting less done. This signals context-switching, interruptions, or fatigue. **Crunch indicator:** Activity Time increases while Focus Time stays flat or drops. The team is working longer hours but not producing proportionally more output. This is the classic crunch trap — more hours, not more results. ### After-Hours and Weekend Activity Track the percentage of IDE activity that occurs outside normal working hours (whatever your studio defines as normal): - **Baseline (healthy):** 5-10% of activity outside working hours - **Warning zone:** 15-25% of activity outside working hours - **Crunch zone:** 25%+ of activity outside working hours More importantly, track the *trend*. A sudden increase from 8% to 20% over two weeks is a clear signal that something changed — likely a deadline squeeze or scope increase. ### Commit Patterns Git activity data adds another dimension: - **Late-night commits** increasing week over week - **Weekend commit frequency** above baseline - **Commit message quality degrading** (shorter messages, less descriptive — a subtle but real indicator of fatigue) - **Larger, less frequent commits** replacing smaller, more frequent ones (developers are staying heads-down for longer stretches to avoid losing context, a sign of feeling behind) ## Building an Early Warning System ### Step 1: Define Your Baseline Every studio is different. A small indie team with flexible hours will have different patterns than a AAA studio with fixed office hours. Don't apply generic standards — measure your own team's normal. Deploy PanDev Metrics IDE plugins across your development team (supports 10+ IDEs including Visual Studio, Rider, VS Code, and JetBrains tools — all common in game development). Collect 4-6 weeks of data during a non-crunch period to establish your baseline. Key baseline metrics: - Average daily Activity Time per team - Average daily Focus Time per team - After-hours activity percentage - Weekend activity percentage - Deployment/build frequency ### Step 2: Set Threshold Alerts Based on your baseline, define three levels: **Green (Normal):** Metrics within one standard deviation of baseline. No action needed. **Yellow (Warning):** Metrics 1-2 standard deviations above baseline. Trigger a conversation with team leads about workload and deadlines. **Red (Alert):** Metrics more than 2 standard deviations above baseline, or after-hours activity exceeding your defined threshold for more than one week. Trigger immediate intervention — scope review, deadline adjustment, or resource reallocation. ### Step 3: Weekly Monitoring Cadence Producers and engineering managers should review crunch indicators weekly: - Team-level Activity Time trends - Focus Time vs. Activity Time ratio - After-hours and weekend activity percentages - Deployment frequency trends (declining frequency during high activity is a bad sign) - DORA metrics trends (rising change failure rate during high activity means quality is suffering) ### Step 4: Intervention Protocols When metrics hit warning levels: 1. **Talk to the team.** Not accusatorially — inquisitively. "We're seeing longer hours across the team. What's driving that?" 2. **Review scope.** Is the current milestone achievable without sustained overtime? If not, cut scope now rather than burning out the team. 3. **Check dependencies.** Often, crunch on one team is caused by delays on another team. Address the root cause, not the symptom. 4. **Adjust the plan.** Move deadlines, add resources, or reduce scope. These are the only three options. "Work harder" is not a plan. ## The Production Pipeline View Game development has a unique production pipeline that makes crunch particularly insidious: ### Pre-Production During pre-production, crunch risk is lower but not zero. Watch for: - Technical directors or lead engineers putting in excessive hours on prototype work - Unrealistic technical scope being committed to without data on actual team capacity Engineering metrics during pre-production establish the team's actual velocity, which makes production planning more realistic. ### Production This is where crunch risk is highest. Key patterns to watch: - **Milestone crunch:** Activity spikes before milestone deadlines, then drops after. This is common and may be manageable if brief, but becomes destructive if every milestone triggers it. - **Escalating baseline:** Average working hours gradually increase over months. Each milestone starts from a higher baseline. This is the boiling frog pattern. - **Bug-fixing crunch:** As the project matures, the bug backlog grows faster than the team can address it. Developers split time between features and bugs, leading to longer hours to keep up. Track DORA metrics during production: - **Deployment frequency** (build frequency in gamedev terms) should be stable or increasing - **Change failure rate** should not spike as the team works faster - **Lead time** should not creep up as more features compete for testing resources ### Alpha/Beta Feature-complete doesn't mean work-complete. Polish, optimization, and bug fixing during alpha/beta can be as crunch-intensive as production if not managed. Watch for: - Sudden increase in after-hours activity as the team pushes for quality - Focus Time dropping as developers context-switch between bug fixes - MTTR increasing as the codebase becomes more complex ### Gold/Release The final push to release is the most common crunch period. Metrics should show: - Activity Time returning to baseline (not spiking further) - Focus Time maintained (quality of work, not just quantity) - Change failure rate declining (stability improving, not degrading) If metrics show the opposite, the release date may need to move. ## Using Metrics to Prevent Crunch (Not Just Detect It) Detection is only half the value. Metrics also enable prevention: ### Capacity-Based Planning If your team averages 5 hours of Activity Time per day (a healthy, sustainable number), and your builds take 200 developer-hours per milestone, you need the team for 40 developer-days. Don't plan for 8 hours of productive work per day. Use your actual, measured Activity Time as the basis for planning. This single change eliminates the most common source of crunch: unrealistic plans. ### Scope Negotiation With Data When a producer asks for more features, you can show the data: "Our team's sustainable capacity is X. The current scope already fills that capacity through the milestone. Adding features either means cutting something else or extending the timeline." This is far more effective than subjective arguments about workload. ### Technical Debt Budgeting Track what percentage of team activity goes to maintenance, bug fixes, and technical debt versus new feature development. If this ratio is shifting toward maintenance, the team's effective capacity for new work is declining. Address technical debt proactively rather than letting it accumulate until the team can't move fast enough, triggering crunch to compensate. ### Team Health Dashboards Make crunch indicators visible to the entire leadership team, not just engineering management: - Activity Time trends - After-hours activity percentages - Focus Time ratios - Deployment frequency and change failure rate When everyone can see the data, the conversation shifts from "can we add this feature?" to "can we add this feature sustainably?" ## The Business Case Against Crunch For studios where leadership needs convincing, engineering metrics provide the business case: **Crunch doesn't increase output proportionally.** Research and production data consistently show that after 2-3 weeks of extended hours, Focus Time (productive output) declines even as Activity Time (hours in the IDE) increases. This aligns with findings from the IGDA's Quality of Life surveys — studios that enforced sustainable hours reported comparable or better output over a full production cycle than studios that relied on crunch. **Quality degrades under crunch.** Track change failure rate during crunch periods versus normal periods. The data will show that quality drops, which means more bug-fixing work later — a vicious cycle. **Attrition is expensive.** A developer who quits due to burnout costs ~$50K-$150K in recruitment, onboarding, and lost institutional knowledge. The IGDA Developer Satisfaction Survey reports that ~50% of developers who leave the industry cite crunch as a primary reason. Engineering metrics can help you retain your team by preventing the conditions that drive them away. **Sustainable velocity is higher.** Teams that maintain healthy work patterns consistently outperform teams that cycle between crunch and recovery when measured over quarters and years. ## Privacy and Trust Considerations This is the most important section. Crunch detection metrics will backfire if the team perceives them as surveillance. **Do:** - Use team-level aggregates, not individual data, for crunch monitoring - Be transparent about what's being measured and why - Frame metrics as protection for the team ("we're tracking this to prevent crunch") - Let developers see their own data - Use metrics to argue *for* the team (scope reduction, deadline extension) **Don't:** - Use individual activity data for performance reviews - Share individual-level crunch data with producers or leadership - Frame high activity as positive ("look how committed the team is!") - Punish teams for low Activity Time during healthy periods PanDev Metrics supports multi-tenancy and role-based access, so you can ensure the right people see the right level of detail. ## Getting Started 1. Deploy PanDev Metrics IDE plugins to your development team 2. Connect your Git platform (GitLab, GitHub, Bitbucket, Azure DevOps) 3. Collect 4-6 weeks of baseline data 4. Define your green/yellow/red thresholds 5. Establish weekly review cadence with production leads 6. Create intervention protocols for each threshold level The game industry doesn't have to accept crunch as inevitable. With the right data, you can see it coming and prevent it — protecting your team, your project, and your studio. --- **Ready to build a healthier game studio?** [PanDev Metrics](https://pandev-metrics.com) — engineering intelligence that protects your team while delivering your game. --- ## GovTech: Development Transparency for Government Clients URL: https://pandev-metrics.com/docs/blog/govtech-development-transparency-government-clients Date: 2025-12-01 Tags: govtech, transparency, engineering-metrics, compliance, government Description: How GovTech companies use engineering metrics to provide development transparency and build trust with government clients. Government clients don't just buy software — they buy accountability. Unlike enterprise B2B deals where a handshake and a Jira board might suffice, government contracts demand documented evidence of progress, process compliance, and resource utilization. The NIST Cybersecurity Framework and FedRAMP authorization process set the bar for what "documented" means — and it's high. For GovTech companies, this creates a unique challenge: how do you provide genuine transparency without drowning your engineering team in reporting overhead? Engineering metrics, collected automatically, are the answer. ![Role-based access control panel — audit-ready permission management](https://pandev-metrics.com/img/blog/admin-panel-detail.png) *Role-based access control panel — audit-ready permission management.* ## The GovTech Transparency Problem Government clients operate under public scrutiny. Every dollar spent on software development can be questioned by oversight bodies, auditors, or the public. This creates a fundamentally different dynamic than private-sector B2B: **Government clients need to prove due diligence.** They need documentation that shows they selected the right vendor, that the vendor delivered what was promised, and that taxpayer money was spent effectively. **Progress must be demonstrable, not anecdotal.** "The team is making good progress" doesn't satisfy a government project manager who needs to report to an oversight committee. They need quantifiable evidence. **Process compliance is contractual.** Many government contracts specify development processes, security practices, and reporting requirements aligned with NIST SP 800-53 controls and the Risk Management Framework (RMF). Failure to comply isn't just a problem — it's a breach of contract. **Timelines are political.** Government software projects often tie to legislative deadlines, fiscal year boundaries, or political commitments. Missed deadlines aren't just business problems — they're public embarrassments. ## What Government Clients Actually Want to See Having worked with GovTech companies that serve government clients across multiple jurisdictions, we've identified the key information categories that government stakeholders demand: ### 1. Development Activity Evidence Government clients want proof that development is actively happening. This sounds basic, but it's a real concern — there are plenty of cases where vendors took months of payments while making minimal progress. Engineering metrics provide automatic evidence: - **Deployment frequency** shows regular, consistent delivery of new code - **IDE Activity Time** aggregated at the team level demonstrates active development effort - **Commit frequency and patterns** show consistent work across the reporting period - **Build and CI/CD pipeline activity** shows a healthy, active development process PanDev Metrics captures all of this automatically through Git platform integrations (GitLab, GitHub, Bitbucket, Azure DevOps) and IDE heartbeat tracking. ### 2. Progress Against Milestones Government contracts are typically milestone-based. Engineering metrics help you demonstrate progress objectively: - **Lead time for changes** shows how quickly work moves from development to delivery - **Deployment frequency trends** show whether the team is accelerating, stable, or slowing down - **Feature completion rates** correlated with project tracking data from Jira or ClickUp Instead of subjective status updates ("Feature X is 70% complete"), you can show concrete data: "15 of 22 planned endpoints are deployed and tested. Lead time for the remaining endpoints averages 4 days. We're on track for the milestone." ### 3. Quality Assurance Evidence Government software often handles sensitive data — citizen information, financial records, health data. Quality isn't optional. - **Change failure rate** demonstrates that your deployment process catches issues before they reach production - **MTTR (Mean Time to Recovery)** shows that when issues do occur, they're resolved quickly - **Test coverage trends** (correlated with deployment data) show ongoing quality investment ### 4. Resource Utilization Government contracts often specify staffing levels or require reporting on how resources are allocated. Engineering metrics provide: - **Activity distribution** showing time spent on different project components - **Focus Time metrics** demonstrating productive utilization of development resources - **Financial analytics** connecting engineering effort to budget line items PanDev Metrics' financial analytics features are particularly valuable here — they help you demonstrate that engineering resources are being utilized efficiently and allocated appropriately. ### 5. Security and Compliance Practices Government clients expect evidence of secure development practices: - **Code review metrics** showing that all code goes through mandatory review - **Deployment pipeline data** demonstrating that security scanning is part of the process - **Lead time breakdown** showing that security gates are respected, not bypassed ## Building Automated Transparency Reports The key to sustainable transparency is automation. If your team spends 20 hours per month preparing reports for government clients, that's 20 hours not spent building software. ### The Weekly Development Report Automate a weekly report that pulls directly from PanDev Metrics: **Development Activity:** - Total deployments this week: [number] - Deployment frequency trend: [increasing/stable/decreasing] - Active developers: [number] - Total Activity Time: [hours] **Quality:** - Change failure rate: [percentage] - Open issues by severity: [breakdown] - Issues resolved this week: [number] **Progress:** - Features completed: [list] - Features in progress: [list with estimated completion based on lead time data] - Blockers: [any identified blockers] This report can be generated automatically — no manual data collection needed. ### The Monthly Progress Review Monthly reports for government stakeholders should include: **Milestone Progress:** - Current milestone: [name] - Planned completion: [date] - Actual progress: [percentage based on completed vs. planned work items] - Delivery forecast: [based on current lead time and deployment frequency] **Team Metrics:** - Average deployment frequency: [per week] - Average lead time: [hours/days] - Change failure rate: [percentage] - MTTR: [hours] **Resource Utilization:** - Activity distribution by project component - Focus Time averages - Financial summary (if required by contract) **Trends:** - Month-over-month comparison of key metrics - Identified improvements and their impact - Risks and mitigation plans ### The Quarterly Audit Package For contracts requiring quarterly audits: - Complete deployment history with timestamps - Code review records showing compliance with review policies - Security scanning results summary - Incident log with resolution times - Compliance checklist with evidence links - Financial reconciliation of engineering resources ## On-Premise Deployment: A Government Requirement Many government contracts require that development tools and data remain within approved infrastructure. PanDev Metrics supports full on-premise deployment, which means: - **No data leaves your network.** Engineering metrics, activity data, and reports all stay within your infrastructure or your government client's infrastructure. - **Compliance with data sovereignty requirements.** Data can be stored in the jurisdiction required by the contract. - **Integration with government authentication.** LDAP/SSO support means the tool fits into existing government identity management systems. - **Air-gapped environments.** For high-security contracts, PanDev Metrics can operate in environments without external network access. This is a critical differentiator. FedRAMP authorization and equivalent national frameworks often require that tools processing government data meet specific deployment and data residency standards. Many engineering analytics tools are SaaS-only, which automatically disqualifies them from most government contracts. ## Handling the "Surveillance" Perception Government clients want transparency. Your engineering team wants autonomy. These can conflict. The solution: be transparent about transparency. **With your team:** - Explain that metrics are collected for client reporting, not individual performance tracking - Use team-level aggregates in all client-facing reports - Let developers see their own data - Never use activity metrics in performance reviews **With your government client:** - Set expectations about what metrics mean (and don't mean) - Explain that Activity Time is not the same as "hours worked" - Frame metrics as process quality indicators, not productivity scores - Educate stakeholders that lower activity during some periods is normal (architecture planning, design, learning) ## GovTech-Specific Metric Considerations ### Multi-Vendor Environments Government projects often involve multiple vendors. Engineering metrics help you demonstrate your team's contribution clearly and avoid blame when other vendors cause delays. Track lead time carefully: if your team's internal lead time is 3 days but the end-to-end delivery takes 3 weeks, the data shows exactly where the delay occurs. ### Security-Cleared Environments For projects requiring security clearance, engineering metrics need to operate within classified networks. PanDev Metrics' on-premise deployment supports this — the tool runs entirely within the approved environment. ### Accessibility and Standards Compliance Government software must typically meet accessibility standards (WCAG 2.1 AA, Section 508 in the US, EN 301 549 in the EU). Government digital transformation reports, including the UK Government Digital Service playbook and the US Digital Services Playbook, emphasize that accessibility is a first-class requirement, not an afterthought. Track the percentage of development activity going toward accessibility compliance to demonstrate ongoing commitment, not just a checkbox exercise. ### Legacy Integration Government projects frequently require integration with legacy systems. Engineering metrics help you show the cost and complexity of these integrations: - Lead time for changes involving legacy integration vs. new development - Change failure rate for legacy-touching code vs. new code - Activity distribution showing time spent on integration vs. core development This data helps justify timelines and budgets that might otherwise seem excessive to government stakeholders who don't understand the technical complexity. ## Case Example: Structuring Transparency for a Government Contract Here's how a typical GovTech engagement might structure engineering transparency: **Phase 1: Contract Start (Month 1)** - Deploy PanDev Metrics within approved infrastructure (on-premise) - Connect Git platform and project tracking tools - Deploy IDE plugins to the development team - Establish baseline metrics - Agree on reporting format and cadence with the government client **Phase 2: Active Development (Months 2-12+)** - Automated weekly reports delivered to the government project manager - Monthly progress reviews with stakeholder presentation - Quarterly audit packages for oversight bodies - Real-time dashboard access for designated government representatives (read-only) **Phase 3: Delivery and Transition** - Complete metrics history available for post-project review - Documentation of all process improvements driven by metrics - Final audit package with full project metrics ## The Competitive Advantage In GovTech procurement, transparency is a differentiator. When two vendors bid on a government contract, the one that can demonstrate: - Automated progress reporting - Objective quality metrics - Resource utilization evidence - Compliance-ready audit trails ...wins the trust of government evaluators who have been burned by opaque vendors before. Including engineering metrics capability in your proposal signals maturity, accountability, and confidence. You're not just promising transparency — you're showing the mechanism for delivering it. ## Getting Started If you're a GovTech company looking to strengthen your transparency offering: 1. **Evaluate on-premise deployment requirements** for your target government contracts 2. **Deploy PanDev Metrics** within your development infrastructure 3. **Establish baseline metrics** before your next contract begins 4. **Build report templates** that align with common government reporting requirements 5. **Include metrics capability** in your next proposal as a transparency differentiator Government clients deserve genuine transparency, and your engineering team deserves to provide it without drowning in manual reporting. Automated engineering metrics deliver both. --- **Building software for government clients?** [PanDev Metrics](https://pandev-metrics.com) — on-premise engineering intelligence that delivers the transparency government contracts demand. --- ## MedTech: Engineering Metrics in a Regulated Environment URL: https://pandev-metrics.com/docs/blog/medtech-engineering-metrics-regulated-environment Date: 2025-11-28 Tags: medtech, healthcare, regulated-environment, engineering-metrics, compliance Description: How MedTech CTOs use engineering metrics to navigate FDA, HIPAA, and IEC 62304 requirements while maintaining development velocity. MedTech software development operates under a level of regulatory scrutiny that most industries never experience. FDA 21 CFR Part 11, IEC 62304, HIPAA, MDR in Europe — these aren't guidelines you can selectively follow. They're legally binding requirements where non-compliance can result in product recalls, criminal liability, and patients being harmed. The FDA's Software Validation Guidelines emphasize that software used in medical devices must be developed under documented, repeatable processes with full traceability. For MedTech CTOs, the challenge is building software that saves lives while satisfying regulators that your process is rigorous enough to trust. Engineering metrics make this possible without turning your development process into a bureaucratic standstill. ![LDAP/AD integration with enterprise security — critical for healthcare compliance](https://pandev-metrics.com/img/blog/settings-ldap.png) *LDAP/AD integration with enterprise security — critical for healthcare compliance.* ## The Regulatory Landscape for MedTech Software Before diving into metrics, let's establish what MedTech engineering teams are actually dealing with: ### IEC 62304: Software Life Cycle Processes IEC 62304 is the international standard for medical device software development. It requires: - **Documented software development plans** with defined processes - **Risk management** integrated throughout the development lifecycle - **Traceability** from requirements to implementation to testing - **Configuration management** with version control and change tracking - **Verification and validation** at each lifecycle stage The standard classifies software by safety level (Class A, B, or C), with increasing rigor requirements for higher-risk software. ### FDA 21 CFR Part 11: Electronic Records For MedTech companies operating in the US: - **Audit trails** for all electronic records used in development - **Access controls** ensuring only authorized personnel can make changes - **Electronic signatures** that are legally binding - **System validation** demonstrating that tools used in development are fit for purpose ### HIPAA: Protected Health Information If your software touches patient data (and under HIPAA, the definition is broad — covering ~18 categories of identifiers): - **Technical safeguards** protecting data in development and testing environments - **Access controls** limiting who can see patient data - **Audit logs** tracking all access to protected health information - **Breach notification** requirements with defined timelines (60 days for breaches affecting 500+ individuals) ### MDR/IVDR (European Union) The EU Medical Device Regulation adds: - **Post-market surveillance** requirements that extend into software maintenance - **Clinical evaluation** integration with development processes - **Unique Device Identification** affecting configuration management ## Why Traditional Metrics Fall Short in MedTech Most engineering metrics frameworks were designed for SaaS companies that deploy continuously and iterate rapidly. MedTech is fundamentally different: **Deployment is not continuous.** Medical device software goes through formal release processes, regulatory submissions, and sometimes clinical validation before reaching users. "Deploy 10 times a day" isn't just impractical — it's potentially illegal for certain device classes. **Speed is not the primary goal.** While efficiency matters, the primary objective is producing software that is safe, effective, and compliant. Metrics that optimize for speed at the expense of rigor are counterproductive. **Every change has regulatory implications.** A "minor bug fix" in a SaaS product is a routine deployment. In MedTech, the same fix might trigger a risk assessment, design review, and regulatory filing. **Traceability is mandatory, not optional.** Standard DORA metrics don't capture whether requirements are traceable to tests, whether risk assessments are current, or whether change control procedures were followed. ## The MedTech Engineering Metrics Framework ### 1. Controlled Deployment Frequency In MedTech, deployment frequency means something different. Track it at two levels: **Internal build frequency:** How often the team produces testable builds for internal verification and validation. This should be high — daily or multiple times daily. Frequent internal builds enable early testing and fast feedback loops. **Formal release frequency:** How often you submit new versions through your regulatory release process. This will be lower and is driven by your regulatory strategy, not engineering capability. The gap between these two numbers tells you something important. If internal builds happen daily but formal releases happen quarterly, your regulatory process might be a bottleneck. If internal builds are also infrequent, the problem is in your development process. PanDev Metrics tracks build and deployment activity across your Git platforms, letting you see both levels clearly. ### 2. Lead Time With Regulatory Gates MedTech lead time includes gates that don't exist in other industries: - **Development** — coding, unit testing, code review - **Risk assessment** — does this change affect the risk profile? - **Design review** — formal review of the change against design requirements - **Verification** — does the software meet its specifications? - **Validation** — does the software meet user needs in the intended environment? - **Regulatory review** — does the change require a filing or notification? Measure time spent at each gate. If design reviews take 2 weeks because reviewers are overloaded, that's actionable. If regulatory review takes 3 weeks because submissions are complex, that might be inherent to the process — or it might indicate that your regulatory team needs better tooling. ### 3. Change Control Compliance Rate Every change to medical device software should go through your change control process. Track: - **Percentage of changes with complete documentation:** Requirements traceability, risk assessment, test coverage - **Percentage of changes with proper approvals:** The right people reviewed and approved - **Percentage of changes with verification evidence:** Tests were executed and results documented A compliance rate below 100% for released software is a regulatory finding waiting to happen. For internal builds, it might be acceptable during early development, but should approach 100% as you near release. ### 4. Defect Metrics With Safety Classification Not all bugs are equal in MedTech. Track defects by safety impact: - **Safety-critical defects:** Could lead to patient harm - **Safety-relevant defects:** Affect safety mitigations or controls - **Non-safety defects:** Functional issues without safety implications Metrics to track: - **Defect discovery rate** by phase (earlier is better) - **Defect resolution time** by safety classification (safety-critical defects should be resolved fastest) - **Defect escape rate** — defects found after formal release (this should trend toward zero for safety-critical defects) ### 5. Development Activity and Traceability PanDev Metrics' IDE heartbeat tracking provides activity data that supports regulatory requirements: - **Activity distribution** showing time spent on development, testing, documentation, and review — supporting resource allocation evidence - **Focus Time** metrics helping you optimize developer productivity within regulatory constraints - **Project-level activity** showing which software components are actively being worked on This data, combined with Git activity from your repository platform, creates a comprehensive picture of development activity that supports IEC 62304 lifecycle process documentation. ## Practical Implementation for MedTech Teams ### Infrastructure Requirements MedTech companies handling patient data or developing regulated software need: - **On-premise deployment:** PanDev Metrics supports full on-premise installation, keeping all engineering data within your validated infrastructure - **Access controls:** LDAP/SSO integration ensures that metrics access aligns with your access control policies - **Audit trails:** All tool access and data views are logged, supporting 21 CFR Part 11 requirements - **Validation:** The tool should be validated as part of your computer system validation program ### Connecting to Your Development Stack PanDev Metrics integrates with the platforms commonly used in MedTech: - **Git platforms:** GitLab (particularly popular in regulated industries for its built-in compliance features), GitHub, Bitbucket, Azure DevOps - **Project tracking:** Jira (widely used in MedTech for traceability), ClickUp - **IDEs:** 10+ plugins covering all major development environments ### Team Structure Considerations MedTech teams often include roles not found in typical software companies: - **Regulatory affairs specialists** who need visibility into development progress - **Quality assurance engineers** (distinct from QA testers) who need process compliance data - **Clinical specialists** who need to understand software changes in clinical context - **Risk management professionals** who need to assess every change PanDev Metrics' multi-tenancy and role-based access ensure each role sees the data relevant to their function without being overwhelmed by engineering details. ## Balancing Rigor and Velocity The common misconception in MedTech is that regulatory compliance necessarily means slow development. Engineering metrics challenge this by making inefficiency visible: ### Finding Process Waste When you measure lead time by phase, you often discover that: - **Actual development time** is a small fraction of total lead time - **Waiting time** (for reviews, approvals, environment access) dominates - **Rework** from late-stage findings could be prevented with earlier reviews This data helps you streamline processes without reducing rigor. The goal isn't to skip steps — it's to execute them efficiently. ### Automating Where Possible Metrics reveal which manual processes are candidates for automation: - If code review takes 3 days but the actual review takes 2 hours, the problem is queue time — automate review assignments and reminders - If verification testing is manual and takes weeks, invest in test automation for regression testing - If documentation is always the last step and always delays release, integrate documentation requirements into the development workflow ### Right-Sizing Rigor by Risk Level IEC 62304 intentionally defines different rigor levels for different safety classes. Use engineering metrics to verify that you're applying the right level: - **Class C (highest risk):** Full documentation, formal reviews, comprehensive testing — metrics should show thorough coverage - **Class B (medium risk):** Documented processes with appropriate review — metrics should show consistent compliance - **Class A (lowest risk):** Basic documentation — metrics should show the process is followed but overhead is minimized If your Class A software is going through the same rigorous process as your Class C software, you're spending engineering time on unnecessary overhead. ## Regulatory Audit Preparation Engineering metrics transform audit preparation from a months-long scramble to a routine activity: **For IEC 62304 audits:** - Development process documentation supported by activity data - Configuration management evidence from Git platform metrics - Verification and validation evidence linked to deployment data - Lifecycle process compliance demonstrated through metrics trends **For FDA inspections:** - Audit trails from tool access logs - Change control evidence from deployment and review metrics - CAPA (Corrective and Preventive Action) effectiveness demonstrated through defect trend metrics **For ISO 13485 quality system audits:** - Process performance metrics demonstrating continuous improvement - Resource allocation evidence from activity distribution data - Management review data from metrics dashboards ## The Cost of Non-Compliance MedTech companies that fail to maintain adequate development documentation and process evidence face: - **FDA warning letters** that can halt product distribution (the FDA issues ~hundreds of warning letters annually, many citing 21 CFR Part 11 failures) - **Product recalls** requiring field corrections - **Criminal liability** for responsible individuals in severe cases - **Loss of CE marking** in Europe under the MDR, preventing EU sales - **Customer trust erosion** that damages long-term business — in healthcare, trust is literally a matter of patient safety Engineering metrics are not just a productivity tool in MedTech — they're a risk management strategy. ## Getting Started For MedTech CTOs looking to implement engineering metrics: 1. **Start with on-premise deployment** — deploy PanDev Metrics within your validated infrastructure 2. **Connect your Git platform** — this provides immediate visibility into deployment and change patterns 3. **Deploy IDE plugins** — start collecting activity data for development effort visibility 4. **Map regulatory gates** — identify each stage in your development process and measure time at each stage 5. **Establish baselines** — collect 4-6 weeks of data before setting improvement targets 6. **Include quality and regulatory teams** — share relevant metrics with QA, RA, and risk management stakeholders 7. **Integrate with your QMS** — use metrics data to support quality management system requirements The regulated environment doesn't have to mean slow development. It means rigorous development — and engineering metrics help you be rigorous and efficient at the same time. --- **Building medical device software?** [PanDev Metrics](https://pandev-metrics.com) — on-premise engineering intelligence for regulated environments, with LDAP/SSO, audit trails, and compliance-ready reporting. --- ## Digital Agency: Utilization and Multi-Project Metrics URL: https://pandev-metrics.com/docs/blog/digital-agency-utilization-multi-project-metrics Date: 2025-11-25 Tags: digital-agency, utilization, multi-project, engineering-metrics, financial-analytics Description: How digital agency CEOs use engineering metrics to optimize developer utilization, manage multi-project workloads, and improve profitability. Digital agency CEOs live and die by utilization rates. According to SoDA (Society of Digital Agencies) benchmarks, the target billable utilization for development teams is ~75-85% — and most agencies fall short. Every hour a developer spends on non-billable work is lost revenue. Every project that goes over budget eats into margins. And with 5, 10, or 20 client projects running simultaneously, knowing where everyone's time actually goes is nearly impossible. Most agencies rely on manual time tracking. Developers fill in timesheets at the end of the week, guessing how many hours went to each project. The data is inaccurate, the process is hated, and the resulting numbers drive decisions worth hundreds of thousands of dollars. There's a better way. ![Multi-project time tracking — essential for agency utilization calculations](https://pandev-metrics.com/img/blog/projects.png) *Multi-project time tracking — essential for agency utilization calculations.* ## The Agency Metrics Problem Digital agencies face a unique combination of challenges that other software companies don't: ### Multiple Simultaneous Projects A SaaS company has one product. An agency might have 15 active projects across different clients, technologies, and team compositions. Each project needs its own metrics, but you also need an agency-wide view. ### Billable vs. Non-Billable Work The fundamental agency metric is utilization: what percentage of available engineering time is billable? But calculating this accurately requires knowing what developers are actually working on — not what they say they're working on. ### Fixed-Price vs. Time-and-Materials Fixed-price projects need tight scope management and early warning when hours are exceeding estimates. Time-and-materials projects need accurate tracking to justify invoices and maintain client trust. ### Context-Switching Tax Developers working across multiple projects pay a context-switching tax that's real but invisible. A developer on three projects doesn't deliver 33% to each — they might deliver 25% to each (or less), with the remaining time lost to context-switching. ### Client Reporting Clients want to see what they're paying for. Agencies need to produce reports that demonstrate progress and justify costs — ideally without spending hours preparing them. ## Engineering Metrics for Agency Profitability ### Utilization Rate: The Metric That Pays the Bills Utilization rate = billable hours / available hours. Simple in theory, but accurate measurement requires knowing what developers are actually doing. **Manual time tracking problems:** - Developers estimate time entries at week's end (inaccurate) - Context-switching between projects makes allocation guessing harder - Small tasks (quick bug fix for Client A while working on Client B) go untracked - Internal projects, learning time, and meetings get underreported **IDE heartbeat tracking solves this.** PanDev Metrics captures activity automatically, tied to the repository or project the developer is working on. If your developer switches from Client A's repo to Client B's repo, the system records it. No timesheets, no guessing. This gives you an accurate picture of: - How many hours each developer is actually coding per day (Activity Time) - How that time splits across projects - How much time goes to non-project work (internal tools, learning, meetings, etc.) ### Project-Level Metrics For each client project, track: **Deployment Frequency:** How often is the team shipping to the client's environments? High deployment frequency indicates healthy project momentum. Sudden drops signal blockers. **Lead Time for Changes:** How long does it take from code to delivery? In agency work, this often includes client review and approval stages that can dominate the timeline. **Change Failure Rate:** Are deployments causing issues? A high rate means you're spending billable hours on rework, which destroys margins on fixed-price projects. **Activity Distribution:** What's the split between feature development, bug fixes, and maintenance? If a project that's supposed to be in "active development" is spending 50% of time on bug fixes, the original code quality was poor and the project economics are deteriorating. PanDev Metrics tracks all of these across your Git platforms (GitLab, GitHub, Bitbucket, Azure DevOps) and project tracking tools (Jira, ClickUp). ### Financial Analytics: Understanding True Project Profitability Revenue per project is easy to calculate. True profitability requires understanding the actual engineering cost, which requires accurate time allocation. PanDev Metrics' financial analytics connect engineering activity to project costs: - **Actual hours per project** based on IDE activity data, not timesheets - **Cost per project** based on team member rates and actual time allocation - **Margin analysis** comparing actual engineering cost to project revenue - **Trend analysis** showing whether project profitability is improving or declining This data often reveals uncomfortable truths: - The "profitable" project is actually underwater because developers spend more time on it than the estimates assumed - The "small client" project is actually your highest-margin engagement - Internal projects consume more engineering time than anyone realized ### Multi-Project Developer Efficiency Developers working on multiple projects simultaneously are less efficient per-project than dedicated developers. But the economic reality of agency work often requires multi-project allocation. Track the impact: **Focus Time per project:** PanDev Metrics shows uninterrupted coding blocks per project. If a developer working on three projects never gets more than 30 minutes of Focus Time on any single project, they're spending most of their time regaining context. **Context-switching frequency:** How often do developers switch between project repositories? More than 3-4 switches per day indicates excessive multi-tasking. **Optimal project load:** Track developer efficiency (Focus Time / Activity Time) against number of simultaneous projects. Most agencies find that 2 projects is manageable, 3 projects reduces efficiency significantly, and 4+ projects is counterproductive. Use this data to make allocation decisions: sometimes dedicating a developer full-time to one project for two weeks is more productive than splitting them across three projects for four weeks. ## Building the Agency Dashboard ### CEO/Management View **Overall Utilization:** - Agency-wide utilization rate (SoDA benchmarks suggest ~75-85% as optimal for developers) - Utilization by team/department - Utilization trend (weekly/monthly) **Project Portfolio:** - Active projects with status indicators (on track, at risk, over budget) - Revenue vs. actual engineering cost per project - Projects ranked by profitability **Capacity:** - Available developer hours vs. committed hours - Upcoming capacity gaps or surplus - Pipeline projects and required capacity ### Project Manager View **Per-Project Metrics:** - Deployment frequency and lead time - Activity Time allocated to the project - Change failure rate - Progress against milestones (integrated with Jira/ClickUp) **Team Allocation:** - Which developers are assigned and their actual activity on the project - Focus Time per developer on this project - Potential context-switching issues ### Developer View **Personal Metrics:** - Activity distribution across projects - Focus Time trends - Deployment and commit activity Developers should see their own data — it helps them understand their own patterns and advocate for better project allocation. ## Client Reporting: Automated Transparency Agency clients want to know what they're paying for. Engineering metrics automate this reporting: ### For Time-and-Materials Clients Automated reports showing: - Development activity hours attributed to their project - Deployments delivered - Features completed (from Jira/ClickUp integration) - Quality metrics (change failure rate, bug counts) This is far more credible than a spreadsheet of logged hours. Clients can see that work is actually happening, correlated with tangible deliverables. ### For Fixed-Price Clients Progress-oriented reports: - Milestone completion status - Deployment frequency showing consistent delivery - Remaining work estimate based on current velocity - Quality metrics demonstrating professional delivery ### For Retainer Clients Activity and value reports: - Hours of development activity during the retainer period - Changes deployed - Issues resolved - Improvements delivered These reports take minutes to generate from PanDev Metrics dashboards instead of hours of manual compilation. ## Optimizing Agency Operations ### Improving Utilization Without Burning Out Developers The temptation is to push utilization as high as possible. But engineering metrics reveal the diminishing returns: - **At ~70-75% utilization:** Developers have time for learning, internal tools, and non-project work that keeps them effective. SoDA benchmarks confirm this as the sustainable floor for quality agencies. - **At ~80-85% utilization:** Efficiency starts to decline. Developers rush through tasks, skip documentation, and accumulate technical debt. This is the ceiling that top agencies treat as a hard limit. - **At 90%+ utilization:** Quality drops significantly. Change failure rates increase. Developers burn out and leave. The cost of replacing them far exceeds the revenue from those extra billable hours. Track the relationship between utilization and quality metrics (change failure rate, bug counts) to find your agency's optimal utilization rate. ### Right-Sizing Project Teams Engineering metrics help you decide team composition: - If a project's deployment frequency is declining despite full allocation, the team might be too large (coordination overhead) or too small (blocked on dependencies) - If lead time is long but Activity Time is low, the bottleneck is outside the development team (client approvals, design handoffs, infrastructure) - If Focus Time is low across the project team, there are too many meetings or too much context-switching ### Pricing Future Projects More Accurately Historical engineering metrics make estimation dramatically better: - **Average cost per feature type** based on actual data from similar past projects - **Typical change failure rate** for similar technology stacks (budget for rework accordingly) - **Context-switching overhead** when developers will be shared across projects Instead of guessing "this project will take 400 hours," you can say "similar projects averaged 450 hours of developer Activity Time, with 15% spent on bug fixes and 10% on deployment and infrastructure." ### Identifying Unprofitable Patterns Metrics reveal patterns that erode profitability: - **Scope creep:** Activity distribution shifting from planned features to unplanned work - **Maintenance traps:** Projects where bug fixes consume more time than new development - **Client bottlenecks:** Long lead times caused by slow client feedback, not slow development - **Technology mismatches:** Higher change failure rates and longer lead times on unfamiliar technology stacks ## Implementation for Agencies ### Phase 1: Connect and Measure (Week 1-2) 1. Deploy PanDev Metrics and connect your Git platforms 2. Install IDE plugins across your development team (10+ IDEs supported) 3. Connect project tracking (Jira, ClickUp) to correlate activity with projects 4. Start collecting data — no changes to process yet ### Phase 2: Baseline and Insights (Week 3-4) 1. Review utilization data — how does actual utilization compare to what you thought? 2. Analyze project profitability — are your assumptions about profitable vs. unprofitable projects correct? 3. Examine Focus Time — how much context-switching is happening? 4. Share findings with project managers ### Phase 3: Optimize (Month 2+) 1. Adjust project allocations based on Focus Time and context-switching data 2. Set up automated client reports 3. Use financial analytics for project profitability monitoring 4. Establish utilization targets with quality guardrails ### Phase 4: Scale (Ongoing) 1. Use historical metrics for project estimation 2. Build pricing models based on actual cost data 3. Monitor team health alongside utilization 4. Continuously refine allocation strategies ## Multi-Tenancy for Client Isolation Agencies often need to ensure that client data is isolated — Client A shouldn't see metrics or activity related to Client B's project. PanDev Metrics' multi-tenancy support provides this isolation, ensuring that: - Client-facing dashboards show only that client's project data - Internal dashboards aggregate across all projects - Access controls prevent unauthorized cross-client data access ## The Bottom Line For digital agencies, engineering metrics aren't an overhead — they're a profit optimization tool. Accurate utilization tracking, project profitability analysis, and data-driven allocation decisions can improve margins significantly while also improving developer satisfaction (less context-switching, better project assignments) and client satisfaction (transparent reporting, consistent delivery). The agencies that measure their engineering operations outperform those that guess. --- **Running a digital agency?** [PanDev Metrics](https://pandev-metrics.com) — engineering intelligence for multi-project teams, with financial analytics, automated client reporting, and real utilization tracking. --- ## Telecom: Managing Large Engineering Organizations (500+) URL: https://pandev-metrics.com/docs/blog/telecom-managing-large-engineering-organizations Date: 2025-11-21 Tags: telecom, large-organizations, engineering-metrics, dora-metrics, scaling Description: How telecom VPs of Engineering use engineering metrics to manage 500+ developer organizations across multiple teams, sites, and technology stacks. Managing a 500+ developer organization in telecom is like running a small city. You have infrastructure teams maintaining critical network systems, product teams building customer-facing applications, platform teams supporting internal tooling, and integration teams connecting it all together. They span multiple offices, time zones, and sometimes countries. At this scale, you can't rely on tribal knowledge, weekly syncs, or management intuition. You need data. Engineering metrics provide the systematic visibility that makes large-scale engineering management possible. ![Department structure view for managing large engineering organizations](https://pandev-metrics.com/img/blog/dashboard-departments.png) *Department structure view for managing large engineering organizations.* ## The Unique Challenges of Telecom Engineering at Scale Telecom engineering organizations face challenges that are rare in other industries. The TM Forum's Open Digital Architecture framework recognizes this complexity and provides a reference model, but translating it into practical engineering management requires data. ### Critical Infrastructure With Zero Tolerance for Downtime Telecom systems carry emergency calls, enable financial transactions, and support critical government communications. Downtime isn't measured in lost revenue alone — it's measured in regulatory penalties, contractual SLA violations, and potential safety impact. This creates extreme tension: you need to innovate (5G rollout per 3GPP Release 18 timelines, edge computing, IoT platforms), but you can't risk destabilizing production systems. ### Legacy and Modern Systems Coexisting A typical telecom engineering organization maintains: - **Legacy systems** (10-20+ years old) — billing platforms, provisioning systems, network management - **Transitional systems** — legacy systems being modernized or replaced - **Modern platforms** — cloud-native services, APIs, customer apps - **Embedded systems** — network equipment firmware, edge devices Each category requires different engineering practices, different deployment cadences, and different metrics expectations. ### Multi-Site, Multi-Team Coordination 500+ developers typically means: - 50+ teams across multiple functional areas - Multiple geographic locations - Different technology stacks and toolchains - Various development methodologies (some teams use agile, others use more formal processes for safety-critical systems) Coordinating across this landscape without engineering metrics is like navigating without a map. ### Regulatory and Compliance Requirements Telecom is heavily regulated. The TM Forum Frameworx and 3GPP standards define not just what you build but how development cycles are structured. Engineering practices must comply with: - Telecommunications standards and certifications - Data privacy regulations (GDPR, the ePrivacy Directive, national telecom privacy laws) - Network security requirements - SLA commitments to business and government customers ## The Metrics Framework for 500+ Engineers ### Tier 1: Organization-Wide Health Indicators At the VP of Engineering level, you need a small set of metrics that tell you whether the overall organization is healthy: **Aggregate Deployment Frequency:** Total deployments across all teams, trended weekly. This is your top-level indicator of organizational throughput. If total deployment frequency is declining while headcount is growing, something systemic is wrong. **Organization-Wide Change Failure Rate:** The percentage of deployments that cause incidents, rolled back, or require hotfixes. This is your quality indicator. In telecom, this metric should be low and stable — any upward trend requires immediate investigation. **Mean Time to Recovery (MTTR) for Critical Services:** Telecom SLAs often require recovery within minutes. Track MTTR for Tier 1 services separately from everything else. **Engineering Activity Distribution:** How is the organization's time split across new development, maintenance, bug fixes, and infrastructure work? In large telecom organizations, maintenance often consumes 50-70% of engineering capacity. If this ratio is increasing, you're accumulating technical debt faster than you're addressing it. PanDev Metrics aggregates these metrics across your entire development organization, pulling from all connected Git platforms and IDE activity data. ### Tier 2: Department-Level Metrics Below the organization level, each department (network engineering, platform engineering, product engineering, etc.) needs its own metrics: **DORA Metrics by Department:** Each department will have different baseline expectations. Network engineering might deploy weekly with very low change failure rates. Product engineering might deploy daily with slightly higher (but still acceptable) failure rates. The key is tracking trends within each department, not comparing across departments with different risk profiles. **Cross-Department Dependency Metrics:** How long do changes that require cross-department coordination take compared to changes within a single department? In large telecom organizations, this ratio is often 5-10x. Reducing it — through better APIs, clearer interfaces, or organizational restructuring — is one of the highest-leverage improvements a VP of Engineering can make. **Capacity Allocation:** How is each department allocating engineering effort? This is critical for portfolio management: - Is the network team spending enough time on 5G initiatives? - Is the platform team investing in developer experience for the rest of the organization? - Is the product team managing technical debt alongside feature delivery? ### Tier 3: Team-Level Metrics Individual teams (5-10 engineers) need granular metrics: **Team DORA Metrics:** Deployment frequency, lead time, change failure rate, and MTTR specific to the team's services. These are the metrics team leads use for continuous improvement. **Focus Time:** Large organizations are notorious for meeting overload. PanDev Metrics' IDE heartbeat tracking shows how much uninterrupted coding time developers actually get. If your organization's average Focus Time is under 2 hours per day, your meeting culture is your biggest productivity problem — not tools, processes, or technical debt. **Activity Time Distribution:** At the team level, understanding the split between feature work, bug fixes, maintenance, and code review helps team leads manage their backlog and communicate capacity to stakeholders. **Code Review Metrics:** In large organizations, code review bottlenecks are common. Track review wait time, review throughput, and review quality (measured by whether reviewed code has a lower change failure rate). ## Implementing Metrics at Scale ### The Infrastructure Challenge At 500+ developers, metrics infrastructure itself becomes a significant consideration: **On-Premise Deployment:** Telecom companies handle sensitive network data and customer information. PanDev Metrics supports full on-premise deployment, ensuring engineering data stays within your corporate infrastructure. **LDAP/SSO Integration:** With 500+ developers, manual user management is impractical. PanDev Metrics integrates with LDAP and SSO systems, automatically syncing team structures and access controls. **Multi-Tenancy:** Different departments, business units, or subsidiaries may need isolated views of their engineering data while leadership sees the aggregate. PanDev Metrics' multi-tenancy support handles this natively. **Git Platform Coverage:** Large telecom organizations often use multiple Git platforms — GitLab for some teams, GitHub for others, Bitbucket for legacy projects, Azure DevOps for teams that migrated from TFS. PanDev Metrics integrates with all four, providing a unified view regardless of which platform each team uses. **IDE Coverage:** Similarly, different teams use different IDEs. Network engineers might use Eclipse or specialized tools. Web developers use VS Code. Mobile developers use Android Studio or Xcode. PanDev Metrics supports 10+ IDEs, ensuring coverage across your diverse technology landscape. ### The Rollout Strategy Don't try to deploy metrics to 500 developers simultaneously. Use a phased approach: **Phase 1: Pilot (4-6 weeks, 2-3 teams)** - Select teams that are willing and representative of different parts of the organization - Deploy PanDev Metrics, connect Git platforms, install IDE plugins - Collect baseline data - Refine dashboards and reporting based on pilot feedback **Phase 2: Department Rollout (8-12 weeks, 1-2 departments)** - Extend to all teams within selected departments - Establish department-level dashboards - Train team leads on metrics interpretation - Begin weekly metrics review cadence **Phase 3: Organization-Wide (12-16 weeks, all teams)** - Extend to remaining departments - Build organization-wide dashboards for VP/C-level view - Integrate with existing reporting and governance processes - Establish quarterly metrics review cadence for leadership **Phase 4: Optimization (Ongoing)** - Use metrics to identify systemic improvement opportunities - Track improvement initiatives against metrics baselines - Refine metrics and dashboards based on evolving needs ### Change Management Deploying engineering metrics in a large organization is as much a change management challenge as a technical one: **Address the surveillance concern immediately.** In a unionized or works-council environment (common in European telecom), this is especially critical. Be explicit: metrics are for team and organization health, not individual performance evaluation. **Start with teams that want it.** Early adopters will generate success stories that make broader adoption easier. Forced adoption creates resistance. **Show value before asking for compliance.** If the first thing teams see from metrics is criticism, they'll resist. If the first thing they see is "your review wait time is 3 days — here's how to fix it," they'll engage. **Involve team leads in dashboard design.** The people who will use the data daily should have input on what's shown and how. ## Using Metrics to Drive Organizational Decisions ### Build vs. Buy vs. Modernize Large telecom organizations constantly face decisions about legacy systems: do we maintain them, modernize them, or replace them? Engineering metrics inform this decision: - **Maintenance cost:** What percentage of team capacity goes to maintaining the legacy system? - **Change failure rate:** Is the legacy system inherently fragile? - **Lead time:** How long do changes take in the legacy system vs. modern equivalents? - **MTTR:** How quickly can the team recover from incidents in the legacy system? If a legacy system consumes 60% of a team's capacity, has a 15% change failure rate, and a 4-hour MTTR, the business case for modernization writes itself — with data, not opinions. ### Headcount Planning At 500+ developers, every hiring decision matters: - **Are existing engineers productive?** If Focus Time is low across the organization, hiring more engineers won't increase output — reducing meetings will. - **Where is capacity actually needed?** Activity distribution data shows which teams are overloaded (high Activity Time, declining deployment frequency) and which have capacity. - **What's the cost of a new hire?** Financial analytics show the actual cost per deployment, per feature, and per team — helping you justify or challenge headcount requests. ### Vendor and Contractor Management Telecom organizations often use significant contractor workforces. Engineering metrics provide objective assessment of contractor team performance: - Are contractor teams deploying at the same frequency as internal teams? - Is their change failure rate comparable? - Are they contributing to code review and knowledge sharing? - How does their Focus Time compare? (Contractors with excessive meetings might indicate poor onboarding) ### Platform and Tooling Investment With 500+ developers, tooling decisions have enormous leverage. Engineering metrics help you: - **Measure the impact of tool changes:** If you migrate from Jenkins to GitLab CI, does lead time actually improve? - **Identify tooling bottlenecks:** If build times are consuming 30 minutes per deployment across 50 teams deploying daily, that's 25 hours of waiting per day - **Justify platform team investment:** Show how internal platform improvements affect downstream teams' metrics ## Common Patterns in Large Telecom Organizations ### The "Islands of Excellence" Problem In every large engineering organization, some teams perform exceptionally well while others struggle. Without metrics, the struggling teams are invisible until they cause an incident. Engineering metrics make performance variation visible: - Department A deploys 15 times per week with a 2% change failure rate - Department B deploys 3 times per week with an 8% change failure rate The question isn't "why is Department B bad?" — it's "what's different about their context, and can we help?" ### The Coordination Tax As organizations grow, the percentage of time spent on coordination increases non-linearly. Metrics quantify this: - Track the ratio of Focus Time to Activity Time across the organization - Track lead time for cross-team changes vs. within-team changes - Monitor meeting time trends (inverse of Focus Time) If Focus Time has declined 20% over the past year while headcount grew 30%, your coordination overhead is growing faster than your capacity. ### The Technical Debt Spiral Large organizations often enter a technical debt spiral: 1. Maintenance burden increases, consuming more engineering capacity 2. Less capacity for new features, so features are rushed 3. Rushed features create more technical debt 4. Maintenance burden increases further Activity distribution metrics make this spiral visible before it becomes a crisis. If the organization-wide split between new development and maintenance shifts by more than 5% per quarter, it's time to invest in debt reduction. ## Financial Visibility at Scale At 500+ engineers, the engineering budget is likely tens of millions of dollars annually. PanDev Metrics' financial analytics provide: - **Cost per deployment** across the organization - **Cost per team** correlated with output metrics - **Cost of maintenance** vs. cost of new development - **ROI of improvement initiatives** (did the platform investment actually reduce lead times?) This data is essential for board-level reporting, budget planning, and strategic decision-making. ## Getting Started For a VP of Engineering managing 500+ developers: 1. **Identify your pilot teams** — choose 2-3 teams from different departments 2. **Deploy PanDev Metrics on-premise** with LDAP/SSO integration 3. **Connect all Git platforms** used across the organization 4. **Start IDE plugin deployment** with pilot teams 5. **Collect 4-6 weeks of baseline data** before drawing conclusions 6. **Expand department by department** based on pilot learnings 7. **Build the organizational dashboard** once 3+ departments are onboarded At scale, engineering metrics aren't a nice-to-have. They're the operating system for managing complexity, making informed decisions, and ensuring that 500+ talented engineers are collectively moving in the right direction. --- **Managing a large engineering organization?** [PanDev Metrics](https://pandev-metrics.com) — enterprise engineering intelligence with on-premise deployment, LDAP/SSO, multi-tenancy, and support for 500+ developer teams. --- ## AI/ML Teams: How to Track Research vs Engineering Work URL: https://pandev-metrics.com/docs/blog/ai-ml-teams-track-research-vs-engineering-work Date: 2025-11-20 Tags: ai-ml, research, engineering-metrics, developer-productivity, data-science Description: How CTOs of AI/ML companies track and balance research exploration with production engineering using engineering metrics. AI/ML teams are unlike any other engineering organization. Half the team is exploring novel approaches where most experiments fail — and that's expected. The other half is building production systems where reliability and speed matter. Many team members do both, switching between Jupyter notebooks and production codebases within the same day. The MLOps maturity model defines this spectrum — from ad hoc experimentation (Level 0) to fully automated ML pipelines (Level 2) — and most organizations sit somewhere in the middle. Traditional engineering metrics don't capture this duality. Measuring an ML researcher by deployment frequency is like measuring a chef by how fast they wash dishes. But having no metrics at all means you can't tell whether your research investment is producing results or if your production systems are reliable. Papers with Code trend data shows that the gap between state-of-the-art research and production-ready ML is widening — making the research-to-production bridge more critical than ever. Here's how to build a metrics framework that respects the difference between research and engineering while giving leadership the visibility they need. ![Activity patterns showing different coding rhythms for research vs engineering work](https://pandev-metrics.com/img/blog/activity-heatmap.png) *Activity patterns showing different coding rhythms for research vs engineering work.* ## The Fundamental Problem: Two Modes of Work AI/ML organizations have two fundamentally different work modes: ### Research/Exploration Mode - **Goal:** Discover something new — a better model, a novel approach, a performance breakthrough - **Success rate:** Low by design. Most experiments fail. That's the point. - **Output:** Knowledge, publications, prototypes, proof-of-concepts - **Work pattern:** Nonlinear. Long periods of reading, thinking, and experimenting, punctuated by breakthroughs - **Code characteristics:** Experimental, often in notebooks, frequently discarded ### Production/Engineering Mode - **Goal:** Build reliable, scalable systems that deliver AI/ML capabilities to users - **Success rate:** High expected. Deployments should work. Pipelines should be reliable. - **Output:** Production models, APIs, data pipelines, monitoring systems - **Work pattern:** More predictable. Sprint-based or Kanban-style flow - **Code characteristics:** Production-quality, tested, documented, maintained The problem isn't that these modes exist — it's that they're invisible to traditional metrics. A researcher who spent three weeks exploring a dead-end approach before finding a breakthrough looks unproductive in any standard framework. An ML engineer who deploys daily looks efficient, but their models might be mediocre. ## Why Standard Metrics Mislead in AI/ML ### Deployment Frequency Standard interpretation: higher is better. Ship more often, get faster feedback. AI/ML reality: Research doesn't "deploy" in the traditional sense. An ML researcher might push experimental code to a branch, run training jobs, analyze results, and iterate — none of which produces a "deployment." Meanwhile, the ML engineering team might deploy model updates and pipeline changes frequently. Comparing deployment frequency between these two groups is meaningless. ### Lead Time for Changes Standard interpretation: shorter is better. Reduce the time from idea to production. AI/ML reality: The "lead time" for a research insight might be months. The researcher reads papers, formulates hypotheses, designs experiments, runs them, analyzes results, and eventually produces a finding that can be productionized. Measuring this as lead time creates absurd numbers. ### Lines of Code / Commit Frequency Standard interpretation: proxy for activity and productivity. AI/ML reality: A researcher might spend a week reading papers and thinking, then write 50 lines of code that represent a breakthrough. An ML engineer might write 2,000 lines of pipeline code that's necessary but routine. Activity-based metrics wildly misrepresent the value of research work. ## A Better Metrics Framework for AI/ML Teams ### Separate the Streams The first step is explicitly categorizing work as research or engineering: **By repository:** Research code typically lives in different repositories (or at least different branches/directories) than production code. PanDev Metrics tracks activity by repository, making this separation automatic. **By project:** In Jira or ClickUp, maintain separate projects or labels for research and engineering work. PanDev Metrics integrates with both, allowing you to correlate activity with work type. **By team:** If your organization has distinct research and engineering teams, team-level metrics naturally provide this separation. ### Research Metrics For research/exploration work, track these metrics: **Experiment Velocity:** How many experiments is the research team running? This is the research equivalent of deployment frequency — it measures how quickly the team is generating and testing hypotheses. Track this through: - Git activity on research repositories (commits, branches created) - IDE Activity Time on research projects (captured by PanDev Metrics' heartbeat tracking) - Training job submissions (if integrated with your ML platform) Higher experiment velocity is generally better — it means the team is moving quickly through the hypothesis-test-learn cycle. **Research-to-Production Conversion Rate:** What percentage of research projects eventually produce something that's deployed to production? This isn't about individual experiments (most should fail), but about research *initiatives* or *themes*. Track this quarterly: - Number of research initiatives active - Number that produced production-deployable results - Time from research finding to production deployment A healthy conversion rate varies by organization, but tracking the trend matters more than the absolute number. **Knowledge Dissemination:** Research that stays in one person's head is wasted investment. Track: - Internal presentations and documentation produced - Code shared to common libraries - Collaboration patterns (are researchers working with engineering teams?) PanDev Metrics' activity data can show cross-repository collaboration — researchers working in production repos and engineers working in research repos indicate healthy knowledge flow. **Focus Time for Researchers:** Research requires deep, uninterrupted thinking. PanDev Metrics' Focus Time metric is especially valuable here. If your ML researchers are averaging less than 3 hours of Focus Time per day, they're being pulled into too many meetings, reviews, or operational tasks. Research Focus Time should be protected aggressively. Every hour of interrupted research time is dramatically less valuable than an hour of deep research time. This aligns with Cal Newport's *Deep Work* framework — ML research is perhaps the purest example of work that requires sustained, uninterrupted concentration to produce breakthroughs. ### Engineering Metrics For production/engineering work, standard DORA metrics apply, with AI/ML-specific additions: **Standard DORA:** - Deployment frequency for ML services and pipelines - Lead time for model updates and pipeline changes - Change failure rate for model deployments and data pipelines - MTTR for ML system incidents **ML-Specific Additions:** **Model Deployment Lead Time:** The time from "model is trained and validated" to "model is serving production traffic." This captures the productionization pipeline efficiency — packaging, testing, staging, canary deployment, full rollout. **Pipeline Reliability:** What percentage of data pipeline runs complete successfully? Failed pipeline runs waste compute resources and can delay model updates. **Model Rollback Rate:** How often do you need to roll back a model deployment? This is the ML equivalent of change failure rate, but specific to model updates. ### Hybrid Metrics (Bridging Research and Engineering) **Handoff Time:** When research produces a result ready for productionization, how long does it take the engineering team to pick it up? Long handoff times indicate poor communication or misaligned priorities between research and engineering. **Productionization Effort:** How much engineering Activity Time is required to take a research prototype to production? If this is consistently high, either research code quality needs to improve or the production infrastructure needs better tooling for ML workloads. **Retraining Efficiency:** Once a model is in production, how much effort does retraining require? Track Activity Time per retraining cycle — decreasing trends indicate improving automation. ## The AI/ML Leadership Dashboard ### CTO View **Research Health:** - Active research initiatives: [count] - Experiment velocity: [experiments per week, trend] - Research Focus Time: [average hours per day, trend] - Research-to-production pipeline: [initiatives in progress] **Engineering Health:** - DORA metrics for ML services - Pipeline reliability rate - Model deployment success rate - Active production incidents **Investment Balance:** - Engineering Activity Time split: research vs. production engineering vs. operations - Cost allocation: research compute + personnel vs. engineering - Conversion funnel: research initiatives → prototypes → production models ### Research Lead View **Team Activity:** - Experiment velocity by researcher/sub-team - Focus Time distribution - Collaboration patterns (cross-team activity) - Repository activity trends **Research Pipeline:** - Active experiments and their status - Promising results ready for deeper investigation - Results ready for engineering handoff ### Engineering Lead View **DORA Metrics:** - Standard deployment frequency, lead time, change failure rate, MTTR - Broken down by service (model serving, data pipelines, APIs, infrastructure) **ML-Specific:** - Model deployment pipeline health - Pipeline reliability trends - Productionization backlog (research handoffs waiting for engineering) ## Practical Implementation ### Step 1: Repository Structure Organize repositories to enable metric separation: - Research repositories (experiments, notebooks, prototypes) - Production repositories (services, pipelines, infrastructure) - Shared repositories (common libraries, utilities) PanDev Metrics tracks activity per repository, so this structure automatically separates research and engineering metrics. ### Step 2: Connect Your Stack Connect PanDev Metrics to your development infrastructure: - **Git platforms:** GitLab, GitHub, Bitbucket, or Azure DevOps - **IDE plugins:** Support for JupyterLab and VS Code (common in ML), plus JetBrains IDEs (PyCharm is popular for ML engineering) - **Project tracking:** Jira or ClickUp for correlating metrics with planned work ### Step 3: Establish Baselines Collect 4-6 weeks of data across both research and engineering teams. Understand: - What's the current experiment velocity? - How much Focus Time do researchers actually get? - What are the engineering DORA metrics baselines? - How is Activity Time distributed between research and engineering? ### Step 4: Calibrate Expectations This is critical. Share baseline data with both research and engineering teams and calibrate: - What experiment velocity is healthy for your research goals? - What Focus Time target should you protect for researchers? - What DORA targets are appropriate for your ML services? - How should the research-engineering Activity Time split look given your strategic priorities? ### Step 5: Monitor and Adjust Weekly review cadence: - Research team reviews experiment velocity and Focus Time - Engineering team reviews DORA and ML-specific metrics - Combined review of handoff time and productionization pipeline Monthly review: - Research-to-production conversion rate - Activity Time distribution trends - Financial analysis of research vs. engineering investment ## Common Anti-Patterns ### Treating Researchers Like Engineers If you measure researchers by deployment frequency and lead time, they will optimize for those metrics — running shallow experiments that can be "deployed" quickly rather than pursuing deep, potentially breakthrough research. You'll get more deploys and less innovation. ### Treating Engineers Like Researchers If you don't track DORA metrics for your production ML team because "AI is different," you'll end up with unreliable services, slow deployments, and poor incident response. Production ML systems need the same engineering discipline as any other production system. ### Ignoring the Research-to-Production Gap Many AI/ML organizations have a "valley of death" between research and production. Researchers produce promising results that never get deployed because: - Engineering team is too busy with maintenance - Research prototypes are too far from production-quality - No one owns the handoff process Track handoff time and productionization effort to make this gap visible and actionable. ### Over-Optimizing Research Metrics Experiment velocity is valuable, but "number of experiments" can be gamed. A team running 50 trivial hyperparameter variations is less valuable than a team running 5 carefully designed experiments that test genuinely different approaches. Combine experiment velocity with conversion rate — lots of experiments that never produce useful results suggest the research direction, not the research pace, needs attention. ## Protecting Research While Maintaining Accountability The core tension in AI/ML metrics is maintaining research freedom while ensuring accountability for research investment. Engineering metrics navigate this by: 1. **Measuring activity, not outcomes, for individual researchers:** Focus Time and experiment velocity show engagement without judging research direction 2. **Measuring outcomes at the portfolio level:** Research-to-production conversion rate evaluates the research *program*, not individual researchers 3. **Making the investment visible:** Activity distribution and financial analytics show leadership exactly how research investment is allocated 4. **Protecting deep work:** Focus Time metrics justify protecting researchers from meetings and interruptions This balance ensures that researchers have the freedom to explore while the organization has the visibility to ensure research investment is managed responsibly. --- **Leading an AI/ML team?** [PanDev Metrics](https://pandev-metrics.com) — engineering intelligence that understands the difference between research and production, with IDE tracking across JupyterLab, VS Code, and 10+ development environments. --- ## EdTech: Productivity Metrics for Educational Platform Teams URL: https://pandev-metrics.com/docs/blog/edtech-productivity-metrics-educational-platform-teams Date: 2025-11-17 Tags: edtech, engineering-metrics, developer-productivity, dora-metrics, educational-platforms Description: How EdTech CTOs use engineering metrics to manage platform development, content delivery systems, and cross-functional teams effectively. EdTech platforms are deceptively complex engineering challenges. HolonIQ's global EdTech funding data shows the sector attracted over $10 billion annually in recent years — and that capital demands engineering output that matches investor expectations. On the surface, it's "just" a learning management system or an online course platform. Underneath, it's real-time video streaming, adaptive learning algorithms, content management for thousands of courses, assessment engines, analytics dashboards, accessibility compliance, and integrations with school IT systems that haven't been updated since 2010. EdTech CTOs manage teams that span frontend, backend, content engineering, data science, DevOps, and often a dedicated integrations team. The work ranges from highly creative (building engaging learning experiences) to deeply technical (video transcoding pipelines, real-time collaboration engines) to frustratingly mundane (integrating with yet another LMS via a poorly documented API). Engineering metrics help you manage this complexity, allocate resources wisely, and deliver the platform improvements that actually move learning outcomes. ![Engineering dashboard showing team activity and project status](https://pandev-metrics.com/img/blog/dashboard-clean.png) *Engineering dashboard showing team activity and project status.* ## The EdTech Engineering Landscape ### What Makes EdTech Different EdTech engineering organizations face a specific set of challenges: **Seasonal demand patterns.** Usage spikes at the start of academic terms, during exam periods, and drops during holidays. Your infrastructure and feature delivery need to anticipate these cycles — much like e-commerce, but with different timing. **Diverse user populations.** Students, teachers, administrators, parents, and content creators all use your platform differently. Each group has different needs, different technical literacy levels, and different tolerance for bugs. **Accessibility is non-negotiable.** Educational platforms often must comply with WCAG standards, Section 508 (US), and EN 301 549 (EU). The UNESCO EdTech Framework emphasizes that inclusive access is a foundational principle, not an add-on. This isn't a nice-to-have — it's a legal requirement for platforms used by educational institutions. **Content and code are intertwined.** Unlike most software products, EdTech platforms have a content layer that's as complex as the code layer. Content authoring tools, content delivery networks, multimedia processing pipelines — these require engineering resources but don't fit neatly into traditional software metrics. **Integration complexity.** Schools and universities use dozens of systems: SIS (Student Information Systems), LTI-compliant LMS platforms, SSO via SAML/LDAP, grade passback systems, and more. Each integration is unique and often poorly documented. **Long feedback loops.** You can A/B test a checkout button and see results in hours. Testing whether a new learning feature improves student outcomes takes weeks or months. ### The Typical EdTech Engineering Organization A mid-stage EdTech company (Series B+) typically has: - **Platform team:** Core infrastructure, APIs, authentication, scalability - **Product teams (2-4):** Learning experience, assessments, content tools, analytics - **Content engineering team:** Authoring tools, content delivery, multimedia processing - **Data/ML team:** Learning analytics, adaptive algorithms, recommendations - **Integrations team:** Third-party connections, LTI, SIS integrations - **DevOps/SRE:** Infrastructure, deployment, monitoring Each team has different work patterns, different deployment cadences, and different definitions of "done." ## Metrics Framework for EdTech ### Platform Health Metrics Your platform is the foundation everything else is built on. Track: **Deployment Frequency:** How often does each team deploy? For platform and product teams, daily or multiple-times-daily deployment indicates healthy CI/CD practices. For the integrations team, deployment frequency might be lower because each integration requires specific testing with partner systems. PanDev Metrics tracks deployment frequency across all your Git platforms (GitLab, GitHub, Bitbucket, Azure DevOps), broken down by team and repository. **Lead Time for Changes:** From first commit to production. In EdTech, lead time often includes: - Code review - QA testing (including accessibility testing) - Staging environment validation - Content review (for changes affecting content display) - Partner validation (for integration changes) Measure time at each stage to find bottlenecks. If accessibility testing adds 3 days to every deployment, invest in automated accessibility testing tools. **Change Failure Rate:** What percentage of deployments cause issues? In EdTech, "issues" include: - System errors and bugs - Content rendering problems - Accessibility regressions - Integration breakages - Performance degradation during peak usage Track change failure rate by team and by change type. If integration deployments have a 20% failure rate while product deployments have 3%, focus your testing investment on integration code. **MTTR:** How quickly do you recover from incidents? During exam periods, MTTR is critical — a platform outage during a timed exam affects student grades and institutional trust. Track MTTR by service tier and by calendar period (normal vs. peak usage). ### Developer Productivity Metrics **Focus Time:** EdTech companies, especially those with strong pedagogical missions, tend to have meeting-heavy cultures. Product reviews, learning design sessions, content review meetings, partner calls, and cross-functional syncs can consume most of the day. PanDev Metrics' IDE heartbeat tracking reveals actual Focus Time — uninterrupted coding blocks. Compare across teams: - Platform team Focus Time should be highest (they have fewer cross-functional dependencies) - Product teams may have moderate Focus Time (balanced between building and collaborating) - Integration teams often have the lowest Focus Time (constant communication with partners) If any team's Focus Time is consistently below 2 hours per day, investigate their meeting load. **Activity Time Distribution:** Where is engineering effort going? For each team, track the split between: - **New feature development** — building new platform capabilities - **Bug fixes** — addressing reported issues - **Maintenance** — keeping existing systems running - **Integration work** — connecting with third-party systems - **Content tooling** — building and maintaining content authoring and delivery - **Technical debt** — improving code quality, migrating systems, upgrading dependencies This distribution tells you whether your investment priorities match your actual resource allocation. If leadership prioritizes "new learning experiences" but 60% of engineering time goes to maintenance and integration work, there's a disconnect that needs to be addressed with data. ### Content Engineering Metrics Content engineering is unique to EdTech and often underserved by standard metrics: **Content Pipeline Throughput:** How quickly can new content (courses, assessments, multimedia) move from authoring to availability on the platform? This isn't purely an engineering metric, but engineering constraints (processing time, review workflows, CDN propagation) are often the bottleneck. Track engineering Activity Time spent on content pipeline improvements versus content pipeline maintenance. If the ratio shifts toward maintenance, the content infrastructure needs investment. **Content Delivery Performance:** For platforms with multimedia content (video lectures, interactive simulations), track: - Processing pipeline reliability (what percentage of uploaded content processes successfully?) - Time to availability (how long after upload is content accessible to learners?) - Delivery performance (load times, buffering rates during peak usage) ### Integration Health Metrics Integrations are often the most fragile part of an EdTech platform: **Integration Failure Rate:** What percentage of data exchanges with partner systems fail? Track by integration partner — one poorly maintained SIS integration can consume weeks of engineering time. **Integration Maintenance Burden:** How much Activity Time goes to maintaining existing integrations vs. building new ones? If maintenance dominates, consider investing in more robust integration infrastructure (better error handling, automated testing, standardized connectors). **Lead Time for New Integrations:** How long does it take to build and deploy a new integration? If your sales team promises integrations in 2 weeks but engineering data shows the average is 6 weeks, you have an expectation mismatch that causes friction. ## Seasonal Planning With Metrics EdTech usage follows academic calendars. Engineering metrics help you prepare: ### Pre-Semester Sprint (4-8 Weeks Before Term Start) Focus metrics on: - **Deployment frequency acceleration** — ship critical features before the term starts - **Change failure rate** — maintain quality even as you accelerate - **Performance metrics** — ensure the platform handles expected enrollment - **Integration health** — verify all partner integrations before institutions depend on them ### During Term Focus metrics on: - **MTTR** — fast recovery is critical when students and teachers are actively using the platform - **Change failure rate** — zero tolerance for regressions during active use - **Bug fix lead time** — how quickly are reported issues resolved? - **Focus Time** — protect developers from being pulled into support escalations ### Between Terms Focus metrics on: - **Technical debt activity** — this is the time to invest in platform improvements - **Activity distribution** — shift toward maintenance, infrastructure, and debt reduction - **Deployment frequency** — may decrease as teams work on larger, more complex improvements - **Research and experimentation** — data/ML teams should have dedicated time for exploration ## Building the EdTech Engineering Dashboard ### CTO View **Platform Health:** - Deployment frequency trend (all teams) - Change failure rate (last 4 weeks) - MTTR for Tier 1 services - Upcoming peak usage period readiness **Team Allocation:** - Activity distribution across all teams - Focus Time averages by team - Headcount vs. output trends **Financial:** - Engineering cost per product area - Cost trends over time - Resource allocation efficiency (from PanDev Metrics financial analytics) ### Engineering Manager View **Team Metrics:** - Team DORA metrics with trends - Focus Time per developer - Code review metrics (wait time, throughput) - Activity distribution (feature vs. bug fix vs. maintenance) **Delivery:** - Features in pipeline with estimated completion (based on lead time data) - Blocked items and reasons - Cross-team dependencies ### Individual Developer View **Personal Metrics:** - Focus Time trends (help developers protect their deep work time) - Activity distribution across projects - Deployment contributions - Code review activity Developers should see their own metrics as tools for self-improvement, not surveillance. ## Accessibility and Compliance Tracking Accessibility compliance is a legal and ethical requirement for EdTech. Engineering metrics support this: **Accessibility Testing Coverage:** Track what percentage of deployments include accessibility testing. If it's not 100%, identify why and address the gap. **Accessibility Bug Fix Lead Time:** How quickly are accessibility issues resolved after discovery? These should be prioritized as highly as functional bugs — a feature that students with disabilities can't use is a broken feature. **Activity Time on Accessibility:** Track engineering time spent on accessibility improvements, not just fixes. This demonstrates ongoing commitment to inclusive design. ## Data Privacy Considerations EdTech platforms handle student data, which is protected by some of the strictest privacy regimes in any industry: - **FERPA** (US) — Federal Educational Rights and Privacy Act - **COPPA** (US) — Children's Online Privacy Protection Act (if serving under-13 students) - **GDPR** (EU) — General Data Protection Regulation - **State and national laws** — varying by jurisdiction For engineering metrics, this means: - **On-premise deployment** may be required if your engineering data could contain references to student data. PanDev Metrics supports full on-premise installation. - **Data minimization** — engineering metrics should capture activity patterns, not code content or student data. - **Access controls** — LDAP/SSO integration ensures only authorized personnel access engineering metrics. ## Cross-Functional Collaboration Metrics EdTech development requires tight collaboration between engineering, instructional design, content teams, and partner relations. Metrics can illuminate collaboration health: **Cross-Repository Activity:** PanDev Metrics tracks when developers work across multiple repositories. High cross-repository activity in an EdTech context might indicate healthy collaboration (engineers helping content teams) or unhealthy context-switching (engineers pulled in too many directions). **Handoff Time:** How long do design-to-engineering and content-to-engineering handoffs take? Long handoff times indicate process problems or capacity mismatches. **Integration Team Responsiveness:** How quickly does the integration team respond to new integration requests? If sales is closing deals that depend on integrations the team can't deliver on time, metrics make this gap visible and negotiable. ## Implementation Roadmap ### Month 1: Foundation 1. Deploy PanDev Metrics (on-premise if handling student data) 2. Connect Git platforms and project tracking tools 3. Deploy IDE plugins across all engineering teams 4. Collect baseline data ### Month 2: Visibility 1. Build team-level dashboards 2. Share DORA metrics with team leads 3. Identify Focus Time patterns 4. Map activity distribution ### Month 3: Optimization 1. Address the biggest bottlenecks identified by metrics 2. Set up seasonal preparation dashboards 3. Establish integration health monitoring 4. Begin financial analytics tracking ### Month 4+: Continuous Improvement 1. Quarterly metrics reviews with leadership 2. Seasonal preparation playbooks informed by historical data 3. Data-driven resource allocation decisions 4. Integration health management using trend data ## The Bigger Picture EdTech companies exist to improve learning outcomes. Every engineering decision — how you allocate resources, which features you prioritize, how you manage technical debt — ultimately affects whether students learn better. Engineering metrics connect your engineering operations to this mission. When you can see that 40% of engineering time goes to maintaining a legacy content pipeline, you can make the case to invest in modernization — not because it's technically interesting, but because it frees capacity to build features that improve learning. When you can see that your integrations team is overwhelmed, you can hire or redistribute resources before the next integration failure disrupts a school district's semester. When you can see that Focus Time is declining, you can protect your developers' ability to do their best work — which ultimately means building a better platform for learners. --- **Building an educational platform?** [PanDev Metrics](https://pandev-metrics.com) — engineering intelligence for EdTech teams, with DORA metrics, IDE activity tracking, and the visibility to build platforms that improve learning. --- ## Top 10 Programming Languages 2026: Real Coding Time Ranking (Beyond GitHub Stars) URL: https://pandev-metrics.com/docs/blog/top-languages-by-coding-time Date: 2025-11-14 Tags: research, programming-languages, developer-productivity, data Description: We analyzed actual IDE coding time across 100k+ developers. The 2026 language ranking that differs from GitHub Octoverse 2025 — backed by real data. Every "top programming languages" list you've seen is based on GitHub stars, Stack Overflow surveys, or job postings. None of them measure what developers actually spend their time writing. We do. Here's the ranking based on **thousands of hours of real IDE coding time** across **200+ programming languages**, tracked from **active B2B developers** at **100+ B2B companies**. ## Why Existing Rankings Are Misleading The TIOBE Index counts search engine mentions. The PYPL Index counts tutorial searches. GitHub's Octoverse report counts repository counts and pull requests. The Stack Overflow Developer Survey asks developers what they *say* they use. The JetBrains Developer Ecosystem Survey adds another layer of self-reported data. None of these answer a simple question: **which languages do professional developers actually spend their working hours writing?** Search popularity reflects curiosity, not production use. GitHub stars reflect open-source hype, not enterprise reality. Survey responses reflect identity ("I'm a Python developer") more than daily activity. We wanted to fix that. ## Methodology PanDev Metrics collects IDE heartbeat data — timestamped activity records that show exactly which language a developer is writing in, at any given moment. This isn't self-reported. It's measured. Our dataset: - **100+ B2B companies** — enterprise and mid-market, not hobby projects - **active B2B developers** — real professional engineers - **extensive activity data** — granular IDE heartbeat data - **200+ languages tracked** — from Java to YAML to Dockerfile - **thousands of hours of IDE activity** — the denominator for all percentages below We filtered to active coding sessions only (no idle time, no browsing) and aggregated total hours per language. ## The Top 10 Languages by Actual Coding Time | Rank | Language | Coding Hours | Share of Total | Users | |:----:|----------|:------------:|:--------------:|:-----:| | 1 | **Java** | **2,107h** | **15.6%** | High | | 2 | **TypeScript** | **1,627h** | **12.0%** | High | | 3 | **Python** | **1,350h** | **10.0%** | High | | 4 | **TSX** | **1,021h** | **7.5%** | Medium | | 5 | **PHP** | **712h** | **5.3%** | Medium | | 6–10 | Other languages | Varies | — | — | Let's break down what this tells us. ## Finding #1: Java Is Still King in Enterprise B2B Java dominates with **2,107 hours** — over 15% of all coding time. This surprises exactly zero enterprise architects, but it surprises a lot of people on Twitter. Java doesn't trend on Hacker News. It doesn't win "language of the year" awards. But in B2B companies — the ones that pay salaries and ship products — Java is where developers spend the most hours. Why? Enterprise backends, microservices, Android development, and decades of existing codebases that aren't going anywhere. Java isn't exciting. It's profitable. ## Finding #2: TypeScript + TSX Combined Outpaces Everything If you combine TypeScript (1,627h) and TSX (1,021h), you get **2,648 hours** — making the TypeScript ecosystem the single largest consumer of developer time in our dataset. This makes sense. Modern B2B products need web frontends. React with TypeScript has become the default choice for serious applications. TSX is just TypeScript inside React components, so the combined number reflects the true footprint of the TypeScript ecosystem. For hiring managers: if you're building a B2B product, TypeScript proficiency is non-negotiable. ## Finding #3: Python Is Third — But Growing Fast Python sits at **1,350 hours** (10% of total). Its position reflects the growing importance of data pipelines, ML/AI tooling, internal automation, and backend services in B2B companies. What's interesting is that Python's share has been climbing. GitHub Octoverse data confirms Python as the fastest-growing language by contributor count. As companies adopt AI features — and as AI-assisted coding tools themselves are often configured and extended in Python — the language is eating into traditional backend territory. ## Finding #4: PHP Refuses to Die PHP at **712 hours** (5.3%) will upset the "PHP is dead" crowd. In B2B, there are massive codebases running on Laravel, Symfony, and legacy custom frameworks. These companies generate revenue. Their developers write PHP every day. The "PHP is dead" narrative is a social media phenomenon. In actual working codebases, PHP is alive and well. ## Finding #5: The Long Tail Is Enormous We track **200+ languages**. The top 5 account for roughly half of all coding time. The other 231 languages share the rest. This long tail includes: - **Infrastructure languages**: YAML, Dockerfile, HCL (Terraform), JSON - **Data languages**: SQL, R, Julia - **Systems languages**: Go, Rust, C, C++ - **Scripting**: Bash, PowerShell, Ruby - **Mobile**: Kotlin, Swift, Dart Every company's language mix is different. The top 10 gives you a market view, but your team's profile might look nothing like the average. ## How This Compares to Popular Rankings | Language | Our Rank (by coding time) | TIOBE (search) | Stack Overflow (survey) | |----------|:-------------------------:|:--------------:|:----------------------:| | Java | 1 | Top 5 | Declining | | TypeScript | 2 | Rising | Top 5 | | Python | 3 | 1 | 1 | | PHP | 5 | Top 10 | "Dreaded" | The biggest discrepancy is Python. It's #1 in almost every popularity index but #3 in actual B2B coding time. The reason: Python is enormously popular in education, data science notebooks, and personal projects — contexts that inflate survey numbers but don't reflect enterprise development proportionally. The Stack Overflow Developer Survey confirms Python as the "most wanted" language, but our data shows that *wanting* and *daily professional use* are different things. Java, conversely, is underrepresented in popularity rankings because enterprise Java developers don't typically evangelize their stack on social media. The JetBrains Developer Ecosystem Survey paints a more balanced picture — showing Java consistently in the top 3 for professional use — which aligns more closely with our findings. ## What This Means for Engineering Leaders **For hiring**: Align your recruiting with what your team actually writes, not what's trending. If 40% of your codebase is Java, hire Java developers — even if candidates all list Python on their resumes. **For tooling decisions**: Invest in developer experience for your dominant languages. If TypeScript is your primary language, optimized linting, type-checking pipelines, and editor configurations pay outsized dividends. **For technology strategy**: The TypeScript ecosystem's dominance suggests that full-stack TypeScript (Node.js backend + React frontend) is the path of least resistance for new B2B products. You'll find more developers and more tooling. **For training**: If you're investing in upskilling, focus on languages that consume the most coding time in your organization — not the ones with the most hype. ![Coding activity heatmap by hour and day](https://pandev-metrics.com/img/blog/activity-heatmap.png) PanDev's activity heatmap shows when your developers code most intensely — and the same data powers the language-level breakdown. ## How to Measure Your Own Language Distribution PanDev Metrics tracks language usage automatically through IDE plugins. Every coding session is tagged with the language, so you can see your team's actual distribution without surveys or guesswork. This matters because language distribution shifts over time. A team that was 80% Java two years ago might be 50% Java / 30% TypeScript today — and leadership often doesn't know until it's measured. ## Conclusion The most popular programming languages by actual coding time look different from what popularity indexes suggest. Java leads enterprise B2B development. TypeScript (including TSX) dominates when you count the full ecosystem. Python is growing but isn't #1 in professional settings. And PHP is far from dead. Stop relying on GitHub stars and survey hype to make technology decisions. Measure what your team actually writes. --- **Measure your team's real language distribution.** [PanDev Metrics](https://pandev-metrics.com) tracks coding time by language automatically — no surveys, no guesswork. --- ## Morning vs Evening Developers: When Is the Best Code Written? URL: https://pandev-metrics.com/docs/blog/morning-vs-evening-developers Date: 2025-11-12 Tags: research, developer-productivity, work-patterns, data Description: We analyzed extensive IDE activity data to find when developers are most productive. Tuesday is the peak day, Sunday the lowest. Here's the full breakdown. Some developers swear by 6 AM starts with coffee and silence. Others don't open their IDE until 10 PM. Managers debate whether to enforce "core hours" or let people work whenever they want. We looked at **extensive activity data** from **developers** across **100+ B2B companies** to find out when developers actually code — and whether timing matters. ## Methodology PanDev Metrics captures IDE heartbeats with timestamps, giving us a precise picture of when coding happens. We analyzed: - **extensive activity data** from production environments - **active B2B developers** across **100+ B2B companies** - **thousands of hours of IDE activity** broken down by time of day and day of week - Activity type: pure coding sessions only (no meetings, no browsing) We categorized developers into morning coders (peak activity before noon), afternoon coders (peak noon to 5 PM), and evening coders (peak after 5 PM) based on when their highest concentration of coding sessions occurred. ## Finding #1: Tuesday Is the Most Productive Day When we aggregate coding activity across all developers, a clear weekly pattern emerges: **Tuesday consistently shows the highest coding volume**, followed closely by Wednesday and Thursday. Monday starts slower — likely due to standup meetings, sprint planning, and email catch-up. Friday drops off noticeably. Saturday sees some activity from dedicated individuals. **Sunday is the lowest day by far.** This aligns with what many engineering managers intuit: the mid-week block is when deep work happens. But now there's data behind it. ### Why Tuesday? Monday absorbs the organizational overhead of starting a new week. By Tuesday, developers have context loaded, blockers identified, and a clear picture of what to work on. The "Monday context switch" is real and measurable. Friday's decline isn't just about people slacking off. It reflects a rational pattern: developers avoid starting complex tasks they can't finish before the weekend. Code reviews, documentation, and smaller fixes tend to fill Friday instead. ## Finding #2: The 10 AM – 12 PM Window Is Peak Coding Time Across our dataset, the highest concentration of coding activity falls in the **late morning window: 10 AM to noon**. There's a secondary peak in the **early afternoon: 2 PM to 4 PM**, with a visible dip during the lunch hour. A smaller but meaningful cluster of activity appears in the **evening: 8 PM to 11 PM**, representing developers who either prefer late hours or return to work after personal time. ![IDE activity heatmap revealing when developers actually code — morning peaks clearly visible](https://pandev-metrics.com/img/blog/activity-heatmap.png) *IDE activity heatmap revealing when developers actually code — morning peaks clearly visible.* ### The Morning Advantage Morning coding sessions tend to be **longer and more focused**. Developers who start coding before 10 AM show longer uninterrupted stretches compared to those who start after lunch. This doesn't mean morning developers write better code — but they do write code in longer, deeper sessions. This has implications for meeting scheduling. If your most productive coding window is 10 AM to noon, and you fill it with standups, one-on-ones, and "quick syncs," you're cutting into peak output. ## Finding #3: Evening Coders Exist — But They're a Minority Roughly **~15-20% of developers** in our dataset show significant coding activity after 6 PM. These evening coders fall into two categories: 1. **Night owls by preference** — their activity starts late and peaks late 2. **Double-shifters** — they code during the day, take a break, and return in the evening The double-shift pattern is more concerning from a burnout perspective. Sustained evening work on top of a full day often indicates either excessive workload or a daytime environment that's too meeting-heavy for deep work. ## Finding #4: Weekend Work Is a Warning Signal Our data shows that **weekend coding activity is low overall** — Sunday is the least active day by a large margin. But it's not zero. When we look at teams where weekend coding is consistently above average, we often find: - Approaching deadlines or sprint overcommitment - On-call responsibilities bleeding into personal time - Developers who feel they can only focus on weekends because weekdays are meeting-heavy Occasional weekend coding isn't a problem. Consistent weekend coding is a symptom. Engineering managers should monitor this pattern — not to punish it, but to investigate what's preventing sufficient deep work during business hours. ## Finding #5: The "Flow State" Window Varies by Person While aggregate data shows a 10 AM peak, individual developers vary enormously. Some of the most productive developers in our dataset (by total coding hours) had their peak activity at unusual times: early morning (6-8 AM), late evening (9-11 PM), or in a concentrated 4-hour afternoon block. The key insight: **forcing uniform schedules on diverse work patterns has a cost**. Mandatory 9 AM standups punish evening-oriented developers. "No meetings after 3 PM" policies assume everyone's productive period is in the afternoon. The best approach we've seen in high-performing teams: **protect a 3-4 hour core overlap window** for collaboration, and let individuals structure the rest of their day around their natural rhythm. ## What the Research Says Our findings align with broader research on chronotypes and cognitive performance: - **Circadian rhythm research** shows that ~60-70% of people have a peak cognitive period in the late morning, but individual variation is significant - **The "attention residue" effect** (Leroy, 2009) explains why post-meeting coding is less productive — the mind is still processing the meeting - **Cal Newport's *Deep Work*** (2016) argues that 3-4 hours of truly focused work per day is the maximum for most knowledge workers — our data confirms this holds in professional B2B engineering environments - **The Stack Overflow Developer Survey** reports that most developers self-identify as preferring morning or late-morning work — consistent with the 10 AM peak we observe Our data adds a new dimension: in professional B2B environments with developers, these patterns hold at scale. This isn't a lab study — it's real production coding behavior. ## Practical Recommendations for Engineering Managers ### 1. Audit Your Meeting Schedule Against Coding Peaks Look at when your team's coding activity peaks (PanDev Metrics shows this in the activity dashboard). Then look at your recurring meeting schedule. If there's significant overlap, you're destroying productivity. **Action**: Move standups to early morning or late afternoon. Block the 10 AM – 12 PM window as "maker time." ### 2. Monitor the Tuesday-to-Friday Ratio A healthy team shows moderate decline from Tuesday to Friday. If Friday coding drops below 50% of Tuesday's level, investigate. Common causes: meeting overload, sprint scope problems, or burnout. ### 3. Watch for Weekend Creep Track weekend coding activity at the team level. An upward trend over several months is an early warning sign. Address the root cause (scope, meetings, unrealistic deadlines) before it becomes a retention problem. ### 4. Respect Chronotype Diversity If your data shows that some team members are consistently most productive in the evening, accommodate them. Async communication, recorded standups, and flexible core hours cost you nothing and may significantly boost output. ### 5. Use Data, Not Assumptions The biggest mistake we see is managers designing work policies based on their own preferences. A morning-person manager who mandates 8:30 AM starts will underperform compared to one who looks at the actual activity data and optimizes around it. ## The Bottom Line Developers are most productive on Tuesdays, in the late morning, during uninterrupted stretches. But individual variation is enormous. The smartest engineering leaders don't enforce a single "productive hours" policy — they measure actual patterns and optimize around them. The question isn't "when should developers work?" It's "when *do* they work best, and how do we protect that time?" --- **See when your team actually codes.** [PanDev Metrics](https://pandev-metrics.com) shows real-time activity patterns by hour and day — so you can protect your team's most productive windows. --- ## Monday vs Friday: When Do Developers Write Their Best Code? (Data from 100k Engineers) URL: https://pandev-metrics.com/docs/blog/monday-vs-friday Date: 2025-11-10 Tags: research, developer-productivity, engineering-metrics, data Description: Real-time IDE data shows which weekdays produce highest-quality code. Programming weekday vs weekend patterns, with focus-time analysis from 100k+ engineers. Every engineering manager has a gut feeling about their team's weekly rhythm. Monday feels slow. Friday feels like a wind-down. But what does the data actually show? We analyzed **thousands of coding hours** from **developers** across **100+ B2B companies** to map developer productivity across the work week — and the results challenge some common assumptions. ## The Data PanDev Metrics tracks IDE heartbeats — timestamped records of active coding sessions. This isn't self-reported time. It's measured, second by second, across every language and IDE. Our dataset includes **extensive activity data**, giving us granular visibility into when and how much developers code. We aggregated coding time by day of week across all tracked developers, normalizing for holidays and partial weeks. ![Coding activity heatmap by hour and day](https://pandev-metrics.com/img/blog/activity-heatmap.png) The activity heatmap visualizes the weekly productivity pattern — you can clearly see which days and hours produce the most coding activity. ## The Weekly Productivity Curve Here's what the week looks like, ranked by total coding activity: | Rank | Day | Relative Activity | Notes | |:----:|-----------|:------------------:|-------| | 1 | **Tuesday** | **Highest** | Peak productivity day | | 2 | Wednesday | High | Sustained deep work | | 3 | Thursday | High | Slight decline begins | | 4 | Monday | Moderate | Slow start, builds through day | | 5 | Friday | Lower | Noticeable drop-off | | 6 | Saturday | Low | Occasional work | | 7 | **Sunday** | **Lowest** | Minimal activity | The shape is consistent across companies, team sizes, and tech stacks. **Tuesday is the peak day. Sunday is the valley.** ## Monday: The Warm-Up Day Monday starts slow. The first few hours are consumed by: - **Sprint planning and standups** — most teams front-load organizational meetings to Monday - **Context reloading** — developers need to remember where they left off Friday - **Email and Slack catch-up** — weekend messages, deployment alerts, customer issues - **Pull request reviews** — code submitted Friday often waits until Monday for review By Monday afternoon, coding activity picks up noticeably. Developers have re-established context, cleared their inboxes, and identified their highest-priority tasks. ### The Monday Fix The most productive teams in our dataset minimize Monday organizational overhead. Strategies include: - **Friday context notes**: Developers write a 2-3 sentence note before leaving Friday about what they'll pick up Monday - **Async standups on Monday**: Replace the synchronous meeting with a Slack thread - **Protected Monday afternoon**: No meetings after 1 PM on Mondays These small changes can recover 1-2 hours of Monday coding time per developer. ## Tuesday: The Peak Tuesday is where the magic happens. By Tuesday morning, developers have: 1. Full context from Monday's planning 2. Clear priorities for the sprint 3. Resolved blockers identified Monday 4. A fresh, focused mind after Monday's warm-up The result is the **highest concentration of deep coding sessions** in the entire week. Long, uninterrupted stretches of 2+ hours are most common on Tuesdays. This finding has direct implications for meeting policies. If your Tuesday calendar is full of meetings, you're cutting into your team's single most productive day. Guard it fiercely. ## Wednesday and Thursday: The Sustain Wednesday and Thursday maintain high productivity, though with a slight declining trend. This mid-week block is where the majority of a sprint's coding work gets done. Wednesday often shows slightly more collaborative activity — code reviews, pair programming, technical discussions — as work started Monday/Tuesday reaches the point where feedback is needed. Thursday begins the psychological wind-down toward the weekend. Developers start avoiding complex new tasks and focus on finishing in-progress work. ## Friday: The Taper Friday shows a clear productivity drop. But contrary to the "nobody works on Friday" stereotype, it's not a wasted day. The activity that happens on Friday tends to be different in nature: - **Code reviews** — finishing the review cycle for the week's work - **Documentation** — updating README files, writing ADRs, commenting code - **Small fixes and cleanup** — addressing tech debt items that don't require deep focus - **Deployment preparation** — staging, testing, and verifying changes for release Friday isn't unproductive. It's *differently* productive. Smart engineering managers plan for this by assigning Friday-appropriate work: reviews, documentation, small bug fixes, and refactoring tasks that don't require starting complex new logic. ### The Friday Deploy Debate A common question: should teams deploy on Fridays? Our data doesn't directly answer this, but the lower Friday activity level suggests that if something goes wrong with a Friday deploy, fewer people are in a deep coding flow that would be disrupted by incident response. That said, most experienced teams still avoid Friday deploys. The cost of a failed Friday deployment (weekend on-call, stressed team, missed family time) outweighs the benefit of shipping one day earlier. ## Weekend Work: A Health Check Weekend coding activity in our dataset is minimal — especially Sunday. But it's not zero, and the pattern is informative. **Saturday** occasionally sees activity from: - Developers working on side features they're passionate about - On-call engineers addressing production issues - Teams in crunch mode before a deadline **Sunday** is the lowest point. When we do see Sunday activity, it's almost always one of two things: genuine passion projects or a team in trouble. ### Weekend Work as a Team Health Metric We recommend tracking the ratio of weekend coding hours to weekday coding hours at the team level. A ratio below 5% is normal (some people enjoy weekend coding). A ratio consistently above 10% warrants investigation: - Is the sprint scope realistic? - Are deadlines externally imposed and unreasonable? - Is the daytime environment too meeting-heavy for focused work? - Is the team understaffed? You don't need to ban weekend work. You need to ensure it's optional, not necessary. ## Cross-Company Patterns One of the advantages of analyzing data from **100+ B2B companies** is that we can spot patterns that hold across different contexts. The Tuesday peak and Sunday valley are **universal**. GitHub Octoverse commit pattern data confirms a similar mid-week peak across millions of repositories. We see the pattern in: - Small startups (10-20 developers) and mid-size companies (100+) - Teams working in Java, TypeScript, Python, and PHP - Companies across different time zones - Both remote-first and office-based organizations The only variation is intensity. Some companies show a sharper Monday-to-Tuesday ramp, suggesting more Monday overhead. Others have a flatter profile, suggesting better async practices that reduce the Monday warm-up penalty. ## Practical Recommendations ### For Engineering Managers 1. **Protect Tuesday and Wednesday for deep work.** Minimize meetings on these days. If your team can only have two meeting-free days, make them Tuesday and Wednesday. 2. **Redesign Monday.** Accept that Monday is a transition day. Front-load your organizational work here so the rest of the week is clear. 3. **Plan Friday for completion, not creation.** Assign code reviews, documentation, and cleanup tasks for Friday. Don't start new features. 4. **Track your team's weekly curve.** Use PanDev Metrics to see your specific team's pattern. If your team peaks on Thursday instead of Tuesday, adapt your processes to fit. ### For Individual Developers 1. **Schedule your hardest problems for Tuesday.** That complex algorithm, the tricky refactoring, the architectural decision — do it when your focus is sharpest. 2. **Use Monday to set up the week.** Review your tickets, ask clarifying questions, set up your branch. Don't feel guilty about low Monday output. 3. **Front-load your week.** If something can be done Tuesday or Thursday, choose Tuesday. The Thursday version of you will be less focused. 4. **Use Friday for debt.** Address those TODOs you've been ignoring. Review pull requests. Write the tests you skipped. ## Conclusion The weekly productivity curve — peaking Tuesday, declining through Friday, minimal on weekends — is one of the most consistent patterns in our data. This aligns with Cal Newport's *Deep Work* thesis: sustained focus requires both cognitive readiness and freedom from organizational overhead. Tuesday delivers both. It's not a bug. It's a feature of how human attention and organizational rhythms interact. The smartest teams don't fight this pattern. They design around it. They protect the peak, accept the warm-up, and use the taper for work that doesn't require deep focus. Your team probably follows this pattern too. The question is: are your processes helping or hurting it? --- **See your team's weekly rhythm.** [PanDev Metrics](https://pandev-metrics.com) visualizes coding activity by day of week — so you can optimize your sprint schedule around real data. --- ## IDE War 2026: VS Code vs JetBrains vs Cursor — Real Usage Data from 100k Developers URL: https://pandev-metrics.com/docs/blog/ide-war-2026 Date: 2025-11-07 Tags: research, developer-tools, IDE, data Description: Which IDE actually wins in 2026? VS Code vs JetBrains vs Cursor compared by real coding time across 100k+ developers — see the surprising numbers. The IDE debate is eternal. VS Code fans say it's fast and extensible. JetBrains loyalists swear by deep language support. And now Cursor is the new challenger, riding the AI wave. The Stack Overflow Developer Survey consistently ranks VS Code as the most popular editor, while the JetBrains Developer Ecosystem Survey shows strong loyalty among its users. But surveys measure sentiment, not reality. What do developers actually *use* when they sit down to work? Not what they tweet about. Not what they starred on GitHub. What they **code in**, hour after hour, day after day. We have the data. **thousands of hours of tracked coding time** across **100+ B2B companies**, broken down by IDE. ## The Data Source PanDev Metrics collects IDE heartbeat data through editor plugins. Every coding session is tagged with the specific editor or IDE being used, the language, and the timestamp. This gives us precise usage data — not survey responses, not download counts, but actual hours spent coding. Our dataset: - **100+ B2B companies** (enterprise, mid-market, startups) - **nearly 1,000 individual users** on the platform - **active B2B developers** generating heartbeat data - **thousands of hours of IDE activity** across all tracked IDEs - Data period: production data as of early 2026 ## The Top 3 IDEs by Real Usage | IDE | Total Hours | Active Users | Hours/User | |-----|:-----------:|:------------:|:----------:| | **VS Code** | **3,057h** | **100 users** | **30.6h** | | **IntelliJ IDEA** | **2,229h** | **26 users** | **85.7h** | | **Cursor** | **1,213h** | **24 users** | **50.5h** | These three numbers tell a story that no survey can capture. Let's unpack it. ## VS Code: The People's Choice VS Code dominates by user count. **100 out of our tracked users** — more than both competitors combined — use VS Code as their primary editor. With **3,057 hours** of total coding time, it's the most-used IDE in our dataset by a wide margin. ### Why VS Code Wins on Adoption - **Zero cost**: No license negotiations, no budget approvals needed - **Language agnostic**: Works for TypeScript, Python, Java, Go, Rust — everything - **Extension ecosystem**: Whatever you need, there's an extension for it - **Fast startup**: Opens in seconds, even for large projects - **Remote development**: SSH, containers, and Codespaces support built in ### The VS Code Caveat Notice the **hours per user: 30.6h**. This is the lowest among the top 3. There are two possible explanations: 1. VS Code attracts a wider range of users, including those who code less frequently (managers, designers, DevOps engineers who occasionally edit config files) 2. Some VS Code users are lighter coders who supplement with other tools This doesn't mean VS Code users are less productive. It means VS Code's user base is broader and more diverse than JetBrains or Cursor. ## IntelliJ IDEA: The Enterprise Workhorse IntelliJ has only **26 users** in our dataset — but those 26 users logged **2,229 hours**. That's **85.7 hours per user**, nearly three times the per-user average of VS Code. ### The IntelliJ Profile IntelliJ users are almost exclusively **Java and Kotlin developers** working on large enterprise codebases. They tend to be: - Senior developers and architects - Working on long-lived, complex backend systems - In companies that provide JetBrains licenses as standard tooling - Heavy users of IntelliJ-specific features: refactoring tools, database integration, debugging ### Why IntelliJ Users Code More Per Person The 85.7 hours/user figure reflects the profile of IntelliJ's user base in enterprise settings: dedicated backend developers who spend most of their working hours in the IDE. They're not switching between tools. They live in IntelliJ. This concentration is both IntelliJ's strength and its limitation. It's the best IDE for deep Java/Kotlin work. But it hasn't captured the broader developer population the way VS Code has. ### The JetBrains Ecosystem Note Our data specifically tracks IntelliJ IDEA. JetBrains also offers WebStorm, PyCharm, GoLand, and others. Some developers in our dataset may use other JetBrains products that are tracked separately. The total JetBrains ecosystem share is likely higher than IntelliJ alone suggests. ## Cursor: The AI-Native Newcomer The most interesting story in this data is **Cursor**. With **24 users** and **1,213 hours**, it's already the third most-used IDE in our dataset — a remarkable achievement for a product that's only a couple of years old. ### Cursor by the Numbers - **24 users** — comparable to IntelliJ's 26 - **1,213 hours** — already 40% of VS Code's total with 24% of the users - **50.5 hours per user** — higher than VS Code, lower than IntelliJ ### Who's Using Cursor? Cursor users in our dataset tend to be: - Early adopters and tech-forward developers - Working primarily in **TypeScript, Python, and newer stacks** - Often in smaller, more agile companies - Developers who have invested in AI-assisted workflows ### The Cursor Effect What makes Cursor's numbers notable is the trajectory. It went from zero to **24 users and 1,213 hours** in a B2B enterprise context — not hobby developers, not students, but professional engineers at companies paying for PanDev Metrics. This suggests that AI-native editors are moving from curiosity to daily driver status. The question isn't whether AI-assisted IDEs will gain share. It's how fast. ![Coding activity heatmap by hour and day](https://pandev-metrics.com/img/blog/activity-heatmap.png) Activity heatmaps reveal not just which IDE developers use, but when they are most actively coding throughout the day and week. ## What the Data Tells Us About IDE Switching One pattern we observe: IDE switching is rare at the individual level. Most developers in our dataset use a single primary IDE for 90%+ of their coding time. The exceptions: - Developers who use VS Code for frontend work and IntelliJ for backend work in polyglot projects - Developers who are gradually migrating from VS Code to Cursor - DevOps engineers who use VS Code for most work but occasionally open a JetBrains IDE for specific tasks This "IDE loyalty" means that the competition isn't about winning over existing users day-to-day. It's about being the choice for **new developers** and **new projects**. Evans Data Global Developer Population estimates put the worldwide developer count at ~30 million+ — and each one of them makes an IDE choice that largely sticks. ## The Real Comparison: It Depends on What You Do The "best IDE" question is misleading because each IDE serves a different profile: ### Choose VS Code If: - You work across multiple languages - You value customization and extensions - You want the largest community and ecosystem - You need remote development capabilities - Budget is a constraint ### Choose IntelliJ (JetBrains) If: - You work primarily in Java, Kotlin, or other JVM languages - You need deep refactoring and debugging tools - You work on large, complex enterprise codebases - Your company provides JetBrains licenses - You value "it just works" over configurability ### Choose Cursor If: - AI-assisted coding is core to your workflow - You work in TypeScript, Python, or modern stacks - You're willing to be an early adopter - You want inline AI suggestions and chat integrated into your editor - You're transitioning from VS Code (Cursor is VS Code-based, so the switch is painless) ## Implications for Engineering Leaders ### Don't Mandate a Single IDE Our data shows that each IDE has a distinct user profile. Forcing all developers onto one IDE means some will be working with a suboptimal tool. The productivity cost of using the wrong IDE for a specific job outweighs any standardization benefit. ### Budget for JetBrains Where It Matters If you have a Java/Kotlin team, JetBrains licenses pay for themselves. The 85.7 hours/user figure shows these developers live in their IDE. A $200/year license for a tool someone uses 80+ hours is trivial. ### Watch the Cursor Trend Cursor's growth from zero to 24 enterprise users deserves attention. If AI-assisted coding delivers even a 10-15% productivity improvement, the ROI of Cursor licenses for your team could be significant. Consider running a pilot. ### Track IDE Usage, Don't Guess Most engineering leaders don't know their team's actual IDE distribution. They assume "everyone uses VS Code" or "we're a JetBrains shop." The reality is often more varied. Knowing what tools your team actually uses helps you make better decisions about tooling investments, plugin development, and developer experience. ## The Future: Convergence or Specialization? Our data suggests we're heading toward **a three-way market**: 1. **VS Code** as the universal default for general-purpose development 2. **JetBrains** as the premium choice for enterprise language-specific deep work 3. **AI-native editors** (Cursor and upcoming competitors) as the future for AI-augmented development The wildcard is whether VS Code's AI extensions (GitHub Copilot, etc.) can close the gap with Cursor's native AI integration. If they can, Cursor's growth may plateau. If not, we could see a significant migration of VS Code users to AI-native editors over the next 1-2 years. Either way, the IDE war of 2026 has three real contenders — and the data shows each has a legitimate place. --- **Track your team's real IDE usage.** [PanDev Metrics](https://pandev-metrics.com) shows which editors your developers actually use, how many hours they spend in each, and how usage is trending over time. --- ## Brooks's Law 2026: How Team Size Actually Affects Productivity (Real Data) URL: https://pandev-metrics.com/docs/blog/team-size-productivity Date: 2025-11-04 Tags: research, developer-productivity, engineering-management, data Description: Communication overhead in large teams: real data confirming Brooks's Law in 2026. Productivity loss as engineering teams grow from 5 to 50 — full breakdown. "Adding manpower to a late software project makes it later." Fred Brooks wrote that in 1975. Fifty years later, engineering leaders still debate whether it's true. We looked at real coding data from **100+ B2B companies** on PanDev Metrics to understand how team size relates to individual developer productivity. The answer is more nuanced than Brooks suggested — but his core insight still holds. ## The Original Argument Brooks's Law, from *The Mythical Man-Month* (1975), rests on two observations: 1. **Communication overhead scales quadratically.** A team of 3 has 3 communication channels. A team of 10 has 45. A team of 20 has 190. This is closely related to Conway's Law — that organizations design systems mirroring their communication structures. 2. **New members need ramp-up time.** They don't contribute immediately, and they slow down existing members who need to onboard them. The implication: there's a point where adding developers actually reduces total team output. More people, less done. But is this reflected in actual coding data? ## What Our Data Shows PanDev Metrics tracks individual developer activity across companies of varying sizes. With **active B2B developers** across **100+ B2B companies** generating **thousands of hours of IDE activity**, we can observe productivity patterns across different organizational contexts. ### Observation 1: Smaller Teams Show Higher Per-Developer Coding Hours When we segment by company size, a consistent pattern emerges: developers at smaller companies tend to log more coding hours per person. This aligns with Brooks's prediction — less communication overhead means more time writing code. In small teams (2-5 developers), a larger proportion of each person's day goes to actual coding. There are fewer meetings, fewer Slack channels, fewer code review loops, and fewer coordination touchpoints. In larger teams (20+ developers), individual coding hours per person trend lower. This doesn't mean larger teams are unproductive — their total output is higher. But the *efficiency per person* decreases. ![Department structure in PanDev showing team size and management hierarchy](https://pandev-metrics.com/img/blog/dashboard-departments.png) *Department structure in PanDev showing team size and management hierarchy.* ### Observation 2: The Communication Tax Is Real Larger teams in our dataset show characteristic patterns of communication overhead: - **More context-switching**: Activity records show shorter, more fragmented coding sessions - **More review cycles**: Pull requests take longer to merge as more reviewers are involved - **More coordination time**: Morning coding starts later, likely due to longer standups and planning meetings These aren't bugs in the process. Code reviews and coordination are valuable. But they have a measurable cost in coding time. ### Observation 3: The Two-Pizza Team Still Works Teams in the 5-8 developer range appear to hit a sweet spot in our data. They're large enough for meaningful code review and knowledge sharing, but small enough that communication overhead remains manageable. This aligns with Amazon's famous "two-pizza team" rule, with Jeff Sutherland's recommendation for Scrum teams of 5-9 members, and with Conway's Law — small, autonomous teams naturally produce more modular, maintainable systems. Beyond 8-10 developers, teams in our dataset that maintain high per-person productivity tend to have clear sub-team boundaries, well-defined interfaces, and strong async communication practices. ## Where Brooks Was Right ### The Ramp-Up Effect Our data on developer onboarding (see our article on new developer ramp-up) confirms Brooks's second point. New team members take weeks to reach full productivity. During that time, they also require attention from existing team members — pair programming, code review, answering questions. In a 5-person team adding 1 developer, the temporary productivity hit is significant: you're slowing down 5 people to onboard 1. In a 50-person team adding 5 developers, the hit is distributed across more people but lasts longer. ### The Coordination Explosion A team growing from 5 to 10 people doesn't just add 5 developers. It adds complexity: - **45 possible communication pairs** (up from 10) - More microservices, more APIs, more shared dependencies - More meetings to keep everyone aligned - More code review bottlenecks Our activity data shows this as a measurable increase in fragmented coding sessions — shorter bursts interspersed with communication activities. ## Where Brooks Was Incomplete ### The Parallelization Factor Brooks assumed most tasks are sequential — that you can't make a baby in one month with nine women. In modern software development, many tasks *are* parallelizable. Microservices architectures, well-defined API contracts, and feature flags allow multiple developers to work on independent workstreams with minimal coordination. Teams that invest in architecture that reduces coupling can scale more efficiently than Brooks predicted. ### Tooling Has Evolved In 1975, communication meant meetings and memos. In 2026, teams have: - **Async communication** (Slack, Notion, Loom) that reduces meeting overhead - **CI/CD pipelines** that catch integration issues automatically - **AI-assisted code review** that reduces the review bottleneck - **Infrastructure as Code** that makes environment setup reproducible - **Activity tracking tools** like PanDev Metrics that provide visibility without meetings These tools don't eliminate Brooks's Law, but they shift the curve. The team size at which overhead becomes problematic is larger now than it was in 1975. ### Specialization Matters Brooks treated developers as interchangeable. In practice, a well-composed team of specialists (frontend, backend, infrastructure, QA) can scale more efficiently than a team of generalists, because each specialist's work requires less coordination with others. Our data shows that teams with clear role boundaries maintain higher per-person coding hours at larger sizes compared to teams where everyone works on everything. The GitHub Octoverse data on contributor patterns supports this — repositories with well-defined CODEOWNERS files show faster merge times and fewer conflicts. ## Practical Implications ### For Growing Teams If your team is growing from 5 to 15 developers, plan for a temporary productivity dip. Budget 2-4 weeks of reduced output per new hire, and factor in the onboarding burden on existing team members. **Mitigation strategies:** - Stagger hires (don't add 5 people simultaneously) - Invest in documentation and automated onboarding - Assign dedicated onboarding buddies rather than spreading the burden - Use pair programming sessions strategically, not as a default ### For Team Structure The data supports the two-pizza team model. When your team crosses 8-10 developers: 1. **Split into sub-teams** with clear ownership boundaries 2. **Define interfaces** between sub-teams (APIs, shared contracts) 3. **Minimize cross-team dependencies** in sprint planning 4. **Maintain one tech lead per sub-team** for coordination ### For Estimation If your team has 5 developers producing X output, adding 5 more will not produce 2X. At best, expect 1.5-1.7X in the medium term. Communicate this to stakeholders before they ask "we doubled the team, why isn't output doubled?" ### For Remote Teams Remote teams experience Brooks's Law differently. Async communication reduces the meeting tax but increases the "waiting for response" tax. Remote teams in our data show longer coding sessions (fewer interruptions) but slower feedback loops. The ideal remote team structure: small, autonomous pods with clear ownership, minimal cross-pod dependencies, and well-defined async communication protocols. ## Measuring the Effect in Your Organization You can validate Brooks's Law in your own data using PanDev Metrics: 1. **Track per-developer coding hours** over time, especially during hiring periods 2. **Compare coding session length** before and after team expansion 3. **Monitor the Tuesday/Wednesday peak** — if it flattens, communication overhead may be increasing 4. **Look at ramp-up curves** for new hires to understand the real cost of each addition The goal isn't to stop hiring. It's to hire intelligently, with realistic expectations and the right team structures to maintain productivity at scale. ## Conclusion Brooks's Law is 50 years old and still fundamentally correct: communication overhead scales faster than team size, and adding people has a real cost. But modern tools, architectures, and practices can mitigate the effect significantly. The teams that scale best in our data share three traits: small autonomous sub-teams, clear ownership boundaries, and investments in async processes that reduce the coordination tax. Don't fight Brooks's Law. Design around it. --- **See how team growth affects your productivity.** [PanDev Metrics](https://pandev-metrics.com) tracks per-developer coding hours over time, so you can measure the real impact of scaling. --- ## Cursor Users Code 65% More Than VS Code Users: AI Copilot Impact 2026 URL: https://pandev-metrics.com/docs/blog/ai-copilot-effect Date: 2025-10-31 Tags: research, AI, developer-tools, developer-productivity, data Description: Cursor users log 50.5h/person vs VS Code's 30.6h. Either AI made them 65% more productive — or it just keeps them in the IDE longer. Real data, you decide. AI coding assistants went from novelty to necessity in under three years. GitHub Copilot, Cursor, Cody, and dozens of alternatives now sit inside developers' editors, suggesting code, answering questions, and writing boilerplate. A Deloitte report on AI adoption in software development estimates that ~70% of enterprise development teams now use some form of AI coding assistance. But are they actually making developers more productive? Or just more reliant on autocomplete? We looked at real IDE usage data from **100+ B2B companies** to find out what AI-assisted coding looks like in practice. ## What We Can (and Can't) Measure Let's be upfront about methodology. PanDev Metrics tracks IDE heartbeats — which editor is being used, for how long, in which language, and at what time. We can see: - Which developers use **Cursor** (an AI-native IDE) vs **VS Code** (with or without AI extensions) - How many hours each group logs - Session patterns (length, frequency, time of day) What we *can't* directly measure: - Lines of code produced per hour (we track time, not output volume) - Code quality differences between AI-assisted and non-assisted work - Whether a specific AI suggestion was accepted or rejected With that caveat, here's what the data shows. ## The Cursor Signal From our production data: | IDE | Total Hours | Active Users | Hours/User | |-----|:-----------:|:------------:|:----------:| | VS Code | 3,057h | 100 users | 30.6h | | Cursor | 1,213h | 24 users | 50.5h | **Cursor users log 50.5 hours per person compared to VS Code's 30.6 hours.** That's a 65% higher per-user engagement. This number requires careful interpretation. It doesn't necessarily mean Cursor makes people 65% more productive. There are several possible explanations. ### Explanation 1: Self-Selection Developers who adopt Cursor in a B2B environment tend to be more engaged with their craft. They're early adopters, power users, people who actively seek tools that improve their workflow. These developers might log more coding hours regardless of their IDE choice. ![Coding session patterns tracked through IDE heartbeats](https://pandev-metrics.com/img/blog/activity-heatmap.png) *Coding session patterns tracked through IDE heartbeats.* ### Explanation 2: The AI Flow State Cursor's inline AI suggestions and chat integration can reduce friction in common tasks: writing boilerplate, looking up API signatures, generating test cases, understanding unfamiliar code. If AI assistance removes micro-interruptions, developers may sustain longer coding sessions without reaching for a browser or documentation. Our data shows that Cursor users tend to have **longer average session lengths** compared to VS Code users — suggesting fewer interruptions or context switches during coding. ### Explanation 3: New Workflow Patterns AI-native editors create new workflow patterns. Instead of: 1. Write code → hit a problem → search Stack Overflow → return to editor Cursor users do: 1. Write code → hit a problem → ask Cursor → continue coding This "stay in the editor" pattern could explain both longer sessions and higher total hours. ### The Likely Reality All three factors probably contribute. Self-selection inflates the number somewhat, but the magnitude of the difference (65% more hours per user) is too large to attribute entirely to selection bias. Something about the AI-assisted workflow is keeping developers in their editors longer. ## What 24 Cursor Users in B2B Tells Us The fact that **24 professional developers** at B2B companies — not students, not hobbyists, not tech influencers — are using Cursor as their primary IDE is itself significant. Consider the barriers to adopting a new IDE in a corporate environment: - IT approval for new software - Learning curve and temporary productivity loss - Team standardization pressure ("everyone uses VS Code") - License costs - Plugin compatibility concerns That 24 developers overcame these barriers suggests Cursor is delivering enough value to justify the switching cost. ### The Adoption Curve Based on the technology adoption lifecycle, 24 out of ~150 total IDE users (across all tools) puts Cursor in the **early adopter** phase — past the innovator stage but not yet mainstream. If the adoption curve follows typical patterns, we could see Cursor usage double or triple within the next 12 months as word-of-mouth spreads within organizations. ## AI Extensions vs AI-Native: Does It Matter? Many VS Code users also have AI extensions installed — GitHub Copilot, Codeium, Tabnine, and others. Our data doesn't distinguish between VS Code with and without AI extensions. But the fact that Cursor users show different patterns than VS Code users (even those who likely have Copilot installed) suggests that **native AI integration matters more than bolt-on AI**. Why? Because Cursor was designed from the ground up around AI interaction. The AI isn't an extension that adds suggestions — it's a core part of the editing experience. Tab completion, inline chat, multi-file understanding, and codebase-aware suggestions are deeply integrated rather than layered on top. This has implications for the IDE market: VS Code's extension model may not be sufficient to compete with natively AI-integrated editors in the long run. ## The Productivity Question Every engineering leader wants to know: does AI-assisted coding make my team faster? Based on our data and industry research, here's an honest assessment: ### Where AI Copilots Clearly Help - **Boilerplate generation**: Standard patterns, CRUD operations, type definitions - **API exploration**: Understanding unfamiliar libraries without leaving the editor - **Test generation**: Creating test scaffolding and basic test cases - **Language translation**: Porting patterns from one language to another - **Documentation**: Generating docstrings and comments ### Where AI Copilots Are Neutral or Negative - **Complex architecture decisions**: AI suggestions follow patterns, not strategic thinking - **Novel algorithms**: AI can't write what hasn't been trained on - **Debugging subtle issues**: AI suggestions can mask root causes - **Security-critical code**: AI may suggest insecure patterns that look correct - **Domain-specific logic**: Business rules require context AI doesn't have ### The Net Effect For typical B2B development work — which involves a significant amount of boilerplate, API integration, and standard patterns — AI copilots likely deliver a **~10-25% productivity improvement** for experienced developers. This aligns with findings from McKinsey's research on AI-augmented software development, which reported ~20-45% time savings on specific coding tasks (though net productivity gains were lower). For juniors, the improvement may be higher (more boilerplate assistance) but carries a risk of reduced learning. ## Implications for Engineering Leaders ### 1. Don't Ban AI Tools Some organizations restrict AI coding tools due to security or IP concerns. This is increasingly a competitive disadvantage. Developers at companies with AI access will outproduce those without it. Address the concerns (data handling, code review of AI-generated code) rather than blocking the tool. ### 2. Measure the Impact, Don't Assume It Track coding patterns before and after AI tool adoption. PanDev Metrics can show you whether session lengths change, whether total coding hours shift, and whether weekly patterns evolve. Measure, don't guess. ### 3. Budget for AI IDEs If Cursor licenses cost $20/month per developer and deliver even a 5% productivity improvement for a developer who costs $150K/year, the ROI is enormous. $240/year for $7,500 in productivity gains. The math is straightforward. ### 4. Set Quality Guardrails AI-generated code still needs review. Establish clear expectations: - All AI-generated code goes through standard code review - Security-sensitive sections require manual review regardless of generation method - Test coverage requirements don't change because code was AI-generated - Developers must understand code they commit, whether they wrote it or AI suggested it ### 5. Watch for Over-Reliance Junior developers using AI copilots may accept suggestions without fully understanding them. This creates a learning debt that becomes visible when they need to debug or extend the code later. Balance AI assistance with deliberate learning opportunities. ## The Broader Trend > Forbes Kazakhstan reports that within teams using engineering intelligence platforms, the impact of AI copilots becomes measurable: "one developer writes 30% of their code with AI assistance, while another writes 70%" — highlighting the need to track AI's real effect on individual workflows rather than assuming uniform adoption. — [Forbes Kazakhstan, April 2026](https://forbes.kz) The shift from "developer writes every line" to "developer guides AI to write many lines" is the most significant change in software development since the move from on-premise to cloud. GitHub Octoverse data already shows that AI-generated code suggestions account for a growing share of accepted pull request content. Our data from 100+ B2B companies shows this shift is already happening in production environments — not just in demos and blog posts. The 24 Cursor users in our dataset today will be 100+ within a year, as AI-native tooling becomes the expected standard. Engineering leaders who invest in understanding and measuring this transition now will be better positioned than those who wait. ## Conclusion AI copilots are changing how developers work. Cursor users in our data log 65% more hours per person than VS Code users, likely driven by a combination of self-selection and genuine workflow improvements. The AI-native IDE is moving from experiment to production tool. The smart response isn't hype or fear. It's measurement. Track how AI tools change your team's patterns, invest in the ones that demonstrate real impact, and maintain quality standards regardless of how the code was generated. --- **Track how AI tools affect your team's coding patterns.** [PanDev Metrics](https://pandev-metrics.com) shows IDE usage, session lengths, and productivity trends — so you can measure the AI copilot effect in your own organization. --- ## New Developer Onboarding: How Metrics Show the Ramp-Up to Full Productivity URL: https://pandev-metrics.com/docs/blog/developer-onboarding-ramp Date: 2025-10-30 Tags: engineering-management, developer-productivity, onboarding, HR Description: New developers take 2-4 months to reach full productivity. Here's how to measure the onboarding ramp-up with real coding data — and how to shorten it. You've just hired a senior developer. They start Monday. When will they be fully productive? HR says "30 days." The hiring manager says "a few weeks." The developer themselves says "give me the codebase and I'll be fine." Reality is different. Coding activity data tells a more honest story about what new developer ramp-up actually looks like — and it's longer than most organizations plan for. ## The Uncomfortable Truth About Ramp-Up Most companies treat onboarding as a one-week event: laptop setup, access provisioning, a few introductory meetings, and then "you're good to go." The expectation is that a competent developer should be contributing meaningful code within days. Research from the DORA State of DevOps Reports shows that onboarding effectiveness is one of the strongest predictors of long-term team performance — yet it remains one of the least measured processes. This expectation is based on a fundamental misunderstanding. Setting up a development environment is not onboarding. Onboarding is the process of reaching full productivity — and for software developers, that process involves learning: - The codebase architecture and patterns - Business domain knowledge - Team conventions and coding standards - Deployment processes and infrastructure - Internal tools and workflows - Who to ask for what None of this happens in a week. ## What the Data Shows At PanDev Metrics, we track individual developer activity over time. When a new developer joins a company using our platform, we can observe their coding activity from day one and watch the ramp-up curve unfold. Based on patterns we've observed across our **100+ B2B companies** with **active B2B developers**: ### Week 1-2: The Setup Phase Coding activity is minimal. New developers are: - Setting up their development environment - Getting access to repositories and tools - Reading documentation (if it exists) - Attending introductory meetings - Making their first small commit (often a README edit or config change) **Typical coding activity: 10-20% of an established developer's daily output.** ### Week 3-4: The First Contributions Activity starts picking up. New developers tackle their first real tasks, usually small, well-scoped tickets: - Bug fixes in isolated components - Small feature additions with clear specifications - Test additions for existing code They're writing code, but slowly. Every task requires learning something new about the codebase. A change that would take a veteran 30 minutes takes the new hire 3 hours — not because they're a bad developer, but because they're learning the system while working. **Typical coding activity: 30-50% of baseline.** ![New developer metrics showing Activity Time ramp-up and Focus Time development](https://pandev-metrics.com/img/blog/employee-metrics-safe.png) *New developer metrics showing Activity Time ramp-up and Focus Time development.* ### Month 2: The Growth Phase This is where acceleration happens. The developer has enough context to work independently on medium-sized tasks. They've internalized the main patterns, know where to find things, and have built relationships with team members who can help when they get stuck. Coding hours per day increase significantly. Session lengths grow as the developer can sustain focus on longer tasks without needing to stop and look things up. **Typical coding activity: 60-80% of baseline.** ### Month 3-4: Approaching Full Productivity By the third month, most developers reach **80-100% of the team's average coding activity**. They're handling complex tasks, participating in architecture discussions, and reviewing others' code. Full productivity — where the new hire's output is indistinguishable from an established team member — typically arrives around month 3 for senior developers and month 4-6 for mid-level developers in complex codebases. ### The Shape of the Curve The ramp-up curve isn't linear. It's S-shaped: 1. **Slow start** (weeks 1-2): Minimal coding, mostly setup and learning 2. **Acceleration** (weeks 3-8): Rapid improvement as context builds 3. **Plateau approach** (months 3-4): Gradual convergence with team baseline Understanding this shape helps set realistic expectations for the new hire, their manager, and leadership. ## Factors That Speed Up Ramp-Up Based on patterns across companies in our dataset, these factors correlate with faster onboarding: ### 1. Documentation Quality Teams with comprehensive, up-to-date documentation (architecture docs, setup guides, coding conventions) show faster ramp-up times. This is obvious but underinvested. Every hour spent on documentation saves multiple hours across every future hire. ### 2. Pair Programming Companies that pair new hires with an experienced developer for the first 2-3 weeks show measurably faster coding activity growth. The new hire learns patterns, conventions, and tribal knowledge in real-time rather than through trial and error. ### 3. Well-Scoped First Tasks The best onboarding programs include a curated list of "first tasks" — small, self-contained issues that touch different parts of the codebase. Each task is a learning opportunity that builds context incrementally. Bad first tasks: "pick any ticket from the backlog" or "add this major feature." ### 4. Small, Clean Codebases This one is structural. Developers onboarding onto a clean, well-organized codebase ramp up faster than those facing a tangled legacy system. This isn't surprising, but it's worth noting: code quality affects not just maintenance but hiring velocity. ### 5. Automated Environment Setup Teams where the dev environment can be set up in under an hour (using Docker, Nix, or similar) skip the multi-day setup phase entirely. This alone can save a week of onboarding time. ## Factors That Slow Down Ramp-Up ### 1. Tribal Knowledge If important information lives only in people's heads, every new hire needs to extract it through conversations. This is slow, unreliable, and doesn't scale. The worst version: "ask John, he built that module" — where John is in a different time zone and always in meetings. ### 2. Complex, Undocumented Architecture Microservices without architecture diagrams. Shared libraries without READMEs. Config files with magic numbers. Each of these is a roadblock that slows onboarding and frustrates new hires. ### 3. Lack of Tests Without test coverage, new developers can't safely experiment. They can't refactor to understand the code. They can't verify that their changes work. Fear of breaking things is the #1 productivity killer during onboarding. ### 4. Organizational Overhead Long access provisioning processes, slow laptop setup, weeks of "security training" before code access — these administrative delays directly extend the ramp-up timeline. Every day a new developer can't write code is a day of lost productivity. ## The Cost of Slow Onboarding Let's do some rough math. A senior developer costs approximately $150K-$200K per year in salary, benefits, and overhead. That's roughly $750-$1,000 per working day. If your onboarding takes 3 months to reach full productivity (the typical case), the cost curve looks like: | Period | Lost Productivity | Cost (at $180K/year) | |--------|:-----------------:|:--------------------:| | Week 1-2 | 80-90% | ~$6,000-$7,000 | | Week 3-4 | 50-70% | ~$4,000-$5,500 | | Month 2 | 20-40% | ~$3,500-$7,000 | | Month 3 | 0-20% | ~$0-$3,500 | | **Total** | — | **$13,500-$23,000** | That's ~$13K-$23K in reduced productivity per hire. For a company making 10 hires a year, that's ~$135K-$230K in onboarding productivity loss. Brooks's Law compounds this further — each new hire temporarily slows existing team members who spend time mentoring and answering questions. Cutting the ramp-up by even 2 weeks saves ~$5,000-$7,000 per hire. ## How to Measure Onboarding with PanDev Metrics PanDev Metrics provides direct visibility into the onboarding ramp-up: ### Track Daily Coding Hours Compare the new hire's daily coding hours to the team average over their first 90 days. The convergence point is your real "time to productivity" — not the date they cleared HR paperwork. ### Monitor Language and Project Distribution A developer who's working across multiple repositories and languages is building broad context. One who's stuck in a single file for weeks may be blocked or struggling. ### Watch for Activity Gaps Long periods of zero coding activity during the first month often indicate environment setup issues, access problems, or a lack of clear first tasks. ### Compare Across Hires With multiple data points, you can benchmark your onboarding process. If Developer A reached baseline in 8 weeks and Developer B took 14 weeks, what was different? The data gives you a starting point for the conversation. ## Recommendations for Engineering Managers 1. **Set realistic expectations.** Tell new hires and leadership that full productivity takes 2-4 months. This reduces pressure on the new hire and prevents leadership from wondering why the "senior developer we just hired isn't delivering yet." 2. **Invest in documentation.** Every architectural decision, setup step, and convention that's documented saves onboarding time for every future hire. It's the highest-leverage investment you can make. 3. **Automate dev environment setup.** If your setup takes more than an hour, fix it. Invest in containerized dev environments or setup scripts. 4. **Assign a buddy.** A dedicated onboarding buddy for the first 3-4 weeks accelerates learning significantly. Choose someone patient and knowledgeable, and give them protected time for this role. 5. **Measure and iterate.** Track onboarding ramp-up for every hire. Compare timelines. Identify what works and what doesn't. Treat onboarding as a process to optimize, not a one-time event. ## Conclusion Developer onboarding takes longer than most organizations acknowledge. The typical ramp-up to full productivity is 2-4 months, with a characteristic S-shaped curve. This timeline can be shortened significantly with good documentation, pair programming, and automated setup — or extended by tribal knowledge, complex systems, and organizational bureaucracy. The first step is measuring it. You can't improve what you can't see. --- **Track onboarding ramp-up with real data.** [PanDev Metrics](https://pandev-metrics.com) shows individual developer activity over time — so you can see exactly how quickly new hires reach full productivity. --- ## Technical Debt: How to Show Your CEO That Refactoring Is an Investment URL: https://pandev-metrics.com/docs/blog/technical-debt-cost Date: 2025-10-27 Tags: engineering-management, technical-debt, CTO, leadership Description: CTOs struggle to justify refactoring. Here's how to use developer activity data to build a business case your CEO will understand. Every CTO has had this conversation. You walk into the CEO's office and say, "We need to spend the next quarter refactoring." The CEO asks, "What's the business value?" You struggle to answer in terms that don't involve the words "architecture," "coupling," or "dependency injection." The DORA State of DevOps Reports consistently find that teams burdened by technical debt deploy ~50% less frequently and have ~2-3x higher change failure rates. The CEO isn't wrong to ask. They're not anti-engineering. They just need to understand the investment in business terms. And that's where most CTOs fail — not because they're bad communicators, but because they don't have the right data. Here's how to fix that. ![Project time tracking showing where engineering hours actually go](https://pandev-metrics.com/img/blog/projects.png) *Project time tracking showing where engineering hours actually go.* ## Why the Refactoring Conversation Fails The typical refactoring pitch goes like this: > **CTO**: "Our backend has accumulated significant technical debt. The authentication module is tightly coupled to the billing system. We need 6 weeks to refactor it." > > **CEO**: "What happens if we don't?" > > **CTO**: "It'll be harder to add features." > > **CEO**: "How much harder? Can you quantify it?" > > **CTO**: "...It's hard to quantify." And that's where the conversation dies. The CEO makes a reasonable business decision: without quantified cost, they prioritize work that has quantified value (new features, customer requests). The CTO walks away frustrated, convinced the CEO "doesn't get it." But the real problem isn't the CEO's understanding — it's the CTO's inability to present the data. ## Technical Debt Has a Measurable Cost Technical debt isn't an abstract concept. It manifests as concrete, observable effects on developer activity: ### 1. Slower Feature Development When code is tangled, every new feature takes longer. A change that should take 2 days takes 5 because the developer has to understand and work around accumulated complexity. **How to measure it**: Track how long similar-sized features take over time. If features that took 1 week six months ago now take 2 weeks, you can calculate the cost: *Extra time per feature × developer daily cost × number of features per quarter = quarterly debt tax* ### 2. More Context-Switching Legacy codebases with poor separation of concerns force developers to touch multiple files and modules for simple changes. This creates fragmented coding sessions — developers jump between files, lose context, and spend time re-orienting. **How to measure it**: PanDev Metrics tracks coding session patterns. Shorter, more fragmented sessions compared to historical baselines can indicate growing architectural complexity. With **extensive activity data** in our dataset, we can see these patterns clearly. ### 3. Longer Debugging Sessions Technical debt makes bugs harder to find and fix. When modules are tightly coupled, a bug's symptoms appear far from its cause. Developers spend hours tracing through layers of indirection. **How to measure it**: Track time spent on bug fixes versus new features over time. An increasing proportion of time on bug fixes is a debt signal. ### 4. Onboarding Slowdown New developers ramp up slower in debt-heavy codebases. Complex, undocumented, tangled code takes longer to understand. This has a direct cost (see our article on developer onboarding). **How to measure it**: Compare onboarding ramp-up times across different periods. If new hires are taking longer to reach full productivity, debt is likely a factor. ### 5. Reduced Developer Satisfaction and Retention This one is harder to quantify but has the highest cost. Developers leave companies with painful codebases. The Stack Overflow Developer Survey consistently ranks "working with legacy code" and "poor tooling" among the top reasons developers consider leaving. Replacing a developer costs ~50-200% of their annual salary in recruiting, onboarding, and lost productivity. **How to measure it**: Exit interviews, developer satisfaction surveys, and Glassdoor reviews all provide qualitative signals. Combined with activity data showing declining coding engagement, you have a compelling narrative. ## Building the Business Case: A Framework Here's a step-by-step approach to making the refactoring case in terms a CEO understands. ### Step 1: Quantify the Current "Debt Tax" The debt tax is the amount of developer time consumed by working around technical debt rather than delivering new value. Calculate it like this: **Method A: Time-based comparison** - Estimate how long a typical feature *should* take (based on similar features in cleaner parts of the codebase) - Measure how long it *actually* takes in the debt-heavy area - The difference is the debt tax per feature - Multiply by the number of features per quarter *Example: If the debt-heavy area adds 3 extra days to every feature, and you ship 12 features per quarter, that's 36 developer-days — roughly $25,000-$35,000 per quarter at senior developer rates.* **Method B: Activity-based measurement** - Use PanDev Metrics to track coding patterns over time - Identify declining efficiency (shorter sessions, more fragmented work, lower total coding hours) - Correlate with the accumulation of known technical debt items ### Step 2: Project the Future Cost of Inaction Technical debt compounds. If the debt tax is $30K/quarter today and growing at 20% per year: | Quarter | Quarterly Debt Tax | Cumulative Annual Cost | |---------|:------------------:|:----------------------:| | Q1 2026 | $30,000 | — | | Q2 2026 | $31,500 | — | | Q3 2026 | $33,000 | — | | Q4 2026 | $34,500 | $129,000 | | Q4 2027 (projected) | $41,500 | $155,000 | Show this trajectory. CEOs understand compound costs. ### Step 3: Estimate the Refactoring Investment Be specific and honest: - Number of developers needed - Duration in weeks - Total cost (developer-weeks × loaded cost) - What feature work will be deferred *Example: "We need 3 developers for 6 weeks = 18 developer-weeks. At $10K/week loaded cost, the investment is $180K. During this time, we'll defer the analytics dashboard and the API v3 migration."* ### Step 4: Calculate the ROI Compare the refactoring cost to the projected debt savings: *Example: "$180K investment eliminates ~$120K/year in debt tax. Payback period: 18 months. Plus: faster feature delivery, easier onboarding for the 4 hires we're planning, and reduced risk of a major incident in the billing system."* ### Step 5: Add the Risk Factor CEOs are risk-aware. Quantify the downside of inaction: - "If the authentication-billing coupling causes a production incident, estimated cost is $X in downtime and customer impact" - "If senior developer Y leaves due to codebase frustration (they've mentioned it), replacement cost is $Y" - "If we can't deliver Feature Z on time due to debt, the revenue impact is $Z" ## The Right Language When presenting to a CEO, translate engineering concepts: | Engineering Language | CEO Language | |---------------------|-------------| | Technical debt | Maintenance backlog that slows delivery | | Refactoring | Infrastructure investment that accelerates future delivery | | Code coupling | Interdependencies that create risk and slow changes | | Test coverage | Quality assurance that prevents costly incidents | | Architecture improvements | Structural changes that reduce operating cost | **Don't say**: "The code is a mess and we need to fix it." **Say**: "We're spending an estimated $120K/year in reduced developer productivity due to structural issues in our billing module. A $180K investment in Q2 will eliminate this recurring cost, accelerate feature delivery by an estimated 25%, and reduce the risk of billing-related incidents." ## Using Data to Support the Case This is where engineering intelligence platforms like PanDev Metrics add enormous value to the conversation. ### Before and After Metrics Establish baseline measurements before the refactoring and track improvements after: - **Feature delivery time**: Average days from ticket start to merge - **Coding hours per feature**: Tracked via IDE heartbeats - **Session fragmentation**: Average session length as a proxy for focus quality - **Bug fix ratio**: Proportion of time on fixes vs. new development - **Onboarding speed**: Ramp-up time for new hires Present these as a dashboard to the CEO. Numbers are more persuasive than narratives. ### Weekly Progress During Refactoring One of the CEO's biggest fears with refactoring is: "How do I know the team is actually making progress and not just gold-plating?" Activity data provides transparency. During the refactoring period, show: - Total coding hours on refactoring tasks (proving the team is actively working) - Proportion of codebase touched (showing scope progress) - Test coverage changes (showing quality improvement) This transparency builds trust and makes future refactoring proposals easier to approve. ## Common Objections and Responses ### "Can we do it incrementally instead?" Sometimes yes, sometimes no. Incremental refactoring works for localized debt. Structural problems (like tightly coupled modules) often require a concentrated effort. Present both options with timeline and cost comparisons. ### "What features are we delaying?" Have a specific answer. List the features that will be deferred, their expected value, and why the refactoring ROI exceeds the deferral cost. If you can't show that, the CEO is right to question the priority. ### "How do I know this won't happen again?" Acknowledge that technical debt is ongoing. Propose a sustainable approach: allocate ~10-20% of sprint capacity to continuous debt reduction. SaaStr benchmarks suggest that high-performing SaaS engineering teams allocate ~15-20% of capacity to platform health and debt reduction as a standard practice. Show how tracking tools like PanDev Metrics can provide early warnings before debt accumulates to crisis levels. ### "Can we hire contractors to do it?" Usually no. Refactoring requires deep system knowledge. Contractors can write new features but are the wrong tool for restructuring existing code. Explain that this requires your most experienced developers, which is exactly why it has an opportunity cost. ## Conclusion The refactoring conversation fails when CTOs speak in engineering terms to a business audience. The fix is data: quantify the debt tax, project the cost of inaction, estimate the investment, and calculate the ROI. Engineering intelligence tools make this possible by providing concrete activity metrics — not opinions, not estimates, but measured data about how developer time is being spent. Your CEO isn't the enemy of good engineering. They just need the same thing you'd want if someone asked you for a $180K investment: a clear business case backed by data. --- **Build the business case with data.** [PanDev Metrics](https://pandev-metrics.com) tracks developer activity patterns over time — giving CTOs the numbers they need to justify engineering investments. --- ## Developer Gamification: Levels, Badges, and XP — Does It Work or Annoy? URL: https://pandev-metrics.com/docs/blog/gamification-works-or-annoys Date: 2025-10-24 Tags: gamification, developer-experience, engineering-management, devex Description: Gamification in engineering teams is polarizing. Levels, badges, and XP can motivate or alienate. Here's an honest look at when it works and when it backfires. Add XP, levels, and badges to a developer platform and you'll get two reactions. Some developers light up — they check their progress daily, compete on leaderboards, and proudly display badges on their GitHub profiles. Others recoil — they see it as surveillance dressed up in game mechanics, an infantilizing system that reduces their craft to a score. Both reactions are valid. The question isn't whether gamification works in absolute terms. It's when, how, and for whom. ![Activity Time and Focus Time indicators — the metrics behind gamification levels](https://pandev-metrics.com/img/blog/employee-metrics-safe.png) *Activity Time and Focus Time indicators — the metrics behind gamification levels.* ## What Developer Gamification Actually Looks Like Let's define terms. When we talk about gamification in engineering, we mean applying game-like mechanics to developer workflows: - **XP (Experience Points)**: Points accumulated through coding activity, code reviews, commits, or other contributions - **Levels**: Progression tiers unlocked by accumulating XP (e.g., Level 1 Novice → Level 10 Master) - **Badges/Achievements**: One-time awards for specific accomplishments (e.g., "First Pull Request," "100-Day Streak," "Polyglot — coded in 5 languages") - **Leaderboards**: Rankings comparing developers within a team or organization - **Profile decorations**: Visual indicators (like SVG badges for README profiles) that showcase achievements PanDev Metrics implements several of these mechanics. With **nearly 1,000 individual users** across **100+ B2B companies**, we've observed how real engineering teams interact with gamification features. Here's what we've learned — the good, the bad, and the nuanced. ## The Case FOR Gamification ### 1. It Makes Invisible Work Visible Most developer work is invisible. You write code, push it, and it disappears into the product. Gamification creates tangible markers of progress. When a developer reaches Level 5 or earns a "Code Review Champion" badge, there's a concrete acknowledgment of work that would otherwise go unnoticed. This matters more than you might think. Research from the Developer Experience Collective and findings in the Stack Overflow Developer Survey confirm that "feeling recognized for contributions" is one of the top 5 factors in developer job satisfaction. Gamification, when done well, provides this recognition automatically and consistently — without relying on managers to remember to say "good job." ### 2. It Encourages Desired Behaviors Smart gamification design rewards behaviors the organization wants to encourage: - Badge for thorough code reviews → developers write better reviews - XP for documentation contributions → documentation improves - Achievement for mentoring new hires → onboarding gets better - Streak badges for consistent activity → reduces extreme feast-or-famine work patterns The key is aligning incentives with outcomes that benefit both the individual and the team. If the gamification system rewards the right things, it subtly steers behavior in a positive direction. ### 3. It Creates a Shared Language Levels and badges create a common vocabulary for progress. Instead of vague discussions about seniority, teams can reference concrete milestones. "She reached Level 8 — she's been incredibly consistent" is more specific than "she's doing well." This shared language is especially valuable for distributed teams where visibility into individual contributions is limited. ### 4. It Adds Fun (For Some People) Let's not over-intellectualize it. Some developers enjoy gamification. They like seeing numbers go up, unlocking achievements, and having a visual representation of their work. Not every system needs a deep psychological justification. If it makes work slightly more enjoyable for a portion of your team, that has value. ## The Case AGAINST Gamification ### 1. Goodhart's Law: When the Metric Becomes the Target "When a measure becomes a target, it ceases to be a good measure." This is the #1 risk of gamification. If XP is based on lines of code, developers write verbose code. If it's based on commits, they make tiny commits. If it's based on hours logged, they leave their IDE open while browsing Reddit. **The mitigation**: Design the XP system to reward outcomes that are genuinely valuable and hard to game. PanDev Metrics tracks actual coding activity via IDE heartbeats — you can't inflate your hours by leaving Slack open. But no system is completely game-proof, and acknowledging this limitation is important. ### 2. Extrinsic vs. Intrinsic Motivation Self-Determination Theory (Deci & Ryan) suggests that extrinsic rewards can undermine intrinsic motivation. If a developer who previously coded for the joy of problem-solving starts coding for XP, their underlying motivation shifts. Remove the XP, and they may feel less motivated than before. This is a real concern. The research on this is mixed — some studies show gamification increases engagement, others show it crowds out intrinsic motivation. The effect likely depends on the individual and the implementation. **The nuance**: Gamification works best as *recognition* rather than *reward*. "Here's a badge acknowledging what you already do well" is different from "do more of this to earn points." The first reinforces intrinsic motivation. The second replaces it. ### 3. It Can Feel Surveillance-Like Developers are highly sensitive to monitoring. Any system that tracks their activity and converts it to scores can feel like surveillance. Even if the intent is motivation, the perception may be control. **The mitigation**: Transparency and opt-in design. Developers should understand exactly what's tracked, how scores are calculated, and have agency over what's public. PanDev Metrics shows developers their own data first — it's a tool for self-reflection, not a panopticon. ### 4. Unhealthy Competition Leaderboards can turn collaboration into competition. If Developer A is one rank ahead of Developer B, Developer B might skip helping a colleague to protect their coding time. Worse, developers might overwork — sacrificing health, weekends, and relationships to climb the rankings. **The mitigation**: See our separate article on setting up leaderboards the right way. Short version: emphasize team achievements, use timeboxed challenges rather than permanent rankings, and never tie gamification to compensation or performance reviews. ### 5. One Size Doesn't Fit All Some developers are competitive and love leaderboards. Others are intrinsically motivated and find gamification distracting. Some are early-career and benefit from progress markers. Others are senior and find levels patronizing. A gamification system that assumes all developers respond the same way will alienate a significant portion of the team. **The mitigation**: Make gamification features optional. Let individuals choose whether to display badges, participate in leaderboards, or track XP. The developers who enjoy it will opt in. The others won't be bothered. ## What We've Learned from Nearly 1,000 Users At PanDev Metrics, we've rolled out gamification features (levels, XP, achievements, SVG badges for README profiles) across **nearly 1,000 users** at **100+ B2B companies**. Here's what we've observed: ### Engagement Is Bimodal Developers split into two clear groups: - **Active engagers** (~40-50%): Check their progress regularly, display badges, compare with peers - **Passive users** (~50-60%): Aware the features exist, don't actively engage, focus on the data/metrics aspects of the platform This split mirrors broader gamification research — a ~40/60 active-to-passive engagement ratio is common across enterprise gamification implementations. Very few users are actively hostile to the gamification features. Most who don't engage simply ignore them. This suggests that optional gamification adds value for those who want it without bothering those who don't — as long as it's not mandatory. ### Badges Drive Profile Engagement The SVG badges for README profiles are disproportionately popular. Developers enjoy adding visual indicators to their GitHub profiles. This is gamification at its least controversial — it's self-expression, not competition. ### Streaks Are Powerful but Dangerous Streak-based achievements (e.g., "Coded every workday for 30 days") are the most engaging *and* the most problematic. They drive consistency but can also drive unhealthy behavior — developers coding while sick or on vacation to maintain a streak. We recommend capping streak requirements (e.g., "20 out of 22 workdays" rather than "every single day") and celebrating recovery from broken streaks rather than only rewarding perfect runs. ### Team-Level Gamification Works Better Than Individual When gamification features are applied at the team level ("Team Alpha reached 500 total coding hours this sprint"), it fosters collaboration rather than competition. Individual leaderboards work in small doses but can be toxic at scale. ## Best Practices for Implementing Developer Gamification ### 1. Make It Optional Every gamification feature should be opt-in or easily ignorable. No one should be forced to see leaderboards, display badges, or track XP if they don't want to. ### 2. Reward What Matters Design XP and achievements around behaviors that align with engineering excellence: - Code review thoroughness - Documentation contributions - Mentoring and onboarding assistance - Consistent (not excessive) coding patterns - Cross-team collaboration Avoid rewarding pure output volume (lines of code, number of commits, hours logged). ### 3. Never Tie to Compensation The moment gamification scores affect bonuses, raises, or promotions, you've created a perverse incentive system. Keep gamification in the recognition layer, separate from the evaluation layer. ### 4. Iterate Based on Feedback Ask your team how they feel about the gamification features. Run anonymous surveys. If 70% of the team loves leaderboards and 30% hates them, that's useful data. If it's 50/50, consider making them less prominent. ### 5. Design for Long-Term Engagement Gamification that's exciting for a month and boring by month three has failed. Design progression systems with long-term arcs: harder achievements at higher levels, seasonal challenges, and evolving goals that keep engaged developers interested. ## The Verdict Developer gamification is a tool. Like any tool, its value depends on how it's used. **It works when**: - It's optional and non-intrusive - It rewards genuinely valuable behaviors - It's separated from performance evaluation - It creates recognition for invisible work - It's applied at the team level more than the individual level **It annoys when**: - It's mandatory and pervasive - It creates perverse incentives (gaming the system) - It feels like surveillance - It drives unhealthy competition - It ignores individual differences in motivation style The companies that get the most value from gamification in our dataset treat it as a *complement* to engineering culture, not a replacement for it. You can't gamify your way out of bad management, unrealistic deadlines, or a toxic work environment. But in a healthy team, thoughtfully designed gamification adds a layer of engagement and recognition that many developers genuinely appreciate. --- **Explore gamification that developers actually enjoy.** [PanDev Metrics](https://pandev-metrics.com) offers levels, XP, achievements, and SVG badges — designed to recognize great work, not to surveil it. --- ## Motivating Developers Without the Stick: Positive Reinforcement Through Data URL: https://pandev-metrics.com/docs/blog/motivating-without-stick Date: 2025-10-22 Tags: engineering-management, developer-experience, motivation, leadership Description: Punitive metrics destroy trust. Here's how engineering managers can use activity data as positive reinforcement — celebrating wins, not hunting slackers. The most common fear engineers have about activity tracking is simple: "My manager will use this data against me." They're not wrong to worry. Many organizations have implemented "productivity metrics" as a stick — identifying who codes the least, who commits the fewest lines, who logs the shortest hours. The result is predictable: developers game the metrics, resentment builds, top performers leave, and the remaining team optimizes for looking busy rather than being effective. There's a better way. Data can be a tool for positive reinforcement — and it's far more effective. ![Activity patterns that reveal engagement, not just output](https://pandev-metrics.com/img/blog/activity-heatmap.png) *Activity patterns that reveal engagement, not just output.* ## The Problem with the Stick Let's be direct about what punitive metrics look like in practice: - **Stack ranking by lines of code**: Rewarding volume over quality - **Public shaming of "low performers"**: Based on hours logged or commits made - **Mandatory minimum coding hours**: Treating knowledge work like factory shifts - **Using activity data in performance reviews**: Without context or nuance These approaches fail for predictable reasons: ### Developers Are Not Factory Workers Software development is creative knowledge work. Output isn't proportional to input time. A developer who solves a critical architecture problem in 2 hours of deep thinking delivers more value than one who writes 8 hours of boilerplate. When you measure and punish based on visible activity, you incentivize visible activity — not value creation. ### Goodhart's Law Strikes Again Once developers know they're being measured on commits, they make more (smaller) commits. Measured on lines of code? More verbose code. Measured on hours in the IDE? They leave editors open while doing other things. Every punitive metric creates its own workaround. The metric goes up. Actual productivity stays flat or declines. ### Trust Destruction Is Expensive Trust is the most valuable and fragile resource in an engineering team. Once developers believe their data is being used against them, they: - Stop sharing honest status updates - Avoid asking for help (it might make them look slow) - Resist adopting new tools (they might reduce their visible output during the learning curve) - Start job searching (the market for good developers is always hot) Replacing a developer costs 50-200% of their annual salary. Destroying trust to gain a marginal (illusory) productivity improvement is terrible ROI. ## The Alternative: Data as Positive Reinforcement The same activity data that can be weaponized can also be used to celebrate, support, and develop your team. Here's how. ### Principle 1: Celebrate Wins, Don't Hunt Failures Instead of identifying who coded the least this week, identify who had a great week: - "Alex, your coding sessions this sprint were incredibly focused — your longest session was 3.5 hours of uninterrupted work. That's impressive." - "The frontend team hit a new weekly record for total coding hours. Great momentum on the dashboard feature." - "Maria earned the Polyglot achievement — she's contributed to TypeScript, Python, and Go this month." Positive recognition is more motivating than negative criticism. This isn't soft management — it's backed by decades of behavioral psychology research. Reinforced behaviors repeat. Punished behaviors hide. ### Principle 2: Use Data for Self-Reflection, Not Surveillance The most powerful use of activity data is giving developers visibility into their own patterns. Most developers don't have an accurate picture of how they spend their time. When a developer sees their own data: - "I thought I coded 4 hours a day, but it's actually 1.5 hours. Where does the rest of my time go?" - "I'm most productive on Tuesday and Wednesday. Maybe I should schedule my hardest work then." - "I haven't touched the backend in 3 weeks. I should probably re-engage with that module." These insights drive self-improvement without any management pressure. The developer owns the discovery and the response. PanDev Metrics is designed around this principle. Developers see their own dashboards. They control what's visible to others. The data serves the individual first, the manager second. ### Principle 3: Coach, Don't Police When data shows a potential issue — like a developer's coding hours dropping significantly — the correct response is curiosity, not punishment: **Punitive approach**: "Your coding hours are down 40% this month. What's going on?" **Coaching approach**: "I noticed your activity patterns have shifted recently. Are there blockers I can help with? Meeting overload? Unclear requirements? Something outside work?" The coaching approach treats the data as a signal to start a supportive conversation, not as evidence for a disciplinary one. Nine times out of ten, declining activity has a fixable cause: too many meetings, unclear priorities, a personal issue, or a particularly difficult technical problem. ### Principle 4: Aggregate, Don't Individualize (for Management Purposes) Engineering managers should primarily look at **team-level** data: - Total team coding hours (is the team consistently productive?) - Weekly patterns (is Tuesday still the peak? Is Friday reasonable?) - Language and project distribution (is work balanced across the codebase?) Individual data should be for the individual. Team data should be for the manager. When a manager needs to look at an individual's data, it should be with the developer present, in the context of a supportive 1:1. ### Principle 5: Recognize Consistency, Not Just Peaks Some developers have explosive productive days followed by low-activity recovery days. Others maintain steady, consistent output. Both patterns can be effective, but consistency is often undervalued. Use data to recognize consistent contributors: - "You've been active every workday for the past month — that's a solid streak." - "Your coding hours have been remarkably stable. That kind of consistency is the backbone of reliable delivery." Consistency badges and streak achievements (like those in PanDev Metrics) provide this recognition automatically. ## Practical Playbook for Engineering Managers ### Weekly Team Wins Start your weekly team sync with data-driven wins: 1. Open the team dashboard in PanDev Metrics 2. Highlight total team coding hours and compare to the previous week 3. Call out individual achievements (new badges, level-ups, streak milestones) 4. Celebrate the team's most productive day 5. Acknowledge challenges without blame ("Friday was lighter than usual — let's make sure the sprint scope is realistic") This takes 3 minutes and sets a positive tone for the entire meeting. ### Monthly 1:1 Data Review In your monthly 1:1 with each developer: 1. Share their activity dashboard (they've already seen it — this is a joint review) 2. Ask what patterns they notice 3. Discuss what's working and what's not 4. Identify environmental improvements you can make (fewer meetings, clearer requirements, better tooling) 5. Set voluntary goals based on the developer's own observations **Never**: Use the data to criticize, compare with other individuals, or set mandatory activity targets. ### Quarterly Team Retrospective Every quarter, review team-level trends: - Is total team activity increasing, stable, or declining? - Are weekly patterns healthy (peak mid-week, reasonable Friday, minimal weekend)? - Are there language or project distribution imbalances? - What achievements and milestones did the team hit? Use this as input for process improvements, not performance evaluations. ## What About Genuinely Low Performers? The inevitable question: "What if someone really isn't performing? Don't I need data to address it?" Yes — but not activity data alone. Genuine performance issues are visible through multiple signals: - **Delivery**: Are committed tasks being completed on time? - **Quality**: Are code reviews flagging consistent issues? - **Collaboration**: Are teammates reporting communication problems? - **Growth**: Is the developer improving over time, or stagnating? Activity data might confirm a pattern you've already identified through these signals. But it should never be the *starting point* for a performance conversation. Start with outcomes, not inputs. And when you do address performance issues, the conversation should still be coaching-oriented: "I've noticed deliverables have been delayed recently, and I want to help. Let's look at the data together and figure out what's blocking you." This preserves dignity, identifies root causes, and often resolves the issue without adversarial dynamics. ## The ROI of Positive Reinforcement Is the "soft" approach actually more effective? The evidence says yes: - **Gallup research** consistently shows that recognized employees are ~20% more productive, more engaged, and less likely to leave - **Google's Project Oxygen** found that the most effective managers are good coaches, not disciplinarians — this aligns with Cal Newport's *Deep Work* argument that protecting focus time is a manager's highest-leverage action - **Microsoft's shift away from stack ranking** in 2013 was followed by a cultural and business renaissance — not a coincidence - **The Stack Overflow Developer Survey** data on job satisfaction consistently ranks "feeling of accomplishment" and "peer recognition" above compensation as drivers of retention In engineering specifically, positive environments attract and retain better talent. In a market where top developers have multiple offers, the company that makes them feel valued wins. ## Building a Culture, Not Just a System Tools like PanDev Metrics provide the data infrastructure. But the culture is up to you. **The tool doesn't determine the outcome. The culture does.** In a high-trust culture, activity data is fuel for celebration, coaching, and self-improvement. In a low-trust culture, the same data becomes a weapon. The tool is neutral. The leader's intent makes the difference. If you're an engineering manager considering activity tracking for your team, start by asking yourself: "Am I implementing this to help my team or to control them?" If the answer is "control," fix your management approach first. The tool won't save you. If the answer is "help" — then you have an opportunity to build something genuinely valuable: a data-informed culture where developers feel seen, supported, and motivated to do their best work. ## Conclusion The stick doesn't work with developers. Punitive metrics destroy trust, incentivize gaming, and drive top talent away. The alternative — using data for positive reinforcement, self-reflection, and coaching — is both more humane and more effective. Activity data is powerful. Use that power wisely: celebrate wins, coach through challenges, and trust your team to be motivated by recognition rather than fear. --- **Data for motivation, not surveillance.** [PanDev Metrics](https://pandev-metrics.com) gives developers their own activity dashboards and gives managers team-level insights — designed for positive reinforcement, not policing. --- ## Developer Experience: What It Is and How to Measure It URL: https://pandev-metrics.com/docs/blog/developer-experience-measure Date: 2025-10-20 Tags: developer-experience, engineering-management, devex, metrics Description: Developer Experience (DevEx) is the new competitive advantage. Learn what it means, why it matters, and how to measure it with real data — not just surveys. Developer Experience — DevEx or DX — has gone from a niche concept to a boardroom topic. Companies like Google, Spotify, and Shopify have dedicated DevEx teams. Job postings for "Developer Experience Engineer" have tripled since 2023. The JetBrains Developer Ecosystem Survey now includes DevEx-specific questions, signaling that the industry treats this as a measurable dimension, not a buzzword. But what *is* Developer Experience? How do you measure something that feels inherently subjective? And why should a VP of Engineering care? ![Focus Time and Activity Time — quantitative DevEx dimensions tracked automatically](https://pandev-metrics.com/img/blog/employee-metrics-safe.png) *Focus Time and Activity Time — quantitative DevEx dimensions tracked automatically.* ## Defining Developer Experience Developer Experience is the sum of all interactions a developer has with the tools, processes, systems, and culture of their organization, and how those interactions affect their ability to do their best work. It's not one thing. It's everything: - **Tools**: IDE quality, CI/CD speed, internal platform reliability - **Processes**: Code review turnaround, deployment frequency, bureaucratic overhead - **Codebase**: Architecture clarity, documentation quality, test coverage - **Culture**: Psychological safety, recognition, autonomy, trust - **Environment**: Meeting load, focus time availability, on-call burden Good DevEx means developers can focus on solving problems rather than fighting their environment. Bad DevEx means half their energy goes to working around broken tools, confusing processes, and organizational friction. ## Why DevEx Matters (The Business Case) If DevEx sounds like a "nice to have" — something for companies that have already solved their real problems — consider the business implications: ### Retention Developers leave jobs because of bad developer experience more often than because of salary. In the Stack Overflow Developer Survey, the top reasons for leaving included "poor tools and infrastructure," "too much bureaucratic process," and "inability to do deep work due to meetings." This echoes Cal Newport's argument in *Deep Work* that knowledge workers need protected focus time to produce their best output. Replacing a developer costs ~$50K-$200K (recruiting, onboarding, lost productivity). If improving DevEx prevents even 2-3 departures per year, the ROI is immediate. ### Productivity Good DevEx directly improves productivity. When CI/CD pipelines are fast, developers iterate quickly. When documentation is current, new features get built without tribal knowledge hunts. When code review is responsive, pull requests don't sit in limbo for days. Research from DX (formerly Jellyfish/Uplevel) and other platforms consistently shows that teams with better DevEx metrics ship faster with fewer defects. ### Recruiting Top developers choose employers partly based on DevEx signals. They ask in interviews: "What's your deployment process? How long does CI take? What tools do you use?" Companies with strong DevEx attract better candidates. ### Innovation When developers aren't fighting their environment, they have cognitive bandwidth for creative problem-solving. The companies that produce the most innovative software tend to be the ones that obsess over their developers' daily experience. ## The Three Dimensions of DevEx A useful framework for understanding DevEx comes from the 2023 paper "DevEx: What Actually Drives Productivity" by Noda, Storey, and colleagues. They identified three core dimensions: ### 1. Flow State Can developers achieve and maintain deep focus? Flow state — the psychological state of complete immersion in a task — is where the highest-quality work happens. **What breaks flow**: Frequent meetings, Slack interruptions, slow builds, unclear requirements, context-switching between unrelated tasks. **What enables flow**: Protected focus time, fast feedback loops (build, test, deploy), clear task definitions, minimal process overhead. ### 2. Feedback Loops How quickly do developers get feedback on their work? Fast feedback loops mean developers can iterate rapidly. Slow loops mean they wait, lose context, and switch to other tasks. **Key feedback loops**: - **Build time**: How long from code change to seeing results? (Seconds vs. minutes vs. hours) - **Test execution**: How quickly do tests run? Can developers run them locally? - **Code review**: How long from PR submission to first review? (Hours vs. days) - **Deployment**: How quickly can a change reach production? (Minutes vs. weeks) ### 3. Cognitive Load How much mental overhead does the development process impose? High cognitive load means developers spend mental energy on things unrelated to the actual problem they're solving. **Sources of cognitive load**: Complex configurations, undocumented tribal knowledge, unclear ownership boundaries, too many tools and platforms, inconsistent processes across teams. ## How to Measure Developer Experience This is where it gets practical. DevEx has both subjective and objective components, and measuring it well requires both. ### Subjective Measures: Surveys Surveys capture how developers *feel* about their experience. This matters because perception drives behavior — a developer who perceives their environment as frustrating will be less engaged, regardless of objective metrics. **Effective DevEx survey questions**: - "On a scale of 1-10, how easy is it to get your work done in our current environment?" - "What is the single biggest time-waster in your daily workflow?" - "How often do you achieve a state of deep focus during the workday?" (Never / Rarely / Sometimes / Often / Daily) - "How satisfied are you with our development tools and infrastructure?" - "Would you recommend our engineering environment to a friend?" (Developer NPS) **Survey best practices**: - Run quarterly, not annually (things change fast) - Keep it under 10 questions - Make it anonymous - Share results transparently with the team - Act on at least one finding per quarter ### Objective Measures: Activity Data Surveys tell you how people feel. Activity data tells you what's actually happening. Both are needed. PanDev Metrics provides several objective DevEx indicators: **1. Total Coding Hours** How much time do developers actually spend coding? Our data from **100+ B2B companies** with **thousands of tracked coding hours** shows wide variation. Teams with better DevEx tend to have higher coding-to-meeting ratios. **2. Session Length** Average uninterrupted coding session length is a proxy for flow state. Longer sessions suggest fewer interruptions. If your team's average session length is declining, something is breaking their focus. **3. Weekly Patterns** A healthy team shows **Tuesday as peak day** (as our data consistently demonstrates) with a reasonable Friday and minimal weekends. An unhealthy pattern: flat or increasing weekend activity, which suggests weekday environments aren't conducive to getting work done. **4. Language and Tool Distribution** Tracking which languages and IDEs developers use (we track **236 languages** and tools like **VS Code at 3,057h**, **IntelliJ at 2,229h**, **Cursor at 1,213h**) reveals whether the organization is investing in the right tooling for the stack they actually use. **5. Onboarding Ramp-Up** How quickly new developers reach full productivity is a direct DevEx metric. Faster ramp-up = better documentation, cleaner code, more effective onboarding processes. ### Combining Subjective and Objective The most powerful insights come from combining both: - Survey says developers feel they can't focus → Activity data confirms declining session lengths - Survey says tools are frustrating → Activity data shows time wasted on slow builds or context switches - Survey says everything is fine → Activity data shows weekend work increasing (developers might not recognize their own burnout signals) When subjective and objective data align, you have a strong signal. When they diverge, you have an interesting investigation to pursue. ## Building a DevEx Measurement Program ### Step 1: Establish Baselines Before you can improve, you need to know where you are. Deploy both: - A quarterly DevEx survey (start with 5-7 questions) - Activity tracking via PanDev Metrics (captures objective data automatically) Collect 2-3 months of baseline data before setting improvement targets. ### Step 2: Identify the Biggest Pain Points Combine survey responses with activity data to find the highest-impact areas. Common findings: | Survey Signal | Activity Signal | Likely Issue | |---------------|-----------------|--------------| | "Too many meetings" | Short, fragmented sessions | Meeting overload | | "Slow CI/CD" | Long gaps between code changes | Build/deploy bottleneck | | "Hard to find information" | Long ramp-up for new hires | Documentation gap | | "Weekend stress" | Increasing weekend activity | Scope or staffing issue | ### Step 3: Prioritize and Act Pick 1-2 issues per quarter. Don't try to fix everything at once. Each improvement should be: - Specific ("Reduce average PR review time from 48h to 24h" not "improve code review") - Measurable (using the metrics you've established) - Time-bound (one quarter to show improvement) ### Step 4: Measure the Impact After implementing changes, compare post-intervention metrics to baselines: - Did survey scores improve on the targeted dimension? - Did activity data shift in the expected direction? - Do developers *feel* the improvement? Share results with the team. Seeing that their feedback led to concrete improvements builds trust in the measurement program. ### Step 5: Iterate DevEx is not a project with an end date. It's an ongoing practice. Each quarter: measure, prioritize, improve, validate. Over time, your DevEx measurement program becomes a core competency that differentiates your engineering organization. ## Common Mistakes in DevEx Measurement ### Mistake 1: Measuring Only Speed DevEx isn't just about shipping faster. A team that ships quickly but burns out, produces bugs, and has high turnover has bad DevEx despite good velocity metrics. ### Mistake 2: Surveying Without Acting If you survey developers and don't act on the results, you've made things worse. You've demonstrated that their feedback doesn't matter. Either commit to acting on survey results or don't survey. ### Mistake 3: Over-Indexing on Tools Buying new tools is the easiest DevEx intervention and often the least impactful. Process changes, cultural shifts, and organizational redesigns are harder but more valuable. Don't throw tools at a culture problem. ### Mistake 4: Ignoring Individual Variation DevEx is personal. What one developer considers a great experience (quiet, autonomous, async) might be another developer's nightmare (isolated, unsupported, disconnected). Measure at the individual level and look for patterns, but don't assume one-size-fits-all. ## Conclusion Developer Experience is measurable, improvable, and directly linked to business outcomes. It's not a luxury — it's a competitive advantage. The organizations that measure DevEx systematically — combining survey data with objective activity metrics — can identify and fix problems before they become retention crises, productivity drains, or recruiting disadvantages. Start measuring. Start improving. Your developers (and your business results) will thank you. --- **Measure Developer Experience with real data.** [PanDev Metrics](https://pandev-metrics.com) provides objective activity metrics — coding hours, session patterns, tool usage — that complement your DevEx surveys with hard numbers. --- ## Engineering Leaderboards: Motivation or Demotivation? How to Set Them Up Right URL: https://pandev-metrics.com/docs/blog/leaderboards-right-way Date: 2025-10-17 Tags: gamification, engineering-management, developer-experience, leadership Description: Leaderboards can motivate or crush morale. Here's a practical guide to setting up engineering rankings that drive healthy engagement without toxic competition. You're considering adding a leaderboard to your engineering team. Maybe your platform already has one. The idea sounds straightforward: show who's contributing the most, and everyone will be motivated to contribute more. In reality, leaderboards are the most polarizing gamification feature in engineering. Self-Determination Theory (Deci & Ryan) warns that extrinsic ranking systems can undermine intrinsic motivation — but research also shows that well-designed recognition systems boost engagement. Done right, they create healthy engagement and visibility. Done wrong, they create anxiety, gaming, and resentment. Here's how to get them right. ![Individual developer metrics — the data that feeds team leaderboards](https://pandev-metrics.com/img/blog/employee-metrics-safe.png) *Individual developer metrics — the data that feeds team leaderboards.* ## Why Leaderboards Are Tempting The appeal is obvious. Leaderboards provide: - **Visibility**: Leadership can see who's active and engaged - **Recognition**: Top contributors get acknowledged - **Motivation**: Competitive developers push harder - **Benchmarking**: Individuals can see where they stand PanDev Metrics includes ranking features across **nearly 1,000 users** at **100+ B2B companies**. We've seen what works and what doesn't across a wide range of team cultures. The patterns are clear — and the mistakes are predictable. ## The Case Studies: When Leaderboards Go Wrong Before discussing best practices, let's understand the failure modes. ### Failure Mode 1: The Activity Arms Race **What happens**: The leaderboard ranks developers by total coding hours. Developers start gaming the metric — keeping their IDE open during lunch, making unnecessary file saves, or staying late to inflate numbers. **The result**: Hours go up. Actual output doesn't change. Burnout increases. The developers who refuse to game the system feel penalized for being honest. **Root cause**: The leaderboard measures the wrong thing (input) rather than something meaningful. ### Failure Mode 2: The Demoralization Spiral **What happens**: A permanent leaderboard shows the same 3 developers at the top month after month. Everyone else sees they can never catch up. Mid-tier developers feel invisible. Bottom-tier developers feel shamed. **The result**: 3 developers are motivated. 20 are demoralized. The leaderboard becomes a tool for the already-motivated to feel good while discouraging everyone else. **Root cause**: Permanent cumulative rankings create an unwinnable game for most participants. ### Failure Mode 3: The Collaboration Killer **What happens**: Individual rankings pit team members against each other. Developer A stops helping Developer B because time spent helping is time not spent coding. Code reviews become perfunctory because reviewing someone else's code helps them, not you. **The result**: Individual metrics go up. Team performance degrades. Knowledge silos form. **Root cause**: Individual competition undermines team collaboration. ### Failure Mode 4: The Quiet Exodus **What happens**: Senior developers — often the most valuable — find leaderboards beneath them. They see the feature as "management playing games" and lose respect for the engineering culture. Some start job searching. **The result**: The developers you can least afford to lose are the most alienated by the leaderboard. **Root cause**: One-size-fits-all gamification that ignores the preferences of different developer personas. ## The Principles of Good Leaderboards Understanding the failure modes points to the principles that make leaderboards work. ### Principle 1: Measure What Matters (And Is Hard to Game) The worst leaderboard metrics: - Lines of code - Number of commits - Hours logged - Number of PRs opened These are all gameable and don't correlate well with actual value. Better leaderboard metrics: - **Consistency**: Active coding days in a month (rewards sustained engagement, not spikes) - **Breadth**: Number of languages or projects contributed to (rewards versatility) - **Collaboration**: Code reviews completed with meaningful feedback - **Learning**: New tools or languages explored - **Improvement**: Week-over-week coding hour growth (rewards personal progress) PanDev Metrics tracks actual IDE coding activity via heartbeats — which is harder to game than commit counts — and offers metrics like consistency streaks and language breadth that reward positive behaviors. ### Principle 2: Timeboxed, Not Permanent Permanent leaderboards create "the rich get richer" dynamics. The developer who's been on the team for 3 years will always outrank the one who joined last month. **Better approach**: Reset leaderboards regularly. - **Weekly sprints**: "This week's most active contributors" - **Monthly challenges**: "February consistency challenge" - **Seasonal themes**: "Q1 code review champion" Timeboxed leaderboards give everyone a fresh start regularly. Last month's bottom-ranker can be this month's top contributor. This creates hope and engagement rather than resignation. ### Principle 3: Team Leaderboards Over Individual Instead of ranking Developer A against Developer B, rank Team Alpha against Team Beta. Or rank the whole team against their own previous performance. Team leaderboards: - Encourage collaboration (helping a teammate helps your team's score) - Distribute recognition (the whole team celebrates, not just the top 3) - Reduce individual anxiety (no one is singled out) - Build camaraderie (shared goals create shared identity) **Practical example**: "Team Alpha logged 250 coding hours this sprint — their best in 3 months!" This celebrates the team without creating individual winners and losers. ### Principle 4: Multiple Dimensions, Not One Ranking A single leaderboard creates one definition of "best." Multiple leaderboards allow different developers to shine in different dimensions: - **The Consistent Contributor**: Most active coding days - **The Polyglot**: Most programming languages used - **The Reviewer**: Most code reviews completed - **The Newcomer**: Fastest ramp-up this quarter - **The Mentor**: Most pair programming sessions Different developers value different things. Multiple dimensions mean more people get recognition for the things they're genuinely good at. ### Principle 5: Opt-In, Always This is non-negotiable. Any developer who doesn't want to appear on a leaderboard should be able to opt out without stigma. The leaderboard should be visible to those who enjoy it and invisible to those who don't. In practice, making leaderboards opt-in doesn't kill engagement. The developers who enjoy competition opt in enthusiastically. The others appreciate being respected. ### Principle 6: Celebrate the Middle, Not Just the Top Most leaderboard designs highlight the top 3 and ignore everyone else. This demotivates the majority. Instead: - **Highlight personal bests**: "You had your most productive week since January" - **Celebrate milestones**: "You crossed 100 total coding hours" - **Show improvement**: "You moved up 5 positions from last month" - **Acknowledge participation**: "23 out of 25 team members were active this week" Recognition for progress and participation is more motivating for most people than recognition for absolute performance. ## Implementation Guide ### Phase 1: Start Small Don't launch with a public, individual, permanent leaderboard. Start with: - A team-level weekly activity summary - Individual progress dashboards (visible only to each developer) - One timeboxed challenge (e.g., "February consistency challenge") Gauge the reaction. If the team engages positively, expand gradually. ### Phase 2: Add Dimensions After 1-2 months, introduce multiple leaderboard dimensions: - Consistency (active days) - Breadth (projects/languages) - Collaboration (reviews) Let developers choose which dimensions they care about. ### Phase 3: Introduce Opt-In Individual Rankings If — and only if — the team culture is positive about gamification, add opt-in individual rankings. Make them: - Timeboxed (weekly or monthly resets) - Multi-dimensional (not just one ranking) - Positive-framed (celebrate personal bests, not just absolute position) ### Phase 4: Iterate Based on Feedback Run an anonymous survey after 3 months: - "Do you enjoy the leaderboard features? (Yes / Somewhat / No)" - "Have leaderboards affected your behavior in any way?" - "Do you feel the leaderboards are fair?" - "What would you change?" Adjust based on the feedback. If a significant portion of the team finds the leaderboards stressful, scale them back. If people want more, expand. ## Red Flags to Watch For ### Gaming Behavior If you see unusual activity patterns — sudden spikes in commits, unusually long IDE sessions with no corresponding output, or developers making trivial changes to climb the rankings — the leaderboard is measuring the wrong thing. Redesign the metrics. ### Reduced Collaboration If code review quality drops, pair programming declines, or developers stop helping each other, the leaderboard may be creating perverse individual incentives. Shift to team-level metrics. ### Consistent Negative Feedback If more than 30% of the team reports negative feelings about the leaderboard in surveys, something is wrong. Take it seriously. Scale back or redesign. ### Top-Heavy Engagement If only the top 5 developers are engaged with the leaderboard and everyone else ignores it, the system is rewarding the already-motivated without helping the rest. Add middle-tier recognition and personal progress tracking. ## The PanDev Approach PanDev Metrics implements leaderboards with these principles in mind: - **Employee rankings** are available but designed for positive engagement - **Levels and XP** provide individual progression without requiring comparison - **Badges and achievements** recognize diverse accomplishments - **SVG badges for README** let developers showcase achievements on their own terms - **Activity data** is based on IDE heartbeats, which are harder to game than commit counts The goal is always recognition and engagement, not surveillance and competition. ## When NOT to Use Leaderboards Be honest about when leaderboards are inappropriate: - **During layoffs or restructuring**: Adding gamification when people fear for their jobs is tone-deaf - **In low-trust environments**: If the team doesn't trust management, leaderboards will be seen as surveillance. Fix the trust first. Google's Project Aristotle research found that psychological safety is the #1 predictor of team performance — leaderboards in unsafe environments destroy it. - **For performance evaluation**: Never tie leaderboard position to bonuses, promotions, or PIPs - **In very small teams**: In a team of 3-4, everyone knows where they stand. A leaderboard adds formality without value. - **When the team explicitly rejects it**: If your team says they don't want leaderboards, respect that. Forced gamification is worse than no gamification. ## Conclusion Engineering leaderboards are powerful tools that can go very wrong or very right. The difference lies in the design: **Wrong**: Permanent, individual, single-metric, mandatory, tied to evaluation. **Right**: Timeboxed, team-oriented, multi-dimensional, opt-in, focused on recognition. If you're implementing leaderboards for your engineering team, start small, measure the impact, listen to feedback, and be willing to change course. The goal is a team that's energized and engaged — not one that's stressed and gaming metrics. --- **Leaderboards designed for motivation, not anxiety.** [PanDev Metrics](https://pandev-metrics.com) offers employee rankings, levels, and achievements built around positive engagement — with opt-in design and multi-dimensional recognition. --- ## PanDev Metrics vs Swarmia: Which Developer Analytics Platform Fits Your Team? URL: https://pandev-metrics.com/docs/blog/pandev-vs-swarmia Date: 2025-10-06 Tags: comparison, alternatives, swarmia, developer-productivity, developer-experience Description: PanDev Metrics vs Swarmia compared: developer experience, DORA metrics, financial analytics, IDE tracking, and on-premise deployment options. Swarmia has built a strong reputation as a developer experience-focused analytics platform. The company has published the book "Build" on engineering effectiveness and counts companies like Miro, Bolt, Chess.com, Handshake, and Lovable among its customers. Its free tier for teams of up to 9 developers makes it easy to evaluate. PanDev Metrics takes a broader approach, combining developer analytics with financial tracking and on-premise deployment. Both platforms serve engineering teams — but with different philosophies and capabilities. ## Platform Philosophies Swarmia positions itself as a "developer productivity and experience platform." Its core belief is that improving developer experience (DevEx) leads to better business outcomes. The platform focuses on reducing friction in engineering workflows: slow code reviews, meeting overload, and unclear priorities. PanDev Metrics positions itself as an "engineering intelligence platform" that gives leaders complete visibility into engineering performance, costs, and delivery. Featured in Forbes Kazakhstan (April 2026), the platform has ~40 companies currently in pilot. It combines IDE-level tracking, DORA metrics, financial analytics, and AI-powered insights. The philosophical difference matters: Swarmia optimizes the developer's day-to-day experience. PanDev optimizes organizational understanding of engineering as a business function. Both are valuable — the question is which problem is more pressing for your organization. ## Feature Comparison | Feature | PanDev Metrics | Swarmia | |---|---|---| | **Developer Experience Focus** | Gamification, individual insights | Core platform focus (surveys, DevEx metrics) | | **DORA Metrics** | Yes, 4-stage Lead Time breakdown | Yes | | **IDE Activity Tracking** | Yes, 10+ plugins | No | | **Financial Analytics** | Yes (cost per project/team/employee) | No | | **Git Provider Support** | GitLab, GitHub, Bitbucket, Azure DevOps (simultaneous) | GitHub, GitLab, Bitbucket | | **On-Premise Deployment** | Yes (Docker + Kubernetes) | No (cloud-only) | | **AI Assistant** | Yes (Gemini-powered) | No | | **Gamification** | Yes (levels, XP, badges) | No | | **SSO/LDAP** | Yes | Yes (paid plans) | | **Slack Integration** | Basic | Yes (deep, core feature) | | **Investment Tracking** | Financial analytics | Working agreement tracking | | **Developer Surveys** | No | Yes (built-in) | | **Free Tier** | Yes | Yes (up to 9 developers) | | **Pricing** | Competitive per-developer | ~$15-$20/dev/month | | **Multi-Tenancy** | Yes | No | | **Working Agreements** | No | Yes (team-level rules and tracking) | ## Where Swarmia Excels ### Developer Experience Focus Swarmia was built with developers in mind, not just their managers. Companies like Miro, Bolt, Chess.com, Handshake, and Lovable use the platform to improve their engineering workflows. The platform includes features specifically designed to improve the developer's daily experience: identifying long-running PRs, tracking meeting load, measuring focus time, and surfacing workflow friction. This developer-first approach makes adoption easier because individual contributors see direct value — and Swarmia's philosophy on "healthy" metrics (detailed in their book "Build") resonates with teams skeptical of surveillance-style tracking. ### Working Agreements Swarmia's working agreements feature lets teams define standards (e.g., "PRs should be reviewed within 4 hours") and then tracks compliance automatically. This is a practical feature for teams that want to establish and maintain engineering standards without manual oversight. The agreements are visible to the team, creating shared accountability. ### Slack Integration Swarmia integrates deeply with Slack, delivering insights, PR notifications, and team updates where developers already work. This is not just a notification bot — it is a core interaction model. For Slack-heavy organizations, this reduces the need to visit a separate dashboard. ### Developer Surveys Built-in developer surveys let engineering leaders collect qualitative feedback alongside quantitative metrics. This combination of "what the data shows" and "what developers feel" provides a more complete picture of team health. Survey results can be correlated with workflow metrics to identify root causes. ### Clean, Modern UI Swarmia's interface is well-designed and modern. Dashboards are intuitive, data is presented clearly, and the overall experience feels polished. For teams where dashboard aesthetics and ease of use matter, Swarmia delivers a pleasant experience. ## Where PanDev Metrics Excels ### IDE-Level Activity Tracking PanDev collects data from 10+ IDE plugins covering VS Code, JetBrains, Eclipse, Xcode, Visual Studio, PL/SQL Developer, Chrome, and CLI tools. This captures the full picture of developer activity — including coding time that never results in a commit, debugging sessions, and code exploration. Swarmia relies on git events and integrations. While effective for measuring workflow efficiency, it misses the actual coding activity that happens before code is pushed. For organizations that need accurate time allocation data, IDE tracking provides the ground truth. ### Financial Analytics PanDev provides cost-per-project, cost-per-team, and cost-per-employee analytics with configurable hourly rates. Engineering leaders can answer: "How much did this feature cost?" or "What is our cost per deployment?" Swarmia does not track financial data. If your CTO or CFO asks about engineering costs, you will need a separate tool or manual calculations. ### On-Premise Deployment PanDev supports Docker and Kubernetes deployment within your own infrastructure. Developer activity data — which can be sensitive — never leaves your network. Swarmia is cloud-only with no self-hosted option. ### 4-Stage Lead Time Breakdown PanDev breaks Lead Time into Coding Time, Pickup Time, Review Time, and Deploy Time. When Swarmia tells you lead time is 3 days, PanDev tells you it is 1 day coding + 0.5 days waiting for review + 1 day in review + 0.5 days to deploy. This granularity makes bottleneck identification actionable. ### AI-Powered Queries PanDev's Gemini-powered AI assistant lets you ask questions in natural language. Instead of building dashboard filters, you ask: "Which team had the most improvement in lead time this month?" This reduces the learning curve and makes data accessible to stakeholders who are not dashboard-savvy. ### Multi-Provider Git Support PanDev connects to GitHub, GitLab, Bitbucket, and Azure DevOps simultaneously. This is critical for organizations with diverse toolchains, especially after acquisitions. Swarmia supports multiple providers but does not emphasize simultaneous multi-provider analytics. ### Gamification Levels, XP, and badges in PanDev create positive engagement loops. Developers earn recognition for code reviews, consistent activity, and collaboration. This gamification layer addresses a common challenge: making analytics tools something developers want to use, not something imposed on them. ### Multi-Tenancy PanDev supports multi-tenancy, allowing organizations with multiple business units or agencies managing multiple clients to maintain separate analytics environments. Swarmia does not offer multi-tenancy. ## Pricing Comparison | Aspect | PanDev Metrics | Swarmia | |---|---|---| | **Free Tier** | Yes | Yes (up to 9 devs) | | **Paid Pricing** | Competitive per-developer | ~$15-$20/dev/month | | **Annual Cost (30 devs)** | Lower than Swarmia | $5,400-$7,200 | | **Annual Cost (100 devs)** | Significantly lower | $18,000-$24,000 | | **IDE Tracking** | Included | Not available | | **Financial Analytics** | Included | Not available | | **On-Premise** | Available | Not available | Both platforms offer free tiers for small teams. At scale, PanDev provides more capabilities at a lower price point. ## Real-World Scenarios ### Scenario 1: DevEx-Focused Engineering Culture A tech company where developer experience is a top priority. Leadership wants to reduce meeting overhead, speed up code reviews, and measure developer satisfaction. **Swarmia** is a strong fit. Its DevEx surveys, working agreements, and Slack integration directly address these goals. The platform was designed for exactly this use case. **PanDev** can support this through DORA metrics and gamification, but it lacks built-in surveys and working agreements. However, the IDE tracking data provides deeper insight into how developers actually spend their time. ### Scenario 2: CFO Wants Engineering Cost Visibility The CFO is asking "What does Project X cost?" and the VP of Engineering has no data-driven answer. **Swarmia** cannot answer this question. No financial analytics means manual calculations with spreadsheets. **PanDev** answers this directly with cost-per-project, cost-per-team, and cost-per-employee analytics. Configure hourly rates, and the platform calculates project costs automatically. ### Scenario 3: Regulated Industry Deployment A healthcare company needs developer analytics but cannot use cloud-hosted tools for compliance reasons. **Swarmia** is not an option. Cloud-only deployment means developer data leaves the organization. **PanDev** deploys on-premise with Docker/Kubernetes, LDAP/SSO, and keeps all data internal. ### Scenario 4: Growing Startup (20 developers) A Series A startup outgrowing its free tier and evaluating paid analytics platforms. **Swarmia** offers a good experience at $15-$20/dev/month. The DevEx focus helps maintain engineering culture during growth. **PanDev** offers more capabilities (IDE tracking, financial analytics) at competitive pricing, plus features that will matter as the company scales (multi-tenancy, on-premise). ### Scenario 5: Mixed Toolchain Environment An organization using GitHub, GitLab, and Azure DevOps across different teams. **Swarmia** supports GitHub and GitLab but Azure DevOps support may be limited. **PanDev** connects to all four providers simultaneously, unifying data across the organization. ## The DevEx vs. Business Intelligence Tradeoff The core choice between Swarmia and PanDev often comes down to perspective: **If you see developer analytics primarily as a DevEx tool** — something that helps developers work better and feel better about their work — Swarmia's surveys, working agreements, and Slack integration align with that vision. **If you see developer analytics primarily as a business intelligence tool** — something that helps leaders understand engineering costs, performance, and delivery — PanDev's financial analytics, IDE tracking, and AI assistant align with that vision. The ideal answer is "both" — and PanDev provides business intelligence with gamification that serves developers, while Swarmia provides DevEx with metrics that serve leaders. The question is which direction you start from. ## Who Should Choose What **Choose Swarmia if:** - Developer experience improvement is your primary goal - Built-in developer surveys are important to your organization - Working agreements (team-level standards) are a key feature for you - Deep Slack integration is essential to your workflow - You prefer a developer-first platform design - Cloud-only deployment is acceptable - You do not need financial analytics or IDE tracking **Choose PanDev Metrics if:** - You need IDE-level activity tracking for accurate productivity data - Financial analytics (cost per project/team) is required - On-premise deployment is necessary for compliance - You want 4-stage Lead Time breakdown for bottleneck identification - AI-powered natural language queries would benefit your workflow - Multi-provider git support (including Azure DevOps) is needed - Gamification would drive developer engagement - Multi-tenancy is required ## Bottom Line Swarmia and PanDev Metrics are both quality platforms that take different approaches to engineering analytics. Swarmia excels at developer experience — making developers happier and more effective in their daily work. PanDev excels at engineering intelligence — giving leaders complete visibility into performance, costs, and delivery. The best choice depends on your organization's primary pain point. If developers are frustrated and you need to understand why, Swarmia's DevEx focus is valuable. If leadership needs to understand what engineering costs, where time goes, and how to optimize delivery, PanDev's comprehensive analytics provide those answers. --- *Try [PanDev Metrics](https://pandev-metrics.com) — free tier available, financial analytics and IDE tracking included.* --- ## PanDev Metrics vs Sleuth: Beyond DORA Tracking URL: https://pandev-metrics.com/docs/blog/pandev-vs-sleuth Date: 2025-10-03 Tags: comparison, alternatives, sleuth, dora-metrics, deployment-tracking Description: PanDev Metrics vs Sleuth compared: DORA metrics, deploy tracking, IDE analytics, financial tracking, and on-premise deployment for engineering teams. Sleuth is a focused DORA metrics and deployment tracking platform that does one thing well: measuring software delivery performance. The platform is available on both the GitHub Marketplace and Atlassian Marketplace, and offers a free tier for small teams. PanDev Metrics goes beyond DORA to provide IDE tracking, financial analytics, and organizational intelligence. If DORA is your starting point but not your destination, the choice matters. ## What Each Platform Does Best Sleuth was purpose-built for DORA metrics. It tracks deployments, measures change failure rates, calculates lead time, and visualizes delivery performance. The platform excels at giving engineering teams a clear picture of their software delivery pipeline health. PanDev Metrics provides DORA metrics as one component of a broader engineering intelligence platform. It adds IDE-level activity tracking, financial analytics (cost per project/team/employee), AI-powered queries, and on-premise deployment. DORA metrics are important — but they are part of a larger story. ## Feature Comparison | Feature | PanDev Metrics | Sleuth | |---|---|---| | **DORA Metrics** | Yes, 4-stage Lead Time breakdown | Yes (core feature, strong implementation) | | **Deployment Tracking** | Basic | Yes (core feature, automated detection) | | **Change Failure Rate** | Yes | Yes (with incident tracking) | | **IDE Activity Tracking** | Yes, 10+ plugins | No | | **Financial Analytics** | Yes (cost per project/team/employee) | No | | **Git Provider Support** | GitLab, GitHub, Bitbucket, Azure DevOps (simultaneous) | GitHub, GitLab, Bitbucket | | **On-Premise Deployment** | Yes (Docker + Kubernetes) | No (cloud-only) | | **AI Assistant** | Yes (Gemini-powered) | No | | **Gamification** | Yes (levels, XP, badges) | No | | **SSO/LDAP** | Yes | Yes (Enterprise) | | **Slack/ChatOps** | Basic | Yes (deploy notifications, Slack bot) | | **Feature Flag Integration** | No | Yes (LaunchDarkly integration) | | **Incident Tracking** | No | Yes (integrated) | | **Free Tier** | Yes | Limited free plan | | **Pricing** | Competitive per-developer | ~$20/dev/month | | **Multi-Tenancy** | Yes | No | ## Where Sleuth Excels ### Deployment Tracking Depth Sleuth's deployment tracking is its standout feature. It automatically detects deployments across multiple environments, tracks which changes went into each deploy, and correlates deployment events with system health metrics. For teams that deploy frequently (multiple times per day), this level of deployment intelligence is valuable. The platform links code changes to deploys to incidents, creating a clear chain of causality. When something breaks in production, you can trace back to the exact deployment and the specific code changes that caused it. ### Change Failure Rate Accuracy Sleuth integrates incident tracking directly into its DORA measurement. When an incident is linked to a deployment, the change failure rate updates automatically. This tight coupling between incidents and deploys makes the change failure rate metric more accurate than platforms that estimate it indirectly. ### Feature Flag Integration Sleuth integrates with LaunchDarkly and other feature flag systems. This means it can track not just when code deploys, but when features are actually enabled for users. For teams practicing progressive delivery with feature flags, this distinction matters. ### Deploy-Centric Workflow Sleuth is designed around the deployment as the central unit of work. Every metric, every dashboard, every notification centers on the question: "How well are we deploying software?" This focus creates a cohesive experience for teams whose primary concern is delivery velocity. ### ChatOps Integration Sleuth's Slack integration goes beyond notifications. The Slack bot allows team members to track deploys, acknowledge incidents, and view DORA metrics without leaving Slack. For teams with a ChatOps culture, this is a practical integration. ## Where PanDev Metrics Excels ### Beyond Deployment Metrics DORA metrics tell you how fast and how safely you deliver software. They do not tell you what developers actually do during the day, how much projects cost, or where time goes within the development cycle. PanDev extends the analytics surface beyond deployments: - **IDE tracking** reveals actual coding activity, including time spent on debugging, code exploration, and work that does not result in commits - **Financial analytics** translate developer time into costs, enabling project-level and team-level financial tracking - **4-stage Lead Time breakdown** (Coding, Pickup, Review, Deploy) identifies exactly where delivery bottlenecks occur within the development lifecycle ### IDE-Level Activity Data PanDev's 10+ IDE plugins (VS Code, JetBrains, Eclipse, Xcode, Visual Studio, PL/SQL Developer, Chrome, CLI) capture the full developer workday. This data reveals patterns that git-only platforms cannot see: - How much time is spent reading vs. writing code - Which projects consume the most developer attention - When developers are most productive during the day - How context-switching between projects affects output Sleuth does not collect any IDE data. Its view of developer activity starts when code is committed and ends when it is deployed. ### Financial Analytics PanDev calculates cost per project, cost per team, and cost per employee with configurable hourly rates. This turns abstract metrics into financial language that executives understand: - "Feature X cost $45,000 in developer time to build" - "Team Alpha's average cost per deployment is $2,300" - "Our cost per story point decreased 15% this quarter" Sleuth provides no financial tracking. Cost conversations require separate tools. ### On-Premise Deployment PanDev supports Docker and Kubernetes deployment on your infrastructure. For organizations in regulated industries or with strict data policies, this is a requirement. Sleuth is cloud-only. ### Multi-Provider Git Support PanDev connects to GitHub, GitLab, Bitbucket, and Azure DevOps simultaneously. Sleuth supports GitHub, GitLab, and Bitbucket but does not include Azure DevOps. ### AI-Powered Queries PanDev's Gemini-powered AI assistant answers questions in natural language. Instead of building custom dashboards or applying filters, you ask: "What was the average coding time per PR for Team Beta last month?" The AI retrieves and presents the data. ### Gamification Levels, XP, and badges in PanDev create positive developer engagement. This is particularly valuable when rolling out an analytics platform — gamification gives developers a reason to engage with the system rather than perceiving it as surveillance. ## The DORA Metrics Question Both platforms provide DORA metrics, but with different depth and approach: **Sleuth** calculates DORA from deployment events and git data. It measures the four standard DORA metrics accurately and benchmarks them against industry standards. Deployment Frequency and Change Failure Rate are particularly strong due to Sleuth's deploy-centric architecture. **PanDev** calculates DORA with an additional layer: the 4-stage Lead Time breakdown. While Sleuth tells you "Lead Time for Changes is 3 days," PanDev tells you it breaks down as: - Coding Time: 1.2 days - Pickup Time: 0.4 days - Review Time: 0.9 days - Deploy Time: 0.5 days This granularity is actionable. If Pickup Time is high, you need better PR assignment processes. If Review Time is high, you may need more reviewers or smaller PRs. If Deploy Time is high, your CI/CD pipeline needs optimization. ## Pricing Comparison | Aspect | PanDev Metrics | Sleuth | |---|---|---| | **Free Tier** | Yes | Limited free plan | | **Paid Pricing** | Competitive per-developer | ~$20/dev/month | | **Annual Cost (30 devs)** | Lower than Sleuth | ~$7,200 | | **Annual Cost (100 devs)** | Significantly lower | ~$24,000 | | **IDE Tracking** | Included | Not available | | **Financial Analytics** | Included | Not available | | **On-Premise** | Available | Not available | At $20/dev/month, Sleuth is mid-range in pricing for what it offers. PanDev provides broader capabilities at a competitive price point. ## Real-World Scenarios ### Scenario 1: Platform Engineering Team Focused on Delivery A platform engineering team wants to optimize their deployment pipeline. They deploy 10+ times per day and need to track every deploy, correlate incidents, and measure DORA metrics precisely. **Sleuth** is built for this exact scenario. Deploy-centric architecture, incident correlation, and feature flag integration make it the specialized tool for deployment optimization. **PanDev** provides DORA metrics that cover the need, but Sleuth's deployment depth is superior for this specific use case. ### Scenario 2: Engineering Leader Needs Full Visibility A VP of Engineering needs to understand not just delivery speed, but where time goes, what projects cost, and how individual teams are performing across multiple dimensions. **Sleuth** answers the delivery velocity question but leaves cost, time allocation, and individual activity as blind spots. **PanDev** provides the full picture: DORA for delivery, IDE tracking for activity, financial analytics for costs, and team comparisons for organizational understanding. ### Scenario 3: Regulated Environment A government contractor needs engineering analytics with on-premise deployment and SSO/LDAP integration. **Sleuth** is cloud-only. Not an option for this scenario. **PanDev** deploys on-premise with Docker/Kubernetes and supports LDAP/SSO. ### Scenario 4: Mixed Git Environments Including Azure DevOps An enterprise using Azure DevOps alongside GitHub needs unified DORA metrics. **Sleuth** does not support Azure DevOps. **PanDev** connects to Azure DevOps alongside GitHub, GitLab, and Bitbucket simultaneously. ## When to Use Both Some organizations use a focused DORA tool alongside a broader analytics platform. If your delivery pipeline is complex and you need Sleuth's deployment depth (incident correlation, feature flags, deploy detection), you might use Sleuth for DORA and PanDev for IDE tracking, financial analytics, and organizational insights. The tools are not necessarily mutually exclusive. However, for most teams, PanDev's DORA metrics are sufficient, and using one platform reduces tool sprawl and consolidates data. ## Who Should Choose What **Choose Sleuth if:** - Deployment tracking and optimization is your primary focus - You need deep incident-to-deploy correlation - Feature flag integration (LaunchDarkly) is important - You have a ChatOps culture with heavy Slack usage - You do not need IDE tracking, financial analytics, or on-premise deployment - Your git providers are limited to GitHub, GitLab, or Bitbucket **Choose PanDev Metrics if:** - You need analytics beyond DORA (IDE tracking, financial, team) - 4-stage Lead Time breakdown is valuable for bottleneck identification - Financial analytics are required for project and team cost tracking - On-premise deployment is needed for compliance - You use Azure DevOps alongside other git providers - AI-powered natural language queries would benefit your workflow - Gamification would help with developer adoption - You want a single platform for multiple engineering analytics needs ## Bottom Line Sleuth is an excellent focused tool for DORA metrics and deployment tracking. If your primary need is understanding and optimizing your delivery pipeline, Sleuth does this well with thoughtful features like incident correlation and feature flag integration. PanDev Metrics goes beyond DORA to provide a comprehensive engineering intelligence platform. IDE tracking, financial analytics, AI queries, and on-premise deployment create a broader analytics surface that addresses questions Sleuth was not designed to answer. The choice depends on scope: if you need deployment analytics, Sleuth is focused and effective. If you need engineering analytics, PanDev covers DORA and much more. --- *Try [PanDev Metrics](https://pandev-metrics.com) — DORA, IDE tracking, financial analytics, and AI-powered insights in one platform.* --- ## PanDev Metrics vs Pluralsight Flow (Appfire): Why Legacy Platforms Are Falling Behind URL: https://pandev-metrics.com/docs/blog/pandev-vs-pluralsight-flow Date: 2025-10-01 Tags: comparison, alternatives, pluralsight-flow, gitprime, appfire, engineering-management Description: PanDev Metrics vs Pluralsight Flow (Appfire) compared: innovation, pricing, IDE tracking, and why legacy platforms struggle in modern engineering. Pluralsight Flow, originally known as GitPrime, has changed hands three times: from GitPrime to Pluralsight to Appfire. Each acquisition brought uncertainty. The platform is priced at approximately $50 per developer per month with no free tier, and visible product updates have slowed significantly since the Appfire acquisition. If you are evaluating Flow or considering migration, here is how it compares to PanDev Metrics. ## The Ownership Timeline Understanding Flow's history is important because it directly impacts the product's current state and future trajectory. **2015-2018: GitPrime era.** GitPrime launched as a pioneering developer analytics tool. It introduced concepts like "Active Days" and developer efficiency metrics that the market had not seen before. The product was innovative and well-received by engineering leaders. **2018-2021: Pluralsight era.** Pluralsight acquired GitPrime and rebranded it as "Pluralsight Flow." The product was integrated into Pluralsight's skills platform. Development continued but focused on Pluralsight's broader vision rather than pure engineering analytics. Some features were added, but the pace of innovation slowed. **2021-Present: Appfire era.** Pluralsight sold Flow to Appfire, a company focused on Atlassian ecosystem tools. Under Appfire, the product has seen minimal public updates. Content on the website is largely unchanged, marketing has slowed, and only one published case study is available (BNY Mellon). Zero significant content updates since the acquisition. The product appears to be in maintenance mode. Three ownership changes in under a decade creates legitimate concerns about product commitment, roadmap clarity, and long-term viability. ## Feature Comparison | Feature | PanDev Metrics | Pluralsight Flow (Appfire) | |---|---|---| | **Active Development** | Yes (regular updates, new features) | Minimal visible updates | | **DORA Metrics** | Yes, 4-stage Lead Time breakdown | Basic | | **IDE Activity Tracking** | Yes, 10+ plugins | No | | **Financial Analytics** | Yes (cost per project/team/employee) | No | | **Git Provider Support** | GitLab, GitHub, Bitbucket, Azure DevOps (simultaneous) | GitHub, GitLab, Bitbucket | | **On-Premise Deployment** | Yes (Docker + Kubernetes) | No (cloud-only) | | **AI Assistant** | Yes (Gemini-powered) | No | | **Gamification** | Yes (levels, XP, badges) | No | | **SSO/LDAP** | Yes | Yes | | **Developer Efficiency Metrics** | Yes | Yes (original strength) | | **Active Days Metric** | Similar concepts | Yes (originated here) | | **Free Tier** | Yes | No | | **Pricing** | Competitive per-developer | ~$50/dev/month | | **Published Case Studies** | Growing | 1 (BNY Mellon) | | **Content Updates** | Regular blog, guides | Stale (limited recent content) | | **Multi-Tenancy** | Yes | Unknown | ## What Flow Got Right (Originally) Credit where it is due: GitPrime pioneered concepts that influenced the entire engineering analytics market. ### Developer Efficiency Metrics GitPrime introduced metrics like "Efficiency Rate" (net code change vs. total code change) and "Active Days" (days with meaningful coding activity). These metrics moved the conversation beyond simple commit counts to more nuanced productivity measurement. ### Pull Request Analytics Flow's PR analytics, including review depth, time-to-merge, and reviewer workload distribution, set a standard that other platforms adopted. The visual representation of code review dynamics was ahead of its time. ### Team Comparison Views The ability to compare teams on consistent metrics — active days, commit patterns, review activity — gave engineering leaders a standardized way to understand organizational patterns. These ideas were innovative when GitPrime launched. The problem is that they have not meaningfully evolved since. ## The Stagnation Problem The engineering analytics market has evolved significantly since GitPrime's founding. Modern platforms now offer: - **DORA metrics** with granular breakdowns - **IDE-level tracking** for actual coding activity data - **Financial analytics** connecting engineering work to costs - **AI-powered insights** for natural language queries - **On-premise deployment** for regulated industries - **Multi-provider support** for complex toolchains - **Gamification** for developer engagement Flow has not kept pace with these market developments. The platform still relies primarily on git data, offers no IDE tracking, no financial analytics, no AI features, and no on-premise option. At $50 per developer per month, it charges a premium for a product that has not innovated in years. ### The Content Signal A platform's content output is a proxy for product investment. Active platforms publish regularly: blog posts, guides, case studies, product updates. Flow's public content has largely stagnated. One published case study — compared to competitors who have dozens — suggests limited customer success investment. This is not a criticism of the engineers maintaining Flow. It is an observation about organizational priorities when a product changes hands multiple times. ## Where PanDev Metrics Offers More ### Active Product Development PanDev Metrics is actively developed with regular feature releases. The platform evolves in response to customer needs and market trends. When you invest in PanDev, you are investing in a platform with a forward-looking roadmap, not a legacy product in maintenance mode. ### IDE-Level Tracking PanDev's 10+ IDE plugins (VS Code, JetBrains, Eclipse, Xcode, Visual Studio, PL/SQL Developer, Chrome, CLI) capture developer activity at the source. This provides ground-truth data that git-only analytics cannot offer. Flow relies entirely on git data, which captures output but not the full development process. ### Financial Analytics PanDev translates developer activity into financial data: cost per project, cost per team, cost per employee. Hourly rate configuration enables accurate cost tracking. Flow offers no financial analytics — a significant gap for engineering leaders who need to justify budgets. ### 4-Stage Lead Time PanDev breaks Lead Time into Coding Time, Pickup Time, Review Time, and Deploy Time. This granularity identifies exactly where delivery bottlenecks occur. Flow's lead time tracking is less detailed. ### On-Premise Deployment PanDev deploys on-premise via Docker and Kubernetes. Flow is cloud-only. For regulated industries, this is a non-negotiable requirement. ### AI-Powered Queries PanDev's Gemini-powered AI assistant lets you query data in natural language. This capability reflects the platform's commitment to incorporating modern technology. Flow has no AI features. ### Multi-Provider Git Support PanDev connects to GitHub, GitLab, Bitbucket, and Azure DevOps simultaneously. Flow supports GitHub, GitLab, and Bitbucket but not Azure DevOps. ### Gamification Levels, XP, and badges in PanDev create positive developer engagement and reduce resistance to analytics platforms. Flow has no gamification features. ### Pricing PanDev offers a free tier and competitive paid plans. Flow charges approximately $50 per developer per month with no free tier. For a 50-developer team, Flow costs approximately $30,000 per year for a platform with minimal recent innovation. ## Pricing Comparison | Aspect | PanDev Metrics | Pluralsight Flow | |---|---|---| | **Free Tier** | Yes | No | | **Paid Pricing** | Competitive per-developer | ~$50/dev/month | | **Annual Cost (30 devs)** | Fraction of Flow cost | ~$18,000 | | **Annual Cost (100 devs)** | Fraction of Flow cost | ~$60,000 | | **IDE Tracking** | Included | Not available | | **Financial Analytics** | Included | Not available | | **On-Premise** | Available | Not available | | **AI Assistant** | Included | Not available | The pricing disparity is striking when you consider that PanDev includes capabilities Flow does not offer at any price. ## Migration from Flow If your organization currently uses Pluralsight Flow and is considering alternatives, migration to PanDev is straightforward: 1. **Connect git providers** — PanDev connects to the same providers Flow uses, plus Azure DevOps 2. **Deploy IDE plugins** — Roll out PanDev plugins to developer machines for IDE-level tracking (a new capability) 3. **Configure financial settings** — Set up hourly rates and cost centers (a new capability) 4. **Connect task trackers** — Link Jira, ClickUp, or other tools (a new capability) The migration provides immediate access to features Flow does not offer, while maintaining the git-based analytics your team is familiar with. ### What You Will Gain - IDE-level activity tracking across 10+ environments - Financial analytics with cost-per-project visibility - 4-stage Lead Time breakdown for bottleneck identification - AI-powered natural language queries - On-premise deployment option - Gamification for developer engagement - Lower per-developer cost ### What is Different - PanDev uses different metric terminology than Flow's "Active Days" and "Efficiency Rate" - Dashboard layouts and UX are different - The data model is broader (IDE + git vs. git only) ## Real-World Scenarios ### Scenario 1: Current Flow Customer Evaluating Options Your team has used Flow since the GitPrime days. The product has not changed much, and you are paying $50/dev/month for static capabilities. **Recommendation: Evaluate PanDev.** You will get more capabilities at lower cost, with the confidence of active product development. Start with the free tier to compare. ### Scenario 2: New Customer Choosing Between Platforms You are selecting your first engineering analytics platform and Flow is on your shortlist. **Recommendation: Choose PanDev.** There is no reason to adopt a legacy platform when a modern alternative offers more features, lower cost, and active development. The risk of further ownership changes with Flow adds uncertainty. ### Scenario 3: Enterprise with Compliance Needs You need on-premise deployment and SSO/LDAP for a regulated environment. **Flow** is cloud-only. Not suitable. **PanDev** deploys on-premise with Docker/Kubernetes and supports LDAP/SSO. ## The Vendor Risk Question Choosing an analytics platform is a multi-year commitment. You integrate it into workflows, train teams, and build processes around the data. Vendor stability matters. Flow has had three owners in under a decade. Each transition introduced uncertainty about product direction, support quality, and long-term commitment. While Appfire may continue maintaining Flow, the track record of ownership changes is a legitimate risk factor. PanDev is focused exclusively on engineering intelligence. There is no risk of the product being deprioritized within a larger portfolio or sold to a company with different priorities. ## Who Should Choose What **Choose Pluralsight Flow if:** - You are already deeply integrated and migration cost is prohibitive - You specifically need Flow's original metrics (Active Days, Efficiency Rate) as defined by GitPrime - Your organization has an existing Appfire/Atlassian ecosystem relationship **Choose PanDev Metrics if:** - You want an actively developed platform with a forward-looking roadmap - IDE-level tracking is important for accurate activity data - Financial analytics are required for cost visibility - On-premise deployment is needed - You want AI-powered queries and modern analytics - Lower pricing for more capabilities appeals to your organization - Vendor stability and product focus matter to your decision ## Bottom Line Pluralsight Flow was a pioneering product that advanced the engineering analytics market. Its innovations under the GitPrime brand influenced how the industry thinks about developer productivity metrics. That legacy deserves respect. But the market has moved on. Three ownership changes, minimal visible innovation, stale content, and premium pricing for static capabilities make Flow a difficult recommendation for new customers. Current Flow users should seriously evaluate modern alternatives. PanDev Metrics offers what Flow provides — and significantly more — at a lower cost, with active development, on-premise deployment, IDE tracking, financial analytics, and AI-powered insights. For organizations that value product momentum and capability depth, PanDev is the forward-looking choice. --- *Try [PanDev Metrics](https://pandev-metrics.com) — free tier available, on-premise deployment option.* --- ## PanDev Metrics vs DX (getdx.com): Quantitative Metrics vs Developer Surveys URL: https://pandev-metrics.com/docs/blog/pandev-vs-dx Date: 2025-09-29 Tags: comparison, alternatives, dx, developer-experience, developer-surveys Description: PanDev Metrics vs DX compared: quantitative engineering metrics vs survey-based developer experience measurement. Different approaches to DevEx. DX (getdx.com) and PanDev Metrics represent two fundamentally different approaches to understanding engineering teams. DX measures developer experience through structured surveys and the DX Core 4 framework, and publishes quarterly AI impact reports that have become influential in the industry. PanDev measures engineering performance through quantitative data — IDE activity, git analytics, DORA metrics, and financial tracking. Both provide valuable insights, but they answer very different questions. ## Two Philosophies of Measurement The engineering analytics market is split between two schools of thought: **Quantitative measurement** uses data from development tools — IDEs, git providers, CI/CD systems, task trackers — to measure what developers do and how fast the organization delivers. PanDev Metrics follows this approach. **Qualitative measurement** uses surveys and self-reported data to measure how developers feel about their work environment, tools, and processes. DX follows this approach, grounded in academic research on developer experience. Neither approach is inherently better. They measure different things. The question is which type of measurement your organization needs more urgently — or whether you need both. ## Understanding DX's Approach DX was founded by researchers behind the SPACE framework (Satisfaction, Performance, Activity, Communication, Efficiency) and the proprietary DX Core 4 framework. They also publish quarterly AI impact reports that track how AI tools are changing developer workflows — these reports have become widely cited in the industry. Their platform centers on structured developer surveys that measure: - **Speed and Ease** — How quickly and easily can developers accomplish their work? - **Effectiveness** — How effective are developers in their daily workflows? - **Impact** — Do developers feel their work has meaningful impact? - **Satisfaction** — How satisfied are developers with their tools, processes, and environment? The surveys are scientifically designed, benchmarked against industry data, and produce actionable insights about developer experience. DX targets enterprise customers and positions itself as a research-backed approach to DevEx improvement. ## Feature Comparison | Feature | PanDev Metrics | DX (getdx.com) | |---|---|---| | **Data Source** | IDE plugins, git, task trackers | Developer surveys | | **Measurement Type** | Quantitative (behavioral data) | Qualitative (self-reported experience) | | **DORA Metrics** | Yes, 4-stage Lead Time breakdown | No (not automated) | | **IDE Activity Tracking** | Yes, 10+ plugins | No | | **Financial Analytics** | Yes (cost per project/team/employee) | No | | **Developer Surveys** | No | Yes (core feature) | | **DX Core 4 Framework** | No | Yes (proprietary framework) | | **Research Foundation** | Data-driven | Academic research (SPACE framework) | | **Git Provider Support** | GitLab, GitHub, Bitbucket, Azure DevOps | Not applicable | | **On-Premise Deployment** | Yes (Docker + Kubernetes) | Unknown | | **AI Assistant** | Yes (Gemini-powered) | No | | **Gamification** | Yes (levels, XP, badges) | No | | **SSO/LDAP** | Yes | Yes | | **Benchmarking** | Yes (against platform data) | Yes (against industry survey data) | | **Free Tier** | Yes | No (enterprise-only) | | **Pricing** | Competitive per-developer | Enterprise pricing (contact sales) | | **Target Market** | All company sizes | Enterprise | | **Multi-Tenancy** | Yes | Unknown | ## Where DX Excels ### Research-Backed Framework DX's frameworks (SPACE, DX Core 4) are grounded in peer-reviewed academic research. The survey instruments are designed by researchers who have studied developer productivity and experience extensively. This scientific rigor gives the survey results credibility that ad-hoc surveys lack. For organizations that value research-backed methodology, DX offers a level of academic credibility that data-only platforms do not claim. ### Measuring the Unmeasurable Some aspects of developer experience cannot be captured by tool data: - Do developers feel psychological safety on their team? - Are internal tools frustrating to use? - Do developers understand the business context of their work? - Is the on-call rotation burning people out? These questions require asking developers directly. No amount of IDE or git data will reveal whether a developer feels their work is meaningful or whether they are considering leaving. DX's surveys capture this qualitative dimension. ### Benchmarking Against Industry DX has collected survey data from numerous enterprise organizations, creating industry benchmarks. You can compare your team's developer experience scores against companies of similar size and type. This context makes the numbers meaningful — a satisfaction score of 72 means more when you know the industry average is 65. ### Enterprise Credibility DX's research credentials and enterprise focus resonate with organizations that need to justify DevEx investments to leadership. The academic backing makes it easier to present developer experience as a serious business concern rather than a "developer happiness" initiative. ### Identifying Root Causes Surveys can reveal why metrics look the way they do. If your lead time is increasing, quantitative data shows the trend. Surveys might reveal that developers are spending too much time in meetings, that the build system is unreliable, or that code review standards are unclear. The "why" behind the "what." ## Where PanDev Metrics Excels ### Objective, Continuous Measurement PanDev collects data automatically and continuously. There is no survey fatigue, no response bias, and no need to convince developers to fill out forms. The data reflects actual behavior, not recalled perceptions. Surveys have inherent limitations: response rates vary, recency bias affects answers, and the act of surveying can itself influence responses (the Hawthorne effect). PanDev's automated data collection avoids these methodological challenges. ### DORA Metrics Automation PanDev calculates DORA metrics automatically from git and CI/CD data, with a 4-stage Lead Time breakdown (Coding, Pickup, Review, Deploy). DX does not automate DORA measurement — it may include DORA-related survey questions, but the actual metrics come from behavioral data, not surveys. ### IDE-Level Activity Tracking PanDev's 10+ IDE plugins capture what developers actually do: coding time, debugging sessions, project switching, and language usage. This data is objective and granular. DX surveys might ask "How much time do you spend coding?" but self-reported time is notoriously inaccurate. ### Financial Analytics PanDev translates developer activity into cost data: cost per project, cost per team, cost per employee. DX provides no financial analytics — and surveys cannot answer "How much did Feature X cost to build?" ### Real-Time Data PanDev provides real-time and near-real-time analytics. You can see today's coding activity, this week's DORA metrics, and current project costs. Surveys are periodic — typically quarterly — which means the data is always retrospective and potentially outdated by the time results are analyzed. ### On-Premise Deployment PanDev deploys on-premise via Docker and Kubernetes. For regulated industries, all developer activity data stays within your infrastructure. DX's deployment model for enterprise customers varies. ### AI-Powered Queries PanDev's Gemini-powered AI assistant answers questions in natural language: "What is Team Alpha's average lead time this quarter?" This provides instant access to data without dashboard navigation. DX does not offer this capability. ### Accessibility PanDev offers a free tier and self-service signup. DX is enterprise-only with custom pricing, requiring a sales process before you can evaluate the platform. For organizations that want to start small and scale up, PanDev is more accessible. ### Gamification PanDev's levels, XP, and badges create positive engagement loops for developers. This feature gives individual contributors a reason to engage with the platform, reducing the perception that analytics tools exist only for management. ## The Quantitative vs. Qualitative Debate This is not an either/or choice at the organizational level. The most effective engineering organizations combine both approaches: **Quantitative data (PanDev)** tells you what is happening: - Lead time increased 30% last quarter - Team Beta spends 40% of coding time on Project X - Cost per deployment is $3,200 **Qualitative data (DX)** tells you why: - Developers report that the build system is unreliable - Team Beta feels the project scope keeps changing - On-call responsibilities are affecting coding time Together, they create a complete picture. Quantitative data identifies problems and measures progress. Qualitative data explains root causes and validates that improvements actually feel better to developers. ## Pricing and Accessibility | Aspect | PanDev Metrics | DX | |---|---|---| | **Free Tier** | Yes | No | | **Self-Service** | Yes | No (enterprise sales) | | **Pricing Model** | Per-developer, competitive | Enterprise custom pricing | | **Minimum Commitment** | None | Enterprise contract | | **Time to Value** | Hours (connect tools, install plugins) | Weeks (sales, setup, first survey cycle) | | **Ongoing Effort** | Automated data collection | Periodic survey administration | PanDev is accessible to organizations of any size with immediate time to value. DX requires enterprise commitment and has a longer time to first actionable data (you need at least one survey cycle). ## Real-World Scenarios ### Scenario 1: Engineering Leader Suspects Bottleneck Your lead time for changes has been increasing, and you need to find and fix the root cause. **PanDev** immediately shows you the 4-stage Lead Time breakdown: Coding Time is stable, but Pickup Time has doubled. PRs are sitting unreviewed for too long. Actionable in minutes. **DX** would require running a survey cycle, asking developers about code review processes, and analyzing results. Actionable in weeks. ### Scenario 2: High Developer Turnover Your engineering team has above-average attrition, and leadership wants to understand why. **DX** excels here. Surveys can uncover satisfaction issues, identify friction points in the developer experience, and benchmark against industry standards. The qualitative data directly addresses retention concerns. **PanDev** can show activity patterns (declining coding hours before departure, increased context-switching) but cannot directly measure satisfaction or experience quality. ### Scenario 3: CTO Needs Cost Visibility The board wants to know how engineering budget maps to business outcomes. **PanDev** provides cost-per-project, cost-per-team, and cost-per-employee analytics directly. Financial data is available immediately. **DX** does not track financial data. It measures experience, not costs. ### Scenario 4: Measuring Impact of a Process Change You changed code review policy last month and want to know if it worked. **PanDev** shows you Review Time trends before and after the change with quantitative data. **DX** can survey developers about whether code reviews feel better, faster, or more effective. **Both together** would be ideal: quantitative proof that review time decreased plus qualitative confirmation that developers feel the process improved. ## Can You Use Both? Yes, and for mature engineering organizations, this combination is powerful. Use PanDev for continuous quantitative measurement (what is happening) and DX for periodic qualitative measurement (how developers feel about it). However, budget and complexity are practical constraints. If you must choose one: - **Start with PanDev** if you need immediate, actionable operational data - **Start with DX** if developer satisfaction and retention are your primary concerns ## Who Should Choose What **Choose DX if:** - Developer experience and satisfaction measurement is your primary goal - You value research-backed, scientifically designed survey instruments - Understanding the "why" behind engineering patterns is more important than the "what" - Enterprise credibility and academic frameworks matter to your stakeholders - You have budget for enterprise pricing and a sales cycle timeline - Developer retention is a pressing concern **Choose PanDev Metrics if:** - You need objective, continuous quantitative metrics - DORA metrics with 4-stage Lead Time breakdown are important - IDE-level activity tracking is valuable for accurate data - Financial analytics (cost per project/team) are required - On-premise deployment is needed for compliance - You want to start immediately with a free tier - AI-powered queries and gamification add value for your team - Real-time data is more useful than periodic survey results ## Bottom Line DX and PanDev Metrics are not competitors in the traditional sense — they measure different dimensions of engineering effectiveness. DX measures how developers feel about their work through rigorous surveys. PanDev measures what developers do and what it costs through automated data collection. The most data-mature organizations will use both. But if you are choosing a first engineering analytics platform, PanDev provides immediate operational value with objective data, while DX provides deeper understanding of developer experience through structured qualitative measurement. Choose based on your most urgent question. If it is "What is happening in our engineering org?" — choose PanDev. If it is "How do our developers feel about working here?" — choose DX. --- *Try [PanDev Metrics](https://pandev-metrics.com) — quantitative engineering intelligence with a free tier.* --- ## PanDev Metrics vs Faros AI: All-in-One Platform vs Data Aggregator URL: https://pandev-metrics.com/docs/blog/pandev-vs-faros Date: 2025-09-26 Tags: comparison, alternatives, faros-ai, data-aggregation, engineering-intelligence Description: PanDev Metrics vs Faros AI compared: integrated analytics platform vs data aggregation layer with open-source connectors and Grafana dashboards. Faros AI takes a data aggregation approach to engineering intelligence — connecting 50+ tools through open-source connectors (an alternative to Apache DevLake), normalizing the data into a unified model, and presenting it through Grafana dashboards. PanDev Metrics takes an all-in-one platform approach with integrated analytics, IDE tracking, and financial features. Same goal, very different architectures. ## Architectural Difference The fundamental difference between these platforms is their architecture and philosophy: **Faros AI** is a data aggregation layer. It collects data from engineering tools (git, CI/CD, project management, incident management) through open-source connectors, normalizes it into a unified data model, and makes it available for querying and visualization — typically through Grafana dashboards. Think of it as an ETL pipeline for engineering data. **PanDev Metrics** is an integrated analytics platform. It collects data through its own IDE plugins and direct integrations, processes it internally, and presents it through purpose-built dashboards with integrated AI queries, financial analytics, and gamification. Think of it as a complete product rather than a data infrastructure layer. This architectural choice has significant implications for setup complexity, maintenance burden, customization flexibility, and time to value. ## Feature Comparison | Feature | PanDev Metrics | Faros AI | |---|---|---| | **Architecture** | Integrated platform | Data aggregation layer | | **IDE Activity Tracking** | Yes, 10+ plugins | No | | **DORA Metrics** | Yes, 4-stage Lead Time breakdown | Yes (via Grafana dashboards) | | **Financial Analytics** | Yes (cost per project/team/employee) | No (would require custom dashboards) | | **Data Visualization** | Built-in dashboards | Grafana (requires configuration) | | **Open-Source Connectors** | No | Yes (significant strength) | | **Custom Data Sources** | Limited | Yes (build custom connectors) | | **Git Provider Support** | GitLab, GitHub, Bitbucket, Azure DevOps (simultaneous) | Multiple via connectors | | **On-Premise Deployment** | Yes (Docker + Kubernetes) | Yes (self-hosted option) | | **AI Assistant** | Yes (Gemini-powered) | No | | **Gamification** | Yes (levels, XP, badges) | No | | **SSO/LDAP** | Yes | Depends on deployment | | **Setup Complexity** | Low-medium (guided setup) | Medium-high (connector configuration, Grafana setup) | | **Maintenance Burden** | Low (managed platform) | Medium-high (connector updates, data pipeline) | | **Free Tier** | Yes | Open-source version available | | **Pricing** | Competitive per-developer | Open-source + enterprise pricing | | **Multi-Tenancy** | Yes | Depends on deployment | | **Customization** | Platform features | Highly customizable (SQL, Grafana) | ## Where Faros AI Excels ### Open-Source Connectors Faros's open-source connector framework (based on Airbyte) is its strongest differentiator — essentially a more polished, commercially-backed alternative to Apache DevLake for engineering data aggregation. It can connect to 50+ engineering tools: GitHub, GitLab, Jira, PagerDuty, Jenkins, CircleCI, Datadog, and more. If a connector does not exist, you can build one using the open-source framework. This flexibility is powerful for organizations with complex, heterogeneous toolchains. If you use niche or proprietary tools that commercial platforms do not support, Faros's connector architecture provides a path to integration. For data engineering teams accustomed to building pipelines, Faros feels natural in a way that opinionated SaaS products may not. ### Data Model Flexibility Faros normalizes data from all connected sources into a unified graph data model. This means you can query across tool boundaries — linking code commits to Jira tickets to deployments to incidents in arbitrary ways. For data-savvy engineering teams that want custom analytics, this flexibility is valuable. ### Grafana Integration By using Grafana for visualization, Faros leverages an ecosystem that many engineering teams already know. If your organization already uses Grafana for infrastructure monitoring, adding engineering metrics dashboards feels natural. Teams can build custom dashboards tailored to their specific needs using SQL and Grafana's visualization tools. ### Self-Hosted Option Faros offers a self-hosted deployment option through its open-source components. For organizations that want complete control over their engineering data pipeline, this is appealing. You own the infrastructure, the data, and the configuration. ### Cost-Effective for Data-Savvy Teams For organizations with strong data engineering capabilities, Faros can be cost-effective. The open-source connectors are free, and the primary cost is the engineering time to set up and maintain the pipeline plus any Faros enterprise features needed. ## Where PanDev Metrics Excels ### Time to Value PanDev is a product you configure, not infrastructure you build. Connect your git providers, install IDE plugins, and you have dashboards with data. The time from signup to actionable insights is measured in hours, not weeks. Faros requires configuring connectors, setting up the data pipeline, building Grafana dashboards, and tuning queries. For organizations without dedicated data engineering resources, this setup process can take weeks and requires ongoing maintenance. ### IDE-Level Activity Tracking PanDev's 10+ IDE plugins (VS Code, JetBrains, Eclipse, Xcode, Visual Studio, PL/SQL Developer, Chrome, CLI) capture developer activity at the source. This is data that no data aggregator can collect — you need purpose-built plugins in the developer's environment. Faros collects data from tools (git, CI/CD, project management) but not from IDEs. It cannot tell you how much time a developer spent coding, debugging, or reading code. It only sees the outputs that appear in connected tools. ### Financial Analytics PanDev includes built-in cost-per-project, cost-per-team, and cost-per-employee analytics with configurable hourly rates. This is a product feature that works out of the box. With Faros, you could theoretically build financial dashboards by combining activity data with external rate information, but this requires custom SQL queries, additional data sources, and ongoing maintenance. It is possible, but it is a data engineering project, not a feature toggle. ### AI-Powered Queries PanDev's Gemini-powered AI assistant lets you ask questions in natural language. Instead of writing SQL queries against Grafana, you ask: "Which team had the highest review time last month?" This democratizes data access beyond the few team members who know SQL. Faros has no built-in AI assistant. Data access requires SQL knowledge or pre-built Grafana dashboards. ### 4-Stage Lead Time Breakdown PanDev breaks Lead Time into Coding Time, Pickup Time, Review Time, and Deploy Time automatically. This is calculated from the integrated data model and presented in purpose-built dashboards. Faros can calculate similar breakdowns, but they require custom queries and dashboard configuration. The breakdown is not a built-in feature — it is something you build. ### No Maintenance Burden PanDev is a managed platform. Updates, bug fixes, and new features are delivered automatically. There are no connectors to maintain, no data pipelines to monitor, and no Grafana dashboards to fix when data schemas change. Faros requires ongoing data engineering: connector updates, pipeline monitoring, dashboard maintenance, and troubleshooting when data stops flowing. This is not a one-time cost — it is a recurring operational burden. ### Gamification PanDev's levels, XP, and badges create positive developer engagement. This is a product feature that creates value for individual contributors, not just managers. Faros, as a data layer, has no mechanism for developer-facing engagement features. ## The Build vs. Buy Decision Choosing between Faros and PanDev is essentially a build vs. buy decision: **Faros = Build.** You get powerful data infrastructure components and assemble them into the analytics solution your organization needs. Maximum flexibility, but significant engineering investment. **PanDev = Buy.** You get a complete analytics product with opinionated features designed for common engineering management use cases. Faster time to value, but less customization flexibility. This decision should be driven by your organization's: - **Data engineering capacity** — Do you have engineers who can build and maintain Grafana dashboards and data pipelines? - **Time constraints** — Do you need insights this week or can you invest weeks in setup? - **Customization needs** — Do you need analytics that no commercial product provides? - **Operational overhead tolerance** — Can you maintain another piece of internal infrastructure? ## Pricing Comparison | Aspect | PanDev Metrics | Faros AI | |---|---|---| | **Open-Source** | No | Yes (connectors) | | **Free Tier** | Yes | Open-source version | | **Paid Pricing** | Competitive per-developer | Enterprise pricing | | **Hidden Costs** | Minimal | Engineering time for setup/maintenance | | **IDE Tracking** | Included | Not available | | **Financial Analytics** | Included | Requires custom build | | **AI Assistant** | Included | Not available | | **Maintenance Cost** | Zero (managed) | Ongoing data engineering | The true cost of Faros includes the engineering time to configure, customize, and maintain the platform. For organizations with expensive data engineers, this hidden cost can exceed the subscription price of a managed platform. ## Real-World Scenarios ### Scenario 1: Data-Savvy Platform Team A platform engineering team with strong data engineering skills wants maximum flexibility in their engineering analytics. They use 15+ different tools and need custom cross-tool analytics. **Faros** is a strong fit. The open-source connectors cover their tool landscape, and the team has the skills to build custom Grafana dashboards. The data model flexibility lets them answer questions that no commercial product has pre-built. **PanDev** covers the common use cases but may lack connectors for their niche tools. ### Scenario 2: VP of Engineering Needs Quick Answers A VP of Engineering at a 60-person team needs DORA metrics, cost tracking, and team performance data. They do not have a data engineering team and need answers this week. **Faros** requires too much setup time and engineering investment for this use case. **PanDev** delivers dashboards with data within hours. DORA metrics, financial analytics, and team views work out of the box. ### Scenario 3: Enterprise with Diverse Toolchain A large organization with hundreds of developers using a mix of GitHub, GitLab, Jenkins, CircleCI, PagerDuty, Datadog, and proprietary internal tools. **Faros** can connect to all of these through its connector framework. The unified data model creates cross-tool visibility. **PanDev** covers the core tools (git providers, task trackers) and adds IDE tracking, but may not connect to all specialized tools in the stack. ### Scenario 4: Regulated Industry Needing On-Premise A financial services company needs everything on-premise with no external data transmission. **Both** can work here. Faros can be self-hosted, and PanDev deploys via Docker/Kubernetes. PanDev offers a simpler on-premise experience with less maintenance. ## Who Should Choose What **Choose Faros AI if:** - Your organization has strong data engineering capabilities - You need to connect to many diverse or niche engineering tools - Custom analytics beyond standard dashboards are important - You want maximum flexibility in data modeling and visualization - You are comfortable with Grafana for visualization - Ongoing data pipeline maintenance is acceptable - You do not need IDE tracking or built-in financial analytics **Choose PanDev Metrics if:** - You want a complete product with fast time to value - IDE-level activity tracking is important for accurate data - Built-in financial analytics are required - You prefer managed infrastructure over self-maintained data pipelines - AI-powered natural language queries would benefit your organization - Gamification for developer engagement adds value - You do not have dedicated data engineering resources for analytics infrastructure - 4-stage Lead Time breakdown is valuable for bottleneck identification ## Bottom Line Faros AI and PanDev Metrics solve engineering intelligence differently. Faros gives you powerful data infrastructure to build custom analytics. PanDev gives you a complete analytics product ready to use. For organizations with data engineering talent and complex, heterogeneous toolchains, Faros's flexibility is valuable. For organizations that need engineering insights without building a data pipeline, PanDev's integrated platform delivers faster with less overhead — and includes capabilities like IDE tracking, financial analytics, and AI queries that a data aggregator does not provide. The choice is not about which is better — it is about whether your organization wants to build an analytics solution or buy one. --- *Try [PanDev Metrics](https://pandev-metrics.com) — no data pipeline required, free tier available.* --- ## PanDev Metrics vs Code Climate Velocity: Activity Metrics vs Code Quality URL: https://pandev-metrics.com/docs/blog/pandev-vs-codeclimate Date: 2025-09-23 Tags: comparison, alternatives, code-climate, code-quality, developer-productivity Description: PanDev Metrics vs Code Climate Velocity compared: engineering analytics with IDE tracking and financial data vs PR-focused code quality metrics. Code Climate started as a code quality tool — one of the earliest in the automated code review space — and expanded into engineering analytics with its Velocity product at approximately $15 per developer per month. PanDev Metrics was built from the ground up as an engineering intelligence platform. Both provide team-level metrics, but their origins shape what they do best — and where each falls short. ## Origin Stories Matter **Code Climate** launched as an automated code review tool focused on code quality — test coverage, maintainability, duplication, and security vulnerabilities. Later, they added **Velocity**, a separate product focused on engineering team analytics: PR throughput, cycle time, and team activity metrics. **PanDev Metrics** was built as an engineering intelligence platform from day one, combining IDE tracking, DORA metrics, financial analytics, and AI-powered insights. It was designed to answer organizational questions about engineering performance and cost. This distinction matters because Code Climate's analytics (Velocity) is an add-on to a code quality platform, while PanDev's analytics is the core product. The depth and breadth of engineering metrics reflects this difference. ## Feature Comparison | Feature | PanDev Metrics | Code Climate Velocity | |---|---|---| | **Code Quality Analysis** | No (different focus) | Yes (core Code Climate product) | | **PR/Cycle Time Analytics** | Yes | Yes (core Velocity feature) | | **DORA Metrics** | Yes, 4-stage Lead Time breakdown | No | | **IDE Activity Tracking** | Yes, 10+ plugins | No | | **Financial Analytics** | Yes (cost per project/team/employee) | No | | **Git Provider Support** | GitLab, GitHub, Bitbucket, Azure DevOps (simultaneous) | GitHub, GitLab, Bitbucket | | **On-Premise Deployment** | Yes (Docker + Kubernetes) | No (cloud-only) | | **AI Assistant** | Yes (Gemini-powered) | No | | **Gamification** | Yes (levels, XP, badges) | No | | **SSO/LDAP** | Yes | Yes (Enterprise) | | **Test Coverage Tracking** | No | Yes | | **Maintainability Scores** | No | Yes | | **Security Vulnerability Detection** | No | Yes (via code quality) | | **Free Tier** | Yes | Yes (limited) | | **Pricing** | Competitive per-developer | ~$15/dev/month (Velocity) | | **Multi-Tenancy** | Yes | No | ## Where Code Climate Excels ### Code Quality Analysis Code Climate's original product — automated code review — remains strong. It analyzes code for maintainability, duplication, complexity, and test coverage. For teams that want automated quality gates in their CI/CD pipeline, Code Climate provides actionable feedback on every pull request. If code quality enforcement is your primary need, Code Climate's quality product is mature and well-integrated with GitHub and GitLab workflows. ### PR Analytics and Cycle Time Velocity focuses on pull request throughput and cycle time metrics. It tracks: - How many PRs each developer and team ships - How long PRs take from open to merge - Review activity and reviewer workload - Coding frequency and patterns For teams whose primary concern is "Are we shipping PRs fast enough?" — Velocity provides a focused answer. ### Simplicity Code Climate Velocity does a few things and does them clearly. The dashboards are straightforward, the metrics are easy to understand, and the setup is minimal. For teams that want basic PR analytics without complexity, this simplicity is an advantage. ### Test Coverage Integration Code Climate tracks test coverage over time, showing trends and flagging PRs that decrease coverage. This is valuable for teams that prioritize testing discipline. PanDev does not track test coverage — it is a different analytical focus. ## Where PanDev Metrics Excels ### DORA Metrics PanDev provides all four DORA metrics with a 4-stage Lead Time breakdown (Coding Time, Pickup Time, Review Time, Deploy Time). Code Climate Velocity does not provide DORA metrics. For engineering leaders reporting on delivery performance, this is a significant gap in Velocity. DORA metrics have become the industry standard for measuring software delivery performance. Not providing them means Velocity cannot answer questions that boards and executives increasingly ask: "What is our deployment frequency?" and "What is our lead time for changes?" ### IDE-Level Activity Tracking PanDev's 10+ IDE plugins capture actual developer activity: coding time, debugging sessions, project switching, and language usage. This ground-truth data reveals the full development process, not just its git output. Code Climate Velocity relies entirely on git data. It measures commits, PRs, and reviews — the output of development — but misses the activity that happens before code is committed. For accurate time tracking and cost allocation, this gap matters. ### Financial Analytics PanDev calculates cost per project, cost per team, and cost per employee with configurable hourly rates. Engineering leaders can answer: "How much did Sprint 23 cost for Team Alpha?" or "What is our cost per PR this quarter?" Code Climate offers no financial analytics. Cost questions require separate tools. ### On-Premise Deployment PanDev deploys on-premise via Docker and Kubernetes. Code Climate is cloud-only. For regulated industries, government contractors, or organizations with strict data governance, PanDev's on-premise option is essential. ### AI-Powered Queries PanDev's Gemini-powered AI assistant answers natural language questions about engineering data. Code Climate has no AI features. ### Multi-Provider Git Support PanDev connects to GitHub, GitLab, Bitbucket, and Azure DevOps simultaneously. Code Climate supports GitHub, GitLab, and Bitbucket but not Azure DevOps. Organizations using Azure DevOps are not served by Code Climate. ### Gamification PanDev's levels, XP, and badges create positive developer engagement. Code Climate Velocity is purely a management visibility tool with no developer-facing engagement features. ### Breadth of Analytics PanDev covers a wider surface: DORA metrics, IDE activity, financial analytics, task tracker integration, team comparisons, and AI-powered insights. Code Climate Velocity covers PR metrics and coding activity derived from git data. The analytics surface difference is substantial. ## The Code Quality Question Code Climate's original code quality product is genuinely useful, but it is a different category from engineering analytics. Code quality tools and engineering intelligence platforms serve different purposes: **Code quality tools** answer: "Is this code well-written?" They analyze code for maintainability, complexity, duplication, and test coverage. **Engineering intelligence platforms** answer: "How is our engineering organization performing?" They measure delivery speed, developer activity, team efficiency, and engineering costs. You might need both. But they should not be confused. Code Climate's quality product does not replace an engineering intelligence platform, and PanDev does not replace a code quality tool. If you need both, use Code Climate (quality) alongside PanDev (engineering intelligence). They are complementary, not competitive. ## Pricing Comparison | Aspect | PanDev Metrics | Code Climate Velocity | |---|---|---| | **Free Tier** | Yes | Yes (limited) | | **Paid Pricing** | Competitive per-developer | ~$15/dev/month | | **Annual Cost (30 devs)** | Competitive | ~$5,400 | | **Annual Cost (100 devs)** | Competitive | ~$18,000 | | **DORA Metrics** | Included | Not available | | **IDE Tracking** | Included | Not available | | **Financial Analytics** | Included | Not available | | **On-Premise** | Available | Not available | At approximately $15/dev/month, Code Climate Velocity is mid-range in pricing for the limited analytics it provides. PanDev offers broader capabilities at a competitive price. Note: Code Climate's quality product is priced separately. If you need both quality and Velocity, the combined cost increases. ## Real-World Scenarios ### Scenario 1: Team Focused on Code Quality and PR Speed A team wants to enforce code quality standards and track PR throughput. They do not need DORA metrics, financial analytics, or IDE tracking. **Code Climate** is a good fit — the quality product handles code standards, and Velocity tracks PR metrics. The combined solution addresses both needs. **PanDev** covers PR metrics and adds more, but does not provide automated code quality analysis. ### Scenario 2: Engineering Leader Needs Comprehensive Metrics A VP of Engineering needs DORA metrics for board reporting, financial data for budget planning, and team analytics for organizational decisions. **Code Climate Velocity** falls short. No DORA metrics, no financial analytics, and limited team-level insights. **PanDev** provides the full analytics surface: DORA, financial, IDE activity, team comparisons, and AI queries. ### Scenario 3: Enterprise with Azure DevOps An organization using Azure DevOps as their primary git provider needs engineering analytics. **Code Climate** does not support Azure DevOps. Not an option. **PanDev** connects to Azure DevOps alongside GitHub, GitLab, and Bitbucket. ### Scenario 4: Regulated Healthcare Company A healthcare organization needs engineering metrics with on-premise deployment. **Code Climate** is cloud-only. Does not meet compliance requirements. **PanDev** deploys on-premise with Docker/Kubernetes and LDAP/SSO. ### Scenario 5: Startup Wanting Quick PR Insights A 10-person startup wants simple PR analytics to understand delivery patterns. **Code Climate Velocity** provides this with minimal setup. Simple, focused, affordable. **PanDev** also works but provides more than the startup may need initially. The free tier makes evaluation easy. ## Who Should Choose What **Choose Code Climate (Velocity) if:** - PR throughput and cycle time are your primary metrics - You also need automated code quality analysis (Code Climate's original product) - You want simple, focused PR analytics without complexity - Test coverage tracking is important - You do not need DORA metrics, IDE tracking, or financial analytics - Cloud-only deployment is acceptable - You do not use Azure DevOps **Choose PanDev Metrics if:** - You need DORA metrics with 4-stage Lead Time breakdown - IDE-level activity tracking is important for accurate data - Financial analytics (cost per project/team) are required - On-premise deployment is needed for compliance - You use Azure DevOps or multiple git providers simultaneously - AI-powered natural language queries would benefit your workflow - Gamification would help drive developer adoption - You want comprehensive engineering intelligence, not just PR metrics ## Bottom Line Code Climate Velocity is a focused PR analytics tool that pairs well with Code Climate's code quality product. For teams whose primary need is tracking PR throughput and maintaining code quality standards, it is a practical choice. PanDev Metrics is a comprehensive engineering intelligence platform that covers a much broader analytical surface: DORA metrics, IDE tracking, financial analytics, AI queries, and on-premise deployment. For organizations that need to understand engineering performance at the organizational level — not just PR level — PanDev provides the depth and breadth that Velocity does not. If your question is "How fast are we shipping PRs?" — either platform answers it. If your question is "How is our engineering organization performing, what does it cost, and where are the bottlenecks?" — PanDev is built for that. --- *Try [PanDev Metrics](https://pandev-metrics.com) — DORA, financial analytics, IDE tracking, and AI-powered insights.* --- ## PanDev Metrics vs Haystack: Comprehensive Platform vs Lightweight DORA URL: https://pandev-metrics.com/docs/blog/pandev-vs-haystack Date: 2025-09-19 Tags: comparison, alternatives, haystack, dora-metrics, code-review Description: PanDev Metrics vs Haystack compared: comprehensive engineering intelligence vs lightweight DORA metrics and code review analytics for dev teams. Haystack is a lightweight engineering analytics tool focused on DORA metrics and code review insights at approximately $10 per developer per month — one of the lowest price points in the market. PanDev Metrics is a comprehensive engineering intelligence platform with IDE tracking, financial analytics, and on-premise deployment. The comparison comes down to depth vs. simplicity. ## Platform Overview **Haystack** positions itself as an affordable, straightforward DORA metrics and code review analytics tool. At approximately $10 per developer per month, it targets small to mid-size teams that want delivery metrics without the complexity or cost of enterprise platforms. The focus is narrow: DORA metrics and code review efficiency. **PanDev Metrics** is a broader engineering intelligence platform combining DORA metrics, IDE-level activity tracking, financial analytics, AI-powered queries, and gamification. It offers both cloud and on-premise deployment options, targeting engineering leaders who need comprehensive organizational visibility. Both platforms serve engineering teams, but at very different scopes. Haystack is a scalpel — precise and focused. PanDev is a toolkit — comprehensive and versatile. ## Feature Comparison | Feature | PanDev Metrics | Haystack | |---|---|---| | **DORA Metrics** | Yes, 4-stage Lead Time breakdown | Yes (core feature) | | **Code Review Analytics** | Yes | Yes (core feature) | | **IDE Activity Tracking** | Yes, 10+ plugins | No | | **Financial Analytics** | Yes (cost per project/team/employee) | No | | **Git Provider Support** | GitLab, GitHub, Bitbucket, Azure DevOps (simultaneous) | GitHub (primary), limited others | | **On-Premise Deployment** | Yes (Docker + Kubernetes) | No (cloud-only) | | **AI Assistant** | Yes (Gemini-powered) | No | | **Gamification** | Yes (levels, XP, badges) | No | | **SSO/LDAP** | Yes | Limited | | **Task Tracker Integration** | Jira, ClickUp, and more | Limited | | **Slack Integration** | Basic | Yes | | **Free Tier** | Yes | Limited free plan | | **Pricing** | Competitive per-developer | ~$10/dev/month | | **Multi-Tenancy** | Yes | No | | **Setup Complexity** | Low-medium | Very low | | **Number of Integrations** | Multiple categories | Limited | ## Where Haystack Excels ### Simplicity and Speed Haystack's greatest strength is its simplicity. Connect your GitHub repository, and you have DORA metrics and code review analytics within minutes. There is no complex configuration, no plugin deployment, and no lengthy onboarding process. For teams that want quick, no-fuss delivery metrics, Haystack delivers. ### Affordable Pricing At approximately $10 per developer per month, Haystack is one of the most affordable engineering analytics tools on the market. For a 20-developer team, that is roughly $2,400 per year — accessible for virtually any company, including early-stage startups. ### Code Review Focus Haystack provides useful code review analytics: review time, reviewer workload, review depth, and stale PR identification. For teams whose primary bottleneck is code review, these focused insights are immediately actionable. ### Low Barrier to Adoption With minimal setup and an intuitive interface, Haystack can be adopted by teams without a dedicated analytics champion. Engineering managers can set it up themselves without involving DevOps or platform teams. ### Focused Dashboard By doing less, Haystack's dashboards are uncluttered and easy to read. There is no information overload. The metrics that matter — deployment frequency, lead time, code review speed — are front and center. ## Where PanDev Metrics Excels ### IDE-Level Activity Tracking PanDev's 10+ IDE plugins capture what developers do throughout the day: active coding time, debugging sessions, project switching, and language usage. Haystack relies entirely on git and deployment data, which means it only sees the output of development work. This matters for two reasons: 1. **Accuracy** — Git metrics undercount developer activity. Significant time goes into code reading, debugging, and exploration that never results in a commit. 2. **Cost allocation** — Without IDE data, you cannot accurately calculate how developer time distributes across projects. ### Financial Analytics PanDev provides cost-per-project, cost-per-team, and cost-per-employee analytics. This is a capability Haystack does not offer and that is critical for: - Board-level engineering cost reporting - Project cost estimation from historical data - Team cost comparison and optimization - ROI calculation for engineering investments ### 4-Stage Lead Time Breakdown While both platforms track Lead Time for Changes, PanDev breaks it into four stages: Coding Time, Pickup Time, Review Time, and Deploy Time. Haystack provides overall lead time and some code review breakdown, but the four-stage model provides greater precision for bottleneck identification. ### On-Premise Deployment PanDev deploys on-premise via Docker and Kubernetes. Haystack is cloud-only. For regulated industries, this is a non-negotiable requirement. ### Multi-Provider Git Support PanDev connects to GitHub, GitLab, Bitbucket, and Azure DevOps simultaneously. Haystack is primarily GitHub-focused with limited support for other providers. Organizations using GitLab, Bitbucket, or Azure DevOps may find Haystack insufficient. ### AI-Powered Queries PanDev's Gemini-powered AI assistant enables natural language data queries. Instead of navigating dashboards, you ask: "What was the average pickup time for the backend team last month?" Haystack has no AI features. ### Task Tracker Integration PanDev integrates with Jira, ClickUp, and other project management tools, correlating coding activity with work items. Haystack has limited task tracker integration, which means you cannot easily connect engineering metrics to business deliverables. ### Gamification PanDev's levels, XP, and badges create positive developer engagement. For platform adoption — one of the biggest challenges with engineering analytics tools — gamification gives developers a reason to engage rather than ignore the tool. ### Multi-Tenancy PanDev supports multi-tenancy for agencies, consultancies, or organizations with multiple business units. Haystack does not offer this capability. ## Pricing Comparison | Aspect | PanDev Metrics | Haystack | |---|---|---| | **Free Tier** | Yes | Limited | | **Paid Pricing** | Competitive per-developer | ~$10/dev/month | | **Annual Cost (20 devs)** | Competitive | ~$2,400 | | **Annual Cost (50 devs)** | Competitive | ~$6,000 | | **IDE Tracking** | Included | Not available | | **Financial Analytics** | Included | Not available | | **On-Premise** | Available | Not available | | **AI Assistant** | Included | Not available | Haystack is attractively priced for what it offers. The question is whether the limited feature set meets your needs or whether the additional capabilities of PanDev justify the investment. ## The Growth Question An important consideration is where your analytics needs will be in 12-18 months. Teams often start with basic DORA metrics and code review analytics, but as the organization matures, the questions become more complex: - "How much does Project X cost?" (requires financial analytics) - "Where exactly do developers spend their time?" (requires IDE tracking) - "Can we deploy on-premise for compliance?" (requires self-hosted option) - "Can I ask a question in plain English?" (requires AI assistant) If you start with Haystack and later need these capabilities, you will need to migrate to a different platform — reconfiguring integrations, retraining teams, and losing historical data continuity. Starting with PanDev means the platform grows with your needs. Basic DORA and code review metrics are available immediately, and deeper capabilities are there when you need them. ## Real-World Scenarios ### Scenario 1: Early-Stage Startup (8 developers) A seed-stage startup wants basic delivery metrics to establish engineering rhythm. Budget is minimal. **Haystack** is a good fit. At $10/dev/month ($960/year for 8 devs), it provides DORA and code review metrics with minimal setup. **PanDev** also works with its free tier, and provides more room to grow. The team should consider future needs. ### Scenario 2: Scaling Team Needing Cost Visibility (40 developers) A Series B company needs to report engineering costs to the board and understand project-level spending. **Haystack** cannot provide financial analytics. The team would need spreadsheets or additional tools. **PanDev** provides built-in cost-per-project and cost-per-team analytics that directly support board reporting. ### Scenario 3: Multi-Provider Git Environment An organization using GitLab for most projects but GitHub for open-source contributions. **Haystack** is primarily GitHub-focused. GitLab support may be limited. **PanDev** connects to both simultaneously, providing unified analytics across providers. ### Scenario 4: Regulated Enterprise A financial services company needs on-premise engineering analytics with SSO. **Haystack** is cloud-only with limited SSO. Not suitable. **PanDev** deploys on-premise with Docker/Kubernetes and supports LDAP/SSO. ### Scenario 5: Team Wanting Only DORA Basics A team of 15 developers wants basic DORA metrics and nothing else. Simplicity is the priority. **Haystack** is designed exactly for this. Simple, focused, affordable. **PanDev** works too but may feel like more tool than needed for this narrow use case. ## Who Should Choose What **Choose Haystack if:** - You want simple, focused DORA metrics and code review analytics - Budget is tight and ~$10/dev/month is the target - You primarily use GitHub - Minimal setup complexity is important - You do not need IDE tracking, financial analytics, or on-premise deployment - Your analytics needs are unlikely to expand significantly **Choose PanDev Metrics if:** - You need comprehensive engineering intelligence beyond basic DORA - IDE-level activity tracking is important - Financial analytics (cost per project/team) are required - On-premise deployment is necessary - You use GitLab, Bitbucket, or Azure DevOps (alongside or instead of GitHub) - AI-powered queries and gamification add value - You want a platform that grows with your organization - Task tracker integration for work item correlation is needed ## Bottom Line Haystack is a well-executed lightweight DORA tool. For small teams on tight budgets that need basic delivery metrics from GitHub, it delivers good value with minimal friction. There is nothing wrong with starting simple. PanDev Metrics is a comprehensive engineering intelligence platform that goes far beyond DORA and code review metrics. IDE tracking, financial analytics, AI queries, on-premise deployment, and multi-provider support create an analytics foundation that scales with organizational needs. The decision is straightforward: if basic DORA metrics from GitHub are enough, Haystack is efficient and affordable. If you need (or will need) more — deeper data, cost visibility, compliance-ready deployment, multiple git providers — PanDev is the platform that grows with you. --- *Try [PanDev Metrics](https://pandev-metrics.com) — free tier available, comprehensive analytics when you are ready.* --- ## Best Engineering Intelligence Tools 2026: Top 15 Platforms for Velocity, DORA & DevEx URL: https://pandev-metrics.com/docs/blog/top-engineering-intelligence-tools-2026 Date: 2025-09-15 Tags: comparison, alternatives, market-overview, engineering-intelligence, dora-metrics Description: Compare the best engineering intelligence tools in 2026: 15 platforms tracking engineering velocity, DORA metrics and DevEx — with executive-level visibility. The engineering intelligence market has matured significantly. What started as simple git analytics has evolved into a diverse ecosystem of platforms measuring developer productivity, delivery performance, engineering costs, and developer experience. This guide covers the 15 most relevant tools in 2026, organized by category. ## Market Landscape Engineering intelligence tools fall into five categories, each approaching the problem from a different angle: 1. **Comprehensive Engineering Intelligence** — Full-stack platforms combining multiple data sources 2. **DORA and Delivery Analytics** — Focused on software delivery performance metrics 3. **Developer Experience (DevEx)** — Survey-based and experience-focused measurement 4. **Personal Time Trackers** — Individual developer productivity tracking 5. **Data Aggregation and Infrastructure** — ETL and data pipeline approaches Understanding which category a tool belongs to helps set expectations about what it can and cannot do. ## Category 1: Comprehensive Engineering Intelligence ### 1. PanDev Metrics **Website:** pandev-metrics.com **Pricing:** Free tier available, competitive per-developer paid plans **Best for:** Organizations needing complete engineering visibility with IDE tracking, financial analytics, and on-premise deployment PanDev Metrics combines IDE-level activity tracking, DORA metrics, financial analytics, and AI-powered insights into a single platform. With 10+ IDE plugins (VS Code, JetBrains, Eclipse, Xcode, Visual Studio, PL/SQL Developer, Chrome, CLI), it captures ground-truth developer activity data that git-only platforms miss. **Key strengths:** - 10+ IDE plugins for actual coding activity tracking - 4-stage Lead Time breakdown (Coding, Pickup, Review, Deploy) - Financial analytics (cost per project, team, employee) - Gemini-powered AI assistant for natural language queries - On-premise deployment (Docker + Kubernetes) - Multi-provider git support (GitHub, GitLab, Bitbucket, Azure DevOps simultaneously) - Gamification (levels, XP, badges) for developer engagement - LDAP/SSO and multi-tenancy - Featured in Forbes Kazakhstan (April 2026) — client results show 30% productivity increase and 25% improvement in release quality - ~40 companies currently in pilot, including ABR Tech, Chocofood, and Zeely **Limitations:** - Newer to the market than some established players - Fewer published enterprise case studies than legacy platforms - No built-in developer experience surveys ### 2. Jellyfish **Website:** jellyfish.co **Pricing:** $50,000-$250,000/year (enterprise contracts) **Best for:** Large enterprises with dedicated engineering analytics budgets and executive reporting needs Jellyfish is the enterprise heavyweight of engineering management platforms, claiming over 50,000 teams and hosting GLOWLive events for engineering leaders. Its "allocation" views translate engineering activity into business language, making it effective for board-level presentations and executive communication. **Key strengths:** - Executive-level engineering investment reporting - Deep Jira integration for business alignment - 29+ published case studies, GLOWLive events - Mature enterprise sales and support with ROI calculator - Claims 50,000+ teams on the platform **Limitations:** - Expensive ($50K-$250K/year) - No IDE tracking - Cloud-only (no on-premise) - No free tier or self-service signup - Requires enterprise sales process to evaluate ### 3. Pluralsight Flow (Appfire) **Website:** appfire.com (formerly flow.pluralsight.com) **Pricing:** ~$50/dev/month **Best for:** Existing customers with established workflows (not recommended for new adoptions) Originally GitPrime, this platform changed hands three times (GitPrime to Pluralsight to Appfire). It pioneered concepts like "Active Days" and efficiency metrics. However, visible product innovation has stagnated, content updates are minimal, and only one case study is publicly available. **Key strengths:** - Pioneered developer efficiency metrics - Established PR analytics - Team comparison features **Limitations:** - Three ownership changes create vendor risk - Minimal visible product innovation - No IDE tracking - No financial analytics - Cloud-only - Premium pricing for a legacy product - 1 published case study ## Category 2: DORA and Delivery Analytics ### 4. LinearB **Website:** linearb.io **Pricing:** $35-$45/dev/month ($420-$549/dev/year), free tier for up to 8 developers **Best for:** Teams focused on DORA metrics with workflow automation needs LinearB provides solid DORA metrics with workflow automation through its WorkerB feature. Their benchmark report draws on over 8.1 million PRs analyzed, and the "Dev Interrupted" podcast has become a go-to resource for engineering leaders. The free tier for up to 8 developers makes it accessible for small teams. **Key strengths:** - Strong DORA metrics with industry benchmarking (8.1M+ PRs analyzed) - WorkerB workflow automation — more mature than most competitors - CI/CD pipeline integration - Free tier (up to 8 developers) - "Dev Interrupted" podcast and strong community **Limitations:** - No IDE tracking - No financial analytics - Cloud-only - $420-$549/dev/year at scale ### 5. Sleuth **Website:** sleuth.io **Pricing:** ~$20/dev/month **Best for:** Teams focused on deployment tracking and DORA metrics with incident correlation Sleuth is purpose-built for deployment tracking, available on both the GitHub Marketplace and Atlassian Marketplace. It automatically detects deployments, correlates them with incidents, and integrates with feature flag systems like LaunchDarkly. For teams that deploy frequently, Sleuth provides deep deployment intelligence. It also offers a free tier for getting started. **Key strengths:** - Automated deployment detection - Incident-to-deploy correlation - Feature flag integration (LaunchDarkly) - ChatOps/Slack integration - Free tier available, plus GitHub/Atlassian marketplace presence **Limitations:** - No IDE tracking - No financial analytics - Cloud-only - Limited to deployment-centric analytics - No Azure DevOps support ### 6. Haystack **Website:** usehaystack.io **Pricing:** ~$10/dev/month **Best for:** Small teams wanting affordable DORA metrics and code review analytics Haystack is one of the most affordable engineering analytics tools. It provides DORA metrics and code review analytics with minimal setup. For budget-conscious teams that need basic delivery metrics, Haystack delivers good value. **Key strengths:** - Very affordable (~$10/dev/month) - Simple setup - DORA metrics - Code review analytics - Clean, focused interface **Limitations:** - Limited integrations - Primarily GitHub-focused - No IDE tracking - No financial analytics - Cloud-only - Limited task tracker integration ### 7. Code Climate Velocity **Website:** codeclimate.com **Pricing:** ~$15/dev/month (Velocity), separate pricing for code quality **Best for:** Teams wanting PR analytics combined with code quality analysis Code Climate started as a code quality tool and added Velocity for team analytics. The combination of code quality analysis and PR metrics is useful for teams that prioritize both code standards and delivery speed. **Key strengths:** - PR throughput and cycle time analytics - Code quality analysis (separate product) - Test coverage tracking - Maintainability scores - GitHub and GitLab integration **Limitations:** - No DORA metrics - No IDE tracking - No financial analytics - Cloud-only - No Azure DevOps support - Quality and Velocity are separate products/costs ## Category 3: Developer Experience (DevEx) ### 8. DX (getdx.com) **Website:** getdx.com **Pricing:** Enterprise (contact sales) **Best for:** Enterprise organizations that want research-backed developer experience measurement DX takes a survey-based approach to developer experience, grounded in the SPACE framework and their proprietary DX Core 4 framework. The surveys are scientifically designed and benchmarked against industry data. This is the leading qualitative measurement platform. **Key strengths:** - Research-backed survey methodology (SPACE, DX Core 4 framework) - Quarterly AI impact reports widely cited in the industry - Industry benchmarking from extensive survey data - Identifies root causes behind quantitative trends - Enterprise credibility with academic backing **Limitations:** - Survey-based (periodic, not continuous) - No automated DORA metrics - No IDE tracking - No financial analytics - Enterprise-only pricing - Requires survey participation from developers ### 9. Swarmia **Website:** swarmia.com **Pricing:** ~$15-$20/dev/month, free tier for up to 9 developers **Best for:** Teams that prioritize developer experience improvement with data-driven working agreements Swarmia combines DORA metrics with developer experience features and counts companies like Miro, Bolt, and Chess.com among its customers. Its working agreements let teams define standards and track compliance automatically. The company published the book "Build" on engineering effectiveness. **Key strengths:** - Developer experience focus with published "Build" book - Working agreements (team standards tracking) - Deep Slack integration - Built-in developer surveys - DORA metrics - Free tier (up to 9 developers), customers include Miro and Bolt **Limitations:** - No IDE tracking - No financial analytics - Cloud-only - No Azure DevOps support - No AI assistant ## Category 4: Personal Time Trackers ### 10. WakaTime **Website:** wakatime.com **Pricing:** Free (personal), ~$9/user/month (teams) **Best for:** Individual developers tracking personal coding habits WakaTime is the most popular personal coding time tracker with 500,000+ users. Its 40+ IDE plugins cover virtually every development environment. The annual "Yearly Wrapped" reports have become a cultural event in the developer community, and the open-source plugin ecosystem is one of the strongest in the market. **Key strengths:** - 40+ IDE/editor plugins — broadest coverage in the market - 500,000+ users, strong open-source community - Annual "Yearly Wrapped" reports - Polished personal dashboard with language and project breakdowns - Daily/weekly goals and GitHub profile badges **Limitations:** - Personal-focused, basic team features - No DORA metrics - No financial analytics - Cloud-only - No task tracker integration - Limited git integration - Basic team analytics ### 11. Clockify / Toggl Track **Website:** clockify.me / toggl.com **Pricing:** Free tiers available, paid plans vary **Best for:** Manual time tracking across any profession (not developer-specific) These are general-purpose time trackers, not developer-specific tools. They require manual time entry or basic timer functionality. Included here because some engineering teams use them for time tracking. **Key strengths:** - Free tiers available - Cross-platform (web, mobile, desktop) - Invoicing and reporting features - Team management **Limitations:** - Not developer-specific - No automated coding time detection - No IDE integration (or basic) - No DORA metrics - No git analytics - Requires manual input ## Category 5: Data Aggregation and Infrastructure ### 12. Faros AI **Website:** faros.ai **Pricing:** Open-source connectors + enterprise pricing **Best for:** Data-savvy teams wanting maximum flexibility with custom engineering analytics Faros AI takes a data aggregation approach with open-source connectors (Airbyte-based) — positioning itself as a commercially-backed alternative to Apache DevLake. Data from dozens of engineering tools is normalized into a unified model and visualized through Grafana dashboards. Maximum flexibility for teams that can build and maintain data pipelines. **Key strengths:** - Open-source connector framework (alternative to Apache DevLake) - Connects to dozens of tools - Unified data model for cross-tool analytics - Grafana visualization - Self-hosted option - Custom analytics via SQL **Limitations:** - Requires data engineering skills - High setup and maintenance burden - No IDE tracking - No built-in financial analytics - No AI assistant - Time to value measured in weeks, not hours ### 13. Propelo (formerly LevelOps) **Website:** propelo.ai **Pricing:** Contact sales **Best for:** Teams wanting DORA metrics with CI/CD pipeline visibility Propelo provides engineering analytics with a focus on CI/CD pipeline visibility and DORA metrics. It connects to multiple DevOps tools and provides dashboards for delivery performance. **Key strengths:** - DORA metrics - CI/CD pipeline analytics - Multiple tool integrations - Bottleneck identification **Limitations:** - No IDE tracking - No financial analytics - Limited public pricing information - Smaller market presence ### 14. Waydev **Website:** waydev.co **Pricing:** Contact sales **Best for:** Teams wanting git-based engineering analytics with benchmarking Waydev provides git-based engineering analytics with team benchmarking and performance tracking. It focuses on measuring developer output through git activity and provides comparison dashboards. **Key strengths:** - Git-based analytics - Team benchmarking - Performance tracking dashboards - Multiple git provider support **Limitations:** - No IDE tracking - Limited financial analytics - Cloud-only - Smaller ecosystem ### 15. Athenian **Website:** athenian.co **Pricing:** Contact sales **Best for:** Teams focused on code review optimization and delivery acceleration Athenian focuses on accelerating software delivery by optimizing code review processes and reducing lead time. It provides actionable recommendations based on delivery data. **Key strengths:** - Code review optimization - Lead time reduction focus - Actionable recommendations - DORA metrics **Limitations:** - No IDE tracking - No financial analytics - Cloud-only - Narrower feature set ## Comprehensive Comparison Matrix | Tool | IDE Tracking | DORA Metrics | Financial Analytics | On-Premise | AI Assistant | Free Tier | Multi-Git Provider | |---|---|---|---|---|---|---|---| | **PanDev Metrics** | 10+ plugins | 4-stage LT | Yes | Yes | Yes | Yes | GitHub, GitLab, BB, Azure | | **Jellyfish** | No | Yes | Investment views | No | Basic | No | GitHub, GitLab, BB | | **Pluralsight Flow** | No | Basic | No | No | No | No | GitHub, GitLab, BB | | **LinearB** | No | Yes | No | No | Yes | Yes (8 devs) | GitHub, GitLab, BB | | **Sleuth** | No | Yes | No | No | No | Limited | GitHub, GitLab, BB | | **Haystack** | No | Yes | No | No | No | Limited | GitHub primary | | **Code Climate** | No | No | No | No | No | Limited | GitHub, GitLab, BB | | **DX** | No | No | No | Unknown | No | No | N/A (surveys) | | **Swarmia** | No | Yes | No | No | No | Yes (9 devs) | GitHub, GitLab, BB | | **WakaTime** | 40+ plugins | No | No | No | No | Yes | Limited | | **Faros AI** | No | Via Grafana | Custom build | Yes | No | Open source | Via connectors | | **Propelo** | No | Yes | No | Unknown | No | Unknown | Multiple | | **Waydev** | No | Basic | Limited | No | No | Unknown | Multiple | | **Athenian** | No | Yes | No | No | No | Unknown | Multiple | ## Key Observations ### 1. IDE Tracking Is Rare Only PanDev Metrics and WakaTime provide meaningful IDE-level activity tracking. Most platforms rely entirely on git events, which capture output but miss the actual development process. This is a significant data gap for any platform claiming to measure "developer productivity." ### 2. Financial Analytics Is Nearly Non-Existent PanDev Metrics is one of very few platforms offering built-in financial analytics (cost per project, team, employee). Jellyfish provides investment allocation views at enterprise pricing. Most platforms leave cost questions unanswered, forcing engineering leaders to maintain separate spreadsheets. ### 3. On-Premise Is Uncommon On-premise deployment — essential for regulated industries — is offered by PanDev Metrics and Faros AI (self-hosted). Most platforms are cloud-only, which excludes them from finance, healthcare, government, and defense customers. ### 4. The Market Is Fragmenting No single tool dominates all categories. Organizations often cobble together multiple tools: - WakaTime for personal time tracking - LinearB for DORA metrics - DX for developer surveys - Spreadsheets for cost tracking PanDev Metrics consolidates most of these needs into a single platform, reducing tool sprawl and data silos. ### 5. Pricing Varies Dramatically From free (Jira reports, WakaTime personal) to $250,000/year (Jellyfish enterprise), the pricing range is enormous. PanDev Metrics positions itself as offering enterprise-grade capabilities at accessible pricing with a free tier for evaluation. ## Choosing the Right Tool ### Decision Framework **Start with your primary question:** | Your Primary Question | Best Category | Recommended Tools | |---|---|---| | "How fast do we deliver software?" | DORA/Delivery | PanDev, LinearB, Sleuth | | "What does engineering cost?" | Financial Analytics | PanDev (only option with built-in financial) | | "What do developers actually do all day?" | IDE Tracking | PanDev, WakaTime | | "How do developers feel about their work?" | DevEx/Surveys | DX, Swarmia | | "How can we improve code quality?" | Code Quality | Code Climate | | "We need custom cross-tool analytics" | Data Aggregation | Faros AI | | "We need on-premise for compliance" | On-Premise | PanDev, Faros AI | | "We need everything in one platform" | Comprehensive | PanDev | ### By Team Size **1-10 developers:** WakaTime (personal), Haystack (basic DORA), PanDev free tier, Swarmia free tier, LinearB free tier **10-50 developers:** PanDev Metrics, LinearB, Swarmia, Sleuth **50-200 developers:** PanDev Metrics, LinearB, Swarmia, Code Climate **200+ developers:** PanDev Metrics, Jellyfish (if budget allows), LinearB, DX (surveys) ### By Budget **$0:** PanDev free tier, LinearB free tier (8 devs), Swarmia free tier (9 devs), WakaTime personal, Jira built-in reports **Under $5,000/year:** PanDev Metrics, Haystack, WakaTime Teams **$5,000-$25,000/year:** PanDev Metrics, LinearB, Swarmia, Sleuth, Code Climate **$25,000-$100,000/year:** PanDev Metrics, LinearB Enterprise **$100,000+/year:** Jellyfish, DX Enterprise ### By Compliance Requirements **Cloud acceptable:** Any tool **On-premise required:** PanDev Metrics (Docker/K8s), Faros AI (self-hosted) **LDAP/SSO required:** PanDev Metrics, Jellyfish, LinearB Enterprise ## Market Trends for 2026 ### AI Integration AI assistants are becoming table stakes. PanDev's Gemini-powered natural language queries and LinearB's AI insights point toward a future where engineering leaders ask questions in plain language instead of navigating dashboards. Expect more platforms to add AI capabilities. ### Financial Accountability Engineering is under increasing pressure to demonstrate financial ROI. Platforms that connect engineering activity to costs — currently a PanDev strength — will see growing demand as CFOs and boards expect the same financial transparency from engineering that other departments provide. ### Developer Experience as a Metric The DevEx movement (led by DX and Swarmia) is gaining traction. Combining quantitative metrics with qualitative survey data will become the gold standard for understanding engineering effectiveness. Platforms that offer both — or integrate well with survey tools — will have an advantage. ### Consolidation Tool sprawl is a real problem. Organizations using 3-5 separate analytics tools face data silos, dashboard fatigue, and integration maintenance. Comprehensive platforms like PanDev that consolidate multiple capabilities will benefit as teams seek simplification. ### On-Premise and Data Sovereignty With increasing data regulation globally, on-premise deployment options will become more important. Cloud-only platforms risk being excluded from growing segments of the market. ## Bottom Line The engineering intelligence market in 2026 offers options for every need and budget. The key is matching the tool to your primary problem: - **Need comprehensive engineering intelligence with IDE tracking, DORA, and financial analytics?** PanDev Metrics delivers the broadest capability set at accessible pricing. - **Need enterprise-grade executive reporting with a large budget?** Jellyfish has the track record. - **Need focused DORA metrics with automation?** LinearB or Sleuth are strong options. - **Need developer experience measurement?** DX or Swarmia focus on this. - **Need personal coding stats?** WakaTime is the standard. - **Need maximum flexibility with custom analytics?** Faros AI provides the data infrastructure. For most organizations, the best starting point is a comprehensive platform that can grow with evolving needs. Starting narrow and adding tools later creates integration complexity and data fragmentation. Starting comprehensive and focusing on what matters most is typically more efficient. --- *Try [PanDev Metrics](https://pandev-metrics.com) — IDE tracking, DORA metrics, financial analytics, and AI-powered insights in one platform. Free tier available.*