The Good Tech Companies - inDrive’s Approach to Measuring Engineering Performance

Episode Date: November 25, 2025

This story was originally published on HackerNoon at: https://hackernoon.com/indrives-approach-to-measuring-engineering-performance. How inDrive measures and improves engineering performance using a system of metrics, dashboards, feedback loops, and data-driven management practices Check more stories related to programming at: https://hackernoon.com/c/programming. You can also check exclusive content about #developer-productivity, #engineering-performance, #indrive-engineering, #engineering-performance-system, #dora-metrics, #software-team-performance, #software-delivery-analytics, #good-company, and more. This story was written by: @indrivetech. Learn more about this writer by checking @indrivetech's about page, and for more stories, please visit hackernoon.com. InDrive’s performance and productivity is one of the hottest debates in the software industry. The company has been experiencing rapid business and engineering growth - in both the number of engineers and teams. This scale creates the need for processes and tools that ensure predictable outcomes.

This audio is presented by Hacker Noon, where anyone can learn anything about any technology. InDrive's approach to measuring engineering performance by Indrive. Tech. Indrive is a ride-hailing company operating in 48 countries with a unique peer-to-peer pricing model that enables fair trip costs. Across all products, more than 600 engineers work in 70-plus teams. The topic of performance and productivity remains one of the hottest debates in the software industry. Every company is trying to find its own answer, shaped by internal context, current challenges, or best practices observed in research and publications such as pragmatic engineer. Measuring developer productivity real-world examples and developer productivity with Nicole

Forsgrin. Understanding why organizations need this is essential. The main reason is thataday's market has changed. Companies now want more control and better efficiency from what they already have, their processes, people, and tools. This becomes a especially important when scaling, since hiring more people alone is no longer a sustainable way to grow. And if we want to answer these hard questions, we need to define and manage metrics that help achieve the organization's specific goals. It's important to note that at Indrive, performance is one of our core values, alongside purpose and people. That's why performance isn't just about results. It's part of who-where as a company. We strive to understand impact

and create it at every level of the organization. We identified several key factors that led us to develop our own approach top performance. 1. Since 2020, the company has been experiencing rapid business and engineering growth in both the number of engineers and teams. 2. This scale creates the need for processes and tools that ensure predictable outcomes and support sustainable scaling. 3. Leadership must rely on data-driven insights to understand how teams perform within these processes, identify bottlenecks, and make informed managerial decisions. Four, finally, metrics must be aligned with strategic and operational goals.

Only then do they become drivers of meaningful progress rather than isolated statistics. Performance as a system, it's important to note that performance and productivity are closely connected. Productivity reflects how effectively your delivery processes work, while performance shows what outcomes they actually produce. Different companies interpret these terms and approach metric design in very different ways. Some focus mainly on individual contributor productivity, while others track metrics only at the team level. But I believe this complex challenge requires building a comprehensive system that operates across all levels of the organization.

At INDrive, I implemented a system that includes metrics, integrated into the tech metrics tree, which is divided into domains and levels. We've defined five domains, such as cost efficiency, people metrics, performance, operational and engineering excellence, and each level corresponds to the company's organizational structure. From the division level, the entire tech division, to the cluster level, teams united by a shared product or domain expertise, team LeVay, L and individual contributor level. At the cluster and team levels, performance and operational efficiency are further refined into more specific areas, such as predictability, speed, maturity, and quality. The example below shows how a metric within the performance domain cascades across different levels. roles. Each metric has an owner, SME, a subject matter expert responsible for defining the methodology

and leading the implementation of new processes and metrics. In addition, managers are accountable for performance within their teams, clusters, or division. For us, it's essential that metrics are part of a manager's daily work, not delegated to dedicated roles like agile coaches, service delivery managers, or project managers. Only this way can we achieve systemic and sustainable results. feedback loops, which enabled teams at every level to systematically analyze the current state, make data-driven management decisions, and drive change across the company, through the year's strategy, technology programs or joint initiatives. For example, a few years ago we launched an engineering satisfaction survey in response to metric signals that revealed issues with delivery

performance. Today, beyond being a standalone metric, it has become one of our key sources of insight, helping us identify and drive the changes needed to improve the efficiency of our internal processes and tools, especially those owned by our platform teams. Tool. To support this system, we have built the single analytical system, a table-based dashboard ecosystem that connects all metrics and data sources into the tech metrics tree, serving as the single source of truth for performance across teams, clusters and the entire division. The single analytical system, the concept behind the single analytical system is straightforward, it's a set of dashboards that bring together metrics from multiple sources,

Jira, Grafana, Cabana, Pager Duty, HR systems or in-house tools, into a single one-pager view. In other words, you have a pocket-sized overview of the entire landscape. And when deeper analysis is needed, you jump directly to the underlying data source, such as a detailed dashboard in Grafana. To implement the dashboards, I designed a five-tier structure from the division level down to the sandbox. Each Tierjan have its own dashboard or a family of dashboards, enabling performance analysis of a specific organizational entity or providing a cross-team or cross-service view of a particular metric. One, division level includes key technology metrics aligned with company and

divisional strategy across five domains. Cost efficiency. Cost per ride, lost money, etc. People, turnover, engagement, satisfaction, etc. Operational excellence, mobile performance, availability, security, data quality. Engineering excellence. Dora metrics, technical debt, etc. Performance. Time to market, lead time, completion rate, etc. One of the dashboard sections looks as follows. All metrics are shown in dynamics to track trends over time, with signals indicating whether each metric has reached its target value or not. The dashboard allows CTO and divisional leadership to assess efficiency, identify focus areas, and understand the influence of specific clusters. 2. Cluster level the dashboard at this level includes all cluster metrics organized within the previously defined domains, predictability, goals progress, scope drop, speed, lead time, velocity, time to market, quality, incidents, SLA postmortems, security error budgets, maturity, team maturity, and index. Engineering excellence. Cycle time, lead time for changes, deployment frequency, change failure rate, mean time to restore. Used by directors of engineering, product and CTO to improve performance and other company-wide processes such as annual performance review. Metrics are usually analyzed monthly during cluster metrics analysis. Three, team level mirrors the cluster level

but with team-specific context, predictability, sprint goal success, goals progress, scope drop. Speed. Lead time. Velocity. Time to market. Quality. Incidents. SLA outcomes. Security budgets. Maturity. Team maturity index. Engineering excellence. Cycle time. Lead time for changes. Deployment frequency. Change failure rate. Mean time to restore. I designed the dashboard and metrics to work for any team, whether they use scrum or canbin. This makes the system flexible while keeping the evaluation consistent. This is the primary management tool for any team. I designed. engineering managers for supporting data-driven planning, stakeholder alignment, and continuous improvement during both day-to-day operations and key events like sprint planning or retrospectives. 4. Individual contributor-level the dashboard includes engineer-level productivity data in five key areas, such as collaboration, work quality, workload health, development experience and AI adoption. Used by engineering managers during day-to-day work to maintain a high level of productivity and identify growth areas.

5. Sandbox level contains deep dive dashboards for SMEs managing specific metrics across the organization, enabling advanced analysis and experimentation. For example, time to market or team maturity level used by SMEs or any managers on demand for deep dive analysis. Conclusion, building a system that allows organizations to manage, evaluate, and improve engineering performance is crucial. It enables data-driven understanding of the current. state and helps launch improvement initiatives at multiple levels. At the same time, we recognize the

inherent risks of over-reliance on metrics they can be misinterpreted or gamified. As part of the engineering excellence team, I promote the mindset that metrics are not the goal. They are signals to guide management decisions. Metrics may miscontext, reflect short-term fluctuations, or mislead without proper analysis. Their real value lies in comprehensive, contextual evaluation, enabling managers to answer key questions during planning, reviews, and performance discussions, and to foster a data-driven culture grounded in accountability and learning. Learn more. To learn more about our analytical system, career model, and engineering practices, explore our public engineering handbook. Igor Novaceltsif staff coach, engineering excellence team references 1. InDrive. About the company,

HTTPS colon slash slash indrive.com company. 2. InDrive public handbook. Htt Htt.s.com, in-driver, handbook. 3. Eluminati Inc. How in-drive works. Business and revenue model. H. T-TPS colon slash-slash-W. W.W. Eluminati Inc. com. How Indriver Works Business Revenue Model. 4. George Lee Oroes. Pragmatic Engineer Blog. Measuring Developer Productivity.

Real-world Examples. Developer Productivity with Nicole Forsgren. 5. 4Sgren N, Humble J, Kim G, 2018. Accelerate. The Science of Lean Software and DevOps. It Revolution Press. 6. Forsgrin N. 2021.

The Space Framework. Microsoft Research. 7. Google Engineering Productivity Research. HTTPS colon slash slash research. Google, Pubs, Incrod. 8. State of DevOps reports.

Dora. HTPS colon slash Dora. Dev Developer Experience, DevX, Research, What Actually Drives Productivity. HTTPS colon slash slash getex.com, research, DevX what actually drives productivity. Thank you for listening to this Hackernoon story, read by artificial intelligence. Visit hackernoon.com to read, write, learn and publish.