# On working with international clients

The internet enables us to work with people from all over the world. Though this is becoming more common, there are subtle gotchas to look out for when you don't have the luxury of semi-frequent face to face meetings.

I started freelancing in 2008 and have worked as a developer and as a project manager in different types of settings. Some were remote, some were on-site but working with a remote team or client. Here's how to make that go smoothly:

# Building trust is key

Seeing international clients face to face is seldom common. If there's the luxury of a travel budget for the project, it's a great idea to plan a kickoff workshop on-site. Thanks to the additional non-verbal communication and the comittment to create a relaxing setting you can learn a whole lot about each other - even in a single day.

With or without (in)frequent face-to-face meetings, building trust is key when setting out on a new project. Here's some things that facilitate that:

• Always make good on your promises and communicate asap if you can't make good on them - clients are assured by predictable behaviour from you.
• Make smalltalk - you're a person and so is your client. Getting to know a bit about each other helps put things into perspective later on.
• Focus on delivering value as soon as possible, even if it's small. Showing that you're doing good stuff for the client is better than telling them it's coming.
• Review the relationship - there's nothing weird about asking "how do you feel it's going lately?" and giving your client the opportunity to voice concerns.
• Celebrate victories, both yours and the client. Got the first positive review about or reached a milestone with the product you're building? Claim your fame!

# Make sure you have great audio

You don't truly appreciate the range of the human voice until you try to cram it through a $15 bluetooth microphone. And even if you use a slightly better set, your voice can seem 'off' in all sorts of way. Considering you'll be on a call somewhat frequently and at times at length, it pays to invest in a good headset.

My current setup is a simple HyperX Solocast paired with the excellent Audio Hijack to remove some of the background noise and electrostatic hum that the mic picks up. It's an inexpensive solution that works in a variety of settings with little to no latency.

Speaking of latency, as any gamer knows the best option for reducing latency is calling from a laptop/pc wired with an ethernet cable. The further away your client is calling from, the more latency will already be on the line due to the distance audio needs to travel. No need to add 100-200ms additional latency by using a bluetooth headset (though specialised codecs like Qualcomm's aptX reduce this to ~40ms).

Finally, I highly recommend looking into acoustic room treatment when you're working from home. Most rooms greatly benefit from a couple of absorption panels, it will make your room sound less dead because it absorbs flutter echo. Though mostly to reduce distraction and fatiguing from having to 'filter out' these sounds (of which you're often not aware until you know what to look for), it makes a subtle difference on conference calls as well as your voice sounds 'warmer' to attendees.

# Be mindful of cultural differences

Cultural difference can trip you up in a lot of unexpected ways and when you're working together remotely, it may not be so apparent that something has gone astray. It pays to read into the culture of your client a bit. Though you should be wary of applying generalisations onto specific situations, it gets you thinking and puts things in perspective (even if your client deviates from 'standard' cultural practices).

A great book on this is The Culture Map which dives into the interaction between different international cultures. Particularly interesting is the distinction between 'high-context' and 'low-context' cultural approaches to communication.

# Put together a rolodex for the project

Inevitably, someone in the project team will need to reach out to someone that isn't on their "frequent contacts" list for a project. Especially when dealing with somewhat urgent situations (where you need a phone number) you want to centralise that information in a single place, that's easy to access (e.g. no VPN connection required). A Google Drive document works well for this. Be sure to include some brief background on the persons on there. Even just adding the role (e.g. "Lead front-end developer") will help decide if you have the correct person to contact.

# Visuals are often preferred over text

A visual can convey a lot of information and is usually faster to grasp than text. I find a tool like Skitch to be invaluable in reporting bugs or explaining features as it allows me to capture a screenshot and annotate it with arrows and text. Sure, it looks ugly and the message is a bit "in your face". But it gets the point across quickly:

# Have a system to clarify urgency

People in a position of power don't always realise the weight their words might carry. A client or boss mentioning a bug might do so expecting it to be clear that this needs to be picked up ASAP. Then again, they might also just be notifying you of its existence and expecting it to be dealt with at time and as the team sees fit.

Generic guidelines can be a great help in situations like these. Instead of having to guess intent, there is a default way things get handled and should someone (e.g. the client) find it important to deviate from those it needs to be explicitly stated.

Systems can be as elaborate as simple as you see fit. For example: I once had a client that just used numbers 1-5 to indicate priority of things they mentioned toward us. For bugs we agreed they got put on the backlog ordered by the priority number - with the exception of production-breaking builds which would get picked up straight away. I never went as far as to create a flowchart for a simple guideline system as this but for slightly more complex patterns there's value in having that too.

# Involve the client in the work

The further a client is away from your daily practices (which can be encumbered by time zones), the more important it is to involve the client in the work. It's good to be proactive and make decisions (you don't want to be blocked every time you need input) but in my experience that can lead to the client feeling disconnected.

Just the simple act of sending a frequent update, confirming assumptions and asking for opinions, can go a long way here. There's a lot of ways you can involve the client in the project and what way fits depends on the specific context of the project. The important thing is to make a conscious effort to involve the client in the work since at the end of the day it's still their project that your team is executing.