Planet MySQL - Archives - Communication in a distributed company: Choose you...

Everyone has their preferred method of communication, which they tend to overuse at the cost of other methods. At MySQL AB, email was preferred in many situations where picking up the phone would have saved loads of work, frustration and distractions. SkySQL Ab as a company is equally distributed across continents and time zones. Not surprisingly, we have inherited some of MySQL's bad habits, and created a set of new habits, good and bad. The purpose of this write-up is to take a step back and reflect upon which tool fits which purpose, focusing on a virtual company with colleagues spanning many time zones.

The matter of how to collaborate and communicate has more aspects to it than merely thinking about alternatives to phone and email. It ranges from information architecture issues (how are documents shared and categorised?) over policy issues (what information is individual, what is shared amongst a few, what is company wide, what is shared with the outside community?) to attitude issues (how do I deliver criticism to my colleagues?). While you can shed light on the topic from many directions, I will here take a bottom-up approach, pondering "what tool should I use right now, to achieve my goal?". My attempt is to choose a weapon that fits the purpose.

My assumption is that I work in a situation where there is an established set of communication tools, all of which have some room for improvement when it comes to configuration. Most of all, I assume that there is no agreed policy of what tool to use when: no common understanding of the choice of weapons has been established, as the matter hasn't been thought worthy of attention.

In addition to an email system and a set of mobile phones, I assume there is

an externally visible instant messaging system, normally Skype
an internally visible instant messaging system, such as IRC
an intranet, where documents, calendars, and policies can be shared, such as Google Sites
an internal document sharing system, such as Google Docs
an externally visible file sharing system, such as Dropbox

I also make other, less boring assumptions. I assume there are personalities in the company, who make themselves known through their methods of communication.

Simon is a prolific communicator. He gets things done, yes he does. He has a razor-sharp focus and expects others to share his focus and goals right here and now, no matter if they're his bosses, his team colleagues, or colleagues from other teams. Simon

sends emails right now
conveys a sense of urgency
sets the expectation that matters have to be resolved more or less immediately

which all sounds more or less good. But he also

forgets about descriptive email headers
brings up unrelated topics in existing email chains
creates new email chains for existing topics
spams everyone and their cousin with heaps of email

which matters less to Simon than his colleagues. Simon can ask "Did you read my email from last Thursday?", believing it's as urgent, important and clear to you as it is to him.

I have been surrounded by more than one Simon in my career, and my wish to Simon is

Stay Simon! Retain your focus, your drive and ambitions. Yet, expect to have to work a bit smarter (not louder) on involving your colleagues.
Think of the recipient! While "getting the matter out of your system" is a virtue, do also think about increasing the likelihood that others will pick up the ball from where you leave it.
Think before you send! For each email, have a goal. Make that goal more clear than "make the recipients aware". What action do you wish them to take? Will your email persuade them to do that?
Build upon existing (mental) structures! Refer to quarterly goals, to the CEO's statements, to earlier emails (ideally written by the recipient), to phone calls. Make it easy for the recipient to understand what the email is about.
Send fewer emails! Not every thought of yours is best mapped to a sent email. It can be a note to self about matters to discuss in a chat (voice or text), to bring up in the weekly or monthly report or in the next meeting.

Overall, Simon would benefit from his audience not thinking "Ahh, yet another Simon email. I'll read it later [as it is distractive, takes time to interpret, or may be frustrating]." but "Ohh, Simon writes me. I better read it [as it is important, actionable, and related to my goals]!"

Simon's colleagues also fall into categories. Painting further stereotypes in equally vivid detail would cause me to lose a majority of the readers that have not lost their interest yet at this point, so let me instead come with a list of twelve suggestions. Some of them work also for Simon.

Avoid (forcing) context switches. Concentrated work is focused and single-threaded. Trouble is, you can't work alone on something for too long. You need input and answers from others, and they need it from you. Make the cost of a context switch for others as low as you can; it's good for you.

Resolve matters interactively. Converging on a matter often takes a certain number of back-and-forth interactions. Better for the reply-and-answer loop to happen interactively, rather than over night.

Use joint prime time. I'm far less productive in the evening, so I have no joint prime time at the time of day when Californians work. When creating (project) teams, take time zones into account. Time the creative meetings into everyone's morning or early afternoon.

Avoid interrupting others. This doesn't mean "avoid the phone". It means "respect your colleagues work habits". To make an appointment for a meeting at a certain time will interrupt that person's work at that point in time, forcing them to be available for you. Skyping a "Good morning Simon! Available to talk about the product plan?" may catch him when he is, and may lead to the usage of joint prime time. You wouldn't know unless you ask.

Prepare interaction. If you have a meeting (one on one, or a team meeting), always come prepared. What do you want to achieve? What is the relevant background information? What will others likely ask you? Violating this simple guideline is far too common.

Document interaction. If you take the time to meet, write things down. Clearly. Action items, who does what by when. And if you discussed matters prior to a stage where action items are the main meeting outcome, then document the key insights. I've been in far too many meetings where participants spend heaps of meeting time reconstructing earlier thinking (that wasn't properly documented), or worse still, failing to recall previous key insights - i.e. not using valuable information.

Make the important persistent. Once notes are written and emailed, you may have the next meeting, or have some other valid reason to spend time on something else. But sooner or later, you'll have time to save the meeting notes elsewhere, be it in Google Docs, on the Intranet or in some other common repository.

Make the important accessible. Think of your dinner interactions: "I have it in a presentation, I'll show you later" - or "I'll look it up when I have time". Well, if you saved key documents as PDFs and synced them to your smart phone, you could look it up or show it just now. Perhaps you can resolve the matter instantly?

Promote your emails (and goals). Your boss (or colleague) didn't answer yet? Make it easy to answer! Make your priorities clear! Ping your counterpart over Skype or SMS, quoting the exact email subject, or even pasting the key question. Don't just ask "did your read my email?".

Assume your recipient is travelling. Many of us are myopic and expect others to work in similar surroundings as we do right now. A desk, a big screen, high-speed Internet, electricity. But your colleague might be on the road, have a tiny screen, low bandwidth, batteries running out. If you write an email that can be responded to under such circumstances, it will get likely always get a faster response.

Suggest, rather than ask. If you've been given a task that requires decisions by others, then spend time proposing a decision. Don't just ask for others to decide. Responding "OK" is fast, and as a bonus, you'll get your will! And even if your suggestion isn't approved, you have probably made much more progress than by merely asking a question.

Write clearly. Use short sentences. Be explicit. Say "the below email" (which you forward) rather than "my latest email". Reread your email one more time before hitting Send.

There's more to efficient and effective collaboration than this. Next time, I'll attempt at shedding light on the topic from a different angle!

Search

Oracle MySQL Blogs

MySQL Links

Other Links

Planetarium