Your Worst Collaboration Killers, and How Defaulting to Open Can Protect You

Part 4 of our digital transformation series: why ‘share with everybody’ should be your default setting.

In previous articles we explored why starting small, nurturing psychological safety, and forming small teams were essential tenets for any digital transformation. There is just one more ingredient missing—and it’s a tenet frequently associated with Google, but which is arguably no more or less important everywhere else: defaulting to open.

To be clear up front: your company’s business records and your customers’ personal information constitute sensitive data and deserve strict access controls. But the same isn’t true for your employees’ ideas. To the contrary, good ideas need as much visibility as possible because it’s never clear beforehand from whom they will come and who else will be inspired to aid in their execution. 

Everything we’re about to propose is being practiced in your organization today already, in some areas, some of the time. However, what is common practice to IT may sound like heresy to those outside of it, and what the business would consider essential is often dismissed as extra work by IT. Truly defaulting to open means applying the principle consistently across your organization and, most importantly, at the intersection between business and IT.

Dear email users,

Your single greatest collaboration killer is sending versions of a document as an email attachment back and forth. Not only is it slow and error-prone (how often did your version turn out to not be the latest?), it also disenfranchises everyone on the email recipient list from contributing to it and it discriminates against everyone who isn’t on the recipient list at all. 

Having all ideas, plans and designs in a central place behind a simple web link and inviting real-time contributions from anyone within your organization is a profoundly powerful thing. In essence, you’re taking what is common sense amongst software engineers when they use ‘git’ for code and wikis for documentation and applying it to your whole business. It should come as no surprise that Google Workspace is designed with this functionality at its core, but there are also plenty of other productivity and collaboration tools in the market that can help you achieve this objective too.

Of course, some documents are inherently sensitive and should be locked, but for most documents in an organization, you can safely default to open. This means starting from an assumption that your colleagues are trustworthy and not fearing that they will accidentally or deliberately alter your documents in destructive ways. With today’s software it’s trivially easy to see who made which change and for you to roll it back, if necessary. In return, you will receive more validation and more constructive feedback on how to make your ideas better. 

In fact, this very article was made better by a colleague who stumbled across the draft while searching Google’s intranet for information about email attachments in Gmail. They left a comment in the doc pointing out how, at Google, sharing documents with peers may feel trivially easy but that in fact, this behavior is deeply rooted in a company’s culture. Thanks to this unsolicited feedback, this author was reminded of how trust also factors into the behavior (and that defaulting to open is much more than just a software setting).

Dear software engineers, 

Your single greatest collaboration killer is keeping descriptions of your work to yourselves and not investing enough time to succinctly articulate them so that outsiders may understand them. Your business stakeholders are invested in the success of your project, but without a simple shared language, they must make do with terse project scorecards and proxy translations from “geek-speak” into plain English.

Software engineers can do better by describing their work in the form of a user story or epic that articulates the value generated from the perspective of the user/customer. Two common templates are “As <user role>, I can <action>, so that <value>” and “In order to <deliver some benefit> <these people> will need <this function>”. Choose your preferred template but make sure you apply it consistently across your program.

Here’s an example of a description that would be hard to grasp without further context and technical knowledge: “Render billing_events_summary table view with JekyllCMS and upload to blobstore.” And here is that same piece of work expressed as a more understandable and value-oriented user story: “As Finance, I have a single dashboard for billing data, so I know when an application is costing more than expected.”

Without a plain understanding of all work in progress, your business stakeholders are forced to draw up their own lists of requirements and milestone deadlines, relying on what intermediaries tell them, who in turn can only relay what they themselves understood. Good news floats to the top quicker than bad news, and so over time your respective realities drift further apart, making the eventual but inevitable reconciliation more painful.

Having these shared, simple, value-oriented work descriptions means much less can get lost in translation and less can get out of sync, as the ground truth that is self-evident to you travels and aggregates upwards and outwards.

Dear everybody, 

Consider why team chat applications have experienced exponential growth over the last several years. While being able to communicate with colleagues in real time is useful, the real paradigm shift that team chat introduced was centralizing all topical and project communication in one place. As co-workers join or leave a project or even just pop in for a little while, they can join or leave the team chat channel at any time and re-trace (or search) its history to gain context and understanding about the project.

Team chat is effectively the opposite of email: instead of the sender deciding who should receive a piece of information it is now the recipient who decides what is relevant to them. So the next time you share a valuable piece of information with your project team, consider posting it to your Google Chat space or your Slack channel, instead of emailing it. The next colleague to join your project will thank you.

Open to new ideas

In summary, there are different dimensions to being open: collectively committing to maintaining single sources of truth; granting access to those repositories to the widest appropriate audience; and articulating your work in such a way that even the people farthest removed can still understand it. Internalize those behaviors, and you will serendipitously start to share new insights and forge new synergies that could not have been gained any other way.

Read this next: Transforming collaboration in Google Workspace