Collaboration in the time of Coronavirus

When I’m not sharing my insights and opinions about Agile Delivery I play the violin. Not particularly well, but enthusiastically. I’m a member of a local community string orchestra. We get together every week to practice, and we perform a few concerts each year.

In the time of Coronavirus we obviously can’t play together. This could have robbed us of one of our greatest joys in a time of stress. We decided that we weren’t going to let a global lockdown take our music from us. In the week since that commitment, I’ve learned a great deal about effective collaboration and creation in a distributed team. Much of what we’ve discovered is relevant in other contexts, so I thought I’d share our learnings with you.

Before I tell you what we did, how we did it, and what we’re doing next, here’s the first iteration:

It’s not perfect. It’s not even very good. But a week ago we didn’t know it was even possible. Doing it required the right set of principles, practices and tools.

We need to collaborate in groups of various sizes and with several cadences. To do that we used three tiers of communication tools. For rapid-fire ephemeral communication we set up a Discord server to use for text chat. For messages we wanted the whole group to hear we used email. And to retain our community culture we set up a Zoom videoconference each week at our normal practice time.

It took us a few goes to work out which messages belonged in what channel, but a simple consensus soon emerged. For each message, consider how important the massage is, and what latency is acceptable. ‘Must see’ means email. Low latency/low importance is Discord. Low latency/High importance is Zoom. That simple heuristic is working for us, and it’s keeping the group-wide emails down to 2-3 a week.

Next we iterated on a way of working. I created a timing track for the whole group with GarageBand. I’d never used the tool before, but that didn’t matter. Any new challenge needs new tools, and you don’t need deep expertise to get going. My timing track consisted of a pre-existing recording and me slapping my hand on the table to mark tempo.

There’s an important principle there – at the beginning, you don’t need to be good – just good enough.

II knew that many people would be scared to be the first to share a recording, because everyone is afraid of criticism. It’s a human thing. To get round this, as soon as I’d shared the timing track I grabbed my violin and laid down a recording. It was pretty bad. I deliberately didn’t succumb to the temptation to polish it or re-record it. I shared it in its raw state.

This is another important principle – by setting the bar low, we reduced a barrier to participation. Ship the rubbish version, then iterate. There’s a story of a pottery teacher who did an experiment. With one set of students, she said “Take a week and make me the best pot you possibly can. Focus on every detail, and aim for perfection.” To another group she said “”Make me 1,000 pots in a week. I don’t care about quality, just quantity.” At the end of the week she asked someone to choose the ten best pots from them all.

Every single one selected for the best ten came from the group who made 1,00 pots. You don’t get good by trying hard. You get good with repetition and practise.

Having shared my raw recording people began to share theirs. The initial quality was somewhat variable. I committed to a fast turn-round. As soon as I have a new track, I’d mix it into the whole thing and share it back to the group. We used Google Drive as storage, and Discord to let people know there was a new version – it wasn’t important that everyone saw every release, but the sooner I released, the sooner the people who were around could benefit from the next version.

The key principle here applies in any context, but is particularly critical now that communication is harder – release early, release often, and get feedback as soon as you can.

Up to this point our workflow was simple: receive a track, sync it into the existing master, re-release the master, repeat. I was using GarageBand which is absolutely adequate for this. It’s better to use a ‘good enough’ tool than to spend ages and invest heavily in a ‘perfect’ tool with a learning curve that prevents a fast initial release.

Then the spec changed. Well, this is the real world. I was half-expecting it. Our illustrious conductor decided she wanted video as well as audio. Enough people thought this was a good idea that we committed to getting a video out.

We used the same principle. We did a bit of research and decided to try the deeply impressive daVinci Resolve for video editing. I would have liked to start with iMovie, but it lacked a crucial feature – displaying multiple videos at once. Again, there was no need for a 5-day course on how to use it. We live in the age of Youtube, and there are plenty of excellent instructional videos. I picked up just enough knowledge to create a proof-of concept. We recorded videos of me playing violin, my wife playing cello, and another one of her conducting. I didn’t try conducting because if there’s one thing the whole orchestra agrees on it’s that I can’t count.

With those three videos, I cobbled together a proof-of-concept, and shared it. That triggered our real conductor to record her piece, and she sent it to me by email. All 450MB of it. Thank you Gmail! 

This sort of thing is going to happen. People will push the limits of tools, in this case filling my inbox to capacity. Simply solved, and a quick addition to our agreed workflow rules. Don’t send anything to Charles’s inbox that you wouldn’t want in yours.

This is another principle: People will make mistakes. It’s important that we learn from the mistake and all get better, and that we don’t criticise the person, we address the problem. Rest assured, one of the people who makes a mistake will be you. Have a clear culture that we can attack problems, but never people. 

Another player had been having computer problems. When she’d fixed that (by the simple expedient of buying a new computer). With that fixed she recorded a couple of tracks and sent them to me. I couldn’t make them synchronise with what we already had. It turned out that she had played without the timing track.

It would have been very easy to blame her for this – how could it possibly work without a common  precise tempo? But I looked at it from the other angle. ‘How did my failure to communicate cause this  to happen?’ It was the right question – during her computer issues she’d missed much of the conversation that we’d had about timing. Fixing the root cause is a simple matter of writing the recording instructions in a single place and sharing it.

Assume everyone is doing their best and acting with good intent, even if the behaviour looks like idiocy from a distance. Every perceived instance of stupidity should be assumed to be a communication failure. Start by assuming that you caused the comms failure that caused the idiocy, and work together to prevent it happening again.

By always assuming that mistakes are caused by a communication problem you will create a collaborative, creative and conflict-free culture.

I then edited together the video I shared at the beginning. I’m proud of it. It’s pretty good for Iteration 2, and if nothing else it’s a reason for me to practice my bow action a lot.

Once we’d shared that we started getting feedback. To a musician, it has a slightly artificial feel. You can tell we’re not playing with each other, but to a timing track.

The next key principle came into play here – you don’t need to be an expert, you just need to know how to find one on the internet. Other orchestras were publishing their online collaboration videos, and some of them were very impressive. I reached out to the person who did this video for the Vrije University Orkest in Amsterdam. 

This brought home another point – things could be much worse. We could be living the Coronapocalypse over dial-up. I asked the VU people how they did their timing, and they were taking a more complex but more organic approach. They start with the conductor recording himself. Then the section principals each use that recording to lay down their audio tracks. They edit them together to give a single-instrument per section version of the piece. This doesn’t sound orchestral, but it’s plenty for the rest of the orchestra to use, and gives a more ‘live’ feel to the overall recording.

So, for iteration 3 Anne is going to video herself conducting, and our section leaders are going to create the timing track. That’s the plan for this week. After that, we have ambitions. Our Autumn concert has been cancelled, but what’s stopping us from creating a video of the whole concert programme?

We get together every week on Zoom. The main purpose of that is social. We miss each other. We take that time to check in on each other, share our joys and triumphs and failures, and to talk about what we’ve done and what we’re doing.

Some of our members are not entirely comfortable with all the technology. Those of us who do this stuff for a living have stepped up to form an ad-hoc tech support group. We had some glitches and connection issues with our first VC. We attacked those as priority one first-class issues. If people can’t communicate, they can’t collaborate.

The key lessons we’ve learned are:

• The coronapocalypse can’t stop creativity. You can produce truly collaborative creative content in a distributed team.
• The right response is always ‘How can we do that?’, not ‘Can we do that?’ Start from the assumption that your goal is possible, and make the universe prove you wrong. Don’t be the reason to give up trying.
• Tools matter. Have several channels for communication and agree what is their appropriate use. The latency/importance distinction seems to work in most contexts.
• A breakdown of a communication channel for any team member is a priority one event. Without easy access to all of the channels, you can’t collaborate. Treat technical and training issue as stop-everything events.
• Ship early, ship often, and value feedback. We get better by iterating, not by trying hard.
• Set the initial bar low. Make everyone confident that their contribution will make the world a better place, and that will amaze you.
• Things will go wrong. If you attempt to avoid all mistakes you’ll prevent people trying stuff. Instead, create a resilient culture that values mistakes as opportunities to improve as a team.
• You can attack a problem as hard as you like, but we never blame people.
• Idiocy must be assumed to be a communication failure. Address it as such.
• Facetime matters. Get together by VC as often as you need.
• Focus on people, not just on work. Many people are hurting right now. Make time for the human element – share your cat pics and toddler videos.
• It’s better to know who to ask than to try to be an expert at everything.
• The only real barrier to effective creative collaboration is the cat on the keyboard. For that, I have never found a solution.

Now get out there and make something amazing together.