This post by Ken Adams on improvements to the Series Seed documents (Github versions) triggered a lengthy response from me. It’s no secret that I’ve been fond of the project since its earliest days (see this post on the “simple Series A” and this one on “check the box forms,” my idea from around 2001 or so on improving the drafting process by further eliminating “faux” customization. What’s that? The idea that because lawyers add modest personalization to forms – changing names, jurisdictions, and a handful of specific numbers – that we’ve actually customized them.
Customizing documents is a much more complex process, one that involves talking to clients and determining which alternative term is more appropriate for them. The example I always use when talking about this issue is the drafting of an LLC operating agreement for two folks starting a business as “partners.” There are a variety of governance models, transfer restrictions, and buyout frameworks to be considered. Thinking about specific LLC members and choosing among these alternatives requires actual legal advice, and that is what we get paid to do. Changing the company name in the preamble and the signature page or table of members is not legal advice. This is why good lawyers just “SMH” at admissions by prospective clients that they started their company with Rocketlawyer or LegalZoom. Sigh.
This new approach to drafting is the same reason that I’m drawn to Ruby on Rails: the famous DHH quote is “convention over configuration:” the idea is that the costs of limitless customization are greater than we think for many use cases. I think that this idea holds true when we talk about legal agreements of many kinds. Better drafting, from a deep structural perspective (such as by adopting either check-the-box forms or a document assembly model like that championed by Ken) is nothing but good.
Connecting these threads in the middle of the night when I woke up (maybe that whole “first sleep, second sleep” thing is real after all!) has me wondering what the intersection of these models is. A document assembly program that works off github-based provisions to allow for a kaizen model of continuous improvement from all quarters?
Just writing that sentence updates my views from just a few days ago on this Wired article about Github going mainstream that I saw because it quoted Ted Wang. I now adore the Github model (Github: rickcolosimo), but I’m not sure whether it will in fact take off in quite the way envisioned with regard to the public at large. At the same time, it’s very much like a decentralization of the wikipedia model, one that allows for very grass-roots contribution. Instead of contributing to a tiny corner of a single crowd-sourced monolith, we will all be contributing to 1000 different projects and documents.
One thing the growth of the web has taught us is that the creative impulse is strong, even if it’s embodied from time to time in the aesthetic of stereotypical myspace pages. Even Facebook is in many ways as much about expression as it is about consumption, in which case its great value lies in democratizing the ability to express one’s self in a way that is no less important than WordPress or Twitter. As a writer and a reader, I believe that expression is good, and more of it is better. I believe that writing improves thought, and that sure ain’t bad.
So, to bring this back around to drafting: I think that models that allow for continuous improvement, in small, digestible chunks (every lawyer has time to review a few bits of wordsmithing, but no one has time to revise every single major form. Connecting these themes will improve the overall quality of drafting and more importantly increase the value to clients of legal advice because more of the lawyer’s time will be spent on high-value counseling. And, despite what many might think, I don’t know a lawyer who’d rather churn documents than give real advice to clients. Clients get better value and lawyers get more job satisfaction. For the second time tonight, I’ll gladly abel something a Pareto improvement.