Team health is often discussed when it comes to HR or Team Leadership. It’s a term used when asking how a team is doing generally, and usually comes from a ‘feeling’ perspective. The metrics we focus on in this article highlight the technical side of team health. Metrics that will enable you to truly impact and influence positive change. Everything we mention below is quite novel and experimental. The ideas and techniques are what we’ve developed and implemented over the past year and are still a work in progress.

Team health

Team Health can mean a lot of things. Anything from ensuring your screens are high quality and that people have good posture right through to the leadership style in the company.

Great team health can be observed as a team communicating well, delivering amazing products, being passionate about what they do, and seeming to be functioning perfectly. The flip-side of that would be a team which seems unhappy and feeling like they are unable to deliver the product. Negative team health is typically observations made at a point in time.

Often when things are stacked heavily on the negative side you will notice a higher turnover and people generally seeming off. This is a problem, and understanding a team purely on an emotional spectrum may not always be enough.

Quantifying team health

The first thing to point out is the fact that any sort of quantification effort of something as complex as Team Health is is going to require you to pick out numbers and measures from different sources. One single measure is not enough.

The following four metrics we will refer to as ‘dimensions’ paint an adequate picture of a team’s Technical Health.

1. Identify business purpose

Here you’ll work with the teams to identify each piece of code and what the business purpose of that piece of code is.

By going through this process you may find artefacts and repositories that don’t have any value or purpose at all. Teams often don’t completely clear off old deprecation efforts. This process will often outline this and enable instant improvements.

But the second part of this is that—since you’re going to measure each process—your measures will need to be associated with things, and you need to be able to talk about these things with the rest of the business.

Let’s say you have metrics that are attached to GitHub repositories. Great! But the thing is, your CEO doesn’t know what GitHub repositories are, or what their business function is, nor should they. And if I say “this repository is in bad health,” what information does that really provide in this instance?

So we have to attach source code to specific business functions which we can then talk about. You should assign each of these business processes to a team; typically this will happen by the way your teams are structured, but if not, this is another great outcome of doing this step.

By assigning business processes to a team, you apply context to all of the conversations that happen later on. You may also uncover key business-critical processes that no one has true ownership of. On the other side of that, you can identify pieces that people own which they might not need to, or pieces that can be removed completely.

2. Code size

Often when trying to gauge the size of some source code, we look at lines of code.

But there are a lot of problems with the lines of code metrics. The biggest is that it doesn’t speak to anyone. If I talk about lines of code to a Product Manager, or if I talk about lines of code to a customer, that metric won't be relatable in any way.

How big should a search engine be to a business? Is it 100,000 or 100 lines of code? If you said “we have to support a piece of functionality that’s 500,000 lines and we have one person,” is that a lot?
The second problem with lines of code is that it’s highly variable.

An XML file, a CSV file, a Python script, or Scala… these all have very different densities in the effort encoded in each line—which makes a blanket line of code metric effectively meaningless.

What we have to do instead is measure code by how much effort it represents, or how much value was put in to create it (whether that’s time or money).

In our case, we use a dollar figure. We attach every single piece of code to a dollar figure that roughly represents the cost it would take to recreate that entire piece of code one-for-one using the same technology, design patterns, architecture, etc.

A big advantage of using dollar figures is that it’s intuitive. While lines of code might not be universally recognisable, anyone will have a visceral, grounded reaction to the difference between a piece of code that’s $20,000 and something that is $2,000,000.

3. Code quality

There are hundreds of books on this topic, and we’ve taken a radical approach to measure it. It’s a subjective score between one and five:

• Excellent
• Very Good
• Good
• Tolerable
• Bad

You may think this is a very subjective rating, and ask how this is useful anyway, when software engineers are fickle about code and their assessment of it.

The thing is: bad code can come from a really wide array of sources—the code might be hard to read, hard to test, hard to deploy, it may be too slow, or it may just be too large.

Trying to gather all of that data and all the nuances in it probably isn’t worth the cost. Having a 1–5 metric can act as a proxy for any one of these influences. The reality is that if a team collectively had a poor feeling towards the code it was responsible for, it’s going to impact their Team Health, so it can’t be ignored.

4. Team domain knowledge

Domain knowledge or code knowledge of the system is the final metric, but is equally important. For example, if everyone thinks the code quality is extremely high, but the knowledge of it is extremely low then you can question where they’re basing it from. Perhaps they simply skimmed the codebase and it ‘seemed fine’ or it was well documented and so was good.

We use a 0–6 measure—much like that in Code Quality:

• No knowledge
• Unfamiliar
• Some knowledge
• Familiar
• Very familiar
• Expert

Based on this information you can summarize the baseline view of a team’s technical health. As a business stakeholder, having access to this data enables you to prioritise, question, and participate in the improvement of a team’s Technical Health.

We’ve found a ton of value out of every one of the dimensions outlined above alone. I’d highly recommend if you’re responsible for—or can influence change in process in—a software engineering team, start this process. The outcomes we’ve gained from simply performing each one of the dimensions alone was well worth the effort. We’re now able to use that data to drastically influence the overall health of the Engineering teams, and thus business as a whole.

The content discussed in this post was summarised from our recent talk at Techweek2020. You can find more information and examples in the full video here.