Working with people is difficult. Working with people across different timezones is a challenge. Working with people in opposite timezones requires commitment from all parties.
One of my first experiences collaborating with someone on the other side of the planet was the best example of how things should not be done.
My worst experience
Sometimes things pop up at the last minute, and you need urgent help to solve something quickly. On one occasion, long ago, I urgently needed some data that only one person had access to, and that person worked literally on the other side of the planet, with no overlap in our working hours.
I decided to send a message, and the overall conversation went something like this:
Monday
Me: Hi, <some intro>, could I please have <data description>, it’s really important for <project name>, Thanks!
Other person: Sure, when do you need it for?Tuesday
Me: Hi, thanks. I need it ASAP, the project is blocked if we don’t have this data
Other person: Okay, I can send it now. Do you want it in json or xml?
WednesdayMe: json is fine, thank you!
Other person: Can you give me your email?Thursday
Me: My email is jm@example.com
Other person: I’ve sent the email, but the attachment is too large. I’ll have to send it using <another method>. I’ll do that tomorrow.
In the end, I did not get the data by Friday because this other person went off sick, so I actually got it on my Tuesday, one week after the initial request.
You can probably imagine that I was extremely frustrated on that occasion, but over the years I’ve learnt that the problem was actually at both ends.
Making requests
Whenever we send a message, it has to be very clear to ensure that the recipient will process the message in the intended way, but when the message will be read when we’re sleeping (or partying), it needs to be ten times clearer.
In my opinion, this is the key information that such messages should provide, in this order.
What, when, and urgency
The key is to be really brief and to the point, so it’s almost impossible to miss it.
Details
We need to anticipate the needs of the recipient. We need to help them help us.
I find that the easiest way for this is to pretend that we are doing the action, as in a role play game, and consider what questions or alternative options may arise while doing that.
It is impossible to cover every possible question that the other person may have, but we need to try.
CC managers
Sometimes our managers have influence or leverage that we don’t.
If things go wrong and we need to escalate to our managers, we’d have lost one day. Anticipate this by including all relevant managers or people with influence as soon as possible.
It may be that our managers have a meeting we’re not aware of, and this important request can be prioritised by the other team.
If I could go back in time and apply what I’ve learnt, I would send an email like this instead:
To: faraway-colleague@example.com
CC: my-manager@example.com, their-manager@example.com
Hi Faraway Colleague, could you send me the <short data description>? We need it ASAP.The format is not important, as long as we have it soon. If the file is too large, you can use <some data storage> or whatever is easiest for you. Please remember to encrypt the data as per company standards, and share the password separately.
Sorry for the troubles, and thank you,
Jose Miguel
When sending an email, consider sending the message though another medium, usually a chat.
For example, I’d also send this message in Slack:
Hi @FarawayColleague, could you send me the <data description>? We need it ASAP.
The format is not important, as long as we have it soon. If the file is too large, you can use <some data storage> or whatever is easiest for you. Please remember to encrypt the data as per company standards, , and share the password separately.
CC’ing: @MyManager @TheirManagerSorry for the troubles, and thank you,
When sending a chat message, we need to do it in the recipient’s team channel. That way, if the recipient is off sick, some of their teammates can step in and cover them.
In many years following this strategy, only two times I have not received what I needed. The first was because the other person needed some important clarification that I had not thought of. The second was because the other person only skim read my message, and replied with questions that I had already answered.
This method is not bullet proof, because we work with people with their own priorities and commitments. However, it’s given me a success rate of over 99% that I am sure would not have been achieved had I not changed the structure of my message.
Receiving requests
I’ve already shown you how I could have done things better. But the receiver of my request could also have tried harder.
Whenever we receive a request from a different timezone, we must do our best to understand the intent of the other person.
In my example, the other person starts by asking when I needed the data. That question is only relevant if it had been presented like this:
When do you need it? I can’t send it now due to <X problem>, but if you give me your due date, I can try to plan for that.
Similarly, instead of asking for the format, they could have sent the data in json, xml, or both! Asking is just a waste of time. They could have replied:
I don’t know what format you need, so I’m sending it in json and xml. If you need it in another format we may be able to help.
Asking for my email was absolutely needless. They could have checked the sender in the email, or use any other ways to get my email address.
These examples show that my problem was not a priority for them. In any company that values cooperation, we must make capacity to help each other. And if the company works across timezones, there must be a deeper commitment to do all we can to support each other.
As receivers, we need to have a real intent to help, and communicate clearly and promptly if we truly can’t, or when we will be able to reply to the request. Giving useful information is better than just postponing a resolution with useless questions, as the requestor can take mitigation actions based on this new data.
After reflecting on my disastrous interaction, I have come to the conclusion that it went so awfully wrong because neither they nor I knew how to work in a cross-timezone environment.
Working with people in other timezones requires a deep commitment to understand the other person, and the willingness to truly help each other. It’s not like any other interaction, and as such we need to have the right mindset to avoid wasting time.
Whenever you make or receive a request from the other side of the planet, please put yourself in the other person’s shoes. Just doing this will make a huge difference.
Happy coding!
José Miguel