Team interactions must be designed for success

This article is part of a series:

1. Team interactions must be designed for success

2. Get more done with less

3. Your teams are not call centers

---

In 2021, my team was working on a project to extract user behavior data from a web application, merge it with other data coming from the same system, analyze everything, and deliver the results to the stakeholders.

The outcomes of this project were considered highly strategic for the company. Still, despite the fact that it appeared to be a pretty standard data initiative on the surface, the execution turned out to be very problematic, to say the least.

“Picture a car driven by two pilots: one at the steering wheel, the other on the pedals. That’s what happens when you organize teams based on an org chart.” Me, 2024

At least four teams were involved in this project’s outcomes, whether directly or indirectly:

• Backend engineers

• Frontend engineers

• The data team

• One or more operational teams

The situation is illustrated in the diagram below, where each segment represents a flow of information.

If this setup seems fine at first glance, think twice: every segment is not just a connection, but also a source of friction. Communication across teams takes time, creates opportunities for misunderstandings, and slows progress down.

How could it happen that a project deemed critical to the company was not owned end-to-end by a single team, but split among teams with competing priorities?

Unfortunately, this was inevitable.

Enter Conway’s Law

Conway’s Law states: “Any organization that designs a system will produce a design whose structure is a copy of the organization’s communication structure.”

In other words, the systems you build will reflect how your teams are structured.

Here’s how it played out in my case:

• Backend and frontend teams produced data that was often impossible to reconcile.

• The data team tried to shape this data to meet requests from ops teams.

• However, the ops teams had no visibility into what was available, so some of their requests could not be satisfied, or had to be heavily approximated.

• The data team would ask engineers to update schemas to improve outputs, but these requests were not engineering priorities, and took an average of three months to fulfill.

• By the time the changes were implemented, the requests had probably become obsolete as the application had moved a couple of versions forward.

A fragmented system, born from fragmented teams.

A way out

If you want to reshape your systems, you need organizational change.

Conway’s Law is inevitable.

• Ignore it, and your systems will keep looking like your org chart.

• Fight it, and you will crash and burn.

• Accept it, and you’ll gain a new tool to succeed.

Back when I was working on that project, I wasn’t aware of the research and frameworks surrounding this concept. But two and a half years of frustrations led me to similar conclusions: if I wanted the project to succeed, I needed to remove as many points of friction and bottlenecks as I could, and make sure that the team working on the project had complete ownership over the flow of change.

In other words, I needed to establish a team that would fit the project’s horizontal nature. This meant:

• Identifying key players in each ops team with a direct stake in the project’s success.

• Get someone from the data team who could bridge engineering and business needs.

• Take over data-related tasks from engineers, who were disengaged from these initiatives.

In the end, the new team consisted of one data engineer (me), one data scientist, and three ops people. It wasn’t perfect — for instance, we had no one from legal, leading to a dozen GDPR-related meetings — but the results were undeniable.

• Data quality improved significantly. Errors became rare, easy to identify, and quick to fix.

• Delivery times dropped from three months to less than a week.

• Ops teams gained shared knowledge, enabling them to handle many requests independently without being bottlenecked by the data team.

Don’t let HR design your team interactions

This approach worked for me because, by addressing the immediate bottleneck, we replaced outdated tactics with better ones — on a small scale.

But in wider scenarios, with dozens of teams in the picture, changing tactics isn’t enough.

You need a structured approach, a strategy, to design team interactions at scale. Remember, if you don’t do this, the fallback option will always be determined by the reporting lines in an org chart. By identifying patterns of collaboration and recognizing that the way you shape your teams shapes your systems, you can achieve far better results.

The framework I mentioned earlier, Team Topologies, offers a set of solutions for brave leaders who understand the danger of under-specifying the team interactions. By identifying specific types of teams, and hard-coding the interactions between them, Team Topologies delimits the playing field and forces you to think intentionally and systematically about topics such as scope, ownership, collaboration, enablement, platform.

Besides the basic concepts of the framework, two key topics deserve a separate callout as they can make a huge difference in your organization: the Team Cognitive Load, and the Team API.

Team Cognitive Load — Teams, like individuals, have limits. When a team becomes overloaded, focus and effectiveness suffer. Organizations need to switch to a “human-first” approach - balancing the cognitive load of a group of people is more important than balancing the loads on a technology!

Team API — An interface to define how teams interact, for what purposes, and under what conditions. This is not just a great way to manage expectations, but will also push your teams to think about usability first.

In the next article of this series, we will discuss Team Cognitive Load in depth. Check it out here!