You’re reading an excerpt of The Holloway Guide to Remote Work, a book by Katie Wilde, Juan Pablo Buriticá, and over 50 other contributors. It is the most comprehensive resource on building, managing, and adapting to working with distributed teams. Purchase the book to support the author and the ad-free Holloway reading experience. You get instant digital access, 800 links and references, a library of tools for remote-friendly work, commentary and future updates, and a high-quality PDF download.

Domain Specific Tools

Common questions covered here
What are the best project management tools for remote teams?
What are the best practices for project management tools on remote teams?

There’s a plethora of tools that we have at our disposal for different kinds of work. Tools like project management software, collaborative design tools, distributed source control for code, and others, become communication channels when we’re doing distributed work. Many of these types of tools support commenting, assigning people to tasks, and other means of communication that cross over with the other channels we’ve already covered—and many tools are aiming to handle a broader spectrum of uses, blurring these lines even further. We can’t cover them all here, but a few examples include Basecamp, Asana, Trello, and Jira for project management; Google Suite for documents, spreadsheets, and presentations; Figma and Sketch for collaborative design; GitHub and GitLab for code source control; and many other options.

Domain Specific Tool Advantages

  • Purpose-built. Tools can be better at serving a specific purpose than general-purpose work suites are. For example, project management tools that support collaborative teamwork are generally preferable to trying to keep track of everything in a spreadsheet.

  • Self-contained. important Communication features like commenting or mentioning people allow for information to be shared in the context of the work, which can lead to faster feedback cycles and less confusion about where to look for status or contextual information. This is an important principle of remote work: Keep discussions close to the work at hand. For example, if decisions about a marketing plan or bug fix are happening in Slack, then the context within the more appropriate tool or document is lost, and people relying on those tools may miss critical information or have to waste their own (and other people’s) time hunting down information in side channels.

Domain Specific Tool Risks

  • Source confusion. When teams use too many tools, learning where to find specific information or how to find and log into each one can be cumbersome. This leads to confusion when you end up with multiple tools to track work in progress, or to store files in the cloud.

  • Tool proliferation. As tools become more specialized, they can be harder to use for general purposes, leading to similar tools being adopted by different teams. A source-code versioning tool may be good enough for software engineers to manage changes, but the legal team may prefer to keep using redlining in text documents for their workflow.

  • Overhead. As the tool collection grows, the need for dedicated access management by IT becomes more important.

  • Questionable reliability. Startups in particular are often early adopters of new tools. But sometimes newer companies that produce these tools are bought or shut down, leaving teams scrambling to figure out what to do with all their information.

When to Use Domain Specific Tools

Tools for project management, sharing designs, or tracking technical issues are a big chunk of your communication architecture, largely for:

  • Asynchronous status and context on projects.

  • Asynchronous questions and communication specific to team projects (as opposed to more general company-wide Q&A).

  • In some cases, synchronous collaboration, such as within a design tool or whiteboarding app.

Tips for Domain Specific Tools

  • Project management tools are only useful if the state of work in progress is represented accurately. Ensure that the state of your work is reflected on the tool as soon as you start or stop working on it, so others can rely on this information without asking around.

  • If you encounter information relevant to tasks in other tools, consider moving and reflecting it in the relevant tool or channel so others can have access to the same information. For example, if the team is discussing a particular GitHub issue in Slack, be sure to link to it in the chat, and direct the team back to the issue for discussion.

  • Evaluate your company’s tools occasionally. Especially at a growing startup, people’s needs will change and evolve, and while it’s important to allow teams to use the tools that make them the most productive, there’s a balance to strike when information starts getting scattered or hard to track across a multitude of tools.

Further Reading on Domain Specific Tools

Determining Your Communication Architecture

In order to determine how best to communicate, you will need to inventory the tools and channels your company uses, and pair those with your own values and communication philosophy. This should apply to everyone at the company, including in-office employees in a hybrid environment.

Here’s an example of what a more traditionally co-located communication structure might look like:

Figure: Co-located Company Communication Channels and Tools

You’re reading a preview of an online book. Buy it now for lifetime access to expert knowledge, including future updates.
If you found this post worthwhile, please share!