Lots of recent conversations have made me think it would be helpful to collect my thoughts on how to ‘get into legal tech’.
I think some context is needed though before we get to ‘how’ part of this:
- what do I mean by legal tech;
- why get into legal tech;
- what do people doing legal tech do; and
- how do you get to do those things (and how can you get good at it).
I’m mainly writing this for a younger version of myself. Hopefully helping some people leap some of their career, hopefully emboldening some people, and hopefully surfacing some information that isn’t normally written down publicly.
What is legal tech?
This is an unnecessarily contentious question that people waste a lot of time on Twitter and conference stages defining.
Some people define legal tech so narrowly that it almost doesn’t exist (ie. technology that only solves legal user stories, and so if the technology is also useful outside of the ‘legal domain’ it is not legal tech). I don’t see the point of this definition, unless the point is that any given technology is normally useful across industries. It’s also tempting to take the opposite approach – to point to the long and rich history of lawyers embracing and using technology, and call any use of technology by lawyers legal tech – including sending emails, or typing a letter in MS Word. I think this definition is more helpful because it is a something, not a nothing.
If we go further, I think we can identify the ‘something’ at the core of that definition which gives us a useful platform to use for the rest of this essay. I might later write more on this, as it could be an essay in itself.
Stealing a line from someone that won’t mind me taking it: ‘tech’ is anything that removes the need for humans or makes things faster, cheaper, more secure or powerful. To me you’re doing legal tech anytime you’re working on a legal problem and make or use some tech which wasn’t in your or your peers’ baseline method for working on the problem. Note that this is a relative definition, and it keeps moving. Efficient methods that become the way that everyone does it, stop becoming legal tech at some point.
So, using the telephone, or email, or a word processor: no longer legal tech. Automated drafting, ML based meaning extraction, scripted approval and signature flow systems, ‘no-code’ deal flow platforms: all definitely legal tech. e-billing of legal matters, automated client on-boarding and KYC, matter management systems: also legal tech.
So this is a broad definition, but it doesn’t cover everything. For me, to be legal tech there still has to be a way that reasonable competent people would still attempt to do the task without the legal tech tool. Once that method is pervasive, it’s not legal tech any more – it’s just the way.
Why do legal tech?
This is a hugely important aspect, don’t just skip to the how.
You only get one life, and it should be fulfilling. There is a tension here between following your passions, and following your competencies. Common advice is to ‘follow your passion’. On the whole this is poor advice, and you are better served becoming excellent at stuff, and you’ll then become passionate about being a leader in your field (ie. commanding top pay, having agency and autonomy as to how you work, being respected by your peers and clients, understand the methods well enough to be creative and groundbreaking, etc.) These are more rewarding, on the whole, than a middling position in the field that you are, or had, a passion for. The passion grows anyway (see here for more on this).
I’ll still answer the ‘why legal tech?’ question for completeness, but it comes with the heavy caveat above.
To me, working in legal tech raises the stakes from providing classic legal services. It’s legal services with added leverage. There is more upfront cost, compared to the late-majority / post-chasm way of solving the same problem, but also more potential upside. You get it wrong, you get no customers – sure, you learned some lessons, but you lost money. You get it right, there is far more opportunity to delight clients, earn revenue, sweep the market, make a name for yourself, etc. Getting it right is value creating (not zero-sum), meaning you can both deliver more value to users & clients, and capture more value for yourself. Higher variance, higher risk, but more reward if it goes right.
I get an intrinsic, pleasure out of solving a problem through a new process, that is efficient or elegant. I am in flow when working on these sorts of problems, and time disappears, I think in ways I can’t properly recall or describe, etc. This led to me spending quite a bit of time as a kid hacking around music, file sharing, Photoshop, Dreamweaver, remote controls, modems, PC parts, etc. etc. I built up competencies in being a heavy user, and also a lightweight builder, of tech stuff.
I also get an extrinsic pleasure from showing this stuff to people – seeing delight on people’s faces from surprisingly good solutions, being regarded as having a good shot at doing things that other people can’t: taking the problem from 0 to 1, getting a 10x solution, etc. These are vain thoughts, maybe not even healthy thoughts, and I probably have a bias around how often this happens – but I can’t deny the thoughts exist and that they are motivating.
So, I want to maximise impact, get an intrinsic kick out of elegant system based solutions, and am a junkie for adoration: that explains why to do tech, but not legal tech.
The honest answer is I got into legal tech because I got into law first. I went to law school, became a solicitor, and built up those skills and expertise. I then had a chance to differentiate by creating new tech based things within that context. This highlights the importance of skill-stacking. I am a good lawyer. I am a moderately good tech user / hacker. I am in no way a proper coder. I however have a differentiated skillset at that combination of skills (I’ll tackle the old ‘should lawyers code?’ another day). Each of those areas are well-established markets in which it takes years of work, and lots of talent, to stand out. In combination however, you’re competing with far fewer people, but also established methods in one field can be novel and exciting, or be even more effective, in another field. ‘Stacking’ skills, and then using the combination of them to exceed the greats (in utility and in fame) in any one of those areas alone, is an established method (see Range for example).
There are a few specific advantages to the ‘[industry] + tech’skill pair: for example, if you have an idea or a hunch, and you are able to yourself go and build a proof of concept, then you don’t need permission, you can decide to break a few rules doing to see if it would work, and the thing you build is probably far better at communicating the idea, than just the description is.
So, my path here happened in part because, from legal, ‘tech’ was a differentiator (even in a technology law practice).
There is an interesting side thought here – what level of intrinsic interest in law is necessary for it to be worth going into legal tech or, even law? You might read what I wrote above, and think the law part is entirely arbitrary – it could be accounting, or surfing, or anything else in there. That’s not quite right. Looping back to the ‘don’t just follow your passion’ bit above: I had an interest, and good indicators I could be good, in law – then made a somewhat arbitrary choice to go into that industry, and then became more interested in legal issues and legal business issues – so that when I started applying a ‘tech’ lens to those legal issues, I care enough about them intrinsically, and understand them enough through experience, to find the work motivating, and to avoid pitfalls. I say this because of one of Justin Kan’s post-mortem reflections on Atrium was about not going into an industry you don’t really care about. His strong tech competencies could not just be turned to the legal industry (which he had not worked in before), and give him intrinsic motivation. This made life hard when success was not coming quickly for Atrium, and so the extrinsic motivation was not forthcoming. I would also suggest, based on his other observations, that more experience in the
industry profession , before he started, would have helped.
What do people who do legal tech do?
This is now getting to the idea that got me thinking about this post.
First, note the breadth of the definition of legal tech above. I have not cheated and defined it broad, so that I have a long list here. I suspect all the people in the list below would say they ‘do’ legal tech (or at least, they’re doing legal tech, when doing these things).
I think all of these personas are doing legal tech:
- the lawyer who learns how to use visual basic in MS Word to create 100 versions of a contract with basic differences
- the lawyer next to them that uses and runs that same script, using an Excel table to turn on and off paragraphs, re-drafting paragraphs to have elegant phrasing and syntax with the various variables in play, and maintaining this so it doesn’t break as updated through a project (really, doing any of these)
- the lawyer who sets up a conditional signing flow, and docs with dynamic / variable elements in DocuSign for a completion
- the lawyer who reaches out to DocuSign, arranges training for their team on advanced use, organising the session, and supports users on issues and questions
- the lawyer who writes a project & implementation plan for the re-structuring of a typical but fiddly document processing problem that their team encounters, works with an existing vendor to use existing but unused features to address this, and pilots the idea
- the lawyer who gets an API key for companies house, or legislation.gov, and sets up an automatically download of documents for KYC, or legislation tracking, etc.
- the lawyer who identifies a repetitive heavy click, formulaic process, and builds, trains and tests an RPA approach to automate it
- the angel investor who invests in a legal tech startup
- the partner who [buys it] the service
- corporate ventures teams who survey the tech landscape, and work on corporate dev projects in legal tech
- people running market landscape / ideation / marketplace assessment projects in relation to legal tech
- people using and building no-code tools, RPA, regex matching patterns, etc. to solve legal problems
- the software developer at a legal tech firm
- the software developer at an agency who is working on a project for a legal client
- consulting on running and operating automated drafting projects and solutions
- using AI / ML to analyse legal text (whether using TensorFlow, Torch, SpaCY, etc., or off the shelf products, as a basic, or advanced user)
A portion of these are outside the control of just one person (they require budget for example), but quite a few don’t. A portion of these require full time focus, but quite a few don’t. A portion of these require ‘hard’ technical skills, but quite a few don’t and are surprisingly accessible.
Some of these look a lot like just ‘running a business’. If you’re a senior partner in a law firm, you may well be involved in major legal tech initiatives as a stakeholder or for budget approval. This may well be even if you did not operationally ever become involved in such things – still, if you’re buying that stuff, making the final decision on vendors, on project go/no-go, on approval gates, or risk appetite – in my book, you’re also doing legal tech.
Some of these are only legal tech because they happened to be doing law. If you were doing the same of these tasks in another context, it might be called [something else] tech. I don’t think this is problematic however – the skills might have general application, but when you’re doing it in the legal sector, it’s fair to call it legal tech.
How to ‘get into’ legal tech?
I hope the above list of examples of legal tech activities helps to frame this – you can start doing legal tech from most places, I think. This can be broken down into: (a) activities you can do; and (b) decisions you can make.
In a small, non-tech-driven practice, there are opportunities: the marginal difference of small efforts can be higher. Widespread adoption of inefficient processes means ‘simple’ adjustments can reap large returns. Look at what is inefficient, frustrating, repetitive, expensive, or unsatisfying – in your practice, and imagine it being better. Two main ways to go from there:
(1) Without breaking things, with sensitivity to regulatory duties, using dummy data, have a go at fixing it. Get a book on python, learn AutoIT, learn visual basic, learn PowerAutomate, and see if you can make a demo of a better way of doing it. Find an ally to talk to, show them what you’ve done, get their thoughts, and think about who to show it next to.
(2) Read voraciously, attend conferences (online and physical) and seek to understand what commercial products could help. Scout out the market, see if you can get free demos, try them with dummy data, and understand the costs, and work on the business model / RoI model for adoption.
In both cases, keep working on it iteratively, hone that idea, address the key objections, and work towards showing the leadership what you’ve done, how it is better, how the risks are mitigated, and your clear ask for what you want next (budget, time, access to clients, intro to someone, etc.)
In a mid-size and up, more tech-enabled practice – firstly everything set out above can still be done. Secondly – there is probably some more sophisticated tech and software available to you. It almost certainly does more than you are using it for. Learn all of it. The vendor will have manuals, there will be training, they will probably be happy to come in and give extra training, they may well be happy to share their roadmap, or meet to discuss feature requests. Find those opportunities / vendors / problems, turn up, put in the work, and interesting opportunities will follow. Learning how to be the best person in the practice at using some particular software will make you the person people talk to about this stuff: asked to help on the pitch, or if there is another way, or why it doesn’t work. Contribute value, be useful, learn more skills, and a positive feedback cycle will form.
There have always been lots of choices in legal services about who to work for – the market is highly fragmented (and I haven’t looked into it, but I think it has been highly fragmented for a long time in the UK). There is now however also a lot of choice of structure in which you work to do legal tech (LLPs of all sizes, ABS (inc. limited co’s), publicly traded law firms, Big4, start-ups of all sorts, huge tech company…)(e.g. see here, in relation to just one region).
If you look at the list of ‘people doing legal tech‘ above – have a think about which of those you think you would be good at, and map it up against the business structures where their business model involves training and investing in you in these areas (and where solid work would add the most value), and also against particular businesses with synergies to your skills / ambitions, and which are performing well – particularly look at investments in (read the industry press, look at, or set alerts on, Crunchbase). Then simply find a way to work in those places.
You’ll notice a portion of what I put down as people doing legal tech are in senior or stakeholder positions. I think there is a useful observation there – that promotion in an organisation will tend widen the scope of what you’re asked to manage, and it will increasingly include software decisions. So, another ‘way’ to do legal tech becomes – “be involved in strategy” in a legal organisation – and this then will include (now, and increasingly in the future) being involved in the use of tech & software in that strategy. This is not very actionable advice at the start of your career, but I think a neglected observation for people asking this question mid-career.
I hope you’ve found some original and helpful ideas in here. Lots of people seem to define things in a way that makes themselves rare, special or elite. I think high agency people however can actually do legal tech from lots more environments than classic thinking says – and people can make much more difference in the ‘staid, conservative, profession of law’ than people (particularly young people) think.