It is interesting how one’s professional maturity allows for different perspectives over the years. Reflecting on the past thirteen years, I realize how my standards have changed since I started in this business. Starting out, my product team standards were based on pure performance, supported by absolute metrics – more ‘output’ than ‘outcome’. Fast-forward to the present day, my standards lay heavily on holistic, empathic and value-driven approaches – quite a metamorphosis.
Over the last decade, I held the pleasure (and luck!) to work with amazingly talented people who built not only great products, but also great relationships that brought their teams to the next level. In some cases, I was on the front line as a team member and solo contributor (e.g. Developer, Business Analyst, Product Owner); in others, a supporting role ensuring a clear path for others to do their best work (e.g. Program Leader, Portfolio Director). No matter my specific role, working with these teams helped create my 360º view of what it takes to create and maintain a well-oiled product team.
For the sake of this analysis, I will focus on Agile teams, mainly using Scrum with software development. What I have learned constitutes universal principles that can be applied to any other software project methodology, regardless of unique circumstances or popular trends.
Let’s take a look at what product teams should pay attention to as they create teams that are not only a well-oiled machine in terms of “output”, but more critically able to produce meaningful and often mission-critical “outcomes”. Adhering to the following six key principles has served me well in creating truly high-performance product teams:
1. Foster Diversity
Regardless of the ecosystem, diversity is pivotal for success:
Diversity of gender
Ten years ago I was fortunate enough to participate in a team that had a near-even split of women and men. Even a mere decade ago, this was nearly unheard of. The “Women in Tech” movement was still waiting to reach critical mass and the effort to diversify, especially in tech, was in a nascent stage. The contribution these people made was significant and could and the ideas generated were more complete and creative.
Diversity of culture
I have worked on product teams that are co-located and where every team member is from the same country or region. I have also worked on teams that have team members from many cultures and regions. It is clear to me that having a diversity of culture and the increased breadth of experience and empathy that this brings, fosters radical innovation at velocity. Put simply, more great ideas and creative problem-solving in less time. Having a more homogenous team may facilitate the team members’ onboarding, and lead to a quicker project start. That advantage diminishes over the longer term, as you start to see patterns in how they approach problems, and how they think about solving them. This is in large part due to lifelong exposure to the same social phenomena, similar experiences, and similar values. With diverse cultures, you see how world-a-part backgrounds influence different narratives, which generates a positive clash of ideas.
Diversity of skill set
Multi-disciplinary teams bring better products to life. I’m not referring to adding a “Backend”,
“Frontend”, or “Fullstack” Developer into the mix. I’m talking about teams in which the customer and the end-user are engaged, bringing critical business knowledge which will ultimately underpin the key decisions and tough choices which are part of every project. This also builds on top of other capabilities that do not rely solely on development, such as Architecture, UX-UI Design, Business Analysis, Quality Assurance, Copywriting, etc.
Diversity of behavior
Outspoken people often clash with introverts, the same way reactive and enthusiastic people often struggle working with those who are reserved and patient or vice versa. I believe these differences, and the resulting very different approaches and discordance they bring to problem-solving, are great! They bring the team out of their comfort zone. When this happens, it plants the seed to understanding conflicting viewpoints and perspectives. Taking full advantage of this positive group dynamic takes leadership and a reasonable degree of willingness to be open from the team. After a while, teams look for a balanced state in which they understand the benefit of “disagree and commit”, which leads to better critical thinking.
Diversity of business experience
Working all of your life in a single vertical or industry has its advantages, but too much time in the same industry can inhibit out-of-the-box thinking and cross-pollination from one business model to another. On a personal note, I feel strongly that having worked in several industries (Telco, Bank, Insurance, and Autotech) has given me a degree of mental elasticity that allows me to promote better digital solutions and robust design thinking.
2. Treat Seniority As An Enabler
In an ideal world, if you could assemble a product team with no limitation on resources, would you pick junior people or more senior people? If you want faster results, you might be inclined to secure the most experienced senior team money can buy. Whatever their area, senior professionals bring judgment, knowledge, experience, and confidence. In the real world, we know it is close to impossible and very expensive to create such a team. (Yes, not even Tesla or Apple have them all of the time). Teams across the globe purposefully have a range of seniority from junior, mid-level to senior to maximize proficiency. While there is a correlation between seniority and proficiency it is far wiser to measure proficiency independently and look for the specific skills and competencies required for the project.
That said, it is best to find well-rounded team members that possess the soft and hard skills one expects from a strong contributor. Context frames the output, but the outcome may result from different competencies. From a proficiency standpoint, it is expected the professional to:
- Master technical skills by being a reference in the domain
- Exhibit strong autonomy while performing tasks without close supervision
- Possess great soft skills like persuasive communication, critical thinking, and problem-solving to engage others efficiently and achieve better solutions
- Be emotionally intelligent so that empathy can be used to create a better work experience
- Share acquired knowledge to enable lift the skills of the entire team
- Understand the value of sensing, probing, and adapting responses in the presence of complexity knowing well that there is no silver bullet for solving tough problems
- Mentor/coach junior team members, with less proficiency, so they grow (when one teaches, two learn)
So when someone asks me what skills and qualities a senior professional should possess, I answer with the bulleted points above. It is expected that less senior team members are still learning, exploring, and maturing these attributes. Well-oiled product teams understand this difference and leverage their senior professionals to build better products and build better people.
3. Foster Open Communication
On the surface, open communication is like Mom and apple pie. Everyone loves them and everyone talks- the-talk about their value. Much more rare, is the team that operationalizes this best practice consistently.
By problems, I do not mean business or product problems the team discusses in refinement sessions. I’m talking about internal and external issues that create friction between people or lead them to a demotivated, lethargic state. I know frameworks like Scrum create dedicated events to address those — like a Scrum Retrospective — but people usually hold back on providing honest and concrete feedback. This is a well understood and very human reaction, especially among conflict averse cultures and personalities. It is not so much a function of introversion or extroversion. It is a function of the group psychological safety and trust that is established. There has been much written on the techniques and practices that help create the positive group dynamics that lead to open communication. Despite the recognized importance of doing so, far too many leaders and team members focus strictly on tasks. In doing so they often ignore the key relationship and human issues that contribute much more to creating high-performance product teams.
4. Embrace Uncertainty And Ambiguity
“How innovative would your product or solution be if you knew every challenge you would have, every decision you would need to make, and had complete and perfect information at every turn before you started?
A powerful question and an interesting thought experiment. If any product team knew from the start, ‘Why,’ ‘What’ and ‘How’ they need to build their product, we would not need agile frameworks to cope with the absolute reality of uncertainty and complexity. But ignore the principles of VUCA, and ignore how it plays a part in every human endeavor, and you are ignoring the reality of modern software development. Creating certainty was what waterfall was all about; Sequential, linear, and serial, it assumed that all requirements are known beforehand and would not change over the span of the project. The beauty of Agile in such design and development approaches is to have continuous inspection and adaptation that helps ensure the team is always focused on the maximum value delivery. A well-oiled product team embraces unclear and unforeseen demands because they know there’s a chance that the next-in-line request may generate a better solution overall.
5. Create A Bias For Action
If well-oiled product teams had to choose an anthem, it would undoubtedly be “A little less conversation, a little more action, please” from King Elvis. Overthinking topics or exploring options ad infinitum creates confusion, unmanageable complexity, and wasted time-to-market opportunities. A high-performing product team copes well with little information but knows when they have just enough to start drafting solutions and submitting them to customers and stakeholders scrutiny. Pareto’s 80–20 Law serves the team’s argument since the full commitment of finding a perfect solution creates a complex network of dependencies, discussions, and misunderstandings that usually lead to inaction.
Meaning, 20% of your original effort usually yields 80% of your results. 80% is already a fair percentage of the solution’s value, considering the team’s original commitment. Going the extra mile looking for that final 20 % of results usually does not justify the investment. So it’s clear why these teams make everything actionable: focused effort and necessarily limited resources looking for a faster return on investment and powerful outcomes.
6. Promote A Full Stack Mindset
Specialized teams are different from teams with specialized team members. It is not uncommon to have team members with very different skills or specializations. This can lead to a single individual having key information. When multiplied across the team this high degree of specialization can lead to silos of knowledge about the product design and build. Here are some real-life scenarios of under-performing Scrum teams. Names and identities omitted to protect innocent…and the guilty!
Scenario #1 (Enter here a stressful moment):
- Developer X: “Production is down! We need a quick-fix on the front-end component!”
- Developer Y: “Well… Developer ‘Z’, our Frontend specialist, is absent today… We have 2 options: let’s all dive deep into product documentation and Google for answers, or let’s wait for him to come back tomorrow…”
Scenario #2 (Enter here a Scrum Refinement moment):
- Developer A: “To avoid future technical debt, I truly believe this business logic should be implemented on the backend side. What do you think?”
- Developer B: “I have no idea about what happens on the backend…”
- Developer C: “Me neither… Cannot support a decision like that.”
These are simplified but very real scenarios. They make clear the risk one runs when executing with a team of overly specialized team members that lack cross-skilling and a broader view of product development. We don’t want a Backend Engineer to deep dive on Frontend topics and create a new skill set. We want her to learn the basics from other colleagues. Hence, she’s able to: 1) contribute to issues in a more thoughtful and valuable way, and; 2) build a sense of belonging since their product is not just backend or frontend — it’s the sum of all its parts, which all the members should be acquainted, so they may better react and plan for product growth.
I do not advocate creating more specialization. Nor do I advocate that everyone on a product team should be a generalist. I have found that to create truly high performing, outcome oriented, agile teams one should look for a ‘T-shape’ professional, one with a strong core on a given competence and solid knowledge in the domains of his teammates.
I understand how writing about principles and best practices is not the same as executing them in the real world. In future blogs, I will address some of the real-world challenges of following the six key principles I outlined, and how to overcome them. It is a journey, not a destination. It is a dialog, not a monologue. I look forward to continuing both with you.
