---

KPI i.e key performance indicator is a type of performance measurement for your team, organization, or company. KPIs evaluate an organization's success or a particular activity in which it engages. Most likely you work for a team that belongs to an organization whose success is measured in terms of KPIs. So why should software engineers really care about KPIs defined by the business team? Let's understand basic KPIs defined by engineering and business teams and hopefully answer that.

Business KPIs

Business teams track the KPIs that are critical to your business. These KPIs measure an organization/company’s success versus a set of targets and objectives. For example, if you are part of an eCommerce organization, there are KPIs defined to understand and grow the eCommerce business.

Examples of the business KPIs

• Revenue per site

• Average Order value

• Customer acquisition cost

• Return customer rate

• Average Revenue per Customer

…

Core engineering KPIs

Software engineers and engineering teams are passionate about measuring the core engineering KPIs related to their team’s efficiency. These are important metrics to determine the team’s performance and monitor performance and quality or the rate at which they could deliver value to the customers.

Examples of the core engineering KPIs

• Velocity

• Sprint burn down

• Mean time to repair

• Deployment frequency

• Quality metrics

…

As you see, the problem is, engineering and business teams look into totally different metrics and KPIs to determine their success and performance. As a side effect, companies often find out pretty late when there is an impact or downturn in business. A lot of energy and resources are spent to find out the root cause and how it could be resolved. The postmortem is quite complex, involves multiple teams, and costs money to the business with continued losses and bad customer experience. How could the engineering team help find the problem sooner? With most companies moving towards a microservices architecture, how could engineers own their domain and have a stake in the growth of the overall business?

---

How could the engineering teams help reduce this gap?

Domain-specific engineering KPIs

Engineering teams can identify and define key KPIs for their domain that could provide directional guidance toward how the business is performing. In many instances the exact values/numbers might not be as important or interesting, however, the trend of the KPIs could tell an interesting story. Let’s take an example of what these KPIs could be for an eCommerce organization we discussed above.

Examples of domain-specific Engineering KPIs

• Orders per country

• Order size( number of items in an order)

• Checkout conversion( Percentage of shoppers who begin checkout, then complete it over a given period of time)

• Conversion funnel( Conversion through each step of checkout leading to purchase)

…

The idea is for the engineering team to produce the KPIs that are related to business metrics for the domain, which could be monitored by the engineering teams. Now let’s try to understand how that helps. For example, Checkout conversion per site(domain-specific engineering KPIs) would directly impact the revenue per site(business KPI). Order size(domain-specific engineering KPIs) would directly impact the average order value(business KPI). So by monitoring the domain-specific Engineering KPIs, the engineering team could proactively determine and minimize the impact on the business KPIs even without being directly involved in tracking the business metrics. And the good news is most of these KPIs could be built based on the data dropped by the same engineering team.

---

So what’s stopping us then?

“I want to monitor the business-specific KPIs, but our analytics team doesn’t have the bandwidth to create/ update those”.

This is the most common concern heard from the engineers. Is this completely valid though? Engineers are very smart individuals who are capable of learning new programming languages, frameworks, and databases, so why can't we create our own dashboards based on the data that is already generated by us..!! I am confident we can, we just think that it’s someone else’s responsibility and don’t prioritize it. “it's not my job”, “there is an analytics team to create dashboards”, “My job is to code per business requirements”…etc…etc… While I agree the analytics team should be relied on for understanding the granular details of what's affecting the business and how it could be improved, there is no reason to be blocked for creating key domain-specific KPI dashboards. Smaller companies might not even have a separate analytics organization. We(software engineers) can build them ourselves. Don’t forget, if we OWN the domain, understanding how the domain is performing is a part of ownership as well.

Ownership as a software engineer. What am I actually owning ?
You might hear the word “Ownership” a lot around you. As a software engineer do you often think, “I can write code and…medium.com

---

We don't have to create tools for visualization. There are already great visualization tools that could be used to build amazing dashboards based on data and that could provide great insights and stay on top of engineering KPIs for the domain. Tableau and PowerBI are my choices, however, there are many other alternatives. Just find the one that works best for the team and the company and go for it. Once the dashboards are created, it would be easy for the teams to monitor and track them.

---

Summary

Identifying and monitoring the key domain-specific engineering KPIs is extremely important for all the engineering teams and could really help identify the issues that could impact the business even before it actually does. It also builds a sense of ownership and understanding of how the team makes an impact on the business. Remember you own the domain and driving the business is your responsibility too. Let’s know our data and grow the business together..!!!