What Should a Product Owner Do with an Incompetent Team?

As a product owner, you might sometimes face the challenge of working with a team that isn’t meeting expectations. Incompetence in a team can be frustrating, but it’s essential to approach the situation thoughtfully and strategically before taking any drastic steps. So, what should you do if you find yourself in this predicament? Let’s dive into it.

🧐 First Things First: Define “Incompetence”

Before jumping to conclusions, it’s critical to distinguish between true incompetence and lack of knowledge or experience. Sometimes, what we perceive as incompetence is simply a gap in training, exposure, or communication. Let’s break down a few scenarios:

Are They Really Incompetent?

• Lack of knowledge: Maybe the team has never been exposed to the right tools or processes. This isn’t incompetence but rather a training opportunity.
• Inexperience: Sometimes, the team might be new to a certain technology or domain. They need time to grow.
• Malice vs. Incompetence: Be careful not to confuse incompetence with malicious behavior. A truly malevolent team member could be worse than someone simply lacking skill. More on this later.

🔥 When It’s Time to Let Go

If you’ve determined that the team is truly incompetent, or worse—intentionally harming the project—you need to act. A business cannot thrive with people who don’t contribute positively to the team or the product. In my experience, amazing teams build amazing products, and amazing teams don’t come from incompetence. If a team member or an entire team is genuinely holding your product back, don’t hesitate to let them go.

Steps Before Firing the Team:

1. Engage and Support: Ensure that you’ve provided every opportunity for the team to improve. Engage them in meaningful ways and offer clear feedback on what’s not working.
2. Provide Resources: Offer them training, tools, and support. Sometimes, what seems like incompetence is just a lack of proper resources.
3. Evaluate Progress: After giving them support, check their progress. If they still aren’t meeting expectations, it’s time to consider more drastic measures.

💡 A Personal Story: Incompetence or Strategic Manipulation?

Let me share a story about a team I worked with at a bank. At first glance, their behavior seemed incompetent, but as I dug deeper, I realized it was more complex than that.

I was consulting on a project, helping a team transition from their previous systems to Azure DevOps (or TFS, as it was known then). This team was using Java, and if you know Java teams back then, many were resistant to moving to TFS. That was their first issue: hostility toward change.

The Real Horror Story: No Source Control

This team refused to use source control. They believed it would slow them down, preferring to log directly into their production servers and make changes live. Yep, you read that right—straight into production.

Even worse, each team member had their own server, and they would log in independently to make changes. You can imagine the chaos this caused. How did they synchronize across servers? They didn’t. Each person managed their own server, and the changes were not aligned.

To make matters worse, these weren’t just any servers—they handled real-time banking transactions for a multinational bank. This realization horrified me, and I immediately raised the issue with leadership.

Holding the Bank Hostage

Here’s where it gets interesting. The bank’s leadership knew about the situation but chose to stay silent. Why? Because these team members had essentially held the bank hostage. They knew that if leadership complained, they could leave, and the bank wouldn’t know how to fix the mess they left behind. This wasn’t just incompetence anymore—it was strategic malevolence.

What Should Have Happened?

In this case, my recommendation was clear: Fire the entire team. The organization needed to take the hit, remove the team, and rebuild properly. Keeping such individuals around would only lead to more sabotage and risk for the business.

👩‍🏫 A Word on Training and Knowledge Gaps

Not every team that struggles is incompetent. Often, they simply don’t know better because no one has ever taught them. For example, I’ve worked with teams that didn’t understand basic concepts like source control or how to properly manage code branches. This isn’t malicious behavior or incompetence—it’s a gap in knowledge.

How to Address Knowledge Gaps

1. Training: Provide structured training sessions to fill those gaps.
2. Mentoring: Pair inexperienced team members with seasoned veterans who can guide them.
3. Continuous Feedback: Give them regular feedback so they know where to improve.

Teaching and nurturing your team can transform perceived incompetence into competence. However, if after extensive training, the team still doesn’t improve, it may be time to part ways.

🚫 When to Cut the Cord

So, when do you finally decide to fire the team?

• Malicious Behavior: If the team is intentionally holding your project hostage or creating unnecessary risk, fire them immediately. Don’t let them sabotage your business any further.
• Lack of Improvement: If the team has been given every opportunity to improve but fails to do so, it’s time to let them go.
• Cultural Misalignment: Sometimes, the team might be technically competent but not a cultural fit. If their way of working doesn’t align with the organization’s values and goals, it’s worth considering a replacement.

Key Takeaways 📝

• Amazing teams build amazing products. If your team isn’t performing, take action.
• Distinguish between incompetence and lack of knowledge. Sometimes all a team needs is proper training.
• Don’t tolerate malevolence. If a team is intentionally holding your organization back, it’s time to fire them.
• Provide every opportunity for improvement. Engage, train, and support your team before making the decision to let them go.
• Act quickly when necessary. Prolonging the inevitable only hurts the product, the organization, and ultimately, your customers.

🚀 Moving Forward At the end of the day, a successful product owner understands when to invest in their team and when to cut their losses. It’s not an easy decision, but it’s one that can save your product—and your organization. If you find yourself in a situation like this and need advice or coaching, feel free to reach out. I’m always happy to chat about Scrum, Agile, or DevOps. Let’s build amazing teams together!