From the preceding examples, we can distill a few principles of collaboration tools:
Good tools get the fundamental units of information right.
For example, with commit emails, the fundamental unit is the change (or "changeset"). When the tool failed to treat each change as a single logical entity, and instead divided it across multiple interface access points (in this case, emails), people became less inclined to inspect the change.
Getting the fundamental units right does not merely make individual tool usage better. It improves collaboration, because it gives the team members a common vocabulary for talking about the things they're working with.
When you see necessary tasks being repeatedly postponed ("I'll try to get to it this weekend … "), it's often a sign that the tools are forcing people into a higher per-task commitment level than they're comfortable with. Fix the tools and the postponements may go away.
The Contribulyzer didn't help with any of the interesting parts of evaluating a contributor's work: one still had to review the actual code changes, after all. But it did remove the uninteresting part, which was the manual search through the revision control logs for that contributor's changes. That dismaying prospect, although less work than the actual evaluation in most cases, was significant enough to be a gumption sink, in part because it's simply boring.
Removing it, and replacing it with a pleasant, lightweight interface, meant that team members no longer had to make an emotional commitment to a major effort when deciding to evaluate a contributor. Instead, it became like a decision to sharpen a pencil in an electric sharpener: there's no effort involved in starting up the task, you can stop in the middle and resume later if you want, and you can do as many pencils as you want without multiplying the start-up overhead.
When your team starts routing around the tools you've offered them, pay attention: it may be a sign that you're offering the wrong tools.
Not always, of course: there can be cases where people don't initially appreciate the benefits a tool will bring, and need to be taught. But even then, the tool is probably at least partly to blame, in that it didn't make the benefits clear enough from the outset. At the very least, grassroots workarounds should make you sit up and investigate what's motivating them. When the French translators of my book defected to a wiki-based interface, at considerable start-up cost to themselves, that was a clear sign that something was wrong with the interface I'd been providing.
A change in a team's demographics may require a change in tools.
With those XML book chapters, as long as the "team" consisted of programmers who had prior experience working with version-controlled XML files—which was the case for as long as the team consisted only of me—the tools I'd set up were fine. But when new people came on board, simply extending the existing framework was not the right answer. Instead, the tool environment needed to be rethought from scratch.
Partial automation is often enough to make a difference.
Designers of collaboration tools love 100% solutions: if something can be fully automated, they feel, then it should be. But in practice, it may not always be worth the effort; a hybrid model is often the better choice. If you can get 90% of the benefit with 10% of the effort, then do just that much, and remember that the team is willing to make up the difference as long as they'll get clear benefits from it. The Contribulyzer, for example, completely depends on humans following certain crediting conventions when they write log messages. It takes time and effort to teach people these conventions. But the alternative—a fully automated intelligent project watcher that infers connections between mailing list messages and commits—would require a huge amount of effort with no guarantee of perfect reliability anyway.
Actually, that's one of the often overlooked benefits of hybrid tools: because they cause humans to stay engaged with the data at more points, such tools can prove more reliable than allegedly fully automated ones. The point of good tools is not to make humans unnecessary, but to make them happy. (Some might say "to make them more efficient," but an inefficient team is rarely happy anyway, and you surely wouldn't want a team that is efficient but unhappy.)
Despite the benefits to be had from good tools, my experience is that most teams' actual tool usage lags behind their potential tool usage. That is, most teams are failing to take advantage of potentially large multiplier effects. I think this is because of two built-in biases shared by most humans.
One bias is that trying new things costs too much. Since most new things are likely to bring little benefit, groups tend to be selective about adopting new tools, for the overhead of changing habits can be a drag on both productivity and enjoyment. (I do not mean to imply that this bias is unreasonable. Indeed, it is usually well founded, and I share it myself.)
The other bias is subtler. Because successful tools quickly become second nature—blending into the mental landscape until they are considered just part of "the way things are done"—people can easily forget the effect a tool had at the time it was introduced. Examples of this phenomenon are not hard to find, starting with the text editor in which I'm writing these words. Fifty years ago, the idea of editing and reshaping a text while simultaneously writing its first draft would have been a writer's wishful dream; [32] now it is so commonplace that it's probably hard for schoolchildren in the developed world to imagine writing any other way. And even computer text-editing starts to look like a mere incremental improvement when compared to a truly transformative tool like universal literacy.
Imagine trying to get a team to cooperate without depending on its members being able to read and write!
And yet, consider how your team would react if someone came along and advocated the following:
I know a way to make you many times more productive. Do what I tell you, and your group's ability to collaborate will increase beyond your most optimistic projections. Here's the plan: first, everyone's going to learn this set of symbols, called an alphabet. Each symbol is called a letter, and the letters map, more or less, to sounds in a language that is native to some of you and non-native to others. Once you've learned the basic sounds of the letters, I'll show you how to arrange them in groups to form written words. Once you've memorized between 5,000 and 10,000 of those words, you'll be able to transmit arbitrary sentences, and then your productivity will increase by a whole lot!
Literacy is a classic example of a high-investment, high-payoff tool. Everyone spends a lot of time in training, but after they make it through that part, it pays off for years to come.
Usually, the tools that get people most excited are low-investment, high-payoff. But it would be a mistake to consider only such tools: literacy did pay off in the end, after all. A dedicated team can make non-trivial tool investments when necessary, especially if everyone bears the burden together and thus is able to strengthen his sense of community by learning the new tool as a group. A tool that makes obstacles go away and makes new things possible will justify a lot of investment. For people working together on a technical project, few things have as direct an effect on daily experience as the tools they work with. The more you understand their experience, the better tool choices you can make.