One of the common reasons people deploy engineering metrics is due to pressure from the board of directors and/or CEO to provide greater visibility into their oh-so expensive engineering organization. They are not unjustified in this desire, given that software is an increasingly large part of the budget in many organizations.
Some engineers try to resist providing transparency to the board/CEO as a result of previous traumatic experiences with micromanagement. However, if done well, sharing metrics with the board can increase their confidence in engineering and even make them excited to invest more money in the team.
Before diving into the metrics themselves, it’s important to first understand the goals of sharing them with the board.
The first goal is to improve alignment between the engineering team, the board, and the CEO. CEOs and boards often get a bad reputation in the media, but they are generally trying to do the right thing for the employees and the company. Similarly, engineers usually take pride in their work and try to do the right thing for the business (not just do as little work for as much pay as possible).
Issues with alignment tend to arise because engineers and the board have different perspectives about the best way to achieve their common goal of improving the company. Boards don’t see all the low-level things that happen to ship software, nor do they hear directly from individuals about how they feel. On the other hand, engineers are often insulated from how investors value the business, the cost of capital, and where money really comes from for their paycheck.
So, what are the areas where engineers commonly struggle to get alignment and buy-in from their board about priorities? Well, it tends to be behind-the-scenes developer experience stuff. People outside engineering see the features that ship and may even hear about bugs or quality issues. But, they don’t see how painful it is to deliver those features due to overaccumulation of tech debt, process problems, or personnel issues on the team.
These behind-the-scenes issues tend to grow over time if left unaddressed, increasingly slowing down development and driving away the best engineers. They are similar to financial debt in that they are a significant liability, but dissimilar in that they don’t show up on the balance sheet, so are not directly visible to the board.
When delivering metrics to the board, the first goal that engineers should have in mind is accurately portraying issues that impede engineering so that the board is aligned about investing in improvements.
Board meetings don’t happen very frequently, and often focus on longer-term plans. At the same time, a key tenet of agile software development is adapting to circumstances rather than sticking to an outdated plan.
This can create conflicts between the board and engineers, with the board justifiably wanting to review strategic plans and then have them actually implemented rather than thrown out the next week.
Another important goal of sharing engineering metrics with the board is to establish the parameters of predictability so the board can depend on promises they receive while engineering retains enough flexibility to practice agile software development. As such, metrics should highlight impediments to predictability (like tech debt and quality issues), their impact, and the cost of fixing them.
Finally, it is better for everyone if the board trusts that the engineering team is responsibly managing its budget. It’s not that boards and CEOs don’t trust engineers, but it would be negligent on their part not to verify what they are told.
On this front, it is the responsibility of engineering to account for where their resources are spent and the impact of internal improvements on productivity so that senior leaders have confidence in engineering management. This also benefits engineering because it makes the board more willing to increase their budget.
This section highlights different categories of engineering metrics that can be helpful to show the board to achieve the goals outlined above. It is divided into different sections for different areas of engineering productivity, each roughly corresponding to one slide you can create in a board presentation.
Employee satisfaction is the number one most important metric for a healthy engineering team. Whether you believe 10x engineers exist, every company has top performers who are highly respected in the organization. If they leave, they can set off a talent exodus that permanently cripples the team. So, it is critical to retain them and keep them happy, because they can easily cause more than 10x damage.
To show employee satisfaction, there are a few different types of data you can show:
With employee satisfaction metrics, it’s helpful to also count and categorize the types of feedback in addition to the raw numbers. The benefit of this is that it builds alignment around investing in the internal improvements that the team needs to make to improve its scores.
Finally, Overall Onboarding Time can be a useful people metric to show in addition to employee satisfaction. This metric helps expose tech debt and put a concrete cost on it so that the team can invest in bringing new people up to speed more quickly. You can collect this by surveying people, or looking at how long it takes for new team members to reach a consistent velocity.
The next area that’s important to cover in engineering board presentations is quality. There may already be some sense of how quality impacts customers with things like the churn rate, but here you should highlight the impact of quality on the pace and predictability of engineering work. This helps the board understand the importance of investing in quality improvements and tech debt reduction to increase feature velocity.
Here are some specific metrics that can paint a high-level picture of the current state of quality in your organization:
Finally, it can be useful to present a Total Quality Overhead metric, which is the Theoretical Bug Load plus the Revert Rate. At the end of the day, this is the total amount of engineering resources that are unavailable for new feature work, and can be the basis for justifying investments in quality improvement and tech debt reduction.
Once quality overhead is out of the way, the board will probably want to know what you got done compared to what you planned on the roadmap. This only makes sense, as it indicates the likelihood of delivering on your current plans in the future.
This is not to say that changing plans is bad or that the board should be upset if you went another direction to pursue better opportunities. What’s most important is that projects don’t end up taking a lot longer than expected without realizing commensurate value, because this means that any return on investment (ROI) calculations done to justify the projects will be wrong. Essentially what the board should care about is that realized ROI doesn’t come in significantly below planned ROI, like the project that was supposed to take a month taking six.
Here are some ways you can provide transparency into project predictability, depending on what data you have available:
At the end of the day, you want to convey to the board the Total Project Overhead rate, which is the amount of additional time taken to complete projects as a percentage of their original estimates. This enables you to communicate clearly about how much padding to add to projects when making roadmap commitments, and identify significant variations representing problems or improvements.
The final set of metrics that boards should see is how effort (and therefore money) was allocated on the engineering team. This overlaps a bit with quality and project overhead metrics, but is good to show too because it directly maps to the bottom line.
To compute these metrics, a system like minware will be the most accurate (and easy to implement) because it looks at data from version control and ticket tracking. You could also use manually recorded time logs or story points. These approaches are less reliable and miss some things, but are better than showing up to a board meeting empty-handed.
Here are the categories of time that you can show with the output of a system like minware:
After you compile these aggregate metrics, you will want to break down the Project Time metrics by large project or initiative. This empowers the CEO and board to assess actual ROI, which should be their primary concern. When you do this, just make sure the numbers add up to 100% and that the “other” category is small.
This list is not exhaustive and there are other things that may be helpful to show to the board in different areas, like performance or security KPIs. However, there are some things you should probably avoid sharing with the board, not because you want to hide them, but because they can be misleading or easy to misinterpret.
DORA Metrics - DORA is an acronym that stands for DevOps Research and Assessment. DORA Metrics are a suite of four things that can be helpful internally, but are not good to share directly with the board because they are easy to manipulate or don’t tell the whole story in the following ways:
This article covered the goals engineering teams should keep in mind when communicating with their CEO or board, then walked through several types of metrics that can help achieve those goals.
Being asked to present engineering metrics in a board meeting is a great opportunity for engineering leaders – not a threat – because it gives them a platform for helping the board understand the challenges they face and make smarter decisions about engineering investments.
Compiling all of these metrics can be a lot of work, but minware has a lot of them out of the box. If you’d like to learn more, then let’s talk – we are eager to help!