For years, the common practice in software and digital product development has been to organize teams by speciality. However, in recent times, there has been a growing tendency to organize work into multidisciplinary teams.
In the past, separate teams were established for development, design, analysis, QA, project management, systems, business intelligence, etc. As software development became increasingly complex, these teams could be further subdivided into more specialized tasks, such as frontend and backend within development teams, or research and UI in design.
In many contexts, this specialized organization is falling into disuse in favour of multidisciplinary teams, where individuals with diverse skills and specialities collaborate to achieve a common goal. Thanks largely to the popularization of iterative and incremental methodologies, this new organizational form has proven more effective in adapting to today’s ever-changing world.
What are the benefits of working in multidisciplinary teams?
By aligning with a common goal and having the necessary capabilities to influence any stage of an organization’s value stream, teams can operate and achieve results more effectively.
By value stream, I refer to the concept of lean manufacturing: the series of steps necessary for an initiative to advance from conception to the realization of its value impact. In the context of digital product creation, this involves the journey from identifying the opportunity or problem to delivering the solution to users, enabling us to observe its effects.
Instead, hand-offs between teams occur when multiple teams are involved in the value delivery stream. This process tends to be more problematic and inefficient, as each team may have very different and conflicting goals.
Hand-offs often create extra bureaucracy between teams. The effort needed to implement changes increases in the case of errors or fixes. They can lead to longer wait times, disputes over where each team’s responsibilities begin or end, attempts to reach a definitive solution from the outset, and a lack of clear ownership of the initiative, among other issues.
A team can make decisions and iterate much faster when it is multi-disciplinary and empowered.
Collaborating in multidisciplinary teams can result in greater job satisfaction among team members as an added benefit. This, along with cooperation among individuals with varied skills, nurtures improved creativity centred on reaching a common goal.
However, it is essential to remember that a multidisciplinary team is not merely formed by assembling individuals with diverse profiles and hoping it will function seamlessly. Multidisciplinary teams may use organizational patterns by specialty and they may not be genuinely aligned, leading to potential hand-offs. In these instances, the same issues arise again, albeit on a smaller scale.
We can and should work on this at three levels: at the individual level, at the team level and at the organizational level.
Individual level
At the individual level, we should comprehend the various roles involved in creating digital products. While it is not essential to know every detail, it is important to have at least a basic overview of other roles: their typical motivations and incentives, the practices they employ, and the processes and tools they utilize in their daily work, among other aspects. This understanding fosters a more empathetic and harmonious daily relationship with the rest of the team.
For example, what topics should someone in development study to better collaborate with designers? Some examples are usability, information architecture, research methods, colour psychology, accessibility, typography, interaction design, prototyping, copywriting and user-centric design techniques.
What about a designer who wishes to collaborate more effectively with developers? Software architecture, technical debt management, automated testing, and other continuous integration and delivery practices, web standards, component-oriented design, etc.
Moreover, the terms product designer and product engineer or developer have emerged in recent years. If we delve a bit deeper into these terms, moving beyond a mere fashion statement, they encourage greater engagement and collaboration with product management roles, as these roles collectively share responsibilities related to the team’s impact.
This means that at some point, each individual in their speciality area may find that some responsibilities are blurred across the entire product team. To reach that point, all roles need to train themselves on issues far beyond pixel-perfect designs and clean code: gaining a more strategic point of view and working with data to improve decision-making.
Team level
Alongside good individual intentions, where each person strives to be empathetic towards others, we, as a group of multidisciplinary individuals, must form a cohesive team.
It is essential to align towards a common goal, ensuring it is specific. Without delving into various methodologies that can be employed, the attainment of the goal, if feasible, should rely on quantitative or qualitative data, establishing one or more metrics to determine if we are making progress towards it. While context may not always allow for this, having an easily accessible dashboard for the entire team is ideal. If that is not possible, at the very least, data should be collected, and metrics reviewed collectively on a regular basis to assess whether we are on track or need to iterate to adjust our course.
While not everyone on a team is necessarily required to be involved at the same level in every activity, different roles should participate throughout the entire process, from discovery to delivery, and in certain contexts, even in the launch strategy.
It is important for the team to be represented in the problem or opportunity analysis phase done in the organization as early as possible, as well as in the research exercises conducted. This may include conducting joint interviews with key stakeholders, engaging in quantitative analyses based on data alongside qualitative analyses through shadowing, and participating in focus groups or user interviews, among other activities.
By collaboratively devising high-level solutions, various roles contribute their expertise, aiming to identify outcomes that are viable from a business perspective, feasible to construct from a technical standpoint, and desirable to customers or users. To achieve this, we can conduct prior experiments to gain insights into the different aspects where we aim to mitigate uncertainty: proof of concepts or technical prototypes, qualitative tests with users, quantitative A/B testing, and so forth. This approach safeguards investment while enhancing our learnings.
Communication between individuals is the most complex aspect of software development.
Therefore, in addition to fostering active communication, we should develop a ubiquitous language within the context of the product domain in question, both among the team and with other stakeholders. We must avoid using different or inaccurately specific terms in our conversations and various written documentation; this encompasses UI design artefacts as well as the source code itself. Furthermore, we can create a glossary to make this language more explicit.
To enhance communication and collaboration between design and development roles, we can employ various practices.
For instance, investing effort in creating and maintaining a design system fosters products with greater visual and interaction consistency. This approach enhances the efficiency of the team that utilizes it, eliminating the need to reinvent the wheel and facilitating communication within the team itself. It is common to have a UI Kit for design and component libraries for development surrounding the design system.
“A set of connected patterns and shared practices, coherently organized to serve the purposes of a digital product” (Alla Kholmatova, Design Systems).
We can enhance it by employing design tokens, which serve as the atoms upon which a design system is constructed: colours, fonts, iconography, spacing, and so forth, accompanied by a nomenclature that grants them meaning based on their application. This promotes the consistency and maintainability of visual designs, allowing for the implementation of mechanisms to synchronize UI kits and component libraries.
Another way to facilitate collaboration to minimize the feedback cycle as much as possible is to employ practices framed under what has begun to be popularized as The Hot Potato Process in some circles:
Perform pair-design alongside development roles, whether sketching on paper or using a design tool on a high-fidelity UI. The idea behind this is that feasibility and desirability are considered, early assuming trade-offs from one side or the other, if necessary.
Frequent reviews of UI design advancements by developer, whether synchronously or asynchronously. We often make the mistake of striving for overly tight and comprehensive UI designs, leading to increased effort and friction between roles when changes occur.
Frequent product reviews by the designers. As the software is developed and after confirming its functional correctness through both automatic and manual testing conducted by the development team, designers ensure that the implementation of the UI aligns with the agreements established in the high-fidelity UI design. Although not yet widely adopted, tools for automating visual testing have begun to surface. In such instances, these reviews will tend to be less rigorous or more exploratory in nature.
“I’ve seen designers and developers often fall victim to is believing that handoff goes one way. Designers hand off comps to developers and think their work is done. That puts a lot of pressure on the designer to get everything perfect in one pass” (Dan Mall, The Hot Potato Process).
All this should always be accompanied by a spirit of continuous improvement, which may occasionally relate to individualities. However, we should generally view it through the lens of being a multidisciplinary team.
A powerful practice for this is conducting regular team retrospectives. If we use an iteration-based methodology, we can ensure that there is always one session per iteration, or if we adopt a methodology without iterations, we can schedule a recurring session every few weeks. The key point is to have a moment of collective reflection, allowing the team to leave with a series of actionable steps for improvement, which will be followed up in future retrospectives.
Another practice that is similar, yet distinct from having a recurring nature, is postmortems. These occur when a special event takes place, prompting us to conduct an in-depth analysis of what happened, what was done well to add value, and what could be improved upon. Postmortems may arise from some negative situation that has affected the team, such as an incident that has had a detrimental impact on our customers, or we might simply wish to evaluate how we could have performed better regarding an initiative or project we have undertaken as a team.
When we implement any of these practices, we should endeavour to create psychologically safe spaces for the participants, avoiding blame and approaching the issue more systemically. Once we have completed the process, we should identify concrete actions and accountable individuals to drive those actions forward. It is best practice to document these in writing, as this clarifies the actions, provides a historical record, and enhances transparency both within the team and externally, if we choose to make it accessible to the rest of the organization.
Organization level
To ensure alignment among multi-disciplinary teams, leaders at the organization level should provide a vision and mission to be shared throughout. Additionally, high-level strategy and objectives should be established. Ideally, the latter should be data-driven and readily accessible to everyone in the organization.
A team structure should be established that considers the cognitive load and strategy of the organization. Each team should have a defined scope of action with clear objectives that establish a shared goal. It is essential to balance this with the avoidance of knowledge silos and excessive tunnel vision within teams, while also ensuring that team members possess the necessary skills to navigate towards successful outcomes, whether through hiring, training, courses, or mentoring.
In this team structuring, there may be more specialized or transversal team typologies, without directly impacting the value stream. In fact, in organizations of a particular scale, they are often quite necessary. The purpose of these may be to enable multi-disciplinary teams in some way, temporarily assisting or training them; or to facilitate their work by establishing a platform in the form of processes, documentation, or tools that reduce cognitive load and friction in the value stream that multi-disciplinary teams may experience.
Continuous improvement should also take place within the organizational structure. However, those responsible for the organization must assist teams in settling in, providing them with stability and continuity. People working in a group need encouragement to become a team, and it takes time to observe the impact.
Conclusion
In digital projects or product development, multi-disciplinary teams will remain a trend due to their superior adaptability to today’s changing environment. For these teams to function effectively, we must engage with them personally, collaborate with the rest of the team, and address issues at the organizational level.
And essentially, at any level, we need to look for three factors:
Aim to align the team with a shared goal, just as their objective aligns with that of the organization goals.
Try to make the individual capability set viable to achieve that goal or at least be able to be trained to do so.
Try always to have respect and empathy between the people on the team and the rest of the organization you interact with.
Yes, factors infinitely easier to verbalize than to achieve.
References
POPPENDIECK, Mary; POPPENDIECK, Tom (2013). The Lean Mindset: Ask the Right Questions. O’Reilly.
TORRES, Teresa (2024). «Product Trios: What They Are, Why They Matter, andHow to Get Started». Product talk [online]. Available at: https://www.producttalk.org/2024/06/product-trios/
SUTILO, Abel (2018). «Diseñadores desarrolladores y viceversa». Slideshare [online]. Available at: : https://es.slideshare.net/slideshow/disenadores-desarrolladores-y-viceversa/104855167
ANSIO, Carmen; BARRIOS, María (s.d.). «Desarrollo y diseño: todas a unafuenteovejuna». YouTube [online]. Available at: https://www.youtube.com/watch?v=sGJSUfQuQXg
KHOLMATOVA, Alla (s.d.). «Meet “Design Systems”, A New Smashing Book». Smashing Mazazine [online]. Available at: https://www.smashingmagazine.com/design-systems-book/
BUSQUETS, Cris (s.d.). «Design Tokens: qué son, ventajas y cómo diseñarlos eimplementarlos». Ui from mars [online]. Available at: https://www.uifrommars.com/design-tokens-que-son-ventajas/
MALL, Dan (2019). «The Hot Potato Process». Danmall.com [online]. Available at: https://danmall.com/posts/hot-potato-process/
PAIS, Manuel; SKELTON, Matthew (2019). «Team Topologies: organizing businessand technology teams for fast flow». Team topologies [online]. Available at: https://teamtopologies.com/book
Recommended citation: LATORRE, Dani. Multidisciplinary digital product development teams. Mosaic [online], January 2025, no. 202. ISSN: 1696-3296. DOI: https://doi.org/10.7238/m.n202.2410
Deja un comentario