Tracking Developer Productivity: Because We All Know 'Lines of Code' is a Scam!

Measuring productivity in a technology team is straightforward, but the skill lies in understanding how to take a team from underperforming to one that continuously improves.

Ironically, utilising CI/CD practices doesn't inherently give you this edge, despite what many technology leaders may think.

One company I worked with had over 50 engineers, yet they were shipping at a snail's pace, despite utilising CI/CD, Agile, DORA and microservices. Why? No investment in team growth or shared process ownership.

Often, people try to produce this formula along the journey:

More code ∝ productivity

However, as the title suggests, we all know that lines of code are not a direct measure of productivity, nor are they directly proportional to the number of features or higher employee satisfaction.

What Does Productivity Actually Mean?

A prominent place to start, but what does productivity mean in software engineering?

If we're honest, the only measurement that matters is what drives ROI for the business, but this doesn't always mean releasing new features to increase sales or enhance customer experiences. I can be paying down technical debt or improving processes that take hours when they could take minutes.

Ultimately, we aim to have a well-oiled machine, enabling rapid and timely work to improve the business's bottom line when needed, thereby helping the company stay competitive in the market.

I've often seen the software productivity conundrum described as the following triangle:

The software productivity triangle.

As you can see, it's broken down into three distinct parts: Team, Process and Velocity. I've even seen some people suggest that you can't have all three, as something suffers; in other words, to have a happy team and incredible velocity, the process suffers.

Ultimately, that's because people think about this triangle wrong, and they index for the wrong things from the get-go.

If you were to keep the view above, the process would be the thing that suffers the most in the short term. But eventually, after a sufficient period of time, the velocity will reduce and the team will suffer.

If you think about it, without a process, people cut corners, technical debt accumulates, people become unhappy with their tech stack, velocity slows due to the bloated mess, and eventually, you're shackled by your tech.

How To Transform My Team's Productivity?

There are specific frameworks that help, such as SPACE, DORA, and Agile, among others. I'm not going to discuss what methodologies you should employ for productivity (that's for a separate blog). Instead, I'm going to suggest how you set up your team to ensure productivity.

So what's the secret sauce? It's not more dashboards. It's how you treat your people and how seriously you take their progression.

When people talk about developer productivity, they often jump straight to process frameworks or delivery metrics. But one of the most overlooked levers is also the most human: growth.

Progression by Craft is the idea that engineering should be treated as a discipline, a craft to be honed over time. Teams don't magically become high-performing; they're built through mentorship, learning, and well-defined career paths.

When engineers are progressing, everything improves: retention, code quality, decision-making, and even team morale. You start promoting from within, you spend less time backfilling roles, and people stay because they see a future. It's not just a culture boost, it's a capability boost.

Some of the best indicators aren't raw output metrics but qualitative signals:

• Are engineers growing into leadership roles?
• Are they mentoring others?
• Is the organisation investing in skills and craftsmanship?

Treating progression as a first-class pillar of your engineering strategy builds sustainability. Anyone can sprint, but only teams that invest in their craft can run the marathon.

Ultimately, productivity isn't a metric; it's a mindset. So forget about measuring lines of code. Start measuring how far your team can grow.