In this piece we chat to Sam Smolkin of Office & Dragons about Transaction Development, or how to design deals like software and thereby save a ton of time whilst creating a wealth of value for clients and lawyers alike.
What is Transaction Development?
Transaction Development is a way to deliver deals. At its core, it is a shift in mindset – rather than focusing on drafting and negotiating various documents like Share Purchase Agreements or Senior Facilities Agreements, you think about transactions as a set of deal terms, or data, which can be visualised in various ways, such as clauses in various contracts, steps in a tax structuring powerpoint, or points in a post-closing governance memo.
It’s moving our thinking one level up: rather than thinking about how individual documents or sets of documents are constructed and produced, we’re thinking about how deals are constructed and delivered as a whole.
Thinking about deals, rather than documents, leads to greater efficiencies. Rather than creating templates one at a time for just the work we’ve done frequently before, we can put in place a framework that guides and supports the way deal terms are developed and contracts are produced for any deal, even where all the contracts are new and bespoke.
So, it starts with a better process, and that alone can save a lot of time and improve accuracy as you rationalise away redundant steps and error-prone procedures from your workflows. On top of that, we can build technologies leveraging that framework to automate away the toilsome manual processes which remain.
We achieve these efficiencies when we separate out the key deal terms from the documents that they appear in during the negotiation process. Keeping the deal terms separate and in one place until we’re ready to sign the contracts, rather than writing and updating them directly and repetitively into various document pages, makes it quicker and easier for everyone to align on terms and make sure they’re reflected correctly in the final form contracts and other work products created for the deal.
If we’re working this way, we’re also capturing data about the deal in real-time as it develops. We don’t have to spend a bunch of time and money trying to find it in the documents afterwards (whether it’s expensive lawyers or expensive AI tools doing the digging), and we can use it to provide valuable insights to our clients (and stand out from our competitors who can’t do so as quickly).
You talk about a shift in mindset. What led to conceptualising that mindset and applying it to law?
This concept isn’t new; it’s a core principle of modern software engineering whereby software engineers decouple the data (the information) from the view (the presentation of the information).
It’s also known as the separation of concerns, i.e. breaking up a system into component parts such that each part does one thing and one thing only.
This principle is the backbone of software engineering patterns like Model-View-Controller (MVC) and software development frameworks like Angular and technologies like the Angular compiler.
These frameworks and technologies are what make it possible for software developers to rapidly develop the many different apps we all use today – there are reasons we have so much more software today than we did a couple decades ago, and this is a big one.
The speed of development doesn’t stem from standardising the applications, but from standardising the way they organise information while working – where the data, the business logic and the presentation elements go. This allows many developers to work together efficiently without having to dig through each other’s code to find relevant information, and to develop technologies based on these “standard formats” to speed up the work.
Separation of concerns (if this remains unclear, see below expandable section) also makes it far easier to re-use and update systems built in this way. It also provides greater control over how changes to one part of the system do and don’t affect the other.
Up until now, this is not how contracts are created and updated, nor how a transaction is thought about (including its underlying contractual components).
Instead, each contract in a transaction has no link to a common data source representing (in technical terms, modelling) the transaction’s key terms. This means that if you change the amount of a loan in the loan agreement, references to that figure in any related documents – such as the security documentation – remain unchanged and instead require individual manual updating. This is because there is no common data model to the transaction and separate from the various presentations of that data, i.e. the contracts comprising the deal.
Modern websites employ separation of concerns so that you can update the underlying data once and have those changes automatically rendered in each place and on each web page where that data is presented vs. having to make the same change one by one across multiple pages. Conversely, this also allows you to update the interfaces (e.g. web pages for a website) without upsetting the underlying data that such interfaces present to the user.
Let’s use the example of Amazon to explore separation of concerns, before seeing how this has parallels with modern contract drafting.
Changing data without upsetting the presentation
If I were browsing for The Lord of the Rings Blu-ray boxset, that product listing will also highlight other items I might consider buying, eg.
These items all display several pieces of data (the item name, price, star rating, leading actors) stored in Amazon’s inventory database. In a lot of ways, the way in which one item’s listing will refer to other item’s listings is akin to how one contract cross-references data in one or more other contracts, e.g. a defined term or important obligation.
If Amazon wanted to change a piece of that data (say, apply a 15% discount to all Lord of the Rings products for Black Friday), they simply need to access the database that contains the data for each of these products and make a single change (e.g. run a command that reduces the price of all Lord of the Rings items by 15%) in order to update the entire store, including every place across every page on Amazon’s website where this information is listed, ie. both the item’s individual listing and any cross-references to that listing in any other item’s listings (as above).
Without separation of concerns this data might be hardcoded into each individual page in which that item’s data appears (including recommendation bars like the above), creating multiple and separate copies of that data. In that scenario, somebody on the merchandising team would need to go to every single page that a product might appear in to double check that the price is reflected correctly across the site - they couldn’t make one change and have it automatically updated across the site. This setup would make no sense because Amazon’s website is necessarily in constant flux, being updated to reflect market pricing, changes to inventory and recommendations based on user interactions.
Changing the presentation without upsetting the data
Now, if Amazon also decided that the “Customers who viewed this item also viewed” bar should not have any star rating data displayed, i.e. a change in the presentation of data, a single programmatic change can remove that piece of data from the user interface without deleting the underlying data. The data still remains in the database, and will appear anywhere else in the site that they want, but for that bar, the data will not be displayed.
Without separation of concerns, if that data was hard coded into the interface, then removing that data would delete that copy of it. In that scenario, if Amazon later wanted to put the star ratings back into that bar, they would need to go and manually find that data to insert, or recreate it from scratch!
By employing separation of concerns, Amazon is able to update and extend their website whilst being able to sell millions of products across millions of pages and cross-referenced listings, and can do so without having inconsistencies from page-to-page.
This is not how lawyers tend to work...
Negotiations in legal transactions require lawyers to track and update multiple variables across each and every instance where those variables are described, e.g. parties, amounts, percentages, specific wording and so on. Until agreement is reached and the contracts are signed, these variables remain in constant flux. For the same reasons as described for Amazon, lawyers would - but do not - benefit from separation of concerns.
For instance, in a lending transaction the deal variables change through negotiation. If the amount of a loan is referenced on average x 5 times in each document across x 30 deal documents (e.g. the loan agreement, security agreements, corporate authorisation documents (borrower entity board and shareholder resolutions)) that’s 150 manual updates to be made, saved and redlined to check the changes each and any time that amount changes!
150 manual changes! Why is that?
That is because each reference to the loan value in each document is a separate copy of that data in multiple places, i.e. not linked to a centralised database of the deal’s key variables such as dates, amounts, percentages and so on. As such, there is no easy way to change that value once and automatically repeat that change across every reference in every document. The most lawyers can hope for is to do a simple find + replace in Word for a single document, and repeat that process for each and every other document where that value appears. And that takes time! A lot of time!
As we’ll see, Transaction Development puts lawyers in the same position as Amazon with regard to bulk updates to contract data. By separating the data (deal variables) from the presentation (the contracts in which those deal variables are described) it becomes easy and efficient to change the deal variables and have them reflected instantly across every instance in every contract where that value appears. Likewise, updating the presentation of the contract can be done without upsetting the underlying deal variables.
Why does the market need Transaction Development? What problem is it solving?
When I was a private equity M&A lawyer at Kirkland & Ellis, there’s a phrase I used to hear all the time from my colleagues, which was “Worst. Deal. Ever.” I heard it when I finished my first deal – rough, late nights digging through hundreds of pages of contracts making last-minute changes while “what’s the status?” emails pile up in my inbox. At the time I was relieved – if that was the worst, it could only get better, right? Wrong. The next deal was even worse, and the trend of “Worst. Deal. Ever.” continued. In the interest of self-preservation, I started to wonder why.
Eventually, I came to an obvious conclusion: it’s because deals like M&A and financings are constantly changing, getting faster and more complex, but we lawyers are scrambling to keep up, drafting documents the way they have been for centuries. It feels very unsustainable.
Today, partners and legal tech leaders at law firms I work with tell me:
“Sam, our team is strong, and we do great work, but I’m frustrated with all the document churn that gets in the way of getting deals done. Some of it, we can’t even bill to clients, and I’m sick of reviewing for missing zeroes and other stupid mistakes in the docs.”
On the client side, transaction counsel and deal teams tell me:
“Sam, I’m worried because I always feel a few days behind where the advisors are on my deals, despite the memos and catch-up calls. And I trust my lawyers, but when I catch a mistake in the docs, that trust evaporates, and now I’m frustrated because I have to check each one meticulously.”
On top of that, we know GCs are always under pressure to keep fees down.
It would seem like Document Automation should solve these problems, but it doesn’t, because deals are bespoke, and documents keep turning well beyond the first draft.
This is the conundrum that Transaction Development aims to solve: evolving our approach to developing transactions just as the transactions themselves evolve, helping lawyers and their clients develop complex deals with bespoke contracts efficiently.
How does it work? Can you give a use case?
For a concrete example and use cases, I can talk about Office & Dragons (O&D) and how some of our customers are using it.
O&D provides a termsheet-like command centre for creating and editing contracts, letting you simultaneously update multiple suites of documents, or automatically spin out new documents from previous work or templates.
When you’re working on a deal using O&D, rather than taking the deal terms (for example, financial amounts, closing date, governing law clause, etc.) and manually entering them directly in every document one by one, you put that information in just one place: a simple table (we call these “Turnsheets” because they are kind of like termsheets that turn into documents)). This forms the central data source – the data model – common across the desired number of contracts to a transaction.
Now, rather than hunting through dozens of documents for a piece of information, everyone knows exactly where to look and can find it quickly, without confusion. All relevant transaction variables live inside the Turnsheet.
Normally, making changes to any one of these terms is painful because you have to make conforming changes one-by-one across every affected document (on top of hunting through all of the documents to uncover which ones are affected). This process can take hours, even for something simple such as adding an additional zero to a financial figure that appears in multiple documents in multiple places.
With O&D, you make the change in just one place – the Turnsheet – and all relevant documents are updated at once.
With O&D, they’ve changed their approach. They now negotiate and agree all of their documents with meaningful placeholders like [loan amount] for terms that might vary, instead of typing $100,000,000 directly into the docs, and separately agreeing to the Turnsheet which contains the specific data points. This has not only sped things up by removing a lot of toil from the process of spinning out and updating docs, but also by making the work easier to review and improving accuracy. Before, each side would check the other’s work by combing through redlines and sending markups where errors were inevitably caught, keeping people up late and delaying closing. Now, the documents are correct from the first send, so this process is no longer needed.
In other words, rather than needing to check each reference to each variable in each contract, you can check the Turnsheet and if anything is incorrect or in need of update, that edit can be made one time in the O&D Table and immediately updated across every instance in every document where that variable appears. This can mean tasks that previously took hours can be satisfied within a few minutes.
Importantly, you don’t need to know which terms will change in advance to use O&D. Since Transaction Development is a framework-based approach to automation, rather than a template-based approach, you don’t have to encode any fields at the outset. Instead, it’s highly flexible: you can easily add additional variables at any stage of the process and control these centrally via the Turnsheet.
At another firm, some members of the real estate finance team discovered a mistake in over 300 documents right before closing. They set up a Turnsheet such that it would replace the incorrect information with the correct information across all the docs, and one person fixed it in minutes, whereas before it would have been an all-hands exercise lasting hours. This deals with a pervasive issue in legal processes whereby inconsequential details – e.g. a simple typo – can, absent of a solution like O&D, have outsize negative impacts in terms of time, cost and stress to remediate. O&D resets the balance, making inconsequential errors inconsequential to solve.
What’s the difference between Transaction Development and Document Automation?
To explain the difference, I like to use the analogy of a factory.
In the olden days, when you wanted to build a part for something you were building, like a gear for an automobile engine, each of those parts would be made individually by a craftsperson, cutting parts one at a time. They could make any part they needed, but it wasn’t scalable. You weren’t going to put a car in every home. By analogy, that’s manual drafting in the legal world. It’s very flexible, you can draft any new or bespoke contract in the world, but it doesn’t scale – the next contract takes as long to draft or edit as the first one, and reviewing the document suite to ensure accuracy gets more difficult as the number of documents increases.
Moving forward in time, a major innovation in manufacturing was the introduction of plastic moulding machines. Before beginning production you need to decide exactly what you need to build and how. You invest a lot of time and money upfront building a big, expensive mould, but then you can crank out lots of parts very quickly and cheaply. It scales very well, but it’s not flexible, because the mould can crank out only one type of part. When you need a bespoke part or new product line that doesn’t fit the mould, you’re stuck. You either have to mould a similar part and do a lot of manual cutting and shaping afterwards, or else just make it manually from the start. And whilst this is happening, production may need to be paused.
That’s Document Automation.
It works where standard form contracts make sense, like an ordinary employment agreement. There’s not much value in bespoking those because there’s not a lot at risk or a lot of money on the table. They are also incredibly predictable from the outset, and therefore easily repeatable and not subject to much change.
LegalZoom has built a multi-billion-dollar business automating documents for these use cases. In law firms, however, there’s been very limited application, despite the fact it’s been around for decades.
When we ask lawyers and legal tech professionals why that is, they tell us “Our work is bespoke. We’re not just choosing between a few stock clauses in a standard form. Furthermore, we work on very tight deadlines. Spending a bunch of time making templates won’t help.”
So, they’re stuck with manual drafting.
Bringing the factory analogy forward to today, we’re currently witnessing the revolution of 3D printing. 3D printing changes the game, because it is a scalable way to craft any part with any customisation. Unlike plastic moulding, you don’t need to spend significant time and effort upfront changing the underlying machinery each time a new part is required. Instead, the thing you change is the data about the part to be made, which is sent to the 3D printer for printing. This makes it very easy, quick and cheap to alter production and respond to change. That’s how we see Transaction Development.
Transaction Development is 3D printing for deals.
Unlike document automation, which creates scalable but inflexible templates and requires significant prior knowledge of the automation subject, Transaction Development is about scalability and flexibility without the need for prior knowledge. It’s putting in place a framework that guides and supports the way deal terms are developed and contracts produced for any deal, even where all the contracts are new and bespoke.
Is anyone actually using Transaction Development today?
Yes! Office & Dragons is already being used by some of the world’s top law firms in practices like Finance, Corporate / M&A, Investment Funds, IP Transactions, Employment, and more.
Some of these firms have even found successful use cases in their litigation practices or for document processing functions like redactions.
We’re also having good conversations about Transaction Development with firms and other businesses who aren’t O&D customers. It’s not just about tech or our tech specifically – it’s a paradigm shift that leads to a better process for getting work done. Tech like ours can enable, empower, enforce, and scale that process, but a lot can be done even without tech.
Your company has a pretty unique name! What’s the story behind it?
Ah yes, the #1 question I get asked in interviews… Back when I was a lawyer working on the Worst. Deals. Ever., the office felt a lot like my dungeon, and I needed something magic like a dragon to save me… so yeah, it’s a Dungeons & Dragons pun!
Where can we go to find out more?
If you enjoyed this intro to Transaction Development, please check out our longer overview on Transaction Development. If you’re keen to know more about Office & Dragons and our implementation of Transaction Development, I recommend you check out this short video and our website. If you fancy joining the conversation please follow us on LinkedIn and Twitter and using #DraftDealsNotDocs.