Tech debt and design debt are well known concepts in product development.

It’s ok to accept a reasonable amount of ‘less than perfect’ in engineering quality and delivered product design in exchange for being able to deliver faster. It’s understood that the debt will need to be repaid at somepoint in the future; it’s common practice to have dedicated sprints at regular intervals to pay back the tech and design debt. How much debt is acceptable versus the payback in quicker delivery is – hopefully – a strategic choice made by engineering and product leadership.

But there’s a third debt that isn’t usually spoken about: team debt. Team debt is the ‘less than perfect’ functioning of the delivery team – design, engineering. product, and others.

We build teams and we wear them out too

The qualities of high performing teams – trust, safety, clear comms, shared goals, continuous learning, etc. – take deliberare work. Practice, practice, repeat. None of this just happens, it’s team building.

But, when it’s decided it’s OK accumulate tech and design debt, when short-term speed is priorities, when the shit hits the fan and delivery goals are JFDI – all this takes a back seat. Processes are short-circuited. Teams retreat into a collection of silos and agile becomes mini-waterfalls.

Bad team practices develop, good team practices are not practiced. The team becomes less good at being a team. This is team debt. And it’s unsustainable if not corrected.

Who is responsible?

Probably no one, which is … not great…

For tech debt, engineering leadership should be able to say “There’s too cruft in this code, we need to refactor before we can deliver the next feature”.

For design debt, design leadership should be able to say “This important user journey is broken we need to fix that before we create build new features on it”

Who says “This team is not working well enough, we need to fix it before we deliver more”?

Large orgs might have someone, but probably not. Well functioning teams might have the space to reflect and call it. But well functioning teams aren’t the problem. In reality for most teams it’s no one’s responsibilty and no one’s accountability. It falls between the cracks and manifests as individual burn out.

Product, design, and engineering lead need accountabilty, and autonomy to collectively recognise that the team has built up enough debt that it’s functioning bellow efficiency and that that debt needs repaying.

What else can we do?

We should normalise thinking of team debt as something that builds up and needs repaying and bake it into our delivery practices. Just as it’s a strategic choice how to use accumulate tech and design debt, it should be a strategic choice for how use team debt. We need to recognise it, then we use it strategically.

There’s been a lot written on good team building by people more expert than me, so I’m not going to make too many practical suggestions. Every team is different and there’s lots to get started with.

But! I would like to nominate observing users actually using the product as a very high impact activity to bring cross-functional teams together and build alignment. Having a shared understanding of users builds lasting bonds and strong foundations that will withstand a lot of JFDI.