11 Ways I Use Loom as an Engineering Leader

Async video messaging is all the rage these days and Loom is one of the leaders in the space.

But many of us struggle when trying to figure out what to “loom” about.

I struggled too, but I’ve finally figured it out. Here’s what I learned.

It’s crazy to think how Loom, a simple video recording tool, has become such an integral part of my day-to-day communication.

Its friction-free workflow has made async communication a breeze. Plus, video is a way more powerful way to communicate than plain text.

Sure, Slack is great too, and you can’t replace the convenience it provides. But some things are just better communicated via video than text.

How do you decide what to Loom and what to Slack?

It can be hard to decide which is the better tool to use in different situations.

On one hand, using Loom for something you can type in a sentence creates a lot of unnecessary burden for your audience and makes future documentation and search much harder.

On the other hand, there’s nothing worse than having the tone or intent of your message misinterpreted when using written communication. Not to mention how inefficient it is trying to “use a thousand words to describe a picture.”

Here’s a simple heuristic I use:

With this in mind, let’s dig a bit deeper into the different categories of “looms” I usually record.

Building Software

Pull Request Descriptions

PRs are easily one of the best ways to use Loom as a software engineer.

Why?

Because you can provide much more clarity and save time. You have all the context and remember all the decisions you made for each tradeoff you considered. Plus you can much more easily ask targeted questions.

Github sorts your code contributions by file name, not by how your code flows – and how could it?

Even if you write good commit messages, still you are putting the burden on your code reviewer to figure out how the new changes work. Plus they need to know how the rest of the application works, beyond the code you changed.

No wonder why it takes sooooo long to review PRs.

So, how do I use Loom to solve this?

In most of my PRs (especially the larger ones) I create a short loom where I include:

• A quick demo of my changes, whether that’s UI updates or API responses
• The logical flow of the code I’m committing
• Mentions of specific decisions I made
• Questions for the reviewer’s considerations for things I’m not 100% confident about

Here’s an example, using a PR of an opensource project to help you get a sense of what this might look like:

Note: It’s easy to ramble and share too many details in a Loom which may not be useful for a reviewer. Before recording, consider the specifics of what you want to share and try to be concise. I usually jot down 3-5 bullet points which I keep out of frame and reference as I record. Remember, your Loom is there to make the process faster for the reviewer. These are the notes I took for the above example:

- moved commonly used methods to gatsby-core-utils
  - fixedPagePath & generatePageDataPath
  - gatsby-core-utils/src/page-data.ts
- also wrote tests
  - packages/gatsby-core-utils/src/\_\_tests\_\_/page-data.ts
- replaced the usages in several files

Code Reviews

Similar to PRs, Loom can be useful when you are the reviewer.

Although most of the comments I leave are short and straightforward, in cases where logic is more complicated, leaving a multi-paragraph text comment may not be as productive.

In these situations, I usually create a loom where I explain my thought process and ask questions, offering my perspective on the different options I see.

I could very well be missing something so pointing that out in a Loom seems to be a good way to keep the code review collaborative and productive.

Architecture RFCs

Another great way to bring clarity to your engineering team is by using Loom for architecture discussions and RFCs.

If you are like me, you probably create a document to propose the new and complex system you want to put together so that you can share it with your team and get feedback before starting to build it.

This RFC is usually in text format and might contain visuals, charts of how the old system used to work and the new additions you are proposing.

RFCs are great because they can be specific and quite thorough. They can also be quite intimidating and reviewing RFCs may be time consuming, especially when you don’t have as much context.

I use Looms as a form of executive summary, to highlight the key pieces of the architecture, illustrate in a friendlier format the flows of information, and highlight key tradeoffs that I’m considering or request specific feedback for areas that I’m not totally certain about.

Demos

Who doesn’t love checking out shiny new features?

I’ve found that creating a video recording demoing the new things I’ve worked on is a great way to share the win with the team but also communicate upwards our achievements. Also, when appropriate, you could also share big releases outside the company.

It’s easy to imagine demoing a new UI. You just create a Loom screen recording of yourself going through the new feature and talking about the new functionality it introduces.

Here’s an example demoing the Meetings tool by HubSpot

But how do you showcase backend work?

It’s not as hard if you focus on both impact and effort*.*

To figure out what the impact was, I ask myself:

• What are the benefits of the thing I built?
• Is it enabling new functionality in the UI?
• Was there a significant performance gain? Do I have a chart I could show?*
• Are we saving money?
• Is it making working on the codebase easier? How hard was it before?
• If it’s reusable, how many other teams are using this code?

My favorite way to demo backend changes is with a “spot the deploy” chart. Here’s an example. Can you spot the deploy? The chart speaks for itself, right?

To communicate effort, I consider:

• Was this a simple change or did it involve a massive rewrite?
• How easy was decision-making? Did I have to collaborate with other people/teams?
• What technologies did I use?
• What tradeoffs did I consider?
• Did I have to do a lot of research to transition from a solution that “just works” to something more elegant and efficient?

Team Collaboration

Questions and Bug Reports

How many times have you come across something that seems broken or works in a way you didn’t expect?

Whether that’s recording your interaction with a UI or code that seems to be buggy or unreasonably convoluted, Loom is an excellent way to document it within its context and by providing visuals.

Here are some more ideas:

• This feature seems broken. Is it? Should we look into it?
• What was the intent of this piece of code? Can I change it or remove it?
• I have many things on my plate. Which one should I prioritize?
• Have we considered the following edge case?
• This design element is hard to implement. Could we consider building it another way?
• I’m not sure I understand how this system is architected. Do I have this right?

Status Updates

Why spend 30 minutes for synchronous standups when you can record your updates and share them asynchronously?

Besides, in my experience, most of the time people make up things on the spot or forget to share important updates.

Why not just let them gather their updates and then just watch them at a convenient time?

I know you’ll push back by touting the benefits of identifying blockers and solving them live during the meeting.

Sure, you can still identify blockers and meet as a team. But now you can be focused on solving problems or even team bonding rather than zoning out as your teammate talks about the minutia of the things they are working on.

Oh, and don’t forget that you can rewind a Loom and watch it as many times as you want.

Team Broadcasts and PSAs

Looms are an excellent way to share team updates and PSAs. I usually share things like:

• Welcoming a new team member or sending off an intern that’s going back to school
• Sharing updates about broader initiatives
• Congratulating the team on a big win
• Sharing learnings and ponderings from recent events
• Being transparent about issues that concern team members
• Hyping the team about new initiatives
• Announcing an upcoming team event

Tips and Tutorials

From time to time, when I figure out a more efficient way to do something, find a nifty tool that saves me time or come up with something that reduces friction, I usually want to share it so others can also benefit from it.

It could be all kinds of things like using Alfred workflows, creating abash script that automates common tasks, figuring out a better way to search on Github, coming across a useful IDE plugin, or even a template to document a process (like my monthly engineering performance deep dive.)

External Communication

Recruiting Messages

Looms are an awesome way to make the candidate experience feel more personable.

You can use them in place of an email, especially for candidates you really want to close.

Put yourself in the candidate’s shoes:

You receive a personal video message from your prospective manager or team member saying that they really enjoyed talking with you and they’d be looking forward to working with you. Isn’t that aaaawesome?

And you don’t need to be too fancy. A short 30-60 second message should be more than enough.

Here’s the script I used:

Hey Anna, I just heard the news that you received a verbal offer and wanted to take a moment to say congrats!  It was clear that you are a really strong engineer and it was awesome to hear you talk about solving for the customer. I really think you’d make a great addition to the team and hope you decide to join us! If you have any additional questions just email me and I’d be happy to hop on another call. Have a great day!

See? It doesn’t have to be anything too complicated. Try it next time you decide to extend an offer to a candidate you interviewed.

Social Media Updates

From time to time, I like to share updates on social media, usually LinkedIn. It could be things like new features we launch and company updates.

They are a great way to share with your network cool things that are happening and build up your professional portfolio of wins.

And trust me, they are more engaging than a simple text update. Waaaay more engaging!

Here’s an example from this LinkedIn post:

To sum up

Loom is a very powerful async video messaging tool that has helped me collaborate better with my team and communicate in much richer ways, particularly in a remote or hybrid work environment.

Hopefully these 11 ways I use loom as an engineer and leader has given you inspiration to try this yourself and supplement your chat and sync meetings.

This post was originally published on August 18, 2021

---