Why Lawyers Will Never Use Google Docs

Last November, I published "On Building Git for Lawyers" about building Version Story, the first concurrent version control system for lawyers.

In the essay, I explored the problems that arise when lawyers collaborate on the same document. In the below example from the essay, you can see a screen recording of an actual lawyer copying-and-pasting changes from their colleague’s draft into a shared draft.

Overwhelmingly, the response to my essay was positive! Many people across industries empathized with the problems we’re solving. One response stood out, however. Can’t lawyers just use Google Docs?

If you’ve read the title of this essay, you already know my response.

Google Docs does not work for lawyers.

The inefficiencies of legal collaboration are not a consequence of lawyers being unwilling to adopt the best technology — it is because the needs of their workflow require a fundamentally different technology solution. In this essay, I’ll explain why Google Docs fails to meet the needs of lawyers due to its all-or-nothing adoption model, lack of commit atomicity, and inadequate knowledge management capabilities.

Your job, as a lawyer

Imagine that you’re a lawyer working on an M&A deal at a law firm. Your firm represents the seller in the deal, and the buyer and their counsel (“counterparty”) just emailed you a new version of the terms of sale (a stock purchase agreement) with important changes.

These changes represent the counterparty’s move in a negotiation — seeking terms favorable to the buyer, often at your client’s expense. To do your job well, you need to review every proposed change, advising your client on whether to accept, reject, or modify the terms.

First, you read the counterparty’s changes and assess their potential impact. Which of the modified terms are materially important to your client, and which are low-stakes? Are the terms they’re proposing acceptable to your client’s stated priorities? Are there any legal risks in the new language?

You then advise your client on how to respond, proposing a plan for the next draft: your client signs off.

Next, your firm drafts a response to the counterparty according to the plan that you and your client agreed to. If the changes require input from specialists like tax or intellectual property experts, multiple colleagues will contribute to this response in their own versions of the document. This process looks something like this:

Upon receiving all changes made by specialists, you manually merge them into a single, consolidated new draft (as illustrated in the gif in this essay’s intro). You send this to your team for review before sending it to the counterparty.

Along the way, you, your team, and the client create many versions of the document. After the counterparty emailed you their latest changes, you saved a copy of it and added comments to share with your client. Your client downloaded that copy, responded to your comments, and sent it back to you. You sent this version to your colleagues who each sent you back a different version with each of their changes. You merge all of these into a new version, which is reviewed, commented on, and amended — creating more versions at each step of the way. Finally, you send your response to the counterparty on the final draft.

An example of how a folder might look partway through this process. In practice, real legal matters have far more versions and redlines.

When they respond, the process starts all over again.

With this process in mind, let’s consider how Google Docs would fit into the picture.

All-or-nothing adoption

Google Docs only works when everyone uses it. If one person on the team makes their changes in Microsoft Word instead, the system breaks: there is no way to incorporate those changes without manually copying and pasting them in.

This constraint makes Google Docs unusable for legal collaboration. A law firm would never work directly with a counterparty on a shared Google Doc. Beyond the logistical headache of too many collaborators holding the pen, the drafting process exposes the strategy that both firms undertake. Their documents contain comments by lawyers and the client discussing the client’s priorities, what they’re willing to concede on, what they’re not willing to concede on, etc. Confidentiality in the drafting process is paramount.

Even within a single firm, getting all lawyers to adopt Google Docs instead of Microsoft Word is untenable. Most lawyers strongly prefer Word for a variety of reasons, including,

• Formatting options that Google Docs does not support (My cofounder, Kevin, a lawyer, refuses to put a contract in Google Docs if for no other reason than its lack of support for the “small caps” feature).

• A suite of custom Word Add-Ins that their workflows depend on.

• More granular options for defining clause numbering conventions.

Finally, many lawyers do not want to share their drafts until they’re polished. They don’t want their colleagues or clients to see the sausage getting made. Lawyers need the freedom to work through multiple iterations. They will try writing certain language in one provision, then take a step back to review how it fits in with the agreement as a whole, spot an issue, and zoom back in to make further changes. Throughout this process they don’t want senior partners breathing down their neck and prematurely critiquing half-formed thoughts.

Despite these reasons, let’s suppose all lawyers adopted Google Docs. Even then, it would fail to meet the needs of legal collaboration. This is due to a fundamental flaw with the Google Docs collaboration model.

Commit Atomicity

“Commit atomicity” is the principle that changes should be applied all at once or not at all. It’s a term that’s most commonly used by coders, but applies to any project with multiple collaborators.

Imagine I’m building a feature for Version Story that allows users to add tags to their documents. To deliver this feature, I have to change the user interface, the backend logic, and the database. For the tagging feature to work and to make sure I don’t break other features, I have to apply these changes all together. Furthermore, when my colleagues review these changes, I want them to be reviewed together as a cohesive set. They should also be reviewed separately from any changes my colleagues may have made to the same code, at the same time.

Thankfully, I can use Git to collaborate with my colleagues! I can put all of my changes in a single commit to be reviewed as a pull request. If my colleagues made changes to the codebase since I started working on mine, Git will guide me through merging them with mine.

Like coders, lawyers need to package their changes in cohesive sets.

Consider an example. The original draft has a provision that the agreement will end after one year. A lawyer modifies this provision to instead renew automatically at the end of each year. He adds another provision that either party can stop the automatic renewal by giving notice thirty days before the end of the year. If his colleague accepted the first change without reviewing the second, they would end up with an agreement that renews indefinitely with no way to stop it.

Furthermore, each set of approvals needs to be pinned to particular versions of the contract. If the tax specialist “signs off” on the contract after the M&A associate integrated the tax specialist’s changes to the main document, their approval only applies to that version of the document. If some of the tax specialist’s work is overwritten by subsequent changes made by other colleagues, their approval will not apply to the newer version of the contract. Pinning approval to particular versions mitigates risk for the collaborators reviewing the document.¹

Commit atomicity allows approvals to be pinned to particular versions

Despite its inefficiencies, the current redlining process embodies commit atomicity. The redline is the atomic statement of the lawyer’s changes. Redlines are reviewed independently from other redlines. When lawyers approve a redline, they know they’re only approving that redline and not future changes introduced by other lawyers.

Google Docs does not support atomic changes. By design, all collaborators hold the pen at the same time. While this makes it simple for people to make simultaneous edits to a document, it is not well-suited for legal drafting where atomicity is essential.

Knowledge Management

Lastly, Google Docs doesn’t preserve a comprehensive record of its history. While it offers a “version history” feature which shows a stream of all changes made at various time intervals, it’s challenging to understand what each of those changes represents (again underscoring the need for atomic commits).

Screenshot of the version history feature of Google Docs

Contrast the above with a visual interface

Beyond the challenges of understanding what changed, it’s even more challenging to understand why those changes occurred in the first place.

Comments are essential in the legal workflow. They are how lawyers deliver feedback on changes proposed to documents. While Google Docs allows users to leave comments, its lack of commit atomicity means that comments aren’t associated with any particular version of a document. Once comments are resolved, you can view a history of them, but they won’t be associated with the changes they produced in the document.

If a comment was left on deleted text, there's no way to know what the comment referred to.

This is not acceptable for lawyers who need to maintain a full record of what changed and why. If a partner on a deal asks a junior associate why a material term was changed, the junior associate needs to be able to reference the version and comment history to answer that question. Google Docs would not allow them to do so.

Conclusion

Google Docs is a great product for many types of collaborative writing and was a major milestone in the history of document collaboration. But for lawyers, the need for atomic changes and comprehensive record-keeping makes Google Docs unsuitable.

The system that truly solves the inefficiencies faced by lawyers will:

• Avoid all-or-nothing adoption by supporting partial participation.

• Enable users to make and review changes atomically.

• Preserve a complete history of how and why a document evolved over time.

At Version Story, we’re building that system. If you’d like to try it, click here and register for a free trial.

1. Credit to Jack Shepherd for making me aware of this concern in his excellent essay on this topic, “Is document collaboration in law firms just too “old-school”? https://jackwshepherd.medium.com/is-document-collaboration-in-law-firms-just-too-old-school-3371c024ddbf