I had a fascinating conversation with my web site developer last year. He mentioned that, on average, one programmer could do the same amount of work today as six programmers could do in the late 1990s. That’s a massive productivity improvement: 600%! Some people even recommend that, when building an online company, you should focus on mostly hiring programmers, because this continuing productivity improvement means each person you hire will give you an ever continuing productivity increase during their tenure with you.

I asked my developer why this is possible, and he responded that the constant breakthroughs in computer science, new programming languages, the availability of open source software, and constant communication within the field on novel ways to solve challenges, all combine together to improve the ability of programmers to do more work in a timely manner.

This discussion triggered a Passover memory from about eight years ago. I attended a friend’s Seder and sat next to an elderly gentlemen in his eighties who promptly engaged me in a conversation about the legal world. He practiced law for over fifty years, and regaled me with stories of legal life back in the 1950s. Apparently, a talented, experienced secretary was invaluable, as they did most of the contract drafting. Additionally, he told me transactional attorneys faced a limit on the length of contracts and the number of revisions, as massive editing simply took too long via a typewriter too satisfy the business needs of a client. He said that these constrictions actually are quite positive, as they forced attorneys to hone in on the key expectational concerns of their clients in a deal, and there was little incentive to add a great deal of belt and suspenders language or to argue endlessly over limitation of liability/indemnity provisions (which, let’s face it, are usually of little concern to clients and are often unnecessary in their most extreme, aggressive forms which trigger tiring, lengthy negotiations).

Contrast that context with today’s situation, where we routinely go ten or twenty versions deep into contract drafts, prepare voluminous documents that our clients rarely read, and argue strenuously over provisions that provide little risk protection. Despite all the tremendous tools at our hands over the years, such as overnight mail, faxes, email, word processing, and cloud computing, I have the strong feeling that we are less, not more, productive today. The quality of our work is constantly driven downwards by the weak link in any negotiating chain. For instance, in negotiating an original equipment manufacturer supply agreement, there might be an attorney on each side, a customer procurement manager, a customer operations manager, a salesperson, a finance expert on each side, and an information technology expert on each side. Any one of these people, and each individual’s boss, can grind negotiations to a halt with unreasonable negotiating positions, poorly drafted language, massive spelling and formatting errors, document corruption, loss of version control, and unclear email communications. That’s eighteen possible weak links in the chain! And, one might argue, that the two attorneys are sometimes the two weakest links.

This weak link issue doesn’t really exist as much in the programming context, as the programmer is engaged directly with the client on building an outstanding product, not constantly compromising the quality of that product due to an adversary on the other side who has little incentive to achieve high quality (e.g., a crystal clear contract with little ambiguity that sets up the parties in a satisfying, mutually beneficial business relationship) and instead desires to seek one sided concessions (e.g., a contract that insulates one party from any liability while leaving the other party wide open). Having handled many software development contracts myself, when I have seen programming efforts fail, the common cause is too many people involved in the project who demand short term, one sided efforts that result in overly complex code which is unable to function properly or be completed on time. Essentially, programming projects founder on the shoals of an overly legalistic, adverse project management style.

Ultimately, I don’t believe lawyers will ever change and improve their productivity without a sea change in the financial incentives that drive unproductive behavior. I always engage my developer on a per project flat fee basis with a hard deadline. We work together up front to design and lock down a specification before we agree on the fee and the deadline. As a result, his financial incentive is to do great work (so I give him future projects) with tremendous productivity (so he hits the deadline and makes a good return on investment for his time). We’ll need financial incentives in the legal world that drive a similarly positive state of affairs before we will see a massive increase in legal productivity.