How Engineering Teams Set Goals and Measure Performance

Hey, welcome back to another video. In this video, I'll be sharing my thoughts and my opinion on the recent report done by LeadDev. We will be checking all the data and we will go through how should engineering teams set goals and measure performance. If you don't know me yet, my name is Gregor Ojstersek and I am the founder of Engineering Leadership Newsletter. Now let's get straight into today's topic. Okay, so as I mentioned before, we're gonna go through the report done by LeadDev. I'm also including the, the link to the full report in the description. So let's get first a bit about through demographics so we, we know better, you know, what kind of people have actually answered the survey. So the survey is based, based on 500 respondents. And also it was done between 31st July and 21st August 2025. As we can see here, uh, mostly people in United States, then UK, Europe excluding UK and Germany, and of course Germany, UK, USA, and then also a lot of other countries as well. Role, mostly senior, senior engineering leaders. Of course, also I would say like mostly engineering leaders in general, managers of managers, manager of engineers. Of course, also senior individual contributors, senior software engineers, software engineers, and of course then CTOs, tech leads, and so on. And also number of employees, yeah, we can see various of different sizes of companies, so that is great. So we can get a good overview of what's happening both in big company, big companies, mid-sized companies, and also smaller, smaller size companies. So we can see a lot of diversity in the data. So yeah, we could get pretty good insights on, on, on what's happening across the industry based on this, this report. Okay, so let's go straight to our first, first section, which is goal setting. That, that, that is kind of like the first, first section of the report. And we're going to be in particularly more talking about communicating business goals. So that is our first, first data that we're going to be checking. And the question was, in your company, how are business objectives communicated to the engineering organization? And we can see a lot of it is, you know, through senior engineering leadership, product managers, via wider business leadership, then also some, some other, other stuff like service level objectives. And also some people mentioned that the business objectives are not communicated to the engineering organization at all. So this data is quite, quite align on what I'm seeing as well. What I would mention here is especially, you know, with this, with these numbers being on the top, I recommend to all the companies, every organizations, you know, that I, that I work with, the consulting advising, I recommend that, you know, more is always better in terms of communicating business, business goals and also business challenges in general. So yeah, the best, the best outcome that I would love to see here is that that this would be percentage would be as high as possible. That is my recommendation because engineers, engineering leaders, everyone inside a company can work so much better if they understand the business goals and the business challenges. If they don't, they will be more or less guessing what's important and what's not. And yeah, as engineers, we're making a lot of small decisions on a daily basis when we are creating a certain service, when we're creating an API, when we are deciding on a certain technical direction, when we are, you know, deciding on infrastructure and so on. And knowing and understanding the business challenges and business goals really thoroughly and, you know, really well, we're gonna make a lot better decisions along the way. So yeah, it's good overview to see this, but yeah, my recommendation is always to have this as high as possible. Obviously also, I'm seeing across the industry in some cases that, you know, some companies don't even communicate business objectives to engineering engineers and engineering leaders, and that is a problem. My recommendation to everyone watching this, you know, communicate as much as possible. Okay, let's go to the next, next one, which is measuring progress based on business goals. So, um, yeah, let's— the question was, which of the following metrics are used in your engineering organization to measure engineering team performance? So we can see meeting SLOs is on top. The second one is user satisfaction, then code quality, user growth, number of customer complaints, ROI, user conversion, and so on. So yeah, meeting SLOs is a really, really good metric, and the reason for that is because it's objective. You know, when you have like a metric like, okay, that service needs to be 99.99% of uptime, You know, it can be like, you know, how to say, you know clearly if it's yes or no, right? You can't fake it. And it's a really objective way to measure like, hey, is this, you know, engineering team or this engineering organization doing great work in general? But it's, you know, it's great more for kind of like platform teams, teams that work especially with infrastructure, especially on uptime on certain services. And so on. And that is the expectation, right? But then the problem comes where, you know, you have a lot of product teams also inside your engineering organization. And then, you know, those teams don't have clear SLOs, right? They are more measured by the satisfaction of customers, of the users, you know, the growth of the users, user experience, you know, what people are saying about that particular feature, the user adoption, adoption of user adoption of those particular features and stuff like that. So yeah, that's where you need to measure user satisfaction. 36% up there is great. You can measure that via NPS score or similar. Of course, code quality is always, you know, important, important thing to measure. It's a bit, it's a bit more, you know, code quality can be like very interesting thing to measure because, you know, a lot of it is also, you know, based on the standards you have inside a company, guidelines, style guides as well. In general, it can be also a bit of subjective issue if you don't use like a clear differentiator of, you know, what is good quality versus not. Because the thing is that simple code is really hard to define, and you just know it when you see it. That, that is the, that is the magic behind simple— writing simple code, right? And yeah, also of course user growth, you know, growth of the paid users, the, the ratio between paid versus free users, it's also a good indicator how successful is, you know, a particular team doing. And so obviously it's connected with the whole organization, the whole business, and so on. But of course, if you are a product team, then of course you have goals to ensure that, you know, the users are going to be, you know, their challenges are going to be solved and their satisfaction is going to be as good as possible. And then the next question is, which of those metrics is most effective at determining engineering team performance? Yeah, we mentioned a little bit about this before. So this is, you know, the first one is what companies are using. And then the second one is what do you think about what are the most effective? And yeah, as you mentioned, you know, meeting SLOs is exactly that because it's very objective, right? And then of course, user satisfaction is something, as you mentioned, that, you know, we should all in the, in the overall organization No matter if it's engineering, product, business, marketing, growth, sales, we should all strive towards creating good satisfaction from our users and so on. I would be interested also to see how people are measuring ROI because it's really hard to do that because what ROI means, what return are we getting from the investment and investment is our time and resources and of course also spending, we are spending on tools, we are spending on various different, you know, products to help us, you know, provide certain, certain things to our users and so on. And I'd be interested to see how people actually measure this. All right. That is a complex, complex topic to discuss. But yeah, that would be more kind of great insights for me to get to see as well. Okay, let's get next to team coordination. How often do you coordinate with, with other teams? And a lot of people mentioned every day, and then a little bit more people mentioned weekly, and then a lot less people once a month, and, you know, a lot, a lot less, less than once a month, and some people never. So a very important thing to mention here is that I'm a big fan of having autonomous teams inside, inside your engineering organization, and that, that means that teams can be independent as much as possible. And the thing is that as soon as you have a lot of dependencies across different teams, like for example, one team is building a certain feature and they cannot move forward without that team, that the other team, and then the third thing also finishing those three particular things. And the problem with that is that every team has priorities and every team has certain goals and certain initiatives, and they can't always put their priorities, you know, to be on top as like your priorities. And that has shown to be one of the biggest blockers to actually move things, to actually move things forward for engineering teams. So this is quite interesting data here, and it's a bit alarming because every day communicating with other teams is a bit too much in my opinion. That means that a lot of teams are doing too much communication with other teams and too much alignment. There's a lot less independence between teams. You know, also I had a recent discussion with one of my coaching clients, and you know, even if there's some duplication of certain code or certain things, certain tools or certain services, I'm fine with that as long as, you know, the teams, the team can move forward independently. I mean, obviously you're not going to be doing excessive duplication of, you know, really, really important services, but, you know, those, those small things that, that, um, that, you know, can, can unblock you really quickly, um, you know, I'm more prone towards, um, trying to, you know, small duplication is fine. Small— if you're trying to, to always stick to, you know, don't repeat yourself you're going to end up with so much cross-team dependency and that, that is a big problem in my opinion. So weekly communication is fine. More than once a month is also okay. I think those two categories is okay for me. But of course, you know, every company is different. Every, every, every case is different and you need to see what's, what's the best in your particular scenario, right? So, you know, what, what is the best for your teams? Okay, let's go to the next section, which is going to be performance metrics and measurement. So the first one we're going to talk about, why is it important to measure team's performance? So why do actually teams work to measure the performance, you know, of individuals and also the overall teams in general? And people mentioned, responded with, you know, to improve engineering quality, to identify process bottlenecks, to create accountability, to improve engineering velocity, manage upwards, to inform progression, promotion, firing decisions, other. Yeah, I agree with this, uh, with this data here. And you, you need in various different cases. And my recommendation is, you know, as soon as the company grows, you know, the engineering organization grows at least to, to, to 4 or 5 teams, then you need a lot more metrics to, to, to measure. I recommend to start with, with with one or two things to measure. That can be like lead time to changes or code review size or something else and so on. But at least you need, you need some metrics because it's really hard for you to stay on top of every team if you don't have some objective metrics. And then also it will help you to manage upwards because you have some additional data about your teams. Of course, also, you know, when you have more teams, you need to ensure that you get the historical data where we were and then also what we can do to improve things forward. Accountability as well, you know, what the really important thing is that, you know, what you tolerate becomes a new standard. And, you know, especially with high performance engineers in general, people in general, right? If you tolerate low performance, then of course, then those people won't be happy, you know, working in such team and so on. So yeah, all of these are very important reasons why I want to measure team's performance. And as I mentioned, you know, the more the company grows, my recommendation is also to work on the metrics as well. But yeah, start simple, one or two, and then you can decide on additional as well. You can use many different things here, like, you know, Doras, you can also use Space and so on. I'll add the article in the, in the description where you can check more, more details on especially how I approach to measuring engineering teams. Okay, let's go to the next one, which is which of the following metrics are used at your organization? And yeah, this is a very interesting data here, and I'm quite concerned here to seeing number of tickets closed. Being quite on top. I'm fine with number of incidents, that is a decent metrics because, you know, you don't want to have, you know, you know, if you have a lot of incidents, that is a bad sign. That is a good metric. But then the really interesting thing comes here, which is number of tickets closed. That is 37% and on the second place, which is too much in my opinion. Opinion. You know, this is a metric where, you know, people can— what people can do is they can intentionally create really, really small tickets, and they will look good on, on, on the board, right? Because they're finishing a lot of tickets, but they actually don't deliver a lot of business value because they're making really, really small tickets. And, um, yeah, more doesn't mean better in this case. And same is in number of story points completed, pull requests days work, lines of code. You know, all of these metrics are metrics where people are incentivized to do something, but it doesn't actually mean that it's going to be better for the organization. It can actually incentivize people to try to game the system, which is really bad. And yeah, it's not, it's not their fault. It's the fault from, from people that actually measure this and put too much of the weight on those on those metrics. I'm fine if they're tracked, but the important thing here is how you're using those metrics. You know, if you're bringing them up on the sprint retrospective, on the team retrospective, and saying, yeah, we closed a lot less tickets than we did, you know, previous sprint, you know, the teams are not going to be happy with this. It's not the way to interpret this data. It can be a bit of a, like, informative thing, but it should not be tracked for any performance reasons, and it should not be brought up in terms of like, hey, you're not doing well because you closed a lot less tickets, you open a lot less pull requests, you finish a lot less story points, and so on. It should be more as for informative purposes. So yeah, the bad thing here is we don't see how are these metrics actually used. We are just seeing what are, what are being tracked. So, um, yeah, if they're used, uh, you know, in the right way, it's fine. But a lot of, even in a lot of companies, I, I saw that they are being misused, and I think there's still misuse of them in a lot of companies, in my opinion. Yeah, what, what metrics do you or your team try to avoid? And yeah, that's exactly what we, we have talked about. Of course, lines of code is, you know, being on top 65%, but, you know, I would love to see this metric to be 100% because, you know, still 35% haven't answered, you know, that this should be avoided. But this is something that, you know, should be extremely, extremely avoided because more code is actually a lot, a lot bad, bad than less code. You know, you want you want to solve the problem with as less code as possible. Of course, don't, don't write, don't try to be clever. You want to, you want to write simple code. Simple is the way to go when you're, when you're building features, when you're building functionalities, when you're building things. So yeah, more code is, is, is always better, is always bad. So this is a really, really bad metric. Hopefully in the next, next year we can get this to 100%. And also days worked. Yeah, it's, you know, It's something that we should not be, you know, especially like in Europe, you know, you have a defined amount of time that, you know, you can take time off and, you know, everyone can take those and it should not be, you know, especially engineering teams, that doesn't matter. You know, same is with story points completed, pull requests, a number of tickets closed, those are all metrics where you're putting too much weight on them and people will try to gamify, try to game the system, and you know, it's not going to provide any value to your business. It's going to just create competitive environment inside engineering teams. Okay, let's go to the next one, which is what methods to use to track the metrics. So yeah, retrospectives, customer feedback, annual surveys, short frequent pulse surveys. Yeah, retrospectives is of course a good, good thing to check. I always recommend for engineering teams to create, to be transparent on this retrospective and share this board with everyone. I think, you know, that is the best way to operate as engineering organization in general, to be transparent as much as possible and share, you know, what is going good, what is going bad. And I like to say that, you know, transparent engineering organizations are the best kind of engineering organizations, and they're, they're a big asset for the business. What I'm missing here is dashboards. Dashboards, you know, things like tracking DORA metrics, space metrics and things like that. Though those are also, you know, good methods to track, um, you know, and measure team's performance. Which metrics have you found the most useful to measure developer experience? Uh, yeah, one-on-ones, continuous feedback processes, developer satisfaction surveys, measuring amount of time dedicated to different aspects of software development cycle. Yeah, one-on-ones is really amazing way to track, uh, you know what, what, what do people, how do people feel in general. I put a lot of time into making sure that one-on-ones are really useful both for me and also for my report. I like to have them, you know, very structured, but they are there for the, you know, for the report. I also shared the link to the article where, you know, there's a complete, complete guide on how to have great one-to-ones with your report. There's also a Notion template there it, you know, I use it now for close to 5 years. So yeah, one-on-ones are a really important way to track, you know, how people feel, you know, what can we do better, you know, what things to improve, and so on. And of course, also it's a good way to give feedback to your reports as well. Okay, let's go to the next one, which is popular tools for tracking team performance. Yeah, of course, Jira is, you know, one of the most used software, software tools in engineering organizations. And then also homegrown dashboard analytics tool. This is a very good, interesting data because we can see, you know, this is on the second place. And especially when, you know, tools for building things is getting— are getting better and better, I can see, you know, engineering teams building more and more internal tooling themselves, you know, any kind of dashboards for measuring and tracking different metrics, analytics tools and stuff. Stuff like that. I see this to be, you know, to be growing more and more. So I think, you know, next year this is going to be a lot, a lot more percentage is going to increase. But yeah, also some other, some other useful tools here as well. Okay, let's go now to our last section, last but not least. Let's talk about learning and development. Top reasons to invest in learning. Yeah, you know, obviously Good engineering, great engineering organizations, great engineering cultures are the ones that continuously focus on growing your people and your teams in general, right? And that is also the top reason of, you know, organ— your organization invests in learning and development to retain and maintain developer satisfaction. Yeah, exactly what we mentioned, boost team performance, especially in current times, you know, where there are many unrealistic expectations in terms of AI being a magical tool. You need to give time and space to people to experiment and learn and expand their knowledge. You know, give some time to people to try out different either, you know, different tools, try out different things and see what's working and what's not. I'm also a big fan of doing, you know, hackathons across the engineering organization focused on learning or actually using a new tool. That is a fun way to do something great and also have fun with it at the same time. Now let's, let's focus on which areas is your team currently looking to upskill. Yeah, we mentioned, you know, AI, anything related to AI is something that engineering teams and of course companies in general are looking to, you know, to upskill in general in people inside of companies. Prompt engineering and managing agents being on top, cloud-native technologies. Yeah, this has been something popular for quite a while now. Of course, DevOps and infrastructure. And of course, leadership and strategy skills. This is going to be more and more important as time goes on. I think especially for engineers and engineering leaders, because leadership skill is something that is going to be more and more important, especially when you're building AI features, AI products. As an engineer, as an engineering leader, you can't be just owning the how. You need to be also having a say on why, what, and when as well, because you understand the details. And the reason is that if, if someone is making a decision that doesn't understand the technical details behind the complexity and complexity behind building something, they're going to have a different perspective on, you know, when you should do this and why you should do it and also what you should actually do. It can be really the difference between building a certain AI feature in 3 days or in 300 days. And so on. And of course, also like testing, quality assurance is very important in building AI features, AI products. Of course, communication skills, human-related skills in general are going to be more and more important as time goes on. So those two things are not surprising to me. I'm a big advocate for engineers and engineering leaders to upskill on these skills in general. And yeah, let's go to the last but of course not least data that we can see from the report. What would improve learning and upskilling in your current organization? And yeah, we can see more time provided for learning and training. What I'm seeing a lot over different organizations, different companies, is that people have a lot of unrealistic expectations in terms especially regarding AI. And then the problem comes where people, engineers in general, engineering leaders, don't have enough time to actually try to experiment and try to, you know, learn, learn about the tools, learn about different options available when it comes to, you know, certain AI tools, certain, certain AI spectrums and so on. So it's a bit of a problem of expectations are high, but then the time is getting less and less available, right, for such things. But it needs to be both. If you expect, you know, people to to adopt and use certain, certain new tools. You need to give them time to experiment and see what's actually beneficial. If you're going to say like, okay, we need to use this tool and then, you know, it's not actually going to be helpful, you're going to create a lot more issues. You want to make sure that you provide what are the business challenges, what are the business goals, and then provide a time for everyone to, to see what are the best tools to solve these particular challenges and so on. Employer incentivized to complete learning training. Yeah, of course, with any kind of security, uh, you know, that's, that's, that's always incentive for companies to do that. Increase frequency in training. Um, yeah, tie training and certification directly to compensation increases, um, and so on. Okay, we come to the end of this, of this report. Um, yeah, it was really, uh Great for me to go through this whole report and go through the data. It's really great way for me to, to see what's happening across the industry. And I hope also it was helpful to you. To learn more, you can subscribe also to my newsletter. It's called Engineering Leadership, where I share two articles on a weekly basis. There are more than 165,000 people already reading it. And yeah, thanks a lot for watching and I'll see you on the next one.