How to measure your and your team’s productivity as a developer, manager and engineering lead.

This post is originally from Zero To Architect, a free newsletter available on Substack from Ali Raza, a versatilist software engineer who believes that anyone can be a software architect.

Productivity is contextual and subjective. It can’t be generalized.

I manage and lead 8 to 10 engineers on average across different teams and use different measures to determine their performance and productivity instead of one rule that fits all.

Let’s start.

1. Year of experience in a specific tech stack
2. Difficulty level of new tech stack for a new task
3. Relevance of tasks with the tech stack
4. Ability to learn any new skill to fulfill the job
5. Knowledge of relevant tech ecosystems

Example 1: Experience and task in the same tech stack

Let’s say there is a developer with three years of experience in JavaScript and React. Xe is assigned a task of five-story points, which is relatively fair and expected to be completed if no blockers occur.

If the task is completed within the timeframe, then the developer is performing well.

But if the random tasks are taking more time, then there needs to be a discussion.

What is to be discussed here?

As a lead or manager, I will first sit down and evaluate what went wrong here. There are chances that

1. There was tech debt that needed to be cleared first.
2. But who created that in the first place? Was it some other developer?
3. The feature affected other parts of the code and needed to be handled, and it took more time than anticipated earlier.
4. Was the codebase not scalable?
5. How can we ensure that it doesn’t happen in the next feature implementation?
6. The person took more time.

The first two options clearly illustrate that the developer might not be wrong and could be given leverage. But in the last one, the performance is quite low.

Example 2: A developer is assigned a task of an overlapping tech stack

A backend developer with an Express.js and Node.js tech stack can be expected to take over Nest.js with ease, and his task estimates can be extended from 10% to 25%. However, if the same engineer takes double the time, then it means either he lacks basic JS OOP skills or is a slow learner.

The latter is acceptable, but the former is not and will directly fall under poor performance, and the developer should be considered less productive.

Example 3: You are given a task above your skill level

Assume you have average database skills and know the syntax and APIs to work with. Your next task is implementing sharding and partitioning with eventual consistency and maintaining connection pooling.

It’s a difficult task that requires thorough knowledge of the internals of the database.

What to do as an engineer

1. First, discuss with your manager that you don’t have the current skillset for this task, but you will learn it and finish it.
2. Discuss the timeline. If a person with the required skillset needs two weeks, then it should be four for you.
3. Set expectations earlier to avoid any confusion and delivery delays later.
4. This will ensure that, as a developer, your performance level is as per your skillset, with room to improve.

What to do as an engineering lead and manager

1. Understand the situation and skill level of your resources.
2. Set expectations for the deliverable accordingly.
3. Even if the candidate is able to deliver 50–70%, it means xe performed well and couldn’t be deemed a non-productive engineer.

Tangible criteria to judge an engineer

Irrespective of any task, the developers must be following these practices:

1. Clean code practices being followed
2. Unit and integration testing
3. Scalable code
4. Number of bugs and issues reported
5. Git standards being followed

With different use cases, I have tried to establish that it is not that easy to evaluate even one developer under different scenarios.

So, interact more with your team and ensure that you understand their side of the story before evaluating performance and productivity.

Thanks for reading.