Team structures and operating models
In September 2019 Uber laid off over 50% of its UX Research team, Manik Gupta — the Chief Product Officer of Uber at the time — said that Uber would rely more on experimentation to make tactical product decisions and the UX Research team would be more focused on strategic research projects.
There was a lot of uncertainty at the time as to how the UX Research team would restructure itself to support the demand for research and focus on strategic projects. In a previous article, I described a number of time management and prioritization principles for UX Researchers that helped identify what strategic research projects the team would focus on. In this article, I discuss how UX Research teams can be structured and how UX Researchers can deliver research, as well as briefly discuss the strengths and weaknesses of each approach.
Team Structures
The dedicated team structure is the way the UX Research team at Uber, and many other large tech companies, are structured. A UX Researcher is assigned to a particular feature/product team. For example, a UX Researcher working on the Uber Eats team may be assigned to the Delivery Experience team in the Courier product area.
This team structure allows a UX Researcher to become a subject matter expert and build relationships with the cross-functional team working on the feature/product. However, unless the UX Researcher is frequently reallocated to different teams — defeating the purpose of the dedicated team structure — a UX Researcher may not be working on the highest priority projects within the organization.
The agency or service team structure assigns a UX Researcher to a project, usually based on product/project priorities. For example, when I first joined Google in 2010 the UX team was centralized and I was assigned to the Chrome team, which did not have a UX Researcher at the time. I could have been reassigned to another team, like some of my colleagues were during the development of Google+, for example.
While this structure offers flexibility and an opportunity for a UX Researcher to work on the most important and a variety of projects, it means that feature/product teams do not have dedicated research support, and they may work with a number of different UX researchers, which can make it hard to establish rapport and trust.
The hybrid team structure is a middle ground between the dedicated and service team structures where a UX Researcher is assigned to projects within a product area. For example, a UX Researcher may be assigned to the Courier product area and work with different product teams depending on project priorities that would be determined in collaboration with the team leads in that product area.
While providing some degree of flexibility, it also means that UX Researchers can build up some domain expertise, work on the highest priority projects within that product area, and establish relationships with the team leads.
The primary-secondary team structure assigns a UX Researcher to multiple feature/product teams. Feature/product teams may be within the same product area or span multiple. For example, in 2014 Instagram had three product areas: Engagement, Growth, and Monetization. One of the UX Researchers on the team worked on Instagram Direct and New User Experience, which were teams within the Engagement and Growth product areas respectively.
This structure is usually adopted by smaller UX Research teams to maximize coverage. However, this structure often results in context switching which can be disruptive for both the product team and UX Researcher.
Operating Models
In addition to the team structure, there are a number of different possible operating models. In this section, I describe four ways that UX Researchers can execute research: the solo, pod, red army, and outsourced/vendor operating models.
The solo operating model is when a UX Researcher executes research themself. This is the operating model the UX Research team at Uber, and many other large tech companies have adopted. This results in a high degree of accountability and ownership but makes it difficult to collaborate with other UX Researchers.
The pod operating model is when there is a team of UX Researchers working together — one of whom is a lead. This model supports UX Research team collaboration while allowing the pod to work on more complex, large-scale UX research projects. Unfortunately, this model consumes a large number of UX Researchers on the team — as such the UX Research team needs to focus on the highest-priority, most strategic projects.
The red army operating model was pioneered by Google X. A UX Researcher plans user research studies that are then executed by a team of contract UX Researchers — contractors at Google have red badges, hence the name red army. This allows UX Researchers to scale their bandwidth and research expertise. Unfortunately, the research that can be executed is limited by the ability and skills of the contractors employed (e.g. Usability Testing). This can be mitigated by hiring multi-disciplinary teams of contractors, but their skill sets may not always be effectively utilized, although this is also true for specialist UX Researcher hired full-time. This model places a number of administrative tasks upon the UX Researcher (e.g. approving work hours), as well as management tasks, such as project prioritization and reviews.
The outsourced or vendor operating model is common in Market Research. A UX Researcher plans user research studies and then employs a research agency/vendor to execute the research. Unlike the red army operating model, the research agency/vendor can be selected on a per-project basis depending on the expertise needed. However, this is a costly and timely operating modeling.
The team structure and operating model for your team will depend on its size and how UX Research works with cross-functional partners. Furthermore, this will evolve over time depending on the needs of the organization.
At Uber, several UX Research teams adopted a hybrid team structure and pod operating model. This structure allowed the UX Researcher, to focus on the highest priority projects in a product area, and for UX Researchers to tackle large-scale, strategic projects collaboratively.
Is there a team structure or operating model I have not included? Do you have additional thoughts on the strengths and weaknesses of each of these team structures and operating models? Comment below!
