Blog | Become a data-driven engineering leader with these 6 reports

Updated on April 4, 2024 | Read time: ~10 mins

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 repositories, 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.

1. Work log
2. Code fundamentals
3. Project timeline
4. Proficiency
5. PR resolution
6. Review Collaboration

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.

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. 

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.

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.

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 refractor: 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 others: 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 30 days of original commit.)

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

With the 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 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 spot 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.

The Review collaboration 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 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.

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.