Dependencies are one of the biggest hurdles in product development. They consume time and effort, and often slow down progress. Here are three strategies for managing dependencies:
1. Reorganize to eliminate them
2. Rebuild to reduce them
3. Cooperate to work through them
Let’s take them one by one
1. Reorganize to Eliminate Dependencies
Reorganizing means restructuring teams to remove dependencies. Many companies have component teams—teams focused on specific components, systems, or layers within the architecture, such as an iOS team or a database team. These teams often consist of specialists who solve highly specific problems within their domain. While this setup can be efficient from a technical perspective, it often requires multiple teams to collaborate in order to deliver a feature, increasing inter-team dependencies.
One solution is to create cross-functional teams. These teams combine the skills needed from various component teams into one, allowing them to build a feature end-to-end across all layers of the architecture. These are often referred to as feature teams—teams capable of taking any item from the backlog and implementing it. This structure significantly reduces dependencies, as the team has all the skills required to deliver a solution independently.
However, even with component and feature teams, there can still be a reliance on someone else to elaborate on the solution, which is an often-overlooked dependency.
A product team takes cross-functionality a step further. Not only are they responsible for implementation, but they also define the problems and find the solutions. They own the process from start to finish, reducing handoffs and dependencies even more.
2. Rebuild to Minimize Dependencies
Another approach is to rebuild the architecture and code to reduce dependencies. This will be covered in a future post, but since the organization and communication paths go hand in hand with the architecture you can figure out what this means. It is reverse engineering to get the organisation in shape.
3. Cooperate to Manage Dependencies
Even in product teams operating within a product-centric model, dependencies may still exist. In these cases, the focus shifts to closer cooperation across team boundaries. If dependencies are recurring, you may need to redefine responsibility areas or accept that some problem spaces are too large for one team to handle independently. That said, it’s always possible to draw clearer lines that better define team responsibilities. In these cases there is a limitation of the teams autonomy while they need to cooperate with others.
Misunderstandings Around Cross-Functional Teams
The term “cross-functional team” is often misunderstood, and typically refers to teams with an administrative product owner (PO), developers, and a tester. However, in a true cross-functional team, there’s more to it, particularly in the context of product teams.
A Product Manager (PM) isn’t just responsible for managing a backlog and taking requests from business stakeholders. The PM is part of the team, accountable for the results, and must ensure that the entire team adopts a business-focused mindset. A truly cross-functional team has all the resources necessary to solve customer-facing problems without needing to rely on others.
Team Responsibility and Accountability
A product team is accountable for the overall results and impact of their product. Delivering output alone isn’t enough; the team should follow key performance indicators (KPIs) that ideally tie directly to the product’s success and the company’s bottom line. This level of responsibility gives the team both the autonomy and the mandate to solve the right problems, providing value for both customers and the business.
The team is responsible not just for building the product, but also for its maintenance, operations, and long-term success and need to balance their work accordingly.
Team vs Group
A group is a collection of individuals working alongside each other on separate tasks or goals. Each person focuses on their own objectives and performs independently. In such a setup, members often rely heavily on a leader to assign tasks and ensure the pieces fit together.
A team, on the other hand, is a group of people working together to solve a common problem. They share a joint goal and collaborate closely to achieve it. A successful team relies on strong self-leadership and self-organization to create an environment conducive to cooperation. In a team, collective goals and achievements are prioritized over individual ones. High autonomy is essential for a team to thrive and accelerate its performance.
In my experience, groups tend to prefer simpler, more predictable problems, while teams thrive on tackling complex challenges. Teams leverage their collective intelligence and cooperation to achieve something greater than what individuals could accomplish on their own.
Self reflection until next time: Do you work in a group or a team?
Stay tuned for more on teams and product development in future posts. And if you have missed my previous ones they can be found here.