Google's team effectiveness research offers monday.com a practical lesson

Psychological safety is a delivery tool, not a culture slogan

Google’s re:Work guide makes a blunt point that matters inside any software company: the team is where innovation happens, but also where unclear goals, mismatched skills, and interpersonal friction can slow work down. Project Aristotle, the research effort behind the guide, set out to answer a deceptively simple question: what makes a team effective? Google’s answer was not the smartest people or the neatest org chart. It was psychological safety, meaning teammates felt safe taking interpersonal risks without being seen as ignorant, incompetent, negative, or disruptive.

For monday.com, that is not a feel-good abstraction. Cross-functional product work depends on people surfacing issues early, challenging assumptions before they harden, and asking for help before a problem becomes expensive. When engineering, product, design, support, and go-to-market teams are aligned around an AI feature or a workflow launch, silence has a real cost: it delays bug discovery, blurs ownership, and turns avoidable confusion into rework.

Why org charts do not tell the whole story

Google’s guide draws a hard distinction between a work group and a team. Work groups are mostly defined by hierarchy and light information sharing. Teams are highly interdependent: they plan work together, solve problems together, make decisions together, and review progress together in service of a specific project. Google’s researchers also stress that organizational charts only tell part of the story, because the real question is where the work actually depends on other people.

That distinction is useful for monday.com managers deciding how to organize launches and projects. If a release requires product judgment, engineering execution, design tradeoffs, customer support input, and sales readiness, then those functions are effectively one team for that effort even if they sit in different reporting lines. For individual contributors, the same lens helps identify where you add the most leverage: not just within your department, but wherever interdependent decisions can move faster because you are in the room.

How Google measured team effectiveness

Project Aristotle did not rely on vibes. Google studied hundreds of teams and used both qualitative and quantitative measures to understand performance. The guide says the research looked at 180 teams, including 115 engineering project teams and 65 sales teams, and combined manager, team leader, and team member assessments with quarterly revenue quota performance. That mix matters because it captures both how people experience the team and whether the team actually delivers.

The key finding was that how a team works together matters more than who is on the team. Google says effective teams set meaningful, clear, impactful goals, blend open communication with a culture of continuous learning, and are rated as effective twice as often by their managers. The research also showed a concrete business payoff: sales teams that worked effectively exceeded revenue targets by an average of 17 percent, while teams that did not could fall short by as much as 19 percent.

That is the part monday.com should take seriously. In a SaaS company scaling AI features, the most important problems are often ambiguous and spread across multiple disciplines. A product manager may see a customer risk before engineering does. An engineer may spot a technical constraint before sales promises a timeline. A support leader may hear a pattern in customer complaints before it becomes a release issue. Psychological safety is what lets those signals surface early enough to matter.

What leaders should do differently

Google’s research points to a few habits that matter more than generic encouragement. First, make goals explicit. Teams need clear, meaningful goals so people know what matters and where to spend their energy. Second, encourage respectful risk-taking so team members can challenge assumptions without worrying that a dissenting view will be punished. Third, build a culture of continuous learning, because teams get better when they can admit uncertainty early and treat it as information.

At monday.com, that changes how meetings should work. If someone raises a concern about scope, timing, customer expectations, or a product dependency, the goal is not to smooth over the tension. The goal is to use the disagreement to clarify the decision. In practice, that means managers should reward the person who surfaces the risk early, not just the person who speaks most confidently.

The guide’s deeper message is that psychological safety is not the opposite of accountability. It is what makes accountability usable. A team that can say it is unsure, can disagree without fear, and can ask for help before a deadline slips is more likely to keep execution clean under pressure. That is especially valuable in software, where one hidden assumption can ripple across product, support, and revenue.

What this looks like in day-to-day execution

A psychologically safe team does not avoid conflict. It makes conflict productive. People raise concerns early enough that product and engineering can act on them, instead of discovering them at the end of a sprint or in front of customers. They ask for help before a task becomes a bottleneck, and they challenge assumptions while there is still time to change direction.

That changes the pace of work. Teams stop spending energy on self-protection and start spending it on problem-solving. For a company like monday.com, where speed comes from coordinating many specialized roles at once, that is the difference between moving fast and merely looking busy.

The monday.com takeaway

Google’s research is useful because it treats team culture as a performance system. The best teams are not just happier teams. They are the teams that make better decisions, move faster with less rework, and turn openness into measurable results. For monday.com, the lesson is plain: psychological safety is not a perk sitting beside execution. It is part of execution itself.