Thinking Like a Legal Engineer

This is the second installment in a series outlining how the Monax Platform and the Agreements Network can be used in harmony to create the legal products of the future. This post covers the mindset of legal engineering.

Legal products are digital solutions to legal problems in the network economy. They hold the promise of broader financial inclusion and access to justice while offering countless creative monetization opportunities. We at Monax like to call this “legal engineering,” to distinguish our work in collaborative software product development from the practice of law.

New tools, new skills. Most legal professionals, including us at Monax, require a bit of skill supplementation in order to execute functional digital products, but the first step involves mindset - “thinking like a legal engineer.” Designing and building legal products is different in process from traditional legal practice for many reasons, including the work style and mindset of legal professionals. Legal products combine many technical tools and legal processes. The humans who design and produce these products, the “legal engineers,” have to learn, and in some cases invent, new methods and tools for achieving legal solutions goals. While we at Monax are dedicated to building no-code solutions to enable lawyers to create legal products, other parts of product design areas important for legal professionals as code.

One aspect of the legal product engineering mentality is acceptance that learning about technology, like law, is an ongoing journey. What worked today might not work tomorrow, and we better have a plan for updating understanding and execution over time. For each of us it’s an individual journey to create a new discipline by filling in the gaps of our personal skill sets, but there are a new common strategies, tools and methods that will help bridge the gap.

Iterate small steps and tolerate some uncertainty. Software engineers long ago noticed that in order to be more cost-effective and competitive, they needed to develop in iterative, bite-sized steps that enable them to identify problems and opportunities without wasting too much time or money. The result is the widely-used practice of “Agile Development Methodology” which helps keep projects on track and moving forward without wasting undue expense building things that won’t work.

Legal design meets agile methodology. Lawyers are typically accustomed to coming in toward the end of a development project as part of a review/audit procedure before releasing a product to the public: “let’s run it by Legal.” This means deep sunk costs before valuable feedback that may reveal a problem, or an additional monetization opportunity!

In collaborative software development, legally-trained designers and technical developers participate in the ideation, design and build of a product from the beginning. This shift, from lawyers as gatekeepers regarding whether a product is good enough for the market to active participants in building from the beginning, requires a shift in work style as well as learning new methodologies and tools. By integrating with the product development cycle, legal professionals are able to add value at the code, build, quality assurance and production stages of a product development lifecycle.

In our next legal engineering blog, we apply the above philosophy to the issues of fraud in the supply chain and begin to design a solution.

GROW revenue. SHRINK risk.

I'm working in the

and I a contract management platform,

needing to make

Doug Requested

Thanks for getting in touch! We'll get back to you soon.