Managing Legal
This is a tale of two definitions. Two definitions of what “productivity” means in the delivery of legal services to a company.
It’s about an MIT-trained software engineer named Jason Barnwell who worked in one of the country’s major corporate law firms right out of USC Law School.
The tale begins two months into his first job with a nationally prominent corporate law firm.
Spoiler alert: In Part 2 we learn that Jason Barnwell later became — and is now — Assistant General Counsel – Legal Business, Operations & Strategy at Microsoft.
But I’m getting ahead of the story.
…
Jason Barnwell had been, “staffed as the junior-most associate on an M&A deal advising our client as they sold their business”. He was “naïve” enough — his word — to believe that automating a process in which the law firm deployed six associates and paralegals to photocopy and collate voluminous shareholder consent documents would improve the team’s productivity.
Not to mention, deliver better service to the client.
By writing some basic computer script that was part of his software engineer skill set, Mr. Barnwell’s automation solution would enable one individual to prepare all of these necessary transaction packages — thus freeing up the remaining five team members to do the other tasks needed to close the deal.
For Jason Barnwell — veteran of 4 years of software engineering — getting more done, with fewer resources, in less time, and with fewer mistakes — that all seemed fairly “productive”.
But Jason Barnwell — newly minted attorney with a mere 2 months of corporate law practice — was about to learn that his new profession had a different definition of “productivity” than what he’d been taught at MIT.
…
Jason Barnwell’s account:
“An experience from the second month of my practice as a corporate associate at a big law firm exemplifies the pattern that I have seen again and again ….
“I was staffed as the junior-most associate on an M&A deal advising our client as they sold their business. One afternoon we were assembling the shareholder consents necessary to approve the transaction for mailing. The process involved:
- Printing out master documents;
- Copying the master documents and placing the copies in stacks in the copy room;
- Several paralegals and associates walking loops through the copy room picking up one document from each stack to manually collate a mailing packet; and
- Adding a custom cover letter with share positions and nominal proceeds.”
“I was still an adequate software engineer back then. I told one of my colleagues that I could automate the process with some basic scripting. We could emit a document stack for each shareholder of crisply printed originals with the customized holdings statement using a little mail-merge. A six-person crew would have converged to one person pulling the collated stacks from the printer and inserting them into mailers. The rest of us could focus on other aspects of the transaction rather than walking laps in an ozone filled copy room.
“My colleague declined my offer to automate our task without explanation. I pressed for a reason, and I was told that my process was not known, understood, or trusted. That was fair. And this work needed to be done right. I tried to explain that our automation would be wrong or right, but fully testable. I could run a small test for auditing before sending the whole job. Again, my offer was declined.
“I planned to revisit this for the next M&A deal, but about six weeks later I realized why that would be pointless. I saw the itemized bill for the transaction. A small portion compared to the proceeds, but still a large number. There was a line item for my contribution. My hours worked multiplied by my billable rate.
“That client paid a lot for me to make copies. There was inadequate incentive for my firm to take advantage of the efficiencies I could offer.”
To be continued in Part 2