Trust is the cornerstone of any successful team, playing a crucial role in fostering equal power dynamics among its members. When team members feel secure in their relationships, open communication flourishes, allowing for diverse ideas and perspectives to emerge. This not only enhances collaboration but also promotes a culture of respect and inclusivity, where everyone feels valued and empowered to contribute. In this blog post, we will explore the significance of trust in building strong teams that strive for balance and equality in their decision-making processes.
What is a Balanced Team?
“A team management philosophy that has people with a variety of skills and perspectives that support each other towards a shared goal.” – balancedteam.org
“Balanced” teams are necessary in a healthy, collaborative agile product environment. They thrive on trust in each other’s expertise and autonomous delivery of the product or problem statement. One person cannot possibly have all the information needed to make decisions for a product, however through shared responsibilities, if the 3 roles take responsibility and accountability together the outcome becomes collaborative, efficient, productive, happy teams.
Through balanced decision making and balanced power dynamics, the group minimizes siloed work within a discipline and handoffs between disciplines are focused on collaboration and good communication, throughout the full product development lifecycle. This is because consistent communication allows us to move at a faster pace, reducing time wasted in writing emails, creating nonessential documentation that goes unread, and attending unnecessary meetings.
Developing software is a risky endeavor full of unknowns. Is the product viable? Is it desirable? Is it feasible? How can we answer these questions without taking months or years to get something shipped? Enter the Balanced Team and the magic of interdisciplinary work. While developers, designers, and product managers can do great work alone, magic happens when these roles work together to break through constraints–or innovate around them.
The typical balanced team mix for product development is a product manager, product designer, and engineer(s) dedicated to a single product development effort, typically a pod. This is in contrast to another common team structure where some roles, such as product management and design, are shared across many product efforts.
When we work within the construct of a balanced team, we ensure that all these perspectives blend and inform each other so that we build products that are desirable, usable, feasible, and viable. Not only that, but a Balanced Team structure has no central point of failure because everyone is aware of the same information (risk, strategy, etc). There is also less risk of bad actors that stay on a team for a long time and can erode psychological safety.
Balanced product development teams are:
- Small enough to be fed by two pizzas as pioneered by Amazon
- Multidisciplinary
- Organized around goals established by the product sponsor(s).
- Empowered to define and iterate on solutions that deliver against those goals.
- Empowered to talk to customers, make product decisions, and push code to production.
The transition to balanced teams from other previous methods of x-functional decision-making
There’s definitely a transition period when coming up against norms from former experiences and transitioning into a Balanced Team methodology. Takes time to transition, detox from more hierarchical expectations, and get into a flow of how this new way of working really… works! Sometimes it’ll come in phases when people first see the framework: first they just stay in their own lane, before they really start to co-locate and x-pollinate ideas as much as possible (example: eng not being interested in hearing outcomes of user research —> to joining user interviews for context on the solutions they’re building).
Oftentimes, new practitioners to Balanced Team find this new way of working much healthier and more sustainable because effort and responsibility doesn’t fall to one individual: collective, shared ownership and responsibility actually works! It might take you a while to adjust to Balanced Team, if it’s a new practice to you, but keep an open mind to see what’s possible.
No one likes fighting for authority or even trying to figure out who has decision-making power and who doesn’t. Effective, balanced teams break down authoritarian structures and really come together to work toward building a better product in an autonomous way within an organization.
🤤 Desirable: Does it solve our users’ problems?
The product should be something that users want and that solves real problems. A designer’s primary question is, “How is the user affected?” Designers and UX Research are mostly focused on helping the team answer these fundamental questions: “Is this an important problem to users?” and, “Does this design solve the problem?”
🏭 Viable: Can we monetize this to benefit our business?
The product has to support a sustainable business model. The product manager’s primary question is, “By solving these specific user problems with these specific solutions, are we creating valuable user and business outcomes?”
⚙️ Feasible: How complex is it to build?
Product implementation has to be feasible and robust. Engineers’ primary question is, “What technical implementation will satisfy the project and product goals best?” Engineers help us debate the feasibility and merit of potential solutions while remaining mindful of technology constraints.
Who is a part of a Balanced Team?
The following are the most common roles you will see on a balanced team for product development. However, your team’s roles may differ slightly depending on your product.
| Role | Description |
| Engineering | Engineers implement product functionality, working from a prioritized backlog of user stories. Engineers guide the implementation and help you understand the technical implications of product decisions. You will help them gain an understanding of what product success looks like. You will work together to validate your backlog’s prioritization. |
| Product Management | Leads a team to discover and deliver a product that creates meaningful value for their company and users. They facilitate decision-making in service of shipping successful features. To do so, product managers need to clearly understand who your users are and what they need, what impact the business expects from the product, and who your stakeholders are. They also need to collaborate closely with your team. |
| Product Design & UX Research | Deliver value in the form of User Experience Design decisions. Their job is to deeply understand the users in order to define solutions that are desirable, useful, and usable. Product managers work closely with designers, pairing on user research to validate critical user and solution assumptions before adding development work to the backlog. |
How is this a method for decision-making?
The following are the most common roles you will see on a balanced team for product development. However, your team’s roles may differ slightly depending on your product.
| Benefit | Description |
|---|---|
| Faster cross-functional alignment | Having a balanced team dedicated to a product and highly collaborative during product development allows for rapid context sharing and fewer meetings. The different disciplines can break out of their siloed domains and create more room for compromise and collaboration. |
| Team agility | Shared product knowledge on the team across disciplines allows the team to not get blocked when a team member isn’t present. Creates more flexibility for team members to rotate to other teams and easily onboard new members and establishes a culture of trust and team agility. |
| X-functional appreciation | Working closely together with balanced power dynamics between practices, creates a culture of empathy and respect for other practitioners. Example: Designers can more easily understand technical constraints the more time they spend with engineers and can incorporate those learnings into future design concepts. |
| Efficiency | Having cross discipline balanced team members like a Product Designer and a Developer pair with each other to review UI implementations together allows for much less documentation like requirements and design specification. |
What are individual role responsibilities?
🤖 Engineering
“Raise high the roof-beams”
Envision the best possible solution, based on available technology. Commit to the customer outcome. Facilitate balance within the team. Measure outcomes over time.
Common narratives and preconceptions about Engineers
There are three primary preconceptions and narratives relayed about engineers, including:
- Engineers don’t care about the “why” behind the product they are building; they simply want to know what it is and how to build it
- Engineers want to be left alone to code, and aren’t interested in learning about the end-to-end process associated with building a great product
- Engineers are not strategic – they are best utilized for implementation, and don’t need to be included in the product strategy and planning phases of product development
When Engineers are placed in this box, or operate in accordance with these misconceptions, organizations miss opportunities to build exceptional products. Instead, knowledge of the code base lies with one or a select few, rather than relying on group wisdom and shared knowledge to develop the best product.
Balanced teams means healthy tension and dialogue around what problems to solve for customers, how the product will impact the business, and what is most feasible to build, and this can only be accomplished by having each part of a balanced team involved across critical phases of the product development lifecycle. It is not beneficial for engineers to be order takers. Effective Engineering teams increase operational efficiency in the product development lifecycle by being active participants across the product development process and offering alternative solutions that are more feasible (or cheaper) if they know them to be available.
🎨 Product Design
“Empathizer in Chief”
Understand the customer at an expert level. Translate high-value needs into the product. Hones craft. Facilitates balance within the team. Speaks to the team on customer problems or new opportunities and represents the customer voice to the rest of the agile development pod.
Common narratives and preconceptions about Product Designers and UX Researchers
The following preconceptions and narratives are commonly referenced in relation to Design and UX Research:
- Design and UX research activities are time consuming and slow down product development
- Scope tends to expand based on Design and UX research recommendations
- Designers and Researchers are too idealistic, often creating designs that are not feasible or easy to build, and missing the importance of building solutions that deliver a real return on investment for the business
- UX Research stifles the experimentation and creativity of Engineers
Ineffective Designers and UX Researchers operate in siloes, viewing themselves as the only source of innovation within the team and the sole gatekeepers of user needs. Effective Designers and UX Researchers recognize their role and limitations within the product development lifecycle, offering key insights around user needs, while also understanding and balancing the importance of generating revenue for the company.
🗄️ Product Management
“Scales of Justice”
Makes fast concrete decisions despite inadequate evidence & conflicting priorities. Identify the business value in customer needs. Act in service to the team. Delegate decisions to the appropriate person.
Common narratives and preconceptions about Product Managers
Similar to Engineers and Designers/Researchers, Product Managers are often seen through a narrow lens, and have been characterized as:
- Bureaucratic: Engineers and Designers/Researchers may view PMs as bureaucratic – putting unnecessary process, meetings, deadlines, and documentation in place that minimize UX Research, take engineers away from coding, and slow down product development
- Imbalanced in decision-making: With a primary focus on prioritization of business needs, PMs may make decisions based on a desire to quickly ship products, or their assumptions/ narrow understanding of user needs, leaving little room for research, experimentation, and exploration.
- Product Management as CEO of the product (or product area) puts the PM in a position to be a single point of failure on a team. Accountability should be shared within and across teams rather than sitting disproportionately within one role.
When PMs operate in the manner noted above, products don’t meet their full potential as this behavior drowns out the expertise and shared ownership of Engineers and Designers/Researchers. Ineffective PMs become too focused on the business and leave little space to connect with users which ultimately leads to products being built that don’t solve any real needs and thus don’t get used. In a balanced team, PMs understand their strengths and limitations in the product development process, and involve Engineers and Designers/Researchers in the development of product strategy and solutions at key milestones across the product development lifecycle.
Closing thoughts
Let us share responsibility for delivering user value and share our knowledge. A feature is not done when it’s delivered or deployed or pushed to production, it’s done when someone gets a job done using said feature. So if you’re making a payment app, getting paid quickly and efficiently is everyone’s thing. And designers know that it’s those overlaps, the connective tissue that makes or breaks the experience. Developers are driving toward getting more code in front the eyes of users.
Everyone should be able to call out “that’s a weird interaction…” Everybody understands the business value, the user value and the importance. Ergo no more fighting over how subtly flat the submit button should be. All that is a waste of our valuable time together anyway.
References & further reading on balanced teams
- FORBES – Five Reasons Why Balanced Teams Are So Important
- Clean Escalations play from Atlassian
- Balanced Team, main website
- Why Balanced Teams work better together, by Pam Dineva
- Making Magic with Balanced Teams, by Becki Hyde (Video)
Idealis Design 