People debt is another of the thirteen technical debt categories identified by Alves et al. in their paper “Towards an Ontology of Terms on Technical Debt“. Let’s dig a bit deeper in this category of technical debt.
What Is People Debt?
People Debt is defined in the paper as
people issues that, if present in the software organization, can delay or hinder some development activities.
They immediately give an example:
[…] expertise concentrated in too few people, as an effect of delayed training and/or hiring.
The authors of the paper “Towards an Ontology of Terms on Technical Debt” define design debt as:
[…] missing, inadequate, or incomplete documentation of any type.
Mark Seaman also identified an example of people debt (though he uses the broader concept of cultural debt): staff afraid or unwilling to share information with others.
So essentially, this is a form of technical debt that isn’t technical at all. Which is why not everybody would categorize people debt as technical debt. Some say cultural and people problems can lead to technical debt, but they aren’t technical debt as such.
I’d say it doesn’t really matter, as long as people debt is included in the discussions on technical debt.
Causes Of People Debt
Two big causes of people debt are:
- hiring the wrong people
- directing people in the wrong way
Hiring the wrong people can cause dysfunctional teams because they lack certain skills, or lack maturity and/or professionalism. If not a single developer in your team is aware of architectural best practices, you’ll end up with architectural debt fairly soon. If you have a developer with a toxic attitude, things may start to fall apart inside the team and you will see the results in your software as well.
But even when you hire talented people, misdirecting them can cause people debt. A culture of blame encourages people to hide their mistakes, blame others and avoid collaboration. Micromanagement lowers morale and can cause talented employees to leave.
And forcing everyone to work on separate modules means all knowledge is split up between them. When a single developer is sick or resigns, you’ve lost this knowledge (the famous bus factor) and the other team members will have to scramble to get up to speed. Unfortunately, this practice is still all too common. Often, it is enforced by developers themselves. Herein lies an important task of the manager or team lead: they must encourage the team to work on pieces of the software they are less familiar with.
Solving People Debt
Let’s start with avoiding people debt. This is simple to explain, but not so easy to implement. In essence, organizations do well to hire balanced teams (senior vs junior) but with a focus on the right mentality. When faced with the choice between a senior developer who prefers to work by themselves and in the way they’ve always been doing versus a junior who wants to collaborate, share and learn, the choice should be clear. The hard part is recognizing these characteristics before hiring them.
Once we’ve hired a good team, it’s key to find the good balance between micromanagement and full freedom. Teams should be expected to work together and share knowledge but also get the freedom to work in a way that works best for them.
If you’re facing an existing people debt issue, some difficult changes and decisions may lie ahead. The way the team has been working will need to change and usually, people don’t like change. But if they can see it’s for the better, they may react enthusiastically. In case you have a toxic personality in your team, and they refuse to change their ways, you may have to redirect such a person to a new role or even new organization.
The Business Case For Reducing People Debt
Not reducing people debt can cause or increase many other categories of technical debt. The absolute worst effect is that people who knew the ins and outs of the system leave for greener pastures. Having to train new developers to achieve this level of knowledge will take time and money (and probably many bugs and bugfixes).
The only case where I personally think it is acceptable to let these people (those who know the system well) go, is when they are the cause of people debt. If someone has the wrong attitude towards their colleagues, and refuses to change, they will only bring out the worst in people or cause others to leave.
People debt is probably the most vague of all categories of technical debt, and the most difficult to fix, but possibly one of the most important ones.