- It may be that, as in the example, you have an associate who is mindlessly merging others' changes into the master document. But the hope is that the associate is also thinking critically about the changes as they are merging them, picking up on things like "this probably won't work, I should flag it for discussion", "if we change this clause we'll also need to make consequent changes to that other clause", or even just typos and syntax errors.
- In addition, the hope is that the associate is learning while merging the changes. They are gaining familiarity with this type of contract and the kind of points that tend to be discussed/negotiated.
- If you don't have many specialist teams that you need to work with, you can just ask them to put their changes in a new version (ie, do it synchronously).
- That said, there are definitely arguments for replacing this internal workflow with a fancy new collaboration-focused platform. I can't see it replacing the legacy workflow when actually negotiating deal documents. When I trialled similar software in the past, the way it was presented to me was that we would need to get our clients, counterparties and their lawyers, etc to access the document through our instance of the platform. Which just seems like a non-runner to me.
- It is well known that lawyers are very slow to adopt new technologies. However, I can say from experience that a lot of the software that is peddled to lawyers is awful. Like, stuff seems designed to work well and look great in a demo, but as soon as you start using it in the real world you run into all sorts of edge cases where things don't work properly, you get obscure error messages (that are often just stacktraces), etc. Of course I'm not saying the software in the article is like that but a lot of lawyers have been bitten by botched software transitions and are reluctant to move from what they know as a result.