Not long ago, Google published research titled "Project Aristotle," which debunked the myth that co-located teams are more effective than distributed teams. I’ve written similar observations, albeit my conclusions were driven mostly by gut rather than two years of scientific research studying 180 teams. In retrospect, I’m glad Google researchers did all the heavy lifting for my argument.
My original article was very much self-serving. Four years ago, when we would encounter objections to our operating model, my insecurity made me justify the what, how, and why of our globally distributed business. Part of me cringes when I read the post from three years ago, but at the same time, it amazes me that nearly tripled in size in that time. Water under the bridge, as they say, and let the internet be a witness of my past ignorance.
Effective delivery teams: What have we learned?
Chris, our director of product design, recently suggested that it would be interesting to write an updated version of the same article with the current experience of running a technology organization with 500 employees that form roughly 30+ cross-functional teams. For the record, we are distributed across five offices today: Chicago, Toronto, London, Kaunas, and Vilnius. A single team typically spans across two offices. Product managers sit together with product designers; software engineers hang out with testers and our DevOps staff. We discovered that while disciplines could be distributed, co-location within the same discipline was beneficial to scaling—primarily due to practice leadership and excellence. It’s much easier to build educational and career advancement platforms when all of your testers, for example, are in the same geographic region. However, while our teams work in a distributed model, they do co-locate for specific periods of the project—more on that later.
The objection would sound something like this: “Having the team in our office will give us more control. This is a mission-critical initiative, we want our subject-matter experts (SMEs) to sit next to the designers and engineers…”. While this may sound reasonable on the surface, the request implies that failures or lack of discipline occurred in past project execution. Co-locating doesn’t correlate to effective delivery, and putting a stakeholder or SME in the same room as the product team might actually cause more harm than good. We’ve seen this many times: A senior executive micromanages day-to-day delivery, resulting in death by 1000 paper cuts—gold-plating or fine-tuning micro-features to the point of release failure.
How do you define an effective team?
It’s important to define what an effective team is in context of shipping software to market. The classic triangle of project management illustrates the interdependence of schedule, scope, and budget, yet has nothing to do with effectiveness. Here’s an example: A team ships working features to market, on time and within the designated budget, but users don’t adopt those features due to poor usability, poor understanding of needs, missed acceptance criteria, and so on.
On the other hand, an effective team should have the trust and autonomy to completely butcher a business requirement if they have the data to back up their decision. Spend less time, ship less feature, but make software that’s more valuable to the end user. That’s an indication of effectiveness. To further illustrate this point, Elijah, our director of product management, recently wrote an excellent article about metrics and how we share them using the PowerUp app. Elijah argues that even agile metrics are not an indication of effectiveness—they’re a KPI, just like schedule, budget, and scope, that need to be interpreted and understood to conclude if a team is effective.
In today’s business world, 100 percent co-location is nearly impossible. I can’t name a client in our portfolio that has the luxury and resources to co-locate all of their delivery—nor could they due to their global service footprint. Ultimately, the goal should be to build effective teams that meet delivery needs where quality and speed are justified by return on investment.
Google researchers found that what mattered was less about who was on the team and more about how the team worked together. I agree with this conclusion, but there’s a small caveat that may not always hold true outside of Google: The model works as long as every member of the team is competent in their discipline. While Google and select technology companies have the cultural and financial capital to source the best talent, the same cannot be said about most other enterprises. Don’t get me wrong, many great companies can attract great people, but the reality of market demand versus supply is elementary (see computing bars below).
Data Sources: US-BLS Employment Projections, 2012-2022; National Science Foundation NCSES.
Our banking clients, for example, cannot sit still while fintechs gobble up their most profitable channels and products. Same clients face the challenges described above, so the only viable and scalable solution is distributed teams that span internal employees, contractors, and partner organizations like Devbridge.
Team success depends upon the right culture
The founding pillars of an effective team, based on Google’s research, were defined as follows, in order of importance:
Psychological safety: A successful team is empowered to take measured risks, even if the result is failure.
Dependability: Responsibilities and expectations are clearly defined.
Structure and clarity: Goals, and the plan for achieving them, are communicated.
Meaning: Team members feel that the work they do is important and of value.
Impact: Success is measured by how it affects the user.
Personally, I find the above interesting because it directly aligns with our company values: In no particular order, take ownership, embrace transparency, have fun, make great things, pursue mastery, and deliver results. My conclusion: Google’s research highlights underlying patterns necessary for humans to collaborate and do great work.
In fairness, there are exceptions to the above under certain conditions and times in a project lifecycle. From my experience, these are:
Teams working in close proximity early in the process builds trust and safety before distribution. Trust is easier to build in person, even if the co-location is limited to a week or two.
Teams benefit from co-locating during milestone moments in the project or product lifecycle. For example, story-mapping sessions and large planning sessions for milestone releases (MVP, MMP, etc.).
Working teams should celebrate major wins and releases together (this also strengthens point 1).
The general debate on co-location reminds me of past debates about delivery process, programming language selection, stack benefits, and so on. Scrum, extreme programming (XP), dual-track, kanban—they’re all frameworks that help teams get work done. Processes and working models don’t dictate success or effectiveness. People do.
As an industry, we need to move beyond process and improve psychological safety—in simpler terms, culture. Then, and only then, are teams—whether they’re in the same room or on another continent—best positioned to deliver effective software.
Key article takeaways:
Psychological safety (failure tolerance within the organization) is the key to effective teams.
There is no correlation between co-location and effectiveness.
A baseline requirement for any software team is that each member is competent in their discipline (design, product management, engineering).