If only we could get to a point where we can use these for series A as well. Having to pay $50K for you (and your VC's) legal expenses for an SPA which is 95% boilerplate, is painful and something I pray can get standardized.
Awesome. I was just commenting to our lawyers the other day how badly the legal industry needs better version control for documents.
The existing paradigm is to pay associates $300/hr to pass redlined word documents back and forth or markup docs by hand during phone calls / meetings and then give the hand marked up docs to legal assistants to input changes.
Inevitably things get lost in translation and it's difficult to figure out why things changed versions ago. It's also very expensive.
The resistance to change is driven by the fact that the majority of lawyers make a lot of money being inefficient.
I'm guessing github is not the preferred interface for lawyers but it could very well be the engine behind a more "lawyer friendly" interface.
Great to see the seeds of change being sewn, anyways.
Thanks Taylor! Completely agree with you on your points about lawyer workflow. I'm working on a few things at Fenwick (Series Seed on GitHub is just one) that will hopefully get some of these roadblocks out of the way in the future.
Couldn't agree more. As a working transactional attorney and hobbyist coder, I will say that the obstacle to better workflows is not (in most cases) deliberate inefficiency. Rather, the compensation and billing scheme at nearly all firms strongly discourages investment of time in anything that can't be billed to a specific client.
Look for that to change as more firms move to fixed fee work.
In a lot of law firms, the resistance to change is simply because completely changing workflows is not easy to accomplish. They have a lot to do, and given their system works for them, you need to demonstrate the advantages for them. Show them why this will make their lives easier. They wouldn't really make less money, since if they are really spending this much time, it's probably time they could spend billing two clients instead of one (usually better to run up two small bills instead of one large one).
In any case, this is true in trying to change any enterprise, law is no different.
I converted a group of lawyers, who were still using Corel Wordperfect for drafting multistate legislation, to using an XML based workflow, after showing them why it would make them faster, not why it was "better for the world who was trying to look at drafts".
Imagine you used emacs all day, every day, and then someone came in and says "we're all moving to VIM".
Personally, I do all my drafting in text and use version control, but use word as an interchange format when stuff goes outside of the company.
The idea that lawyers do things inefficiently on purpose to inflate bills ignores basic Econ 101 principles. Corporate law is a field with dozens of producers and fairly fungible products. If a piece of technology really saved a lot of attorney time, firms would have huge incentive to move to it capture market share against the other producers. What they lost in billable hours on any one matter would be more than offset by additional business gained by offering lower costs at the same billing rate. Moreover, more use of technology increases associate utilization, increase leverage, and helps keep headcount down, which, especially in the last several years, is a key factor in maintaining partner profits. Finally, many of the top firms regularly turn down business because they don't have the capacity--these firms have a lot of incentive to do more with each associate. For things that are truly productivity boosters, like say electronic document review platforms, firms have quickly abandoned old methods and moved to new ones.
Lawyers don't use Github for documents for the same reason nobody else uses Github for documents. Corporate America's workflow is based on Word/Excel/etc. There's no good Github-like service for Word/Excel/etc that's appreciably better than passing redlined documents back and forth. There is a business opportunity here for an enterprising engineer... And while you're at it, how about something that's better for marking up documents than a print out and a red pen?
"The resistance to change is driven by the fact that the majority of lawyers make a lot of money being inefficient."
Your comments refuting this are well taken and in hindsight my comment above was cynical and lazy...probably somewhat due to recently paying an enormous legal bill.
Totally understandable... Legal technology is a fairly interesting sub-field that has implications for corporate administrative technology more generally (at least in larger companies). The document management problem is far from solved, for example. There has been a push towards a more diverse set of legal service offerings. Not every deal needs to be scrutinized in the same way as a mega-merger. But that's something clients have to be on board with--accept more risk for lower cost and faster turn-around. Boutiques are popping up that are offering such services.
There's no good Github-like service for Word/Excel/etc that's appreciably better than passing redlined documents back and forth.
Considering the amount of changes, and the terrible interface that Word has for viewing history/tracking changes, Google Docs is perfect for making these kinds of edits, reviewing history and tracking changes. To top it off, legal documents have none of the "requirements" of the "extra features" that people normally complain about when it comes to why they can't stop using Microsoft Office products.
They could still print them out, red-line them by hand, and keep legal assistants employed who update the canonical on-line version.
I've received attachments from someone sent to multiple people with instructions of "make your changes and send it back to me". And then the sender spends time manually merging people's changes into a single document. What a waste.
The amount of effort and time saved in not having to keep track of the most recent version from the multitude of revisions that litter your inbox as attachments and which one is/should be considered canonical would more than make up for any other perceived drawback.
It's purely momentum that keeps MS Office entrenched in this area.
> It's purely momentum that keeps MS Office entrenched in this area.
First, in the legal sector, anything "cloud" is a total no-go. Handing confidential legal documents over to a third party creates a rats nest of privilege issues.
Second, many businesses don't depend on Word's track changes. There are tools for doing version control and diff-ing on Word documents. We e-mail around diffs (redlines) just like how the Linux kernel was managed back before git. What's missing is a "patch" replacement--hence handing markups to secretaries.
Third, Word compatibility is a huge advantage. Legal documents don't need anything too fancy (that said, Google Docs is extremely primitive so I'm not sure it can even handle everything legal documents need, particularly in the area of footnoting), but at the same time law firms have built up huge bodies of templates and precedent in Word format. Having to round-trip through Google docs to copy some language or a citation from precedent would be a huge pain in the ass. Also, there are lots of little plugins, macros, etc, that we use. Westlaw integration, for example, custom macros for generating boiler-plate, etc.
Fourth, clients all use Word, and they all send redlines around too. You hand Goldman Sachs a Google Doc link, and they'd be like "what is this shit?" Big companies have exactly the same set of things tying them to word. Goldman has worked on a billion different prospectus statements before, and they're all in Word format. So you have to have Word and all those tools around anyway for documents coming in and going out.
Fifth, Google Docs sucks. It's the only Office Suite that's even more awkward and finicky than MS Office, and that's saying a lot. I hate using it for the most basic things--I'd hate to have to use it at work. Word processing has been pretty much downhill since Word Perfect 6.x, but it's really hit a new low with Google Docs.
Three of your five, the third, fourth, and fifth, are "momentum", so maybe "purely" is too strong.
So maybe Google Docs isn't the best option currently, but there are definitely more efficient ways to work than what is done now. This is an area that could use some innovation, and putting things on github is an early step to find out what can work. However, those who are used to status quo have to be interested in finding new, perhaps better, ways to work. If you go into things thinking you're married to Microsoft Office, nothing is going to change.
"Momentum" (people use it because it's popular) isn't precisely the same thing as network effect (people use it because to interoperate with other people) which isn't precisely the same thing as high costs of transition (people use it because switching would require a lot of work). E.g. Google has momentum, but not the other two. Facebook has both momentum and network effect. MS Office has all three.
There is nothing better right now than the MS Word workflow with all the accumulated templates, macros, etc. We can both imagine better things, and it is indeed an area that could use a lot of innovation, but github, with zero support for word processing formats or even binary files in general, is a non-starter here. Want to disrupt the space? Make Github for ODF documents in a way that let's you cleanly e-mail around diffs and apply them, and let's you easily merge changes from multiple people to documents that may have drifted from the branch point. Make it robust, so people don't fear using the tool for what it might do to their documents. That's a billion dollar Office monopoly-challenging idea right there with applications far beyond the legal space. It's also technically challenging as hell. This is not a space where a minimally viable product is going to play. It's competing with MS on its own turf.
"Popular" and "network effect" are so similar as to be almost indistinguishable. Which came first: popularity, network effects, or cost of transition? Each one begat the others.
That's a fine suggestion for a product, and you're right about it competing with MS on its own turf: and that's why no one will use it. There is nothing super inherent with many documents that are currently emailed around as whole atomic units that they wouldn't be better represented as plain text. And git ALREADY handles plain text really well. It handles emailing diffs and applying changes from email. It is robust enough to not cause fear of using the tool for with it might do to the text. People are married their MS Office based workflow, and they will always find an excuse to maintain it. Migrating the individual components to a different platform (MS Office to ODF) is a valid way to challenge the status quo, and it's just as valid to challenge it by revisiting the assumptions that enforce the status quo (that you need to email diffs or documents around, for example; that can be challenged with on-line, simultaneous, collaborative editing -- which removes the need to email diffs around). Neither one is going to make significant inroads against the current momentum, no matter which of the finer points of momentum (popularity, network effects, cost of transition) can be resolved.
> Lawyers don't use Github for documents for the same reason nobody else uses Github for documents.
Funny, just earlier today I happened to watch a Clay Shirky TED talk ("How the Internet will Transform Government"), where he showed a hilarious screenshot: a Venn diagram of Lawyers and People with Github accounts.[0]
I've recently started to do this for technology Statements of Work in government. If City A writes a Statement of Work for a Wordpress integration, why should City B have to write the same thing?
One question. I understand that the set of items in these documents is carefully chosen based on many years of experience and thousands of data points. A lawyer could probably take a look at this and understand it in 10 minutes.
But for a non lawyer, it seems like too much too soon. I have to figure most companies will need very few of these provisions.
Is there a way to structure this type of document so that the most important thing(s) only could be included, perhaps on one page?
And then structure it in such a way that every few months, or few years, you add a "plugin" for your particular company needs?
My problem with these types of documents is that for 2 guys in a garage they seem to be overkill, and it would be nicer if there were a simpler option that starts with a tiny core that you can then add on as you go.
Thanks for the compliments on the docs, breck. I helped get these up on GitHub and I think the existing document that would come closest to what you're looking for is the term sheet. That's essentially a one page summary of the key terms that are laid out in the other documents.
Regarding the "plug in" process you mention, that's actually a good analogy for what happens between these docs, which are used in a seed round, and the larger set of docs that are used in a next round like a Series A. Believe it or not, these Series Seed docs are significantly stripped down from what Series A docs look like.
Not sure if that entirely answers your question or not, but let me know if there's anything I can help out with.
That does answer my question. I guess for me, I see these documents and I am overwhelmed. But that's just probably because it's so foreign to me.
I actually was going to say, is there anyway to make these documents more concise like underscore.js? Then I opened up underscore.js in Textmate, hit print, and realized it would be 30 pages printed.
I guess I didn't realize how much the perceived length of something depends on the background of the reader. For me, underscore.js is small and concise, for a non programmer it probably looks like a tome. When I saw the Seed docs to me it was a tome, but to you it's probably a quick read.
I do wish legal docs were smaller. But I also wish code were smaller. And I don't really have an answer to how to make that so!
This is what is done in the documentation of many financial 'over the counter' derivatives trades. There's a big book of definitions, which everyone signs up to (part of the process of creating an 'ISDA Master' with each dealer). And the documentation of each derivative trade amounts to a couple of pages that sets out the key terms (maturity date, rates, currencies, etc) using the main definition document as a source for the major terms, while overriding key distinctive points, as necessary.
After a while, if/when 'market convention' drifts such that everyone is overriding definitions in the same way, a new 'Definitions' document is created, and people start to work off that.
24 comments
[ 3.4 ms ] story [ 75.9 ms ] threadIt is time that the legal profession joined the 21st century and automates that which can be automated.
Markdown extensions for inline change-indications may be part of the puzzle as well:
http://criticmarkup.com/users-guide.php
The existing paradigm is to pay associates $300/hr to pass redlined word documents back and forth or markup docs by hand during phone calls / meetings and then give the hand marked up docs to legal assistants to input changes.
Inevitably things get lost in translation and it's difficult to figure out why things changed versions ago. It's also very expensive.
The resistance to change is driven by the fact that the majority of lawyers make a lot of money being inefficient.
I'm guessing github is not the preferred interface for lawyers but it could very well be the engine behind a more "lawyer friendly" interface.
Great to see the seeds of change being sewn, anyways.
Look for that to change as more firms move to fixed fee work.
I converted a group of lawyers, who were still using Corel Wordperfect for drafting multistate legislation, to using an XML based workflow, after showing them why it would make them faster, not why it was "better for the world who was trying to look at drafts".
Imagine you used emacs all day, every day, and then someone came in and says "we're all moving to VIM".
Personally, I do all my drafting in text and use version control, but use word as an interchange format when stuff goes outside of the company.
I think many startups (including one of my own) fail because they underestimate the difficulty of changing people's workflow.
Lawyers don't use Github for documents for the same reason nobody else uses Github for documents. Corporate America's workflow is based on Word/Excel/etc. There's no good Github-like service for Word/Excel/etc that's appreciably better than passing redlined documents back and forth. There is a business opportunity here for an enterprising engineer... And while you're at it, how about something that's better for marking up documents than a print out and a red pen?
Your comments refuting this are well taken and in hindsight my comment above was cynical and lazy...probably somewhat due to recently paying an enormous legal bill.
Considering the amount of changes, and the terrible interface that Word has for viewing history/tracking changes, Google Docs is perfect for making these kinds of edits, reviewing history and tracking changes. To top it off, legal documents have none of the "requirements" of the "extra features" that people normally complain about when it comes to why they can't stop using Microsoft Office products.
They could still print them out, red-line them by hand, and keep legal assistants employed who update the canonical on-line version.
I've received attachments from someone sent to multiple people with instructions of "make your changes and send it back to me". And then the sender spends time manually merging people's changes into a single document. What a waste.
The amount of effort and time saved in not having to keep track of the most recent version from the multitude of revisions that litter your inbox as attachments and which one is/should be considered canonical would more than make up for any other perceived drawback.
It's purely momentum that keeps MS Office entrenched in this area.
First, in the legal sector, anything "cloud" is a total no-go. Handing confidential legal documents over to a third party creates a rats nest of privilege issues.
Second, many businesses don't depend on Word's track changes. There are tools for doing version control and diff-ing on Word documents. We e-mail around diffs (redlines) just like how the Linux kernel was managed back before git. What's missing is a "patch" replacement--hence handing markups to secretaries.
Third, Word compatibility is a huge advantage. Legal documents don't need anything too fancy (that said, Google Docs is extremely primitive so I'm not sure it can even handle everything legal documents need, particularly in the area of footnoting), but at the same time law firms have built up huge bodies of templates and precedent in Word format. Having to round-trip through Google docs to copy some language or a citation from precedent would be a huge pain in the ass. Also, there are lots of little plugins, macros, etc, that we use. Westlaw integration, for example, custom macros for generating boiler-plate, etc.
Fourth, clients all use Word, and they all send redlines around too. You hand Goldman Sachs a Google Doc link, and they'd be like "what is this shit?" Big companies have exactly the same set of things tying them to word. Goldman has worked on a billion different prospectus statements before, and they're all in Word format. So you have to have Word and all those tools around anyway for documents coming in and going out.
Fifth, Google Docs sucks. It's the only Office Suite that's even more awkward and finicky than MS Office, and that's saying a lot. I hate using it for the most basic things--I'd hate to have to use it at work. Word processing has been pretty much downhill since Word Perfect 6.x, but it's really hit a new low with Google Docs.
So maybe Google Docs isn't the best option currently, but there are definitely more efficient ways to work than what is done now. This is an area that could use some innovation, and putting things on github is an early step to find out what can work. However, those who are used to status quo have to be interested in finding new, perhaps better, ways to work. If you go into things thinking you're married to Microsoft Office, nothing is going to change.
There is nothing better right now than the MS Word workflow with all the accumulated templates, macros, etc. We can both imagine better things, and it is indeed an area that could use a lot of innovation, but github, with zero support for word processing formats or even binary files in general, is a non-starter here. Want to disrupt the space? Make Github for ODF documents in a way that let's you cleanly e-mail around diffs and apply them, and let's you easily merge changes from multiple people to documents that may have drifted from the branch point. Make it robust, so people don't fear using the tool for what it might do to their documents. That's a billion dollar Office monopoly-challenging idea right there with applications far beyond the legal space. It's also technically challenging as hell. This is not a space where a minimally viable product is going to play. It's competing with MS on its own turf.
That's a fine suggestion for a product, and you're right about it competing with MS on its own turf: and that's why no one will use it. There is nothing super inherent with many documents that are currently emailed around as whole atomic units that they wouldn't be better represented as plain text. And git ALREADY handles plain text really well. It handles emailing diffs and applying changes from email. It is robust enough to not cause fear of using the tool for with it might do to the text. People are married their MS Office based workflow, and they will always find an excuse to maintain it. Migrating the individual components to a different platform (MS Office to ODF) is a valid way to challenge the status quo, and it's just as valid to challenge it by revisiting the assumptions that enforce the status quo (that you need to email diffs or documents around, for example; that can be challenged with on-line, simultaneous, collaborative editing -- which removes the need to email diffs around). Neither one is going to make significant inroads against the current momentum, no matter which of the finer points of momentum (popularity, network effects, cost of transition) can be resolved.
Funny, just earlier today I happened to watch a Clay Shirky TED talk ("How the Internet will Transform Government"), where he showed a hilarious screenshot: a Venn diagram of Lawyers and People with Github accounts.[0]
0. http://25.media.tumblr.com/tumblr_mbkedsQ3EZ1qaxovpo1_500.jp...
I've recently started to do this for technology Statements of Work in government. If City A writes a Statement of Work for a Wordpress integration, why should City B have to write the same thing?
https://github.com/adamjacobbecker/RFP-Library
One question. I understand that the set of items in these documents is carefully chosen based on many years of experience and thousands of data points. A lawyer could probably take a look at this and understand it in 10 minutes.
But for a non lawyer, it seems like too much too soon. I have to figure most companies will need very few of these provisions.
Is there a way to structure this type of document so that the most important thing(s) only could be included, perhaps on one page?
And then structure it in such a way that every few months, or few years, you add a "plugin" for your particular company needs?
My problem with these types of documents is that for 2 guys in a garage they seem to be overkill, and it would be nicer if there were a simpler option that starts with a tiny core that you can then add on as you go.
Regarding the "plug in" process you mention, that's actually a good analogy for what happens between these docs, which are used in a seed round, and the larger set of docs that are used in a next round like a Series A. Believe it or not, these Series Seed docs are significantly stripped down from what Series A docs look like.
Not sure if that entirely answers your question or not, but let me know if there's anything I can help out with.
That does answer my question. I guess for me, I see these documents and I am overwhelmed. But that's just probably because it's so foreign to me.
I actually was going to say, is there anyway to make these documents more concise like underscore.js? Then I opened up underscore.js in Textmate, hit print, and realized it would be 30 pages printed.
I guess I didn't realize how much the perceived length of something depends on the background of the reader. For me, underscore.js is small and concise, for a non programmer it probably looks like a tome. When I saw the Seed docs to me it was a tome, but to you it's probably a quick read.
I do wish legal docs were smaller. But I also wish code were smaller. And I don't really have an answer to how to make that so!
After a while, if/when 'market convention' drifts such that everyone is overriding definitions in the same way, a new 'Definitions' document is created, and people start to work off that.