Effective communication while freelancing
Does this sound familiar? You’ve started a new project with a new client. You’ve got your backlog to work on and you get to work. You get into the groove for a week or three and rock out a bunch of those tickets or get that awesome feature nearly complete. And then you log in one day to find a dreaded meeting invite to talk about your performance — or worse, just an email saying the client no longer has need of your services.
Photo by Austin Distel on Unsplash
What happened? You thought you were doing great! Maybe you manage to get feedback and are told you weren’t communicative enough. But you left detailed notes in the tickets and pull requests! How can they accuse you of not being communicative enough?!
Or, moving forward, how can you prevent that from happening again?
When making the transition to remote working, everyone says “over communicate,” but what does that actually look like? There are both general and specific ways this can be done. Let’s take a look at some of them.
Good communication starts before you get the gig
This is the case even if you work a conventional job, but goes doubly so for freelancing. Good communication starts by accurately representing yourself from the beginning.
There’s a lot of temptation to embellish one’s credentials. Not to lie, per se, but to perhaps imply or make it seem like you’re more of an expert than you really are in a topic. Don’t. If you only have cursory knowledge of something, be up front about it (and be clear when you’re open to learning more about it or if it really doesn’t interest you). You’re really not expected to know everything about everything (and anyone who does expect that probably isn’t worth working for or with).
Own what you know. And own what you don’t know.
Make communication a habit with daily check-ins
I like the SCRUM-style “standups,” even if there isn’t a SCRUM/agile process in place. You don’t need to be all formal with it. You don’t even need video chat for it. As long as you have a communication platform to use, you can do it.
Your daily check-in is simply a highlighting of what you’ve done, what you’re planning on doing, and any blockers. I literally post something in Slack like this each morning:
Yesterday: Got the e-commerce widget doing the thing! Also started on the cart thing and took a look at the media widget bug. That bug appears to be more than just a code issue, so I talked to Joe about it and he’s going to take a look at it on the media end.
Today: I should be able to finish the cart thing today, barring any unforeseen hurdles. If I have time, then it’s on to the slider.
Blockers: Nothing completely blocking me, but I know Joe’s got a lot on his plate, so I don’t know if he’s going to be able to get back to me on the media widget bug in time for it to get fixed by the end of the sprint.
That’s all there is to it! The base formula is the key and provides the team and project manager with key information about where you’re at. If anyone needs to follow up with you on something, then they can do that with an idea of where things are.
Don’t forget to communicate your other habits…
Not those habits! Seriously, no one needs to know those ones.
I’m talking about your workday habits. When does your work day generally start and end? When do you generally take lunch? Do you have other obligations that take you away from your desk during your normal working hours? Do you set aside distraction-free time? (If you don’t and you’re a maker, you should!)
There are a few ways you can communicate these.
Some people use calendly or other scheduling applications and run all of their meeting invites through them. This has the perk of only allowing people to schedule in the windows you set, and removes options when you’re busy. There are also all sorts of customization options (like meeting lengths and whatnot) that can be useful. For others, sharing their calendar is not only sufficient, but most efficient.
For anything that is either a one-off or doesn’t communicate well via the standard calendar interfaces, I simply leave a note in the client’s Slack and have reminders periodically. For example, the project manager at one client was looking to schedule a meeting on a Thursday. Thursdays are half-days for me, because I do volunteering those afternoons. So, in the chat working on scheduling, I sent a message that said, “just as a reminder, my office availability only goes until 12:30 EST on Thursdays.”
…and preferences
Do you only begrudgingly use Slack for communication? Maybe you have your email workflow set up just so and it automatically puts things into Asana tasks. Or maybe you hate text communication in general and would prefer to do nearly everything in video or voice.
Tell them. And own your “why.”
What do I mean by that? I mean, don’t apologize for advocating for your best workflow or your needs.
I communicate best over text in one form or another, because I can organize my thoughts best via text, and edit what I say to ensure a level of clarity I can’t always achieve via speaking. Yes, I’ve told clients this.
Some flexibility is needed, of course. Accommodating best workflows is a two-way street, and sometimes you’ll need to accommodate someone else’s or otherwise work in your non-best communication format. It helps to rank your preferences and be able to briefly explain why you’ve ranked them that way.
For me, for example, text is first (Slack or equivalent is ideal, but I can make email work), followed by in-person, with video chat a close third, and phone call a fairly distant fourth. Oddly, the video chat doesn’t need the people cameras on. I think it has to do with the ability to screen share what’s being discussed, which often occurs in video chats in which I’m involved. I can then explain about my preference for text, then include the option for in-person (if applicable) or video chat, and where those fit best into my workflow and preferences. This allows me to advocate for my best environment, while allowing some room for mindful compromise when needed.
Keep detailed logs
Timesheet logs, git commits, bug tracker logs, etc all help create a nice paper trail and progress tracking. These methods are a passive form of communication and shouldn’t be relied upon solely, but they do serve the valuable purpose of providing a detailed log of the work you’ve done that you can draw upon for any reason.
For source control, specifically, this gives new meaning to the “commit early, commit often” developer mantra. I’ve taken to splitting my work into more smaller commits that can help keep me from glossing over work I’ve done. Contrary to my personal projects, which admittedly often have some large commits with vague messages like “did some updates of stuff,” I put more effort into breaking down commits into more atomic pieces. Some of my commits are a single line in a single file, because it didn’t really relate to the work in the other commits (often, it’s a small bug I encounter, documentation update, or the need to add something to gitignore), but wasn’t really big/crucial enough to warrant the overhead of its own ticket and pull request. The dedicated commit not only puts it up front to be seen, but also allows for the project maintainer to cherry-pick it out if they (or the team) decides that even though it’s small, it’s significant enough to warrant its own pull request and ticket. These smaller commits also make a nice auto-populated list in the pull request in Github, Bitbucket, etc. Automatic changelogs for the win!
Ask questions (lots and lots of questions)
This is always a difficult one for people earlier in their career, especially. A lot of people are afraid to ask questions, because they’re afraid of looking incompetent (taken to more of an extreme, this is often an aspect of what’s referred to a “impostor syndrome”). You were hired, after all, to be the subject matter expert, right? You’re supposed to know what you’re doing and (so the anxious logic goes) if you have to ask questions, then you’re not actually the expert.
That couldn’t be farther from the truth. While you should be beyond the basics like “how do I make a commit in git?” You’re not going to magically know the client’s current workflow or environment. You might not know about the specific way they implemented a particular feature, even in the framework or language that you have extensive familiarity with. You might even uncover a gap in their documentation or process that they weren’t aware of, because of things they had in place before they first implemented the process that caused it to succeed when it should have failed.
Learn to communicate over text
Text communication is a different beast from in-person communication. You don’t have the benefit (or overhead) of body language, tone, and the myriad other ways humans communicate in addition to and instead of words.
Before your first remote gig, join and be active in a Slack group or three (or similar online communities) and practice holding discussions over text in a quasi-professional setting. Any group with a regular practice of healthy and constructive debate–as well as a Code of Conduct–will suffice. The purpose is to learn how to take part in the sometimes-contentious discussions, while still maintaining your ability to be understood by others. You’ll also learn how to engage in more playful banter without being misconstrued. The skills you learn in these groups will help hone your communication skills at work, allowing you to avoid misunderstandings and smooth over minor ones that do arise.
Don’t be afraid to switch to video/voice chat
Sometimes, misunderstandings happen and the best way to resolve them is with a spoken conversation. The more you practice text-based communication — and the more you get to know your client — the more readily you’ll be able to tell which misunderstandings need which action. However, when in doubt, ask for a quick video call.
This is useful for getting some questions answered, too. Sometimes, a text description of a problem just isn’t enough to wrap your head around the concept or problem being shared. There’s no shame in telling your coworker, “hey, this isn’t computing, can we hop on a screen share real quick?” As they say, a picture’s worth a thousand words (and if a picture is worth a thousand, how many is a video worth?).
Learn to communicate asynchronously
Believe it or not, text chat isn’t synonymous with asynchronous communication. If you’ve ever been messaged, and then messaged again within a couple of minutes because you didn’t respond fast enough, then you know what I’m talking about.
Communicating asynchronously works a little differently than synchronous communication over text. The core idea is that when you send a message to someone, you don’t expect an immediate response — and you need to adapt your own behavior to match.
First, don’t just say hello (or some variation of it). Attach your message to your greeting instead of waiting for a response. Also, just saying “hi” in a text chat, especially a direct message, and especially if it’s your first one to the person, is kind of creepy.
Second, consider what you’re trying to ask, what context the other person doesn’t have, and how to pre-empt those additional questions. Both Tim Ferriss and Ramit Sethi (among others) encountered and talk about this in their respective blogs (and, in Tim’s case, in 4 Hour Workweek), as well as [Ramit guest writing on Tim’s blog](https://tim.blog/2010/11/02/virtual-assistants/). They talk about this within the context of virtual assistants, but a lot of it still applies to asynchronous communication, especially when spanning many timezones.
The key here is to front-load as much information as you can, so that you avoid time-consuming back-and-forth messages to answer questions (each of which may be time-delayed by upwards of a full day).
This also means being asynchronous with your work — learn to anticipate blockers caused by other people and start moving to get them unblocked before they stop your work entirely. Look through your tickets and ask questions for more information/clarification before you start actively working on that ticket, so that people have time to respond. Have a backup task lined up for when you get stuck on a task and need to set your main one down pending a response from someone.
Conclusion
Communication will make or break remote relationships. Don’t wait until you’re standing in the rubble of an otherwise fantastic client to improve your communication habits. Being mindful, honest, and proactive will go a long way toward building trust and keeping happy clients.
Interested in working with Shauna, or one of our other amazing devs on Gun.io? We specialize in helping engineers hire (and get hired by) the best minds in software development.