Some leaders default to reporting on what they think the board cares about, even if they’re not looking at that data themselves. If you’re sharing something with the board that you’re not otherwise tracking, it’s a signal that something is amiss – you should always be reporting a subset of what you’re already looking at, rather than a separate collection of data. If something isn’t relevant to your priorities, it might not be worth discussing at a board meeting. On the flip side, if something is important enough for your board to care about, it’s likely that your team should care about it too.

The right KPIs are also highly organization-dependent; what you choose to report on should be relevant to your business’s age, stage, size, and priorities. There’s no definitive list, no ‘five engineering KPIs you need to be reporting on right now.’ Still, if you’re looking for inspiration, here are a few examples of KPIs that might be valuable to both your board and your engineering team, along with an explanation of why they matter.

1. Ramp time: In a volatile job market, you need to do more than simply hire good people – you need to ensure that they’re getting up to speed quickly and efficiently. When they’re fully onboarded, they’ll be adding value to the team, which is important to both their satisfaction with their new role, and the business’s bottom line. Ramp time is a measurement of how quickly new hires become productive, and can be measured in months or, hopefully, weeks.
2. Allocations: This KPI can help your team understand the delta between strategic priorities and where your team’s resources are actually going. Looking at allocations can help you rebalance your efforts and expenditures to ensure that key projects are getting the appropriate attention.
3. On-time delivery: By stacking up actual deliveries against delivery commitments, you can demonstrate how well engineering is meeting its commitments. If on-time delivery is falling short of expectations, you can use this data to advocate for additional resources, or for re-evaluating and re-prioritizing the roadmap to match capacity.
4. Cycle time: This is engineering’s speedometer, a close approximation to time to market, which measures how quickly your team is able to deliver on an idea. Cycle time can help you have more informed conversations about the speed at which your team is able to deliver value for the business.
5. Incident frequency: A count of the average number of incidents in a given period of time, incident frequency helps you demonstrate code quality. It’s useful to assess the speed at which your team gets things to market in tandem with incident frequency, so you can ensure that you’re not sacrificing quality for speed, and that your team isn’t spending an inordinate amount of time fixing bugs.

Whatever KPIs you choose, make sure to be judicious – too much information can be counterproductive – and to calibrate your data to the right level of precision. In some cases, it may be useful to get granular, while in others it’s best to stick to high-level information. It’s also important to remember to provide context by including any relevant additional information that can help frame the data in your deck.

With the right data, you’ll be able to provide a more complete illustration of the state of your team so you can facilitate more productive conversations and derive more value from your interactions with the board.