Readit NewsI'd also like a similar solution for non-lawyers reviewing legal docs. I review dozens of legal docs each year. My cofounder reviews even more. We switched to Bonterms last year to adopt some SAAS standard templates. However, there are still a bunch of edits and iterations on the templates per customer. I want an easy solution that makes it easy to work through the changes.
Let me know if you'd like to try Version Story! I'm happy to add you to our whitelist.
google docs has a very nice version control
Google Docs is a step in the right direction but has several limitations.
1. Lawyers don't want everyone holding the pen at the same time. Specialists want to make their changes and have them reviewed in isolation from other's changes. Think of a redline like a pull request. You don't want other people's changes in your work when it's getting reviewed.
2. Google Docs breaks down when even a single person drafts outside of it. See the section of my essay about why lawyers will never stop using Word. Even if you managed to get an entire firm using Google Docs, it still wouldn't work because they need to exchange drafts with external parties.
Reporting back from my biglaw pal I sent this to:
> Big flaw in the product: 60 year old partner who still makes hand edits and has the Secretary scan the pages and send them out of order to the associate
> Second big flaw in the product: specialists edits get rejected because they don’t know the deal points and are just swooping in
I took issue with this as step 4 seems to involve an M&A lawyer accepting/rejecting specialist edits piecemeal, to which he responded "Right, but that doesn’t actually save that much time. It’s the same work that an M&A associate is already doing"
> Third big flaw in the product: big law firms are the least innovative organizations on earth
> Fourth big flaw in the product: having junior associates do menial tasks at $800-950/hr is a feature, not a bug, of law firm business model. So you are solving for something that the target customer doesn’t necessarily want solved.
and there it is :/
> 60 year old partner who still makes hand edits and has the Secretary scan the pages and send them out of order to the associate
We've designed our product to be backwards compatible with existing workflows. It does not require every team member to use the product to add value. Partners who prefer their way of doing things can continue to do so allowing associates to add their drafts to Version Story to create redlines and consolidate changes.
>specialists edits get rejected because they don’t know the deal points and are just swooping in
The possibility of incorrectly rejecting specialists edits exists with or without Version Story. Our product makes it easier to understand what's changed so lawyers can exercise their judgement about these decisions.
> Third big flaw in the product: big law firms are the least innovative organizations on earth
I think this assumption is worth challenging. Millennials are becoming partners at law firms and are spearheading initiatives to update their tech stacks. This is reflected in legal tech budget growth trends (https://www.legalcurrent.com/tech-spending-remains-especiall...).
> Fourth big flaw in the product: having junior associates do menial tasks at $800-950/hr is a feature, not a bug, of law firm business model. So you are solving for something that the target customer doesn’t necessarily want solved.
Making mistakes is not a feature (https://newsletterhunt.com/emails/40489). In the example I outline in the essay, the lawyer made three separate mistakes when manually merging documents.
I remember a post on here a few years ago about someone who had tried doing this and failed. I don't remember the details but you may be able to find it if you search well.
My recollection of his takeaway was that lawyers actually didn't want a lot of the things git offered. For example, they always wanted to be using the latest version -- the abstraction of multiple branches where multiple people independently worked on things then merged them back together wasn't quite how most lawyers worked. And the other big thing was a network problem: a lawyer has to us microsoft office's version control because the opposing team is going to use it, so even if you use some better editor software it still has to be sent as a word file showing the tracked changes to the other side.
> the abstraction of multiple branches where multiple people independently worked on things then merged them back together wasn't quite how most lawyers worked
This depends a lot on the practice. Transactional lawyers working in M&A and real estate encounter the issue of parallel drafts all the time. Personal injury lawyers tend to work in isolation and don't need all of git's functionality. Pretty much every lawyer redlines in some capacity, however, and benefit from visualizing a linear version history.
>And the other big thing was a network problem: a lawyer has to us microsoft office's version control because the opposing team is going to use it, so even if you use some better editor software it still has to be sent as a word file showing the tracked changes to the other side.
Yes, this is absolutely correct. This is one of the main things that keeps docx entrenched as the standard in legal collaboration. It would be an enormous faux-pas to send another lawyer a contract in an application that they're unfamiliar with. Backwards compatibility with their existing workflows is essential.
It's curious to me how many people think "just convert it to a different filetype" will solve the problem.
Do you think there are other professions/industries that would benefit from this?
I think a lot of people unfamiliar with docx think of it as effectively the same thing as any other rich text format. Because of that, they assume converting it to other formats is trivial, not realizing that other formats support a small subset of the functionality docx does.
Definitely. Finance professionals, academic researchers, legislators, among many other professionals, encounter similar version control issues. We are currently focused on law because of our domain expertise and because the problem is particularly pronounced in the law.
In this essay, I address this question and argue that the legal workflow requires a fundamentally different technology solution than what Google Docs provides.