This person is 100% correct that git will never see adoption outside the tech industry.
My partner worked as a veterinarian for several years, and it was fascinating to see how vets use computers. These were brilliant people - I knew three who did literal brain surgery. But they just had zero patience for computers. They did not want to troubleshoot, figure out how something worked or dive deeper. Ever. They didn't care! They were busy saving the lives of people's pets.
It was a good reminder there are many smart people who do not know computers work and do not care to. A good startup acknowledges this reality.
I find this excuse depressing. We live in the age of computers. If you don't know how to use one you shouldn't be employed where they're necessary. Rather than making a dumbed down workforce we should be building people's skills up.
Git for normies already exists even MS Word has document versioning. If they cannot be bothered to use the software and technology they need to then they should be unemployed.
That's a rude, tactless thing to say. People in many fields simply don't need more than a cursory knowledge of computers.
For example, I was talking about veterinarians. They need to type records into a web browser, but that's about it.
Veterinarians spend their time learning about things far more valuable to them. For example, which painkillers are safe to use on a cat recovering from surgery, or how to precisely drill into a dog's spinal cord to remove a fluid buildup that's robbed it of the ability to walk, or how to stabilize a dying animal in the emergency room.
These are the least "dumb" people imaginable. They do not need "upskilling" - they went to four years of medical school. They have more important things to do than figure out computer arcana.
We also live in the age of architecture. Should everyone who drives over a bridge or work in an office know how those things were constructed and how they are maintained? Should everyone be trained extensively on the infrastructure that gets water to their taps?
Many developers will get a headache when a more complicated git merge/rebase/conflict happens and git is confusing as hell unless you encountered this issue many times before.
As a dev commit/push/pull is trivial, but may God have mercy on the veterinary who needs to do a complex conflict merge across branches.
These people clearly do know how to use computers though, they've almost certainly been using them in their professional and personal lives every day for years. They just don't know how to use your preferred tools, and those tools aren't necessary for them.
> We live in the age of automobiles. If you don't know how to use one you shouldn't be employed where they're necessary. Rather than making a dumbed down workforce we should be building people's skills up.
FTFY ;)
Computers are just another modern convenience. We need to be making them more user friendly and safe. Nobody wants to spend all their time learning, maintaining, and fixing their computers any more than they want to do that with their cars.
I think there are two principles at play here. First, I suspect that veterinarians that go into practice as a whole prefer physical manifestations of their intelligence rather than abstract intangible prizes. This is similar to my story of starting vet school after doing bioinformatics.
Second, computer tinkering is similar to shade-tree mechanicing. I drive a car. I even know how to change my oil and can look up how to replace the alternator if I need to. I don't get much satisfaction out of working on my car, though, so I outsource (when I can afford it) to allow me to focus my time on things that drive my professional life forward or are pleasurable.
Add to these that current vet medical records software sucks, and it leads to extreme impatience, and even an expectation that computers don't work, and the cycle continues.
Although the country where I am in doesn't restrict me from vaccinating my pet by myself, I'd rather just outsource it to a vet. vet clinics here also have added facilities like pet cleaning etc which is a plus . In this case I find I'd rather enjoy my pet than figure out its innards or it's anatomy.
> This person is 100% correct that git will never see adoption outside the tech industry
And nor should it. The workflow is awful for anything but software development (and even on that, views differ). It is unsuitable for versioning binary blobs. It contains dozens of footguns that routinely catch out software engineers who use it all day, every day.
A lot comes down to timing. More and more law firm partners these days are digital natives who grew up using computers. They're accustomed to using really good software, and they expect the same in their workplace.
I definitely got that impression reading the reviews of the OP's product. An associate comparing it to "a polished Apple product" shows the younger generation is used to decent software and would appreciate it at work.
(To other commenters, this is not an invitation to dunk on Apple. Please keep discussion on track)
I wouldn't necessarily agree with this. For example, I have seen consultants recommend using Git for document versioning in medical device development.
As an ex-lawyer for over 10 years, this was a huge issue for me, specially when the other party is adversarial (e.g. another lawyer for the other part that is not exactly forthcoming with the changes).
Back in the day, to solve that (before I became a software developer and knew about git), I basically re-implemented "git in Microsoft Word version control".
On bigger contracts with dozens and even hundreds of pages, with more than 2 parties involved, we could have 3-4 parallel changes to the same documents at once. And a lot of times some of the parties didn't want to advertise their changes.
What I did was construct a table in Excel with each "version" of each clause, and where they were present omitted. It was a lot of work to maintain, but back then I didn't know any better, but worked.
By saving the versions of the files we sent for revision (think of the main branch), I could receive the version from other parties (kind of like feature branches), turn on Word changes, paste the complete content of the original, and we could visualize the difference.
It's been more than 10 years since I stopped dealing with contracts, but I imagine a lot of lawyers, specially older folks, are still either doing very convoluted processes to track changes like me or not even bothering most of the times.
The article is spot on on the issues (even brought back some memories). This is something I'd use for sure in my previous life.
> By saving the versions of the files we sent for revision (think of the main branch), I could receive the version from other parties (kind of like feature branches), turn on Word changes, paste the complete content of the original, and we could visualize the difference.
IANAL, but this was a key step for me as well. If you maintain copies of the versions sent out (and modified copies sent back), you can always get a clean diff of the copy sent out versus the copy sent back, or of an earlier version versus a subsequent revision.
The compare/combine tools in Word aren't great, but they are functional. Kind of like a local maximum, I suppose.
Exactly. The part where I used Excel was because Word didn't really scale for more than 2-3 sets of changes like that.
So my "copying current version changes" to Excel was kind of like git merging to the main branch.
People from outside the craft usually get super confused and frustrated by how many hours those contracts could take ("it is just a Word document!"), but that used to be a huge reason why.
> 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.
> 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 really hope you're right because I am 1000000% rooting for you. You just need two counterparties (could be two people in the same firm in the same practice!!) to use it to get some value somewhere in the whole process. As a humble software optimist, I believe there's room for this. I told him his critiques also apply to typewriters -> any old word processor -> MS Word, or fax -> email and those still happened so don't go taking an overpaid millenial's skepticism as normative for the whole thing. If Graeber taught me anything, it's that work is a gas and efficiency will not make the firms bill less.
Sometimes you automate something because you want to do it faster / cheaper. Sometimes you automate something because you need it to be done _correctly_.
I would much rather my critical but menial $900/hr task be done by someone double-checking automated work than the same amount of time being spent doing the menial work.
You could even introduce flaws (in the review step) to catch if you're concerned about the human getting bored and just automatically mashing the "merge" button...
There was a freakonomics[1] podcast about mechanical support of human activities...
> 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.
Also, starting with menial work is how junior associates are trained to do more complex work.
I assume the fourth point is for billing clients for a high fee while paying a quarter to the associates. But some law firms will use the more efficient tools to take on more cases for the partners to bill on their higher rates. Competition will force the firms to use more efficient tools.
One hundred percent! And you can already see this playing out. More and more large law firms are spinning up technology and innovation teams. This is a huge investment on their part, indicating they're incentivized.
Also, the billable hour is somewhat misunderstood. It is more of a process tool than a hard reality. Repeat clients expect the bill to end up within a certain range. And law firms expect their people to work a certain number of hours.
Stuff like this really make me wish people knew about computers. They could see endless gains from switching to something like LaTeX with Git version control. Sure, it would take a bit of time to train people on, but the productivity gains would be massive. The strangest thing is that everyone used to use computers that way. It seems that the creation of GUIs and WYSIWYG has greatly worsened the experience a lot of people have with a computer. I think the issue is that people select their tools based off what is easiest to learn, so there is a kind of local minima reached where most software today is very easy to operate but hugely inefficient for anyone who has to use it frequently.
More "endless pains" then "endless gains" in all honesty. The point of software is to abstract complexity, not present it to users (or worse, create it).
LaTex is just ugly and surprising. People want to write and see what they've written, not type and then render. It's a backwards development workflow from the instant feedback of wysiwyg (which is why wysiwyg was so revolutionary, and became the de facto standard for the task).
Do you ever wonder why audio mixing panels have all those buttons and knobs instead of just one big slider labelled "volume"? It's because audio engineers benefit more from the complexity than they lose out from the time taken to learn it. It's easy to frame features as bad if you describe them as "creating complexity", but what you ignore is that the advanced user of a piece of software (i.e. anyone who uses it for work) will want to do very complex things with that software. A simpler interface is only achieved by making assumptions about how people will use the product, and these assumptions often cause issues for people.
> It's a backwards development workflow from the instant feedback of wysiwyg
No it isn't. I've already explained this in my original comment, and you've provided little rebuttal here. What is the value of instant feedback? As far as writing documents, there is none. That's because the people who write documents are interested in the text, which they get instant feedback on in their text editor. They don't really care how it looks while they are in the process of writing it. Instant feedback may be useful if you are interested in styling a document, but usually style sheets are prepared once and reused many times. Documents are not like computer programs, you typically write the entire thing out then compile it once or maybe twice to fix typos in command names. Even if you think instant feedback is intensely valuable, there is no reason you can't have it in the case of LaTeX (or LaTeX adjacent) documents. Simply design your document editing software with two windows, the one on the left shows the textual source, and the one on the right shows the compiled document. These can be kept in sync in real time.
If Word was implemented with standard XML backend instead of OOXML, then today, we could have easily developed tools to show good, reliable diffs without having to resort to tricks.
The issue is "people who view themselves as good with computers" self-select into jobs in the technology industry. This means we don't have any ambassadors for technological process improvements in the average business.
Git is a tool built around the needs of software developers. Because git is too complicated and branching, though in principle, would make sense in some situations, is actually pretty difficult to manage (especially for binary documents).
Also, they do use version history built into tools like Sharepoint/Office, or the document itself.
How many developers use git? I'd bet there's a huge number of developers out there at non-tech companies who get by with numbered folders and emailing zip archives around.
Oh god, reminds me of the time I was working in consulting and dealing with web developers at small marketing companies. They never used version control. You'd often get them to fix one thing, fix a second thing, and find the first thing had been reverted back to its original broken state.
To be fair, looking at a word doc with tracked changes enabled that has gone through a few rounds with more than a couple people in my Legal dept makes me feel like my brain is melting.
I built something like this about 13 or so years ago. a startup called contractual.ly - they got acquired by Coupa after I left.
I used the papertrail gem to track changes to the contract object and provided diffs and commenting and then allowing collection of digital signatures (Docusign was pretty new at the time so we rolled our own)
In HTML, they should be using <del> instead, which denotes a portion of the text that was removed. If something is inserted, then <ins> should be used.
<strike> is deprecated.
This kind of notation is similar but not the same as redlining. Whoever reads the law actually wants `git history` in this case. The diff is not a means to an end (a fully edited document), having the diff explicit is the end goal.
Earlier this year, I worked on 60 pages of M&A contract documents with lawyers, and I found the change tracking in Word miserable. It's so difficult to see only the delta quickly, it's slow to go back through the history, and it's hard to discuss a change within the tool itself.
It felt crazy that there wasn't better tooling for this, but I also appreciate the difficulty of trying to get lawyers out of the MS Word workflow that they know.
Attorney here. Word tracking works just fine for my work and the work of pretty much every attorney I've ever interacted with.
Meanwhile, as another comment in this thread noted:
>Git is a tool built around the needs of software developers. Because git is too complicated and branching, though in principle, would make sense in some situations, is actually pretty difficult to manage (especially for binary documents).
Every alternative I've seen proposed, especially by non-lawyers, has been far too complicated for our needs and attempts to tackle problems that really aren't actual problems in real everyday practice.
It often seems like developers in this space speculate on theoretical problems they feel lawyers must face and create solutions a programmer would appreciate for those.
Have you used change-tracking software that worked well in other domains?
To me, saying that change tracking in Word is fine when you've never seen anything better is kind of like someone 60 years ago saying, "A typewriter is fine, and everyone I know agrees. All these software people are trying to solve theoretical problems with word processing software."
You might not agree with particular solutions you've seen for improving change tracking for legal documents, but I'm surprised you don't see room for improvement in change tracking.
From my experience as a client who had to participate in the process, I saw lots of issues:
First, it's super slow. A large document with lots of tables and lists takes 20+ seconds to load. Searching is also much slower than it should be.
There's a ton of noise. When I was reviewing documents, 80% of the changes that showed up as redline changes weren't real changes but were just formatting updates (e.g., page renumberings, section renumberings). It made it hard to find the real change vs. just formatting changes.
The changes are all in separate files rather than having a single tool that can show you each version in a single place.
The Word doc supports inline commenting, so it's helpful for each side to be able to discuss it internally within the doc itself, but then that creates the risk that you'll accidentally share a version with the opposing side that includes private notes. As far as I know, Word doesn't have any way of making this safe by default. Rather, it's on the attorney to remember to scrub private information each time before sharing it with the other side.
I was tech editor on a book that used MS Word versioning. (One chapter per .docx because Word couldn't scale to anything longer). As you say, it was absolutely miserable.
it’s ridiculous that a document formatting app/format is used for creation and storage of documents. especially for official ones that follow strict formatting protocol. all data that satisfies the protocol is just a record! just pop a json into a template-engine and you’re go.
i’m so sad about the shithead influence of microsoft on our society.
Readit News
My partner worked as a veterinarian for several years, and it was fascinating to see how vets use computers. These were brilliant people - I knew three who did literal brain surgery. But they just had zero patience for computers. They did not want to troubleshoot, figure out how something worked or dive deeper. Ever. They didn't care! They were busy saving the lives of people's pets.
It was a good reminder there are many smart people who do not know computers work and do not care to. A good startup acknowledges this reality.
Git for normies already exists even MS Word has document versioning. If they cannot be bothered to use the software and technology they need to then they should be unemployed.
For example, I was talking about veterinarians. They need to type records into a web browser, but that's about it.
Veterinarians spend their time learning about things far more valuable to them. For example, which painkillers are safe to use on a cat recovering from surgery, or how to precisely drill into a dog's spinal cord to remove a fluid buildup that's robbed it of the ability to walk, or how to stabilize a dying animal in the emergency room.
These are the least "dumb" people imaginable. They do not need "upskilling" - they went to four years of medical school. They have more important things to do than figure out computer arcana.
As a dev commit/push/pull is trivial, but may God have mercy on the veterinary who needs to do a complex conflict merge across branches.
If most devs are confused then imagine vets.
Deleted Comment
Building easier tech creates jobs for engineers, and saves the time of the people who are willing to do the stuff that's way harder than engineering.
It probably makes things cheaper for people trying to save their pets too.
FTFY ;)
Computers are just another modern convenience. We need to be making them more user friendly and safe. Nobody wants to spend all their time learning, maintaining, and fixing their computers any more than they want to do that with their cars.
They should just work, without surprises.
I think there are two principles at play here. First, I suspect that veterinarians that go into practice as a whole prefer physical manifestations of their intelligence rather than abstract intangible prizes. This is similar to my story of starting vet school after doing bioinformatics.
Second, computer tinkering is similar to shade-tree mechanicing. I drive a car. I even know how to change my oil and can look up how to replace the alternator if I need to. I don't get much satisfaction out of working on my car, though, so I outsource (when I can afford it) to allow me to focus my time on things that drive my professional life forward or are pleasurable.
Add to these that current vet medical records software sucks, and it leads to extreme impatience, and even an expectation that computers don't work, and the cycle continues.
Although the country where I am in doesn't restrict me from vaccinating my pet by myself, I'd rather just outsource it to a vet. vet clinics here also have added facilities like pet cleaning etc which is a plus . In this case I find I'd rather enjoy my pet than figure out its innards or it's anatomy.
And nor should it. The workflow is awful for anything but software development (and even on that, views differ). It is unsuitable for versioning binary blobs. It contains dozens of footguns that routinely catch out software engineers who use it all day, every day.
(To other commenters, this is not an invitation to dunk on Apple. Please keep discussion on track)
Back in the day, to solve that (before I became a software developer and knew about git), I basically re-implemented "git in Microsoft Word version control".
On bigger contracts with dozens and even hundreds of pages, with more than 2 parties involved, we could have 3-4 parallel changes to the same documents at once. And a lot of times some of the parties didn't want to advertise their changes.
What I did was construct a table in Excel with each "version" of each clause, and where they were present omitted. It was a lot of work to maintain, but back then I didn't know any better, but worked.
By saving the versions of the files we sent for revision (think of the main branch), I could receive the version from other parties (kind of like feature branches), turn on Word changes, paste the complete content of the original, and we could visualize the difference.
It's been more than 10 years since I stopped dealing with contracts, but I imagine a lot of lawyers, specially older folks, are still either doing very convoluted processes to track changes like me or not even bothering most of the times.
The article is spot on on the issues (even brought back some memories). This is something I'd use for sure in my previous life.
IANAL, but this was a key step for me as well. If you maintain copies of the versions sent out (and modified copies sent back), you can always get a clean diff of the copy sent out versus the copy sent back, or of an earlier version versus a subsequent revision.
The compare/combine tools in Word aren't great, but they are functional. Kind of like a local maximum, I suppose.
So my "copying current version changes" to Excel was kind of like git merging to the main branch.
People from outside the craft usually get super confused and frustrated by how many hours those contracts could take ("it is just a Word document!"), but that used to be a huge reason why.
> 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 :/
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.
Sometimes you automate something because you want to do it faster / cheaper. Sometimes you automate something because you need it to be done _correctly_.
I would much rather my critical but menial $900/hr task be done by someone double-checking automated work than the same amount of time being spent doing the menial work.
You could even introduce flaws (in the review step) to catch if you're concerned about the human getting bored and just automatically mashing the "merge" button...
There was a freakonomics[1] podcast about mechanical support of human activities...
[1] https://freakonomics.com/podcast/new-technologies-always-sca...
Also, starting with menial work is how junior associates are trained to do more complex work.
Also, the billable hour is somewhat misunderstood. It is more of a process tool than a hard reality. Repeat clients expect the bill to end up within a certain range. And law firms expect their people to work a certain number of hours.
Deleted Comment
LaTex is just ugly and surprising. People want to write and see what they've written, not type and then render. It's a backwards development workflow from the instant feedback of wysiwyg (which is why wysiwyg was so revolutionary, and became the de facto standard for the task).
> It's a backwards development workflow from the instant feedback of wysiwyg
No it isn't. I've already explained this in my original comment, and you've provided little rebuttal here. What is the value of instant feedback? As far as writing documents, there is none. That's because the people who write documents are interested in the text, which they get instant feedback on in their text editor. They don't really care how it looks while they are in the process of writing it. Instant feedback may be useful if you are interested in styling a document, but usually style sheets are prepared once and reused many times. Documents are not like computer programs, you typically write the entire thing out then compile it once or maybe twice to fix typos in command names. Even if you think instant feedback is intensely valuable, there is no reason you can't have it in the case of LaTeX (or LaTeX adjacent) documents. Simply design your document editing software with two windows, the one on the left shows the textual source, and the one on the right shows the compiled document. These can be kept in sync in real time.
Git is a tool built around the needs of software developers. Because git is too complicated and branching, though in principle, would make sense in some situations, is actually pretty difficult to manage (especially for binary documents).
Also, they do use version history built into tools like Sharepoint/Office, or the document itself.
I used the papertrail gem to track changes to the contract object and provided diffs and commenting and then allowing collection of digital signatures (Docusign was pretty new at the time so we rolled our own)
The founder has cofounded another one in the same space https://recitalapp.com/
https://www.loom.com/share/a4c5f5bf035c43938b342361154b6753?...
<strike> is deprecated.
This kind of notation is similar but not the same as redlining. Whoever reads the law actually wants `git history` in this case. The diff is not a means to an end (a fully edited document), having the diff explicit is the end goal.
It felt crazy that there wasn't better tooling for this, but I also appreciate the difficulty of trying to get lawyers out of the MS Word workflow that they know.
Good luck to the team! I hope you're successful.
Meanwhile, as another comment in this thread noted:
>Git is a tool built around the needs of software developers. Because git is too complicated and branching, though in principle, would make sense in some situations, is actually pretty difficult to manage (especially for binary documents).
Every alternative I've seen proposed, especially by non-lawyers, has been far too complicated for our needs and attempts to tackle problems that really aren't actual problems in real everyday practice.
It often seems like developers in this space speculate on theoretical problems they feel lawyers must face and create solutions a programmer would appreciate for those.
To me, saying that change tracking in Word is fine when you've never seen anything better is kind of like someone 60 years ago saying, "A typewriter is fine, and everyone I know agrees. All these software people are trying to solve theoretical problems with word processing software."
You might not agree with particular solutions you've seen for improving change tracking for legal documents, but I'm surprised you don't see room for improvement in change tracking.
From my experience as a client who had to participate in the process, I saw lots of issues:
First, it's super slow. A large document with lots of tables and lists takes 20+ seconds to load. Searching is also much slower than it should be.
There's a ton of noise. When I was reviewing documents, 80% of the changes that showed up as redline changes weren't real changes but were just formatting updates (e.g., page renumberings, section renumberings). It made it hard to find the real change vs. just formatting changes.
The changes are all in separate files rather than having a single tool that can show you each version in a single place.
The Word doc supports inline commenting, so it's helpful for each side to be able to discuss it internally within the doc itself, but then that creates the risk that you'll accidentally share a version with the opposing side that includes private notes. As far as I know, Word doesn't have any way of making this safe by default. Rather, it's on the attorney to remember to scrub private information each time before sharing it with the other side.
i’m so sad about the shithead influence of microsoft on our society.