Listening Like Superman

03 April 2020

Open workspaces are controversial.

Many people who read this may react with a strong “because they’re awful!” or “because they’re amazing”, with each pulling up research papers, editorials, and heated rants regarding the subject.

Allow me to pull the pin on this grenade for a moment: both reactions are correct. Really and truly. I mean it. And not as a cop out. Here’s the problem as I see it:

Saying an open workspace is “good” or “bad” (or whatever more precise terms you may prefer) really doesn’t contain a lot of information. That’s about as meaningful as judging a country’s economic output based on the features of its landscape - its quite similar to saying that mountain ranges are good or bad. There are certainly advantages and disadvantages to the “landscape” of your team’s work, but only a people that is well adapted to that landscape can thrive there.

What does this mean? Well, firstly, it makes most studies regarding “open” vs “closed” workspaces difficult to use without controlling for a large set of cultural variables - the variables relevant to the advantages of an open workspace. Studies that do not take this into account are likely going to show a familiar phenomenon:

An externally imposed process (such as forcing workers into an open workspace) will have a negative effect on the performance of a pre-existing team.¹

Myself, I’ve worked in the open-office style most of my career. But that is insufficient to illustrate how I’ve worked in open-offices successfully: it really should be very different than “doing the exact same work, with fewer walls.”

I work in software, on teams that need high-contact collaboration. That means that the team is constantly creating and revising everything about how the system works: the core business model, the system’s architecture, our shared coding standards, and even team processes, rituals and norms. My teams have a goal of continuous improvement to every aspect of the software - this is in contrast to the industry norm of software that’s built rapidly, and then has a long life of decay until it has to be entirely rewritten ².

With so many things changing, keeping the team in-sync is the highest priority. Becoming de-synced has costs that escalate the longer the discord is unresolved, which can result in either a broken system (very bad!) or a team that is afraid of making substantive changes (decay! very bad!).

Given that need, having a shared workspace helps us solve a lot of problems. We can easily collaborate as needs come up, possibly even rearranging the workspace to support that immediate need. If we hear each other reference an old understanding of a topic, we can chime in and correct, or resolve two different understandings. When things get hot and team members start to fight over different ideas on how to improve things, they can immediately work together to come to a compromise, and being face-to-face reinforces the human connection, which helps us remember to respect one another… after all, they’ll be here with us all day.

Which highlights a difference between a shared workspace and individual offices - your team has to meet some basic requirements in order to make a shared workspace work. Every individual needs to be willing to give up their personal space. They need to be willing to invest in active collaboration skills (see more on this subject in the editorial Radical Availability). Exercising and improving these social collaboration skills progresses much faster in the shared workspace, because we always have each other, and the costs of a team member playing poorly are high.

And this is a big downside of a shared office on a high-contact team: the same vectors that make communication fast and seamless can be hijacked for nefarious purposes. If you have a team member that projects negativity onto other people, it will damage the morale of the whole team. The major benefits of a high-contact team can be short-circuited by team members that refuse to compromise, or refuse to share vital information. Personal attitudes or stances that stand against the goals of the shared space will, over time, create invisible but very real walls within your shared workspace. And, of course, these vectors also communicate disease very quickly, should team members bring their sickness to work.³

Because of these vulnerabilities, teams that commit to a shared office have a responsibility to ensure that it operates as intended. That means making sure that team members all operate according to a minimal code-of-conduct… one that the team has the power to actually enforce. They need to be able to sanction and eventually remove team members that are stinking up the place… sometimes literally!

So now that we know the intended benefits of a shared team space, we can start to measure how successfully our team is taking advantage of them. And taking full advantage of them is a skill that must be developed.

How do we develop that skill? First, we need to recognize the nature of the work at hand: working on software in the way I’ve described is a team sport⁴. And because it a team sport, many of the skills that necessitate good play in sport also are useful here. Such as:

• Internalizing fundamentals, so team members automatically do the right thing
• Learning the skills and weaknesses of each team member
• Balancing further development of weaker team members and letting your star players shine
• Improving field awareness - team members knowing what other team members are doing, and how it may affect their own choices.

That last point is the skill that has the largest range of performance. The better you are at team play, the more you should be able to, without losing your state of flow, switch to help teammates in need. Or change your own strategy given what you hear teammates are doing. Or recognize that there’s a general lack of understanding, and ask the whole team to step back and think about a problem more.

This skill I sometimes refer to as “Listening like Superman.” The DC Comics character (in his modern iteration) has the ability to hear just about anything on the entire Earth, given a little concentration. The hard part? Filtering out the noise and focusing only on the events that truly should draw his attention. Building your own filter takes effort and practice, but the benefits are profound: just as Superman can snap into action to catch Lois Lane from anywhere on the planet because he’s attuned to her panicked voice, you’ll be able to stop your teammates from making catastrophic errors by building your attentiveness.

And, just as in sport, the only way you can successfully execute on the advanced skills is by making the core skills as automatic as possible. Lower the amount of concentration the fundamentals require, so that you can execute them while be available to your team.

As team members get better at this skill, you start to work as a well oiled machine… and, maybe just as importantly, work becomes more fun. You’ll use the skills to do work, sure, but you’ll also use them to make jokes, build relationships, and generally bring more of your human-self to the workplace. This is important for an introvert like myself, because opening up to coworkers does not come naturally, despite the benefits it provides.

So work on those core skills. Get to know your team. Find ways to actively listen throughout the work day, so you can help each other out. And tweak your working spaces and rituals to make these tasks easier. Whatever layout you end up using, make sure it really works for your team.

But mostly, listen.

1. Caveat - for some changes, and some teams, this is only true over the short term. This is because some imposed processes are easier to acclimate to than others. Changes in that category still only have a higher rate of success, because everything depends on the willingness and ability of the team to adapt its culture to the new circumstance. ↩

2. Of course, there’s a lot more to succeeding at that goal than the techniques discussed in this essay… creating trustworthy testing practices, integration practices, etc. ↩

3. Its probably worth noting that these vulnerabilities are still problems on all collaborative teams… they just show up faster and more disruptively on teams that have high-contact collaboration. Finding them faster can be advantageous, of course, as long as your team is responsive to the problem. ↩

4. And to be clear, it is a team sport whether done with a shared workspace, or not. ↩