Are you organising for collaboration or chaos?
Summary
It’s easy to believe that just because people look close to each other on a Powerpoint slide, they’re setup to collaborate with each other. Real life is more complex than slideware. In this article, which is a repost of the original on reworked.co, I explain how you can organise your team internally and externally, to facilitate collaboration, not chaos.
In the world of knowledge work, “collaboration” is probably the most positive word out there. We hear each other use it as a silver bullet for many problems. Can’t produce quality outcomes? We must collaborate better. Are you feeling stuck? Collaborating with the right person can help you get out of that rut. Are departments working in silos? We need better collaboration!
But why is it so difficult to “just collaborate” in some situations? Why does being collaborative sometimes feel chaotic? Do you dread some collaborative activities more than you fear a root canal? Is it that the people in question are uncollaborative? Or can the same people be better collaborators, if someone were to pay attention to how they design the contexts of collaboration? Let’s explore this question together.
PowerPoint proximity ≠ collaboration proximity
I’m sure you’ve seen org charts on slides before. The pixel proximity of functions and individuals on slides creates the illusion that teams that roll up to a single leader, or people whose names are close to each other will be each other’s natural partners. This is what I call the “PowerPoint proximity fallacy.” The origin of this fallacy is the legacy of office-bound work.
In the old world of an office, if two teams reported to a single leader, they likely sat on the same floor. All the ills of the office environment aside, if one team needed help from another, getting that help was a matter of walking up to that team and figuring things out. Quick fixes would get immediate attention. For harder problems, the two team managers would agree on how to address the issue: who works with whom, for how long and when. Of course, there’d be organizational politics and inefficiencies. The bigger the company, the greater the dysfunction. But mostly, physical proximity was a design safeguard, to ensure that the people who needed to collaborate, could collaborate.
Distributed teams work differently. Even if two teams report to the same leader, they’re nowhere close to one another. If you’re geographically dispersed, even an “immediate” response to a call for help can take hours, if not days. This problem exists across teams, but it’s also common within teams, albeit at a lower intensity.
Now, of course, distributed work has many benefits, but if we are to reap all these benefits, we must acknowledge the “PowerPoint proximity fallacy” and design teams and organization structures for remote-native execution. Thankfully, this isn’t rocket science.
Design team processes for flow and autonomy
Nothing sucks the joy out of work, more than seeing your outputs stuck at a bottleneck. Let me give you a few examples:
A developer’s contributions can’t go through because the testers are too busy
A staff writer at an online magazine finds their work stuck at the editor’s desk
An architect’s idea paper awaits design approval at a meeting two weeks from now
A product marketeer waits for corporate marketing to review their social media campaign
While we all dislike the shoulder taps that destroy our flow, we could still shoulder tap our way out of these bottlenecks in the office. Remote teams can’t afford such bottlenecks, because they translate, at a bare minimum, into 30-minute meetings. Pile up enough bottlenecks, and Zoom fatigue ensues. And we all know how that collaboration story ends.
If you are leading a team with such bottlenecks, first address your constraints. For example, if you lead a development team where work often gets stuck at the testing stage, there’s no point pushing more work to the team than the testers can test. Instead, throttle the incoming work and limit it to the number of parallel tasks the testers can handle. This way, the work will flow smoothly through your development process. To improve your throughput, you can add testers to the team, one at a time. That can help more work items flow through your system unless you create a fresh bottleneck. Oh, and if your team has poly-skilled people, you can reconfigure your team to address the constraint, without increasing the team size.
To improve throughput, first address your team’s bottlenecks
But what if your bottleneck is outside the team? Take, for example, the product marketeer waiting for corporate marketing. There are two ways to solve this problem:
If there’s enough work from the product team for a single corporate marketing person to handle, then shift that marketing person to the product team. This is what we call a “cross-functional team”.
If there isn’t enough work from the product team to employ a full-time marketing person, consider how you can give the product marketer more autonomy, so they can work without the bottleneck of outside reviews. You can build this autonomy through training or performance support tools such as templates and brand guides.
Last, if neither of the above approaches works, then shift the accountability for delivery to the group that houses the bottleneck. Take, for example, the editor and staff writers. Measure the staff writers on the stories they submit. Measure the editors on the stories they publish. That way each group’s success depends on factors within their control. Indeed, the happiest teams are those who feel in control of their outputs and success. Heed that sentiment when organizing your people.
Might I add, that improving flow, feedback loops and autonomy for your immediate team, is well within your control as a manager. Sure, you may have to wrestle with your bosses and stakeholders, but it’s a basic act of collaboration design. That said, it’s not the only necessary step.
Organise using team topologies
Companies can’t succeed if teams only care about their outputs. The whole is more than the sum of its parts. Inter-team collaboration is crucial, but it’s harder to orchestrate than simply representing teams next to each other in a PowerPoint slide.
Whether or not your team is technical, you can take inspiration from Matt Skelton and Manuel Pais’ work on team topologies. Skelton and Pais describe four kinds of teams in their book, which I’m taking the liberty to explain in generic language:
Stream-aligned teams. These teams own an end-to-end flow of work for a slice of the business. As the diagram below shows, they own their outcomes end-to-end, with no handoffs.
Enabling teams. These teams help stream-aligned teams achieve time-boxed outcomes they may not be immediately capable of executing.
Complicated subsystem teams. Such teams provide specialized products or services to the stream-enabled teams.
Platform teams: Such teams provide products or services and capabilities that speed up the work stream-aligned teams do.
When you think about your teams this way, you can think of collaboration as a structured, thoughtful activity. In the team topology world, there are only three ways teams interact with each other.
Collaboration. Teams work together for a short time, to discover something new. For example, the platform team and a stream-aligned team can use such interactions to agree on new capabilities that’ll help the stream-aligned team achieve their outcomes more effectively.
X-as-a-service. In this pattern, one team provides another team with a service, with little or no collaboration. Technical teams can consume services from another team by using their components or libraries. Non-technical teams can consume services from another team by using ticketing systems like Zendesk, Service Now or Freshdesk.
The key to making such interactions work is to define services as clearly as possible. For example, an internal technology team can define how to request software licenses and the SLAs around such a service.
Facilitating. This final pattern describes when teams help each other clear some impediments. For example, a division’s central marketing team can work with a stream-aligned team’s product manager and product marketeer to ensure they have the skills and tools necessary to own their marketing efforts.
Types of teams and their interaction patterns
As you’ll notice, all three interaction patterns that Skelton and Pais recommend are more deliberate than the simplistic advice to “just collaborate.” You must design teams for autonomy, figure out the boundaries of the services they provide to others and be sure that all inter-team interactions are finite and time-boxed.
While most companies and teams are at some level of remote, the design of organisations and divisions still suffers from the PowerPoint proximity fallacy. Instead of aligning teams across an affinity of workflow, we follow an outdated notion of alignment through (pixel) proximity. On distributed teams, this leads to inefficient collaboration and prolonged wait times when handing off work between people and groups.
Of course, it’s no trivial task to reorganize your processes to maximize flow and organize your departments and teams along the four fundamental team topologies. You also can’t claim victory even after you’ve sorted out your teams and processes. Managers must have the foresight to plan cross-team interactions. That way these interactions stay finite, and where possible, happen with minimal back-and-forth.
Daunting as it may seem; if you aim to run an efficient distributed department or company, I argue you can’t escape such an effort. Indeed, you owe it to your people to help them enjoy true collaboration - not chaos or frustration!