Article

6 reports every engineering leader needs

Data-driven leaders use data to build predictability in their strategies, set and track goals, and align and guide teams—all with confidence. And while leaders across many fields and functions have tapped into this new leadership style, those in software development are still largely operating in the dark. 

For years, engineering data was not easily accessible. With the introduction of new tools that measure and quantify data in git repository, more and more forward-looking engineering leaders have emerged. They are empowered to speak beyond the number of features delivered or use cases solved. Equipped with objective metrics and actionable KPIs, they are elevating their tech strategies, transforming the way their teams work and increasing engineering's impact on the organization's goals.

So, how do you become a data-driven engineering leader? Start with collecting the right data. Reports tailored to your teams, your software and your development processes can give you the insights you need to quickly know the health of each project, how each member is contributing and the collaboration happening behind the screens.

To help you get started, we've broken down the top six reports you need to better understand how engineering is running at your organization. These reports will give you the context you may have been missing to optimally lead your teams, including facilitating healthy code commits, addressing roadblocks and refining your code review process.

Encourage healthy code commit patterns


It’s important for you to know the rhythm of your team’s commit patterns, so you can work toward aligning to—and timely meeting—your organization’s needs. There are several critical need-to-knows around code commit patterns, and having these data points readily available in one view will help you visualize the health of your development team’s efforts.

Work log

The work log report is your morning cup of coffee. With it, you’ll quickly get a sense of what your team is working on, even if they're distributed around the globe. This report gives you a sense of what “normal” looks like for your team, so you can tell when something is off. While some leaders may rely on code commits to get a pulse on how their teams are performing, that’s really not the complete picture. Code commits are a critical part of understanding how your team is working, but adding a few more variables to the equation can give you a comprehensive view, including the ability to pinpoint bottlenecks in the process and overloaded engineers. 

To really see the scope of your team’s work, here are the metrics you should include in your work log report:

  • Code and merge commits: Track the commits contributed to offer a blanket view of how your developers are spending their time and to understand the scope of their work.
  • PR submission: Record the contributions submitted and opened by your developers for review to understand how patches and code injections are being decided upon.
  • PR comment: Observe the discussion involving pull requests to show how your developers are thinking about and discussing potential updates to the code. 
  • Ticket activity: Track support tickets and how your developers are working through them to stay up on current issues and proposed solutions. 

Let your work log report enable you to make better decisions. Ask yourself questions like these as you review it:

  • Is each engineer breaking their work into small, regular check-ins? 
  • Are there any engineers dropping large commits before code freezes?
  • Is anyone on the team being overloaded?
  • Is everyone sharing the load in code review?
  • Do we have knowledge silos forming?
  • Do I have engineers who are overburdened or burning out?

Code fundamentals

The code fundamentals report will help you understand your team’s typical code commit behavior: commits per day, coding days, impact and efficiency. This report is short, fast and to the point, and you’ll want to review it on a weekly basis. Building a routine of tracking and analyzing your team’s commit behavior over time is extremely useful to put you and your team in the driver’s seat of setting benchmarks and realistic commit goals. Once you see what success looks like, it becomes much easier to improve leading indicators like coding days and commits per day, which lead to higher impact as a team. 

To get a view into your team’s output, your code fundamental report should include these key metrics:

  • Coding days: Know what days your developers are submitting code to understand how and when your software is built and released.

  • Commits per day: Track the volume of your team’s commits so you’re better equipped to set goals and benchmark the team’s raw output.  

  • Impact: Measure impact by accounting for the complexity or “bigness” of code changes, in a way that goes beyond lines of code. Impact attempts to gauge the approximate cognitive load that went into the changes made. The key things to monitor on impact are: 

    • The amount of code in the change

    • What percentage of the work is edits to technical debt

    • The surface area of the change (think about number of edit locations)

    • The number of files affected

    • The severity of changes when old code is modified

  • Efficiency: Monitor efficiency by documenting the percentage of all contributed code that is productive so you can weigh raw output against actual progress.

With this data at your fingertips, you’ll be able to take action and help your team establish healthy coding patterns. As you review the report, ask yourself questions that will surface possible areas for improvement: 

  • Is anything getting in the way of normal contribution patterns?

  • What is the impact of where my engineers are spending the most time, and should I be shifting their priorities?

  • What is the ebb and flow of code implementation every week, and how do we manage our time accordingly?

  • What are spikes or dips in commits telling us? 

Spot and fix roadblocks and inefficiencies


If coding throughput is surging or slowing over time, you need to know so you can understand why it’s happening and adapt. Keeping timeline and proficiency reports, which are based on data from the code fundamentals above, can help you quickly visualize your team’s work across each sprint.

Project timeline

Tracking the ebb and flow of development projects over time is critical, which is why you need a project timeline report. If you can see how much time is being spent on all of your projects as trends, you’ll be able to make more accurate predictions and better informed decisions on how your developers spend their time. 

Get a better understanding of how your team’s work (type and volume) varies across a sprint or project by including these data points in your report: 

  • New work: Report on net new code to see how much effort is spent building new functionality and compare it with the expectations of the project.

  • Legacy refactoring: Capture how much refactoring is occurring. When working on new functionality, it's helpful to see if the team is spending more or less time paying down debt than was planned.

  • Help fixes: Check when developers are working on another developer’s recent code to get a sense of team dynamics and knowledge sharing. (Note: This is not legacy refactoring. Code should have been introduced within three weeks of original commit.)

  • Code churn: Track the level of code change and refinement occurring within a sprint. Excessive levels of churn can indicate an inefficient process or skills gap.

Make the most of your project timeline report by asking yourself these questions:

  • Am I seeing work spike during the last few days, forcing compressed code reviews and rubber-stamping? 

  • Are there days or parts of days where efficiency dips or spikes?

  • What portion of work is going toward technical debt (legacy refactoring)?

  • Are any teams experiencing higher than normal code churn? Is this engineering or product-driven code churn?

Language proficiency

With a language proficiency report, you can make sure your tech stack change is paying off. You can also understand your team’s capabilities across the languages they use within your products. Start by tracking the level of work and relative efficiency of your team by language, so you can get a solid grasp of where your team thrives and where you can help them skill up.

  • Work volume: See how much work occurs over time by language, especially when transitioning your technology stack.

  • Code commit efficiency: Seek a healthy level of efficiency at roughly 70-80%. Dips in efficiency are a great way to spot transitions or skill gaps impacting your team.

As you review this report, ask yourself:

  • Are our technology decisions paying off by increasing our efficiency?

  • In which languages are we weakest, and how can we get up to speed?

  • How have new hires or other transitions impacted the team efficiency?

  • How do new projects change efficiency, and how long are the effects?

Tune up the code review process


As a leader, you want your team working together effectively. To create a healthy working environment, you need to look for unintentional breakdowns in communication and sport inefficient processes. Get a better picture of the code submission and review process by using these reports, and start seeing where you can make improvements.

PR resolution

Engineers are naturally productive, but your code review process may be slowing them down. Are they in a stopped state while waiting for others to review their code? Your PR resolution report will help you find out.

Use these key metrics around pull request duration, responsiveness and collaboration levels to encourage timely, effective code reviews:

  • Time to resolve: Clock the time to resolve each pull request as the baseline essential metric to know if there are red flags in your PR processes. 

  • Time to first comment: Track the time before the first reviewer comment as a leading indicator of reviewers with too much backlog or potential process related issues. 

  • Follow-on commits: Check the end result of the PR beyond whether or not the request was accepted so you can understand if the request led to more commits downstream. 

  • Reviewers per PR: See how many reviewers weighed in on PRs to highlight any inefficiencies in the reviewer process, or if the requests coming in require too much bandwidth to complete efficiently.

  • Reviewer comments: Measure the volume of reviewer comments as another indicator of potential issues with the request process or the proficiency of the reviewers.

  • Average comments per reviewer: Account for the average comments from each reviewer to learn how efficiently each reviewer is handling requests. 

Make sure you understand your PR resolution processes by asking:

  • What is a healthy time frame for PRs to be resolved, and are we on track?

  • What are the weak points of our PR process, and how can we strengthen them?

  • Who are currently the most efficient reviewers, and why?

  • What can be learned from commenting habits of team members?

Collaboration overview

The collaboration overview report empowers you to see how well your team collaborates in PRs. By keeping a birds-eye view on how each team member interacts with one another, you can identify soft skill coaching opportunities without having to pry.

  • Submitter metrics: Measure response timeliness to pull requests, tickets and comment information to understand receptiveness and efficiency of submitters and reviewers.
  • Reviewer metrics: Analyze how robust or trivial reviewer comments are, how quickly they provide feedback and how influential their input is to keep projects transparent and productive.

Help fuel collaboration by asking these questions around these core collaboration metrics:

  • How quickly are reviewers responding to tickets and other requests?

  • How efficient and helpful are reviewers and submitters comments?

  • What are reasonable time goals to set around tickets, PRs and the like?

  • What type of interactions create better collaboration and produce efficient results?

Get started


If you’re looking to unpack your engineering team’s efforts from the black box and elevate your strategy with objective and actionable data, it’s important to start with reports that can get you there. By leaning into the holistic set of metrics like outlined, you’ll empower yourself and your team the context needed to make informed decisions on what your organization needs most. 

While the specifics of your reports may differ from the ones we’ve outlined, the key is to move your team toward more objective goals, KPIs and decision-making that can help your team thrive—and your company reach their goals.