I was at a Meetup the other day telling a software engineer that I’m a legal engineer. First, I apologized for the fact that everyone in the tech industry is overloading the term “engineer,” but then again, licensed civil engineers tend to give software “engineers” the stink eye too.
But he generally agreed that it makes a lot of sense in this context because it’s hard to quickly understand how to bring the combination of law and code to life. A “coding lawyer” isn’t quite right and doesn’t express the intent of the role anyway. He said something like, “being able to analyze code and law must be interesting because they’re so similar.” But they’re not, and it’s not really what legal engineers need or do.
It starts with a capability to write and analyze code. Knowing how to write code that’s legally compliant is a foundation. It’s necessary, but not sufficient, however. A capable legal engineer needs to understand how software gets made. Anyone can take an $11.99 Udemy course on Python, but that teaches you nothing about how teams build software, architecture, or how decisions get made in engineering teams.
For it is not just in the code where law can express itself or legal issues arise; it’s often in the architecture of the software, the design of the system, the UI, the UX, or the infrastructure where legal issues will be found. Privacy law is a great example of this, especially under the soon-to-be effective California Consumer Privacy Act of 2018, where there will be legal implications at code, architecture, and design levels. In this way, a legal engineer is similar to a site reliability engineer because SREs need holistic understanding of an application (or solution in an enterprise context), its design, its architecture, and its performance goals.
Knowing how to effectively work with engineering teams and how to effectively contribute to these conversations is critical and far more important than merely understanding how to write a function in, say, Python.
A legal engineer needs some kind of in depth legal training as well. I am on the fence whether one needs to be a fully licensed lawyer, or solicitor, or whatever the designation is called in your jurisdiction. At a minimum, however, a legal engineer clearly needs to go through full, rigorous legal training and have some experience practicing law.
I do not think one can truly get a good feel for how law actually applies without those immersive experiences.
Specifically, I am thinking about issue spotting. American law schools, for example, emphasize “issue spotting” skills, which is to say, given a set of facts and circumstances, a lawyer needs to be able to “spot” the legal issues implicated by those facts. This is a very different skill from simply Googling for black letter law and then making a judgment about whether a situation falls on one side of the law or the other.
Instead, issue spotting means that you have to take a broader, richer understanding of the full body of law, and think through the issues implicated by the facts before you, which, for a legal engineer, are going to be very technical. Legal engineers should be applying this skill daily.
I think a lot of lawyers, once they leave law school and specialize in a certain area, tend to lose the issue spotting skill and the energy it takes to bring it to bear. But to be a strong legal engineer, one must be able to look at some lines of code or a system architecture diagram or consider a user experience and really think about what the legal implications are. This is a very active step, taking some creativity and energy. Legal engineers must be strong issue spotters in technical issues.
Finally, the effective legal engineer has to be able to lead. I sense, without knowing you, that this may be the hardest capability for legal engineers to develop because most of them have spent so much time developing substantive knowledge in two very large bodies — software and law. As such they are likely strong analytical thinkers, and, worse, neither body is known for developing leadership capabilities.
But leadership is absolutely critical. Simply being able to analyze the technical landscape and point out the legal features implicated by it — no matter how rigorous, critical, and insightful those implications are — will not be enough to get results in the corporate world.
Instead, the legal engineer needs to get out in front by clearly framing the issue(s), making sure the team understands them, and providing a clear vision for how to resolve or mitigate the issues at a technical level. Without leading, the legal engineer runs the risk of being seen as a roadblock to the team, kind of like a QA function that doesn’t lead. The legal engineer must learn to lead.
Having strong software engineering experience, strong legal issue spotting skills, and combining rare leadership capabilities is a lot to ask, I know. It might take a decade or two to accumulate all the skills and capabilities, but I think it’s strongly worth it.