“If you’re bolding the bullet points in your email” said a friend of mine recently, “your email’s too long.” Few web workers would disagree. But all the same, as a blanket statement, that comment made me wonder whether the tools we’re using to communicate are becoming more important than the communications we’re having.
Businesses approaching a market will consider the audience’s media usage, and the message they’re communicating, before they choose a communications tool. But in distributed teams, we may choose collaboration tools for their own sake — their features — rather than their suitability to the tasks we actually need them to perform, or the team we need them to support.
The Limits of a Tool-Driven Approach
Tools are not the process, nor are they the work. Tools are there to make complex tasks easier or more efficient for your team. On paper, that differentiation seems clear, but in practice, it can quickly become muddied.
For example, a considerable influence on the way teams choose tools is, often, how they hope those tools may be able to change team members’ behavior or communications, rather than because they suit the team’s current or preferred ways of collaborating. We might also choose tools we feel will alter the actual process we’re using in some crucial way.
The problem with this approach is that it can be difficult to separate the tool’s problems (or benefits) from the process’ problems (or benefits), and that has the potential to mire the team in confusion and error when things go wrong.
Similarly, you may inadvertently diminish the benefits of either the tool or the process by discarding one, but sticking with the other on the misunderstanding that it’s that part of the equation that’s delivering the benefit.
Riskier still, using a tool-driven approach to actually evolve work processes puts the responsibility for the robustness and longevity of your business processes at the feet of third-party software developers who may never have heard of your organization, and — who knows? — may no longer be developing their product in six months’ time.
Taking a Tools-Last Approach
For these reasons, it is more sound to develop processes around your people — who, after all, you need to do the work — and the outcomes you desire. Then, you can identify the formats in which you need those outcomes, and finally, search for tools that will deliver outcomes in those formats.
In finding starting points for the tools you want to consider, why not look at the tools your team’s already using, and balance those against the project’s individual requirements and characteristics? Looking at what’s working now, and how your team functions now, can give you clear ideas about what your people need to get their jobs done well and happily.
In particular, consider:
- The learning curve and usability of a tool. Choosing tools that are already used by some team members, and have good usability in and of themselves, will reduce the cost to the business of the tool’s adoption. That cost isn’t only apparent in the days following the tools’ inception within a team, and it doesn’t always relate directly to a time-cost. Errors relating to tool adoption can damage everything from data to brand, and may arise months after the tool’s adoption.
- The re-usability of the information you put into it. Getting team members to put information into the tool you’ve chosen is only one part of the equation; the other is getting that information out. Consider the possible scenarios in which you might need to do this — for reporting purposes, if you switched to use a different tool or changed the process in future, to create a project output, and so on — and assess how manageable the job would be. The trend toward smaller, lighter solutions that produce output quickly may not be right for you, if your requirements are demanding, so it’s important to consider the realities of your needs, rather than simply getting caught up in the latest-tool hype.
- Its cost versus its adaptability to other projects or teams. The adoption cost of a tool — in terms of subscription fees as well as the time-cost of its uptake by your team members — would, ideally, be offset by its adaptability to other projects your team might be working on, or to other teams within your organization. Be careful when you’re making this assessment, though: it can be a fast-track to misappropriation if you don’t consider for each possibility of adaptation the points we’ve discussed above.
How do you go about choosing tools for your team? Do you select tools in the hopes that they’ll benefit your process, or do you build your process first, and choose tools to suit it?