Optimise the way you ask for things to improve the likelihood of getting the response you'd like.
For remote teams, or anyone tasked with asynchronous communication, this has never been more important. My tool of choice for this has long been Loom. Creating a to-the-point video is faster than text for you to author and the recipient to consume.
At Sanity (and at my previous jobs) I’ve received positive feedback on the quality and brevity of the Loom videos I create. In my role as a Solution Engineer these videos communicate ideas to clients and bug reports to colleagues.
So, prompted by that feedback the following is my attempt to distill what I think makes a good "ask" in general, and a good Loom specifically.
Disclaimer: There are affiliate links to Loom in this blog post as I have recently joined their Partner program. However I wrote this post before being accepted into the program and have used Loom for 2 years. It's great!
Loom is the fastest way to create short form video content without losing the context of what you’re doing.
The App's icon is constantly in your toolbar so you can start recording a video at the same moment you need to. Once you're done, a shareable link is copied to the clipboard. Should you need to make some light edits, the in-browser tools are handy too.
While there’s other screen recording tools available, Loom’s my favourite for the uninterrupted workflow of creating, restarting and sharing clips.
I also find it superior to starting a video call in circumstances where I need colleagues to give feedback on an issue. A video call is a context-breaker for everyone involved. Asynchronous video allows people to consume content and respond in their own time.
Consider the amount and types of information that you can convey in a 60 second screen recording with voice over.
The comparative amount of text would likely take many minutes to type, proof read for grammar and spelling, proof read again for tone of voice, plus some amount of time to second-guess what you’ve written and then the amount of time your finger hovers over the “send” key while you generate self-doubt.
(And yes, I’m aware of the irony of authoring this blog post in text to advocate against text.)
Text is not only time consuming to author, it’s an effort to consume.
Reading a wall of text asks the author to understand your tone or point of view from words alone. As well as the context of what you’ve written without the context of what you’re seeing.
Why not video?
Any outcomes reached from a video-based conversation should be written into text so they are indexed and searchable.
This article isn't to say that all text-based communication is bad, it’s just occasionally suboptimal when you’re asking for something.
Both text and video communication share a common issue – liklihood of a response diminishes linearly with how much you create. No one wants to read a wall of text or watch a 15+ minute video.
Empathising with your audience
One of Sanity’s core values is “Embody Empathy”.
Empathy is a value that takes many forms. Perhaps asynchronous communication isn’t the first lens through which you'd think about it. But it plays a great role in how you talk, and what you say, because to embody empathy is to consider your audience.
A common tip to improve writing blog posts is write to a single person.
This can be true also of recording video. While your video might have a large audience, record it as if you have a single person in mind.
- How busy are they?
- How urgent is the information you have to offer them?
- How much are you asking in response?
- How technically prepared are they to receive this information?
Keeping this person front of mind can directly influence the quality of your ability to ask. It should impact:
- How well you understand the context of what you’re asking
- How much time you’ve prepared in advance of recording to keep the message concise
- How many assumptions you make about both the recipient and what you’re describing
If your recipient is busy, but you talk like you’ve got time to waste. Or your ask is uninformed and overly opinionated to an audience of experts. Don’t expect a great response to your ask.
Make your point and move on
I still don’t believe Twitter got better when they moved to 280 characters and threads.
Enforced brevity was just enough friction for most authors to consider ways to make the same point in less words. The result is making the same point in less time. The best tweets aren't verbose, they're easily consumed.
(As an aside, Twitter's a great argument against text-based communication of big ideas. How often are threads used to clarify the intention of the original tweet?)
Similarly, Loom’s limit of five minutes for free users is a feature – not a bug. (It’s the 25 video total limit that’ll get you upgrading.) Five minutes is a really long time. Any video longer than five minutes is a webinar – and no one likes webinars.
Don't fill space with empty words.
Try not to repeat yourself. Here’s some things you can do instead of saying the same thing twice (or three or four times):
- Take a breath
- Stop talking
Hit record, describe your ask, hit stop.
Homework: Talk through a translator
Perhaps the most formative experience I’ve had in communication is teaching through a translator. That is, speaking in short statements that can be translated back-and-forward to an audience.
This requires pausing before you speak, to ensure you can capture a complete thought in a single statement. And again to ensure the audience has understood that statement before moving onto the next.
You may find how much you rely on idioms to communicate concepts.
Or how often you repeat yourself to say a single thing.
For example, if you’re prone to statements like “This is a huge, really big, massive problem!” there's a way to say that in less words.
Distilling what you say down to single statements, with considered pauses between, can clear up the way you communicate dramatically.
Perhaps imagine the next video you author needs to be short enough for the recipient – a translator – to listen to, understand, and repeat in a different language. You’ll likely use fewer words, chosen more carefully!
Prepare but don’t rehearse
Good cooking shows typically don't show the host formulating the recipe – or measuring out the ingredients – it starts with Mise en place.
If you’re reporting a bug, no one wants to watch a video of you figuring out how to reproduce the bug.
On the other hand, it’s not worth the time to prepare a scripted short film on the history of software bugs delivered with a lifeless presentation.
Prepare yourself to make your point in a concise way before you hit record, but don’t spend 10x the time preparing for the video as you do recording it.
Loom provides a keyboard shortcut to restart (
Cmd+Shift+R) which I’m prone to use if I really mess up in the first 10-15 seconds.
But after that, even if I stumble over some words, so long as I can still get the point across, we’ll do it live.
Practice for progress, not perfection.
You’ll get better with every video – but no one is expecting a Hollywood-grade video each time you have an ask.
A real world example
Let me be clear, I still get a lot of the above wrong – regularly. I’m prone to the odd text-only context-free “Why is this broken?” in Slack. But I’m constantly trying to improve!
When I actually need someone’s attention – and a response – I'll record a Loom.
Below is an actual Loom I recorded along with an internal bug report ticket.
I could’ve rerecorded this to make it share-worthy, but that would’ve robbed it of authenticity. The audio glitch in the first few seconds is from editing out the Client's name.
Thankfully, this was a bug and was able to be fixed for the client on the same day!
If I take the time to clearly distill the problem, it makes it easier for engineering to resolve, and help our client. It’s a win-win-win.
What is it about this video that I think made it a successful ask?
- Less than 60 seconds long
Not every video can be this concise of course, but it’s the sweet spot for a quick response.
- Preparation, not performance
I spent maybe 10 minutes before recording this video making sure I had the most distilled version of the bug possible on screen and ready. With every piece of context clearly visible on screen too. You can see what I’m describing in the App UI, as well as in the code.
- Assumptions can be off-putting, hesitate making them
When I made this video I wasn’t sure if this was a bug or feature – and didn’t want to assume either way. Sometimes you’ll know (like if the app crashes) but when you don’t, it’s not helpful to alienate the recipient by assuming something they don’t see the same way.
- Explain the value of a response
The point is made at the start that there is a customer that has reported this bug, and they’re impacted by it. The value of addressing this issue is a happier client.
If you're interested in improving your tooling for asynchronus communication you really should sign up to Loom.
But also, no matter what tool you use. Speak clearly, to the point and to a person.