A while back, a group of us in the Winter Tech Forum community were discussing the age old question: How do you measure engineer productivity? It is hard to do without becoming big brother, which just makes people game the system. While I don’t have a neat answer, below are some things I have experimented with.

Most of these don’t involve "measurement" of productivity. In my experience, measurement is extremely difficult to implement without mangling the incentive structure for engineers. Lines of code? Hours per day the mouse wiggles? Ridiculous. You can get a lot of mileage out of simply fixing things known to kill productivity:

Are People Working On Things They Care About?

If engineers people are working on something they believe in/are excited about, output will go up. Give them control & autonomy, and they’ll run through a wall for you.

Are Developers Worried?

Steve Tarver once told me "pay developers enough that they don’t have to think about money." Developers are paid to think, deeply. Threats of layoffs, office politics, bad insurance, etc. - any of these things can be deeply distracting, and productivity will suffer.

Do Developers Have Clear Priorities?

I have worked on teams in which sales people went directly to developers when they needed something. So, everyone was putting out little fires instead of making progress on big-picture tasks.

We resolved this by forming a committee with representatives from sales, dev, support, & management. They choose the work and the scrum master guarded the dev team against interruptions. The developers involved in this group would also meet separately to ensure they present dev team priorities in terms of paying down technical debt, big picture architecture changes, etc.

Are Developers Interrupted?

How often are developers interrupted for support calls? Interruptions are the mortal enemy of deep focus work. Support ticketing systems can sometimes be mined to see what features/modules are causing the most support calls.

What is our level of technical debt?

A company which cannot answer this question is in for trouble. One method I have seen work is simply creating Jira cards for all tech debt with a rough estimate, so the percentage of tech debt in the backlog can be calculated.

How early in the build process are quality checks run?

Having static code analysis, code coverage, etc. run on the build server is great, but having it run also on developer machines is better. Otherwise, you risk people wrapping up a task, pushing, & context switching to another task, only to find out that static analysis failed, for example.

Track ratio of closed bugs to open bugs.

If it is growing, there may be a problem. Over time, you can also track the history of that ratio in relation to other events.

Measure Duplicate Code

Measure the amount of duplicate code present in the codebase using something like PMD. If there is duplication, and the duplicates grow apart, maintenance costs go up.

Schedule heads down time.

Developers should be able to block out interrupted time to cut down on context switching and guard against interruptions. Be sure to take time of day into account as well. Dan Pink gave an excellent talk at Google on this topic.

**Do they have the best machines money can buy? **

(& the other points from the Joel Test) ... Maybe I should have named this article "The Joe Test"!

I have seen developers using 15 year old machines!! What a ridiculous false economy. Sometimes fixing this means pushing back on budgets. Same is true of tooling shared by the team.

**Designate a person or group of people to run interference between support & developers. **

In our case, developers were experiencing significant time loss helping on support tickets. We had a developer switch to a role as head of support, and he is knowledgeable enough to intercept many of the inquiries that would normally reach a developer. Generally, developers don’t want to go to support permanently, so perhaps this could be a rotation.

Fix your local builds!

(Thanks Drew Stephens)

Many companies have projects that won’t build on a fresh machine, fresh clone, etc. Developers can spend countless hours with brittle dependency trees & tooling.

Choose performant tools & languages that integrate well

*(Thanks Marshall Pierce) *

Your choice of programming language & tooling should prioritize developer productivity. At a minimum, you should provide a "paved path" - a set of tools which integrate well.