Post History

I've changed teams (and companies) since asking this question years ago, and the doc set is even larger on my current team.  Here's how we manage changes that affect parts of the documentation with different primary/responsible writers.

First, we do use source control as mentioned in another answer.  At my insistence, we now do work on branches and merge to master only when work is complete.

Because we use branches, more than one writer can work on the same branch at the same time.  If my change has impact on someone else's area, we can both work on it together without making master inconsistent.

That said, we try to be flexible about boundaries.  If I *can* make (or propose) a change in someone else's area, I should do so and then ask the primary author to review it.  That's easier to coordinate than working together on the branch when we can't just sit down together.  (Yeah, my current team is geographically distributed, too.)

And when all else fails -- for example, when the other affected documentation is a blog post or a training module, neither of which is part of our doc repo -- then we file tickets in our bug-tracking system to make sure things don't get lost.  We tie all non-trivial work to tickets already, and can use dependencies in the ticketing system to tie tasks together.  Applying some discipline to tickets (it's not resolved until everything's on master) helps to prevent things from falling through the cracks.

We do have informal communication channels -- chat, email, team meetings, and the like.  These can be extremely helpful when I *mostly* understand what I need to do in someone else's area but have a few questions, for instance.  Sometimes the result is an explanation and sometimes the result is that the other writer does that part of the work.