The concept of “healthy teams” is something I stole from the Engineering Org at Pluralsight before the Vista acquisition. Most people attribute healthy teams to buzzwords like “collaboration” or “psychological safety.” The people who had been a part of healthy teams know what it feels like, but they can’t distill it into a recipe. There is no recipe for culture.
I’ve told this story before but I was initially a team of 1 on the Search team, and in the next 3 years, we grew into a data platform with 5 engineering mobs. Those of us who have left often refer to the Discovery team as “THAT team.” I was very proud of the products that we built together, but I am far more proud of our culture, the invisible thread that connected us beyond our tenure at Pluralsight.
I’ve since reflected on how we work and what made us a healthy team. You can say that the team created all the norms on their own and I merely provided the space for them to do so. As we grew and evolved, I started to put words to the principles behind these norms.
Healthy teams design how they work together.
We own the culture we want to create. We can define norms to encourage reflection as humans and as a team. On our team, we are Lean. We are outcome and learning focused. We don’t follow recipes for recipe sake, agile for agile sake.
When I refer to “team” below, I don’t mean the engineering team, product team, or design team. Team is the collaboration vessel that holds all of the humans who strive towards something together. Designing how we want to work together is a way for the team to be intentional and accountable to each other for building healthy norms.
What it might look like:
1. The team workshops the Team Contract together. The contract may include: Values, Who we are, How we make decisions, How we resolve conflict, We are successful when … The contract is a part of the onboarding process.
2. Since new members have joined, the team came to an agreement about how they will handle outages.
3. The team set a rule that if they can’t agree to an approach, they time box the discussion then vote.
4. The Product Manager sets up time for the cross-functional team to build the roadmap together. The Product Manager creates a roadmap for external stakeholders and customers, and internal roadmap for the team to manage tasks and unpack epics.
5. Due to a re-org, new engineers join the Discovery team. The Engineering team meets to decide how it wants to organize and how the mobs will share data.
6. The team agrees that Design will join the mob when Engineering is ready to work on the frontend or fix accessibility issues.
Healthy teams have good research habits.
Everyone on the team should think like a researcher, because building products is about finding clarity from ambiguity. When we engage in discovery activities, we can ask better questions. When the team collaborates on defining an experiment, they have a shared understanding of the problem and they own the outcome together.
What it might look like:
1. Engineers conducting analysis on query data to understand problems to be solved for query understanding.
2. Engineering prototyping variations of how something might work to provide a path to clarity or propose a hypothesis.
3. Product and Design designs the research activity for the research question they want to ask or to define a path to clarity. There is a bigger world out there beyond usability testing. There are many flavors of Voice of the Customer.
4. The cross-functional team reviews design concepts and fills out the experiment template together. They debate on the rigor of the experiment.
5. Machine Learning conducting Bayesian relevance experiments.
Healthy teams get to a testable, measurable hypothesis ASAP.
I believe that the goal of every activity before implementation should be to arrive at a testable hypothesis ASAP. Qualitative research is a way to get better signals about a direction to get to a concise hypothesis. The reason why this creates a healthy team is because it gets everyone thinking about the drivers to an outcome, and shipping always provides more clarity.
What it might look like:
1. Product Managers and Designers try to articulate and refine the hypothesis and success metric during idea exploration.
2. The team hard codes a few high traffic pages with the feature to test the idea before investing in backend work.
3. The team kills features that gets very little usage to see if the KPI is at parity.
4. The team debates on the merits of the selected KPI defined by leaders as a baseline for a new experience.
Healthy teams build to learn.
The goal for building to learn is about being biased to action. Building or Making unleashes other associations and questions about the problem and help us see further down the path to clarity and identify unknown unknowns. If you hadn’t built it, you would never have thought of certain questions. Building is about showing, and showing is a lot more powerful than telling. The only caveat to building-to-learn is that the artifacts created should be quick, disposable, and preferably ugly, so that no one is attached to a beautiful useless thing.
What it might look like:
1. Bringing an ugly hacked functional prototype to a meeting to show trade offs in feasibility and functionality between options.
2. An R&D team builds a prototype of a machine assisted music synching video editor and disseminates it internally to gather feedback and see if it has legs.
3. Data Science prototypes a graph to show the relationships between entities.
4. Engineers from Search mobs with another team to help them provide the data model we need.
5. Designing and showing many “foils” or the wrong solutions to clarify the right solution.
Healthy teams create value / ship regularly.
Shipping is one of the key ingredients for continuous discovery. Shipping builds the muscle to learn from failures. Shipping by itself doesn’t have value, but shipping regularly with clear learning intent builds motivation and resilience in a team.
What it might look like:
1. The Search team delivers the first bare bones version of Search to gather data.
2. The team piecemeals the new information architecture by adding and testing Browsing components and recommendation iteratively.
3. The Relevance Squad continually ships and tests machine feature bets like personalization to improve relevance.
4. Instead of building out a whole new browsing experience for Certification, the team builds 3 experiences for the most popular segment of the market to test the idea.
5. The team ships topical recommendations to help learners explore topics. serendipitously while waiting for a taxonomy to be developed.
Healthy teams build systems over features
This is another way of saying, “Healthy teams are cognizant of tech debt,” or “Healthy teams don’t build experiences that are unscalable.” But this is beyond those two things. This is about skating to the puck vs chasing the puck. Good systems enable us to scale just in time. Good systems make redundant tasks easy. Good systems creates a holistic UX. Good systems have built-in governance and encourage good behavior. Good systems is the foundation of the platform flywheel.
What it looks like:
1. An experience that remembers what the user did across multiple touch points or contexts.
2. An experience that elegantly flexes based on different access and/or roles.
3. Adherence to data standards before content can be made discoverable or publishable.
4. Creating shorter content, quicker time to edit or update to feed the scale, freshness and ultimately content engagement loop.
5. Design patterns that maps to a coherent information architecture.
6. Investment in data architecture that anticipate scale or growth in the business.
7. Fewer redundancies.
8. Time allotted to work on tech debt.
9. Redundant tasks are automated.
Healthy teams are inclusive and help each other win
One of the things I often say is that I never expected to become a better human by leading. I find that advocating for others makes me better. It’s hard to advocate for myself, because I have my own demons and insecurities, but advocating for others is easy. When work is fulfilling, there are really 3 things that happen all at once: 1) We learn to work with others and we learn from each other; 2) We learn to solve problems better; 3) We become more self aware.
What it might look like:
1. Team members seek the input of members who are quiet.
2. Team members have the humility to admit when they are wrong or are blind to another’s context.
3. Team members seek divergent perspectives and foils to their own perspective to identify trade offs.
4. Team members assume the best intentions in each other and aren’t worried about being judged.
5. Each team member is an advocate and ambassador for the team.
6. The Product Manager knows to provide air cover and slack in the schedule when there is a complexity and ambiguity to set the team up for success.
7. The designer invites input from others, and knows how to frame them into assumptions and bets.
8. The team create norms to address friction.
9. The team has a strong sense of identity.
There are likely other attributes to a healthy team, but I picked these because I think they build fundamentals in critical thinking, alignment on the why behind good execution, and building self awareness. If this list sounds like I expect people to be good humans, who don’t assume they know everything, then you got the point.
