How Engineering Teams Set Goals and Measure Performance
500+ engineering leaders are sharing how they set goals and measure performance in engineering teams!
Intro
83% of engineering leaders mentioned that learning and development is a priority, up from 70% last year.
This has been an interesting insight from the The Engineering Team Performance Report 2025 done by LeadDev, which I closely examined.
This is a good sign, as we all know that there are a lot of unrealistic expectations regarding AI at the current time, and it’s really important to devote time to learning and experimenting.
Some additional interesting insights from the report:
53% Still can’t choose the right metrics vs 56% in 2024
65% Avoid measuring lines of code
41% Believe DORA is an effective measurement framework, down from 56% in 2024
47% Want to upskill their engineers on prompting techniques and managing agents
In today’s article, I am going over the report and sharing my thoughts on the data.
This is an article for paid subscribers, and here is the full index:
- The survey was conducted between 31 July and 21 August 2025 and is based on 500 respondents
- 1. Goal Setting
- 1.1 Communicating Business Goals
- 1.2 Measuring Progress Based on Business Goals
- 1.3 Team Coordination
- 2. Performance Metrics and Measurement
🔒 2.1 Why is it Important to Measure Team’s Performance?
🔒 2.2 Which of the Following Metrics are Used at Your Organization?
🔒 2.3 What Metrics do You or Your Team Try to Avoid?
🔒 2.4 What Methods to Use to Track the Metrics
🔒 2.5 Popular Tools for Tracking Team Performance
🔒 3. Learning and Development
🔒 3.1 Top Reasons to Invest in Learning
🔒 3.2 Which Areas is Your Team Currently Looking to Upskill?
🔒 3.3 What Would Improve Learning and Upskilling at Your Current Organization?
🔒 Last words
If you like these kinds of articles, where I go over a report that is highly relevant and share my insights on it, you’ll also like these articles:
I really enjoy going over them and analysing them, as it gives me good insights into what the pulse is in our industry. Let’s start!
The survey was conducted between 31 July and 21 August 2025 and is based on 500 respondents
Here are the full demographics:
Now, let’s get to specific insights.
1. Goal Setting
Let’s first start with the section on how engineering teams set goals, and of course, the first very important thing is understanding the business goals. It’s crucial that engineering teams are able to know and understand them.
1.1 Communicating Business Goals
The majority mentioned they get insights on business goals via senior engineering leaders, PMs, and business leadership → which is great.
The correct way to do it is via all of these sources and MUCH more as well. You want to use as many different ways as you can to share business objectives and also challenges with everyone.
The more people understand the business goals and challenges, the more aligned the work is going to be with them. And that’s especially important for all the engineers, as we (as engineers) make a lot of small decisions on a daily basis.
So, my recommendation is to constantly be transparent, share the goals at all-hands meetings, company-wide OKRs, write them out in detail as much as possible, and share them throughout the whole company.
7% of people mentioning that business objectives are not communicated is not surprising to me, as I hear from engineers and engineering leaders here and there about not having enough data about the business goals and challenges, and they are more or less making their best guesses with the tech decisions.
But yeah, if you’re reading this, and you are a company leader, make sure to share the business challenges and goals with engineering teams as frequently as possible.
1.2 Measuring Progress Based on Business Goals
We can see in both charts → Meeting SLOs is on top, which is good. It’s good because it’s very objective. And yes, I agree with the second chart → it’s one of the most effective ways to measure whether you’re doing well or not for engineering teams.
Just for everyone, who’s not familiar with SLOs → the most common are:
Availability/uptime
Ensuring 99.9% uptime.
Response time/latency
Example: 95% of API requests are responded to within 200 milliseconds.
Throughput:
Example: Support 1k concurrent users with no degradation in service quality.
However, the problem with just pure SLOs is that not every engineering team operates that way. Especially in more product-focused teams. In such teams, everything revolves around customers/users.
That’s where, in particular, business metrics such as user satisfaction are important → you can track it via NPS score. And also, overall user growth, the free-to-paid user ratio is a good metric as well.
I’d be interested to get to know in more detail how each of these people measures ROI, as that’s got a good amount of % as well in both charts.
1.3 Team Coordination
It’s good to see that it’s really rare that a team is in complete isolation. But there is an important data that I see here, and it’s a bit alarming to me:
I believe that every day coordinating with another team is too much.
I’d personally look to make the teams more autonomous and look to adjust the split a bit more. From my personal experience, cross-team coordination has always been one of the biggest blockers.
And the reason is that every team has its own priorities and also initiatives. And especially if a team is working with multiple other teams, it’s really hard to prioritize one over another, and that can be very costly in time, and teams can wait a long time till things actually get done.
So, yes, I am a big fan of autonomous teams that can move fast without a lot of external blockers. I believe weekly coordination is healthy.
For further learning, you can also check the report from the Coordinations Crisis workshop we did this year:
