Everything the Internet Knows About Legal Engineering – A Bibliography So Far

There isn’t much written about legal engineering yet. The following is what the internet has said so far with my thoughts sprinkled into it.

They say it started with Richard Susskind’s use of the term “legal knowledge engineer” in 2010’s The End of Lawyers, which I was careful not to read considering I had just graduated from law school! Amazon

Monax says that legal engineering is a “combination of legal design and software engineering.” Part of the role is focused on automating rights and obligations into smart contracts and other automated systems. “Drafting the rules of commercial interactions is traditionally the job of a lawyer. In a data-driven ecosystem, it’s the job of legal engineers.” (Emphasis added.)

I particularly like that last line, and I really only have two critiques of the write up. First, I feel like “legal design” may not be very actionable for those wanting to enter the field. And second, it seems to me that legal engineers are needed in more than commercial settings.

Wavelength defines a legal engineer as “a person that sits at the interface of technology, law and data, and who is trained and skilled in the construction of designed legal solutions.” Drew Winlaw later argues there are many different types of legal engineers but if you have a combination of legal training, empathy, impatience with the status quo, bravery to experiment, imagination about technology’s application, and pragmatism then you may have the skills you need to be a legal engineer.

Stuart Barr, following Susskind’s lead, focuses on the legal engineer role within law firms (I tend to focus on the role in any software engineering environment). He says that a legal engineer could come from either a legal or tech background but a legal engineer must “have a deep understanding of both technology and legal practice and an appetite to drive innovation, efficiency, process improvement and client engagement.”

Perhaps most impactful, he hammers on the idea that “technology itself is not the differentiator. It’s about how you apply it. That’s why legal engineers are so important. They have the creativity to come up with technological solutions to very specific problems, and this is where the competitive advantage comes in.” (Emphasis added – emphatically.)

Jake Goldenfein and Andrea Leiter focus the legal engineer role on the evolving field of blockchain engineering and smart contract programming. They draw an interesting relationship between from modern day automated smart contracts to medieval writ system. They seemingly suggest and the legal engineer might be one who translates the facts of a dispute or contract into the correct form of writ, or smart contract. It’s interesting, but I don’t think it’s actually workable in practice.

The IAPP has a number of unique perspectives given that privacy lawyers and privacy engineers also work at the intersection of law and technology. Here is one such article.

I probably missed something. Let me know! michael@michaelricelaw.com

“Want to solve the problems computer science is creating in the world?”

I advocate that the industry should consider including the legal engineering role in some development teams. A recent tweet crossed my feed earlier this week reminding me why.

Then the first reply gets to my rationale behind the new legal engineer role (somewhat orthogonally):

Let me explain.

Computer science is agnostic about the subject matter. Whether you’re building a game, a social network, a supply chain management system, a self driving car, or a new token-based economy, computer science helps us design it correctly and efficiently.

But as the products of computer scientists reached massive global adoption over the past decade, we’ve witnessed all kinds of problems popping up… societal, political, ethics, legal, racism, and much more. As software has entered most of our daily lives, every human problem has has also manifested itself in the products built by computer scientists. These are problems they don’t teach solutions for in core computer science curriculum.

Thus my strong belief, based on years of experience with dozens and dozens of teams, is that a software engineering team needs a diversity of skills and considerations; and the legal engineer may be a critically important one for some teams.

The Legal Engineer’s Core Teamwork Skills

On Monday I was writing about my trip to Oregon. I didn’t mention much about what happened on the ground (can’t) but I can summarize by saying their problems aren’t technical — they’re just a dysfunctional team.

Software, especially software engineering as a discipline, is not a solo endeavor. To be truly successful in today’s market, your product team is going to have to be just that — a team, ideally with diverse experiences and viewpoints.

Now it’s Friday. Since Oregon, I’ve been involved in at least three or four different teams in different organizations. Some are dynamic and high performing, some are slow and methodical, and some are just straight up toxic. Even got into a verbal fight in one such toxic environment just yesterday.

A Lawyer’s Transition to Team Player

It got me thinking about lawyers who want to make the jump to the legal engineer role and be a member of technical teams. It might be a hard transition to navigate.

For context, maybe I should level set with my own experiences. I came to law after about ten years of writing code in small and large companies. Never did actually work for a firm full-time after law school, but I did clerk pert-time for four different law firms while in school and then worked full-time for a federal judge for almost two years.

I admired many of the professionals working in those firms and learned a lot from them. However, the political and organizational skills demonstrated by the lawyers in those environments was very, very different from the skills I see in small, successful software engineering teams.

A Legal Engineer’s Core Teamwork Skills

In this post, I want to highlight a handful of the skills I think are critical for legal engineers, targeted primarily at lawyers making the transition.

Creating Safety

One of the first things a new legal engineer may notice is that they’re deeply embedded with a group of other people, sometimes shoulder to shoulder, day after day. There are rarely doors to close where software is being developed.

In these teams of software engineers, product managers, UX designers, and etc., there’s little status within the team, which may be a hard switch for someone coming from a high status profession like law. Here you’re going to be just one of the team, roughly equal to everyone else, except that you may feel intimidated if you’re just coming up to speed on the technology side.

Thus you may find yourself trying to assert your status or value to the team through any number of behaviors. You might be tempted to get defensive, be quick to correct other team members, project an air of superiority, be overly guarded, or, worse of all, become critical of other team members, the project, or the company. Oh sorry, I didn’t mean you, but maybe you know someone from the legal profession who might act like that from time to time when feeling out of place.

Your team is only going to be successful if everyone on the team feels safe to offer ideas, to take risks, and to try things without worrying whether they’ll be called out. “There’s no team without trust,” leads a popular HBR article on the topic of team safety.

Protecting team safety is everyone’s responsibility, not just management’s. That’s because anyone on the team can damage safety within the team. Any “provocation by a boss, competitive coworker, or dismissive subordinate” gets interpreted by our lizard brains as a fight or flight moment,destroying our ability to bring our creativity to the team.

So, as a new entrant to the software industry in this valuable new role, I beg you please, make preserving team safety your first objective.

And if you find yourself in a team where safety is low, lead from the front and be a safe team member.

Openness, Transparency, Vulnerability

If you’re on a safe team, then everyone, including you as a new legal engineer, is free to be open, transparent, and vulnerable.

Unfortunately, these aren’t traits highly prized in the legal profession. Indeed, if you’re a litigator they may actually work against your effectiveness.

Put another way, just because you’re free to begin to embrace these traits, which we all have if we choose to use them, doesn’t mean you’re going to open right up.

So take baby steps.

And know there’s a big reward waiting for you if you can work in a safe team where everyone is open, transparent, and vulnerable. It would feel almost like family, wouldn’t it? And most importantly, the team wouldn’t have to waste much time on office politics and could focus on creativity and getting awesome stuff done.

Baby steps.

Resilience to Try, Fail, Learn, and Start Again

The legal profession is famously risk averse — for a reason. Lawyers have to get it right the first time when they’re drafting a major corporate merger agreement, someone’s last will and testament, or filing a points and authorities memo with the court. When litigators make arguments in court, they don’t get many chances to change course or walk back a mistake.

In today’s highly agile software industry, we approach it exactly the other way around. We don’t try to get it right from the beginning.

In the software industry we take a lot of chances. We try things. They fail. We learn what worked and what didn’t. We try again, and probably fail again. But we keep iterating until we get it right.

You’ll shed a lot of anxiety, and it’s a lot of fun when you embrace it.

Where are the lawyers?

I’m at an undisclosed airport in the Pacific Northwest as I write this. Was working with an organization that deals with lots and lots of money in a highly, highly regulated way.

We’re thinking through how to modernize their core, legacy software to be more responsive to stakeholders’ and regulators’ shifting demands.

When this monolithic app was being designed, nobody was mashing the word legal and engineer together. It’s a shame they weren’t because there’s a whole lot of law and regulation embedded in this codebase, and it would’ve been nice to have a lawyer who understands software design and architecture show up from time to time while it was being built.

Most of this legacy system’s design was left to the accountants, or, more catastrophically, poorly trained and lightly experienced “business analysts” who struggled to understand the legal and policy implications of what they were doing, let alone the technology.

I strongly believe that some of their confusion led to poor software design choices that have been layered on over the decades.

Accountants Were the Early Movers in the Professional Services / Tech Space

I was in college at Arizona State back in the mid 1990s, when my client’s software was being written. I was in the “accounting information systems” department, which was endowed by Andersen Consulting (remember them?).

Many of my professors were former Andersen consultants (some sporting AC tattoos). They knew the future of accounting wasn’t in managing double entry ledgers or even being CPAs but in managing accounting software and systems — so they helped drive this new degree program called AIS at Arizona State.

Aside from the dot-com boom, there were two accounting slash regulatory upheavals driving a huge amount of software professional services in the late 1990s and early 2000s: the Y2K issue and, 200s post-dotcom crash, SOX 404. The first was clearly an accounting glitch — nobody expected those old accounting systems to run past the year 2000. The second was a reaction to, ironically, Arthur Andersen, Andersen Consulting, and Enron.

The accountants ran away with the professional services market.

So Where Are the Lawyers?

It’s interesting, isn’t it, that accountants are free not only to advise on regulatory requirements but also be the business and technology consultancy for implementing those requirements. They freely advise on both technology and regulatory requirements (whether it’s self imposed, like FASB; regulatory, like SEC regs; or even statutory, like the Sarbanes Oxley Act § 404).

But where are the lawyers? In all the corporate meeting rooms (really, my natural habitat), only once did I see lawyers present and dealing with fairly low level technical issues with technologists — and the lawyers looked pretty ill at ease.

Maybe it’s historical. Maybe, because accountants and auditors have traditionally been deeply embedded in the day to day systems within organizations, they had a unique spot on the playing field.

Maybe it’s the nature of their work; lawyers aren’t, as a whole, known for their math and accounting skills (ask celeb lawyer Michael Avenatti).

Maybe it’s the fact that auditors are requires to dive into the low level systems of corporations

Whatever it is, the Big Four and their associated consulting firms have captured a huge share of enterprise tech and business advisory consulting, to the tune of hundreds of billions of dollars a year. Just ask Deloitte or Accenture or IBM Global Services.

But, having gone through a years of SOX 404 work and legacy codebases like what I saw in the Pacific Northwest today, I know the accountants and their management consulting practices don’t always get it right when interpreting statutory and regulatory provisions. But they show up. They’re there in the dingy meeting room deep in Corporate America and they’re speaking with some authority. When they talk people listen.

Just like accountants made a strategic choice to get deep in the weeds with technology to expand their trade, lawyers should too.