Thinking differently about . . . collaboration
How often have you accidentally hit ‘reply all’ when sending an email? Or included someone on the cc: list that you didn’t intend to? I think that we all know the feeling of making that mistake.
I had a similar experience in my new job at Google last week - but it turned out to be a lesson about collaboration instead of a mistake. (This also seems the right week to share some thoughts on collaboration this week, given the announcement of Google Workplace - but the views in this article are my own).
I was editing a document using Google docs, and when I hit the share button, I was asked whether I wanted to share it with the same people as the document I had copied it from. I hit ‘yes’ - then realised that I had shared the document with about a hundred people, rather than the half dozen I had intended it for. I had a sinking feeling for a moment - then remembered that I needed to think differently about collaboration.
To learn to think differently about collaboration, I needed to reflect on my pattern of collaboration in previous roles. I liked to think of myself as naturally collaborative: much of my work involved producing strategies, designs and other documents for the use of others, and they were never a solo effort. They always needed thought, challenge and feedback from many experts.
But the mechanics of document production were not inherently collaborative. I would typically gather some thoughts from experts on my team, open a document on my hard drive and start writing and editing. Occasionally I would call or mail someone for input, and I would usually send a draft around for comment when it was sufficiently complete. But most of the work was a closed loop between my brain, hands, keyboard and computer. And I don’t believe I was unusual - most people work like this, and have done so for many years. It’s a reasonably efficient way of working, but results in a particular type of output: a document written by a single author, on which several others have commented, rather than a document on which many people have genuinely worked together.
It only took me a few days at Google to realise that that isn’t the standard way of working here. I soon learnt that the thing to do is to start a document, to make it accessible to many people (possibly the whole company) and invite other interested people to edit the document. What I then learnt was to expect edits and comments to appear on documents that I was in the middle of writing.
This is a strange experience for someone who has been used to the normal write-distribute-comment-review-present cycle, and has taken some getting used to. I still haven’t shed the disconcerting feeling that, before, I was making my mistakes in private, whereas now I get to make my mistakes in public (even if no-one else cares about the content, it still feels that way). I think that this has a beneficial effect on writing, for three reasons.
First, I think that writing in public makes you think of others sooner, and leads to better writing (I think that the same applies when writing code that will be published to a public repository: my first experience of doing that certainly made me think twice about the quality and readability of my code).
Second, I think that it reduces the risk of creating something which is flawed but cosmetically compelling. If we are honest with ourselves, we know that we have all done this from time to time: we write something which we are not completely sure of, but find a way of expressing it which looks convincing, and which sways people when they see it for the first time. I find that writing in public makes me check more closely that I understand what I am saying before I think about the most elegant way to say it.
Third, it reduces unnecessary polish. This seems to be an inevitable consequence of the normal write-distribute-comment-review-present cycle. There is always that ‘present’ moment you are heading for at the end of the cycle, when you will share your finished work with others. This encourages you to make sure that your work is truly finished, is polished and shiny, especially if you are presenting to people more senior and powerful than you. But that polish and shine is not always merited: I know that I have spent time adjusting the alignment of boxes in a picture to make them pixel perfect which nobody else will notice. That’s partly my style (and I’ll probably carry on doing it anyway), but I am not sure that it always helps the audience understand the message or make good decisions. But if your audience have been collaborators with you through the development of your material, you probably don’t even that final review and presentation - your audience has been alongside you as you worked.
Which brings me back to that shared document and that sinking feeling. The reason I felt that way was that, in most companies I have worked for, hitting ‘share’ without checking the distribution list would at least have been a faux pas, and could have got me in trouble. Here, I have quickly learnt that inviting people to join in early in what would previously have been closed and private work is a good thing.
I am still learning the Google culture (and will probably be doing so for a long time), but this is already a welcome change to my habits. But there is no reason this mode of collaboration can’t work in every company: now that we have the technology, we just have to learn to think differently about collaboration.
Head Of Sales - North & South EMEA
4 年Great insight and perspective, thanks for sharing David!
FinTech Leader | Helping teams and organisations on their Digital Transformation journey | Strong believer in Human Ingenuity
4 年Thanks for this very timely post David. Just in the middle of bringing together a deck on our story and will surely try and leverage this. While we have worked in distributed teams, working in an office always meant that we had someone we could work with collaboratively in the initial phases and then share wider - not perfect but still better than the current scenario of an office of 1. Working remotely has this big disadvantage of lack of the traditional opportunities of collaboration and your article has not only provided a way to address one such challenge, but triggered a thought on what else can we change to adapt. One of the things I am still struggling with is how to get pair programming working (something I used as a very effective way of ramping up new joiners, by pairing them with experienced team members) ...
Thx for sharing David... love the posts... really insightful to understand better ways to efficiently collaborate!
EMEA CISO @ Fortinet ? Αut?οr ? Keynote Speaker ? NED ? Executive Advisor ? π ?
4 年The anti-pattern of not setting up feedback loops from inception is normally seen in non distributed teams. I've seen it happen more frequently in organisations and lines of business that don't have a remote culture. One observation is that Google strives to be a distributed company where a financial institution normally has all the nudges for the opposite. Thanks for sharing.
Manager, Technical Programme Management
4 年Good read. Something I've been discussing with my team as I encourage them to start using confluence to make work visible. Definitely a reticence to not display anything until "perfect". This delay in feedback from wider team ultimately slows progress.