product organization structures part 2

Part 2: Team Superstructures and alternative organizations
 
Staffing the teams
 
Determining which person goes on which team — can be extremely tricky. If we have teams that stay stable for a longer time, we don’t have to make these decisions very often, but they will impact the team performance for a long time. Conversely, with flexible teams, a lot of staffing decisions will have to be made, but each one won’t matter as much. In other words, with stable teams, your staffing process requires more diligence, and with flexible teams, more speed.
 
Here are few points to consider:
 

• Team dynamic: to build a high-performing team, it’s important to take into account “soft” factors like existing relationships, personality profiles, working styles, etc., and put together people that you believe will be able to work together effectively.
• Seniority mix: it’s important to balance seniorities on the team correctly, so that you allow mutual learning, set the team up for success, balance different teams against each other, etc.
• Diversity: diverse teams perform better, so you should aim to make your product teams as diverse as possible. 

 
 
The role of formal reporting lines
 
While most of the work gets done in cross-functional product teams, there is also the functional element. In many product organizations, the formal reporting line is functional. In other words, engineers report to engineering managers, designers to design manager, and product managers to product directors or similar roles.
 
It’s important to understand that this formal reporting line does not mean that the functional managers engage in a command-and-control style management with their reports —the cross-functional teams are empowered and autonomous, and these teams are at the heart of the product development lifecycle. However, that doesn’t mean there is no role for functional leadership and management. To the contrary: autonomous and empowered teams don’t need less managing:
 
Empowering means creating an environment where people can own outcomes and not just tasks. This doesn’t mean less management; it means better management. It’s important for leaders to step back to create this space, while stepping in to remove impediments, clarify context, and provide guidance.
 
Functional coaching and development
 
Instead of telling their reports what to do, the key responsibility of the functional managers is developing their reports, for example through development plans, feedback, and coaching.
 
This functional aspect complements the natural learning and development that happens in the cross-functional team. Of course, product teams should practice continuous improvement, for example, by conducting regular retrospectives. However, there is a limit to the functional learning that can come from this kind of continuous improvement. For example, a designer is unlikely to “level up” in terms of information architecture or trends in UI design from retrospectives with their engineers and product manager. Coaching from a line manager who’s a more experienced designer is much more effective here.
 
Context and direction
 
The product direction needs to be as cross-functionally aligned as the implementation of it in product teams. In other words, at leadership level, alignment has to happen between the various functions (e.g., product management, engineering, design) before the direction is cascaded down to the product teams.
 
Functional line management still plays a role in the direction-setting though, in highlighting the specific aspects to the function to their reports and providing guidance and coaching on how to make the direction actionable.
 
Organization size and reporting structure
 
In smaller teams, there is also the model of the “player coach”, in which the team is led by one team member who splits their time between individual contributor work and team leadership. These player coaches are sometimes called “lead” (e.g., Design Lead or Engineering Lead) or specifically for product managers, Group Product Manager (GPM).
 
While the player coach model means not having to hire a dedicated manager (who is not “delivering” anything), it can also place a high workload on the player coach, since they are expected to deliver 100% in their product team and then also develop and lead the rest of the team. It might be better to have a dedicated manager who can pick up some small tasks to help out the product teams, but who isn’t part of a product team themselves.

---

Let me know what you think! 
DM me @philippemora on IG and Twitter
​My name's phil mora and I blog about the things I love: fitness, hacking work, tech and anything holistic. 
​
Head of Digital Product
thinker, doer, designer, coder, leader