Principles for structuring a product development team

At my company, we are going through a reorganisation of our product and engineering teams. Do you have any universally applicable advice for leaders trying to structure their product development teams?

While every company should approach this somewhat different, there are a handful of principles that apply to most product companies that I think you should consider.

First, I recommend embracing a model where product and engineering are united under a single organisational department (e.g., product development, R&D, or technology). This is a simple first step towards bringing these teams together and eliminating blame, finger-pointing, and poor communication.

From here, I recommend cross-functional teams. Despite being one of the most misused buzzwords in business, organisations built from cross-functional teams really do scale much more effectively than organisations with too many functional silos. Cross-functional teams are teams that are united by a common goal, rather than a common profession or practice. A cross-functional team might be a group of designers, engineers, product managers and product marketers that are all rallied around a single problem they are trying to solve, whereas a functional team is a group of people brought together because they share a specialisation (e.g., all product designers might work in a single team).

These days, small cross-functional teams are the norm for product development departments, while sales, marketing, and support departments are typically grouped by function. Cross-functionality is a spectrum and while it’s generally better to be more cross-functional than less, the sweet spot is different for all companies. The practicality of a cross-functional organisational structure also varies with the maturity and size of the company. For example, in the early days, most startups are one small cross-functional team out of necessity. As startups grow, though, departments start to form around senior leaders who own a function. Large companies are often resourced well enough to once again enjoy a higher degree of cross-functionality.

Organisations built from cross-functional teams scale better because they rely less on centralised decision making. In a functional organisation, to make a decision that requires the consultation of multiple functions, a lot of communication and negotiation must be done across teams and this can be incredibly slow. It also means a lot of important decisions are made by members of leadership who may not be close enough to critical information that should impact decision making. Cross-functional teams that have a healthy level of representation from the various functions within a business can be more independent and autonomous, which results in both quicker and better decision making.

While I strongly recommend employing the cross-functional teams pattern when structuring teams, in contrast, I recommend functional lines of reporting from an organisational chart perspective. This means, where possible, designers should report to designers, product managers should report to product managers, and engineers should report to engineers. This can complicate your organisational chart because it decouples reporting lines from day-to-day teams (many staff end up in two teams, their functional team and their cross-functional team), but it is critical in order to provide great career development, coaching and mentorship for team members, and to encourage the continuous improvement of how you approach each function.

A common anti-pattern to avoid at all costs is the temptation to have product development team members report to the product manager leading their team. This may seem like a logical way to structure your company because it is technically cross-functional and it puts responsibility into the hands of the person perceived to be the leader of the team (the product manager), but at scale, it always leads to conflicts of interest (product managers are managers of a lot of things, but they are members of the team, not managers of the team), deprives engineers and designers of mentorship from someone experienced in their field, and distracts product managers from their core responsibilities.

The last principle that applies to most teams is to decouple technical leadership from people management within engineering reporting lines in larger organisations. This means the people leaders (often engineering managers) who take care of people from a satisfaction, career growth, and general HR perspective are not the people who take point on technical direction and leadership. Separating these roles explicitly is the only way to ensure excellence in both areas at scale, because anyone juggling these separately will inevitably focus more on the area they’re most interested in, and there is always more work to be done in both fields. This principle also applies to any other function with many employees doing very similar work. For example, at scale, it’s best to separate training and quality assurance for customer support teams from people management, otherwise one will likely fall by the wayside.