Overcoming product team debt
Technical debt - or tech debt as it's often shortened to - is a well-known, well-defined, and fairly well-managed concept. In essence, cutting corners to get things out earlier and not tending to your tech stack diligently can lead to an accrual of tech debt, which in turn means that changes begin to take longer to design, implement, and release over time.
To better illustrate the impact of tech debt, let's consider an image adapted from Martin Fowler's 2019 article, which demonstrates how tech debt can accumulate over time and hinder a team's progress:
I've become increasingly aware of another type of debt that can have the same effect on progress and agility over time - perhaps an even bigger impact in some cases. I call this product team debt.
In this article, I'll describe:
👉 What it is
👉 How it impacts your team and product
👉 Common challenges
👉 What you can do about it
What is it?
The term "product team debt" covers anything that causes drag on the team as a whole, which is in the team's gift to address. A few high-level examples could be poorly-defined comms, a lack of critical tooling, or an absence of key roles or skills.
What impact can it have on the team?
All of these factors are intrinsically linked. It's not uncommon for one to lead to another, and it often doesn't take much to see a team begin to spiral:
🔻 Reduced flow
📉 Reduced impact
😞 Reduced team morale
👋 Increased team attrition
👨💼 Intervention from leadership, such as:
- Augmenting the team
- Eroding empowerment
- Layering on additional processes
To better understand indicators of product team debt, here are a few examples that I've seen in across multiple teams:
1️⃣ Miscommunication, or insufficient communication: When team members aren't effectively sharing information, it can lead to misunderstandings and slow down progress.
2️⃣ Retro actions carry over many times: When retrospective actions persistently remain unaddressed, it indicates that the team is struggling to tackle underlying issues.
3️⃣ Releases have negative downstream impacts: If a team's releases consistently cause problems for other teams or users, it suggests that there's a deeper issue with the team's processes or communication.
4️⃣ Imbalance between discovery and delivery: If a team spends too much time in the delivery space, or focuses almost exclusively on delivery, then undoubtedly the underserved element will suffer as a result, along with the team's progress as a whole.
5️⃣ Single points of reliance: Overdependence on specific individuals can lead to bottlenecks and an unhealthy team dynamic.
6️⃣ Insufficient or spammy monitoring and alerting: Inadequate monitoring can lead to missed issues, while excessive alerts can cause alert fatigue and desensitise team members to potential problems.
7️⃣ New team members left out to dry: When onboarding processes are insufficient, new team members may struggle to integrate and contribute effectively.
8️⃣ Team leavers still relied upon: If a team continues to rely on individuals who have left, it may indicate a lack of documentation or knowledge transfer.
9️⃣ Lots of work in progress: Too many ongoing projects can lead to a lack of focus and slow down overall progress.
Common challenges
Tooling
Either the team does not have the tools they need, or they are not working as required. For example, Slack might not be set up to get the most out of your team, observability may be lacking, Jira might be constraining you, or your engineers might be lacking a licence for a key piece of enabling software.
Ways of working
The team might have set patterns of how they work together, but this isn't explicit. In teams that are struggling in this area, you often see sporadic, messy over-communicating, or, worse still, people are afraid to ask. There is no standard offboarding approach. Onboarding is choppy at best. Other teams don't know how to interact with your team. Team members have their heads down 100% of the time, rarely coming up for air.
Documentation
Yes, working software is the priority, but one-pagers about the gnarliest areas of your codebase and runbooks for those things that you don’t do very frequently can be worth their weight in gold. The usual suspects where a lack of basic documentation can really hold you up: Third party integrations, release management, customer-facing docs (e.g. API docs).
Team and product identity
Team members are unclear on the team's purpose, the boundary of its domain, the team's goals, and what the team really cares about. Either this doesn't exist, or it gets stale and forgotten about very quickly.
Misalignment
Both intra-team and inter-team. Sometimes even broader than that. Different team members may be pulling in different directions. The team as a whole may be working on the same thing as another team, or the team may be working on something that will have a negative impact downstream.
Rockstarism
There will always be leaders that emerge within teams, and there will always be team members who are experts in different parts of their domain. But this can become a problem if left unchecked, whereby the dependency becomes unhealthy, and the team really struggles during periods of enforced absence.
Skills and knowledge
It could be that there is an area of your domain that nobody really understands. It might be that a key role has yet to be filled, or that a team member has recently left and there is no replacement in sight.
Product debt
Perhaps a category all on its own, but a lack of quality, consistency, and tightness in your product can also add to the noise and drag. An inconsistent user experience brings its own challenges. As does having a lot of underused, or wholly unused features. As does leaving it too late to automate enable self-service of repetitive, manual steps. You could add “not knowing your users” into this bracket too.
What you can do about product team debt
Here are a few tactics that I’ve seen work in various different teams:
📝 Set aside some dedicated time to review or create your team principles, roles and responsibilities, domain, and goals. This will help clarify the team's purpose and ensure everyone is on the same page.
🤝 Create a product team canvas and/or a Team API (a set of guidelines for how the team interacts with others). This will make team interactions more efficient and help avoid miscommunications or misunderstandings with other teams.
📊 Either create a team ops board where you track product team debt, or better still, work it into your product backlog. This will help you keep track of issues that need to be addressed and prioritise them accordingly.
🔍 Focus your next retro on product team debt. Ask the question, "What is slowing us down?", dot vote, then generate a product debt backlog or add items to your existing, broader backlog. This will help your team identify specific areas where improvements can be made and create a plan to address them.
⏰ Put in an hour a month for the whole team to review this, outside of your normal cadence. This regular check-in will keep the team accountable and ensure that product team debt remains a priority.
Further reading
- Hyperact's product team canvas template - our free Miro template to help you describe your team's essence on one page
- Team Topologies' Team API GitHub template - a great template to help a team understand itself
- How to get a product team firing on all cylinders - other tips that might help alleviate product team debt
In summary
Recognising and addressing product team debt is essential for maintaining a healthy, productive, and agile team environment. By regularly assessing and resolving issues that slow down the team, teams can foster better communication, collaboration, and improve their all-round productivity.
