How do you measure if a tech team is performing
Engineers are always busy. How do you know if they are actually getting closer to their target?
You would be hard pressed to find an engineering team that doesn’t appear to be busy. There’s always something to do. I personally haven’t seen a team or an engineer that said they didn’t have anything to work on.
On the other hand, we all know there are many engineering teams that underperform or do a bad job building a product. How do you know if your team is making good progress?
Looking at this issue like a white box (so also looking at the internals), there are many metrics. Does the code look good, are there many bugs and regressions that are happening, especially over and over again, do the different team members work well together and so on. However, all of there metrics, put in isolation just give anecdotal evidence and can mean many things.
Looking at this as a black box (just from the outside), it’s difficult to know how the team is performing. It’s very difficult to know how long things should take, so if a team is slow, it’s hard to gauge if that’s an issue, or the project is just complex. If there are bugs, how many bugs are too many? It’s all open to interpretation.
What’s undeniable though, is that software is not written for its own sake. It’s built for a purpose. If the purpose is not fulfilled, nothing else matters. Even if it’s the most beautiful code in the world.
From that perspective, a good metric for measuring the success of an engineering team is:
Compared to the total development time spent, how much of it was spend on user value providing tasks?
Or in other words:
How much of a team’s time is spent on user stories, as opposed to tooling, re-writing and unbreaking?
Do you agree? Let me know in the comments.
Let’s illustrate this is a few examples…
Imagine a team that constantly needs to refactor code and unbreak things. Would that team be performant? No, it wouldn’t - it doesn’t move forward. Hence, it spends most of its time redoing tasks. No further user value is created.
Now imagine a team that’s obsessed with tooling, beautifying the code base and overcomplicating things. Is that team performing? The code might look amazing, but for users, there’s no difference in the product. The engineering team might as well have done nothing.
More interestingly, imagine a team that inherited a codebase full of problems. They are spending months trying to refactor it into a workable state. Is that team performing? Not really, because there’s still no user value being provided. However, there’s a caveat. The team had no chance to be productive from day 1, so they had to lay the groundwork for ever being productive sometime in the future. I would still argue that the project is not performing. Indeed, the project is still in jeapordy, it’s still stick, but on the plus side, it’s on its way back up. My point here is: in some cases the project is stuck, but you shouldn’t judge the team for that.
On the flip side, imagine a team that’s making slow progress because they are solving a complicated issue. Even though there are just a few stories being worked on, they are all connected to user stories providing real value.
One important distinction is that we need to look at a long enough time span to make a judgement. Sometimes internal tooling is important. In the example about inheriting a codebase, some refactoring is needed. If you judge these efforts based on just a few weeks or work, you might get a false impression about them as long as in the long run, the project is building an actual product.
This question is a good way to abstract yourself from the specifics and focus on the important things. A software product is done in order to solve a user pain, not for the technology’s sake. If it’s not solving a problem for users most of the time, it will never be efficient.
Asking ourselves this question can also be beneficial to highly technical leaders too. Often times we are too focused on the nitty gritty of a project to realize that we are stuck on the wrong priorities and not bringing the business forward.
Need more tech leadership advice?
I hope you enjoyed my thoughts about running efficient tech teams. On this substack, I post regularly about technologies, leadership and personal growth. If you enjoy that, consider subscribing :)