Anti-Patterns for Product Team Structure

As the industry resizes, Leadership should be careful not to undermine the engine of innovation in their departments: Product teams. During reorganizations teams will be shrunk, stretched, and assigned new mandates. As that happens teams can easily be crippled, thwarting Leader’s plans for improved efficiency.

The perfect team structure is an elusive goal. When resource limitations meet an ambitious plan, the painful result is often teams designed with clear anti-patterns. Leaders would do well to keep an eye out for these tempting but doomed models.

The Solo Engineer

Wanting to do many things at once, organizations will sometimes spread engineering so thin that a project may only have one engineer. In theory having a single person directly responsible for something should work (as it does with DRI’s in project management). With less process, velocity is often great in the beginning. However, every time I have seen this done it blows up by the end of the quarter. 

A productive engineering team has frequent debates about how to build. In a diverse team of several engineers and various other functions multiple perspectives lead to a better outcome. On a team of one the engineer is often left building something for the first time, without oversight, and is likely to paint themselves into a corner.

Code reviews almost always get skipped. Sometimes this can be accomplished by looping in an external engineer, but that creates its own set of problems (see below). All else equal, quality will be lower without reviews. 

Most importantly, when only one engineer has knowledge of the code base, and that engineer leaves or goes on PTO, fixing even a trivial bug becomes a major project as the new engineer (who is inevitably pulled off of some other high priority project) has a cold start.

A better solution is to have fewer, larger product teams of at least two engineers, and give them a bigger mandate. These teams can either sequence projects, or if several things need to be done in parallel individual engineers can rotate to ensure there are always multiple people who know every part of the codebase.

One exception is building a proof of concept (POC). POC’s are not intended to be durable, production worthy code. 

Fickle Mandates

Changes to headcount often necessitate changes to a product team’s roadmap, but if core team mandates change too frequently then the team never has a chance to reach their full potential. Ideally, a mandate is a distinct and durable business area where performance can be measured quantitatively. Responsibility for the corresponding code base usually goes with that.

It takes time for Product and Engineering to fully grok a new mandate. The first few weeks are often limited to obvious, low risk wins while building stakeholder trust, setting up metrics, and interviewing users. Only after Product has a handle on the opportunities and Engineering has ramped up on the codebase does the strategy come together and can the team move towards higher risk, and higher impact features. It can be three to six months before a team hits full potential. If a team’s mandates are changing within that time period, then productivity is limited. 

Leaders can minimize thrash by having a plan for how their departments scale up and scale down. A scalable org structure can allow you to keep core team members on a topic should a team need to divide (scale up), or consolidate with other teams (scale down). Onboarding a few new members is vastly easier than reassigning the entire team. 

Moving PM’s in & out of teams is a bit trickier than moving Engineers. PM’s are typically solo and do not have the benefit of functional peers inside the team. Moves can be easier if the PM is absorbing an adjacent space because knowing what is going on at the edge of a team’s mandate is part of the PM’s job.

Another good way to reduce thrash is to create fewer teams with larger mandates. Mandates are a tool for leadership to allocate resources to a business area. Within a given department and headcount, more teams mean narrower mandates, which are inevitably more subject to change. Larger teams with broader mandates tend to be more durable because the team has more latitude to determine what it will work on.

That said, companies need to be able to respond when things come up and sometimes that means pulling resources to form a new team outside of the ideal cadence. These ad hoc groups can be remarkably productive, especially if the problem and solution are well defined in advance. There is a balance between responding quickly and killing output by doing a reorg every quarter.

Multiple Backlogs

Another common but misguided response to limited resources is to assign an Engineer to multiple backlogs. This can be the result of having too many Product Managers creating too many projects, or the org can be trying to maximize the output of a talented Engineer. Either way, it ends in tears.

Often the Engineer ends up doing double the sprint ceremonies, reducing the time they get to code and increasing interruptions. Worst of all they end up with competing priorities, inevitably disappointing at least one manager at all times. Each backlog will have its own P1, but having two backlogs sucks the engineer into prioritizing… priorities. The function of the backlog is to resolve prioritization issues so that engineers can focus. Ask an Engineer to work off two backlogs and all the benefit of that process goes out the window.

Not only does output tank, but because engineering and product cannot count on a consistent level of effort on either backlog, tracking velocity is even more difficult than normal, and no one can give a good answer to when anything will be done. 

Like many organizational problems, juggling backlogs often comes from trying to do too much at once. The best way to avoid this is to do projects sequentially rather than trying to parallelize. Sometimes that is the result of too many PM’s, each advocating for their project to be done now. If that is happening, consider having two PM’s (ideally an APM and Sr.PM) collaborate on the same backlog, or rebalancing your teams.

Missing Functions

If a product team is frequently blocked because a critical external resource is unavailable, then the team is incomplete. As heads roll, teams can easily lose a key function and find themselves unable to ship at an acceptable cadence.

Having to go outside of the team for a resource creates a similar issue to working off of multiple backlogs. External resources are on a different cadence, which means requests will often have to wait until the resource frees up. More importantly, because they are not present for team ceremonies, the resource will not have the same context as everyone else. 

What constitutes the right composition for a team varies widely. On the small end, I have seen productive teams consisting of just two engineers working without a PM. On the larger end, I have seen teams with multiple PM’s, User Researchers, UX Designers, Data Science, Analysts, Copywriters, and a vast range of engineering skill sets. Leaders should know what functions are necessary for each team to fulfill its mandate, and ensure that each of those functions is present on the team. 

If the team is frequently having to assign tickets to someone who is not fully allocated to that team, you know there is a resource missing.

The most common mitigation is to have functional groups like Analytics, Research, or Design, float resources to Product teams as needed. However, because these external resources juggle multiple backlogs, and lack the context of dedicated team members, this setup hobbles the team if they depend on it regularly. Alternatively, when a Product team needs deep expertise in a functional area temporarily, the multiple backlog issue can be solved by fully dedicating the resource to the team for a sprint or two. Giving someone external ownership of a ticket should be a last resort.

Another way to resolve a missing function on a team is to have an existing team member take it on. PM’s and Front End Engineers can often stretch into design, particularly if there is a strong style guide and or a low bar for graphics. Every PM should be able to stretch into Analyst, Copywriter, and User Researcher. Everyone can do QA. Leaders can push this too far, and for Product at least, this is where we often hit a wall. The benefit of using this approach is that the team can operate independently, which is a good indicator of a functional product team.

—

Thanks to Kalv Sandhu for reading drafts of this post.