“I’m not a lawyer anymore” — the mindset shifts from law to tech

Being a lawyer gave me the feeling I could turn my hand to anything. When I switched to legal technology, it took me far too long to realise that I had found myself on one of life’s steep learning curves. My mindset and attitudes caused me to make needless mistakes and reject too readily the views of others who came from a different standpoint.

The movement from lawyer to product manager, legal technologist or startup founder, is becoming more and more popular. In this article, I outline four key mindset shifts that I wish I had made earlier, and that I would advise anybody going on a similar journey to consider.

#1 Software and business are different beasts

The first technology project I embarked on was ambitious. It was to build a collaboration portal between clients and lawyers. It would have a task checklist feature, a chat feature, manage documents and display billing information. Oh — and it would be built in four weeks.

My legal experience told me that you could do anything if you spent enough time at your desk doing it. For example, I was once asked to produce a first draft of a company voluntary arrangement — a highly bespoke document that I had to almost entirely free draft. I simply spent three days with only a few hours of sleep working on this. I ended up with a half decent 240-odd page document.

This approach does not work with software.

The first problem is that there are likely a whole host of foundational things that need to be in place before you can even start thinking about features.

There are the obvious things like how people login to a system. There are the less obvious things like foundational system architecture and deployment pipelines (in simple terms, “how people code stuff and where it goes once they build it”). These things are not the equivalent of inserting a counterparts provision into a contract — they are complicated, and require thought.

The second problem is that software is packed with nuances. Requests that seem simple to implement turn out to be hugely complicated. For example, my requests to “just insert an add document button” only raised more questions. Would people need to delete the documents? Where should the document appear, beginning or end? How would people rename the document? What about versions of the same document? These things need to be thought through carefully.

The third problem is that it is difficult to undo things. The nearest comparison in a legal context would be a contract that is drafted around a comprehensive set of definitions. A single change to a definition might have knock-on impacts on the entire document.

In software, the same issue exists — except to a much greater extent. Because of its many nuances, building a feature takes a long time. Change your mind too readily, and you can spend time building a feature, spend time removing it and then spend time rebuilding it again. Adopting the lean ideology of building in small increments rather than boiling the ocean helps here.

#2 Know why you are doing something

All of this means that when implementing or building software, strategy and planning becomes hugely important. The collaboration portal I was building was eventually a success. But the initial reactions to it continue to haunt me.

When people saw it for the first time, they just didn’t “get it”. The product was clearly full of sleek-looking features, but people struggled to understand why they were relevant to them. People started to ask questions we hadn’t considered: “okay, so I get I can add documents here, but what about if I want to send them to my tax team for comments?”.

The problem was that we had embarked on a complex project without a good enough understanding of why we were investing our time in it. We had not thought about the problems we were solving for people. As a result, people struggled to see the value of it.

As an insolvency lawyer, the problems we were solving for people was usually clear — either saving a company or ensuring the best outcome for creditors in an insolvency. We would draft contracts or act in a certain way because this was mandated by law. There were strategic nuances, but the parameters around decision-making were narrow compared to building software, where you often start from a blank canvas.

Unless you can articulate why people should care about a particular piece of technology, you will struggle to get much traction with it. At best, the technology might well solve something people care about, but you are placing the burden on your users to work that out for themselves instead of telling them upfront. At worst, the whole project will be a failure because you have fallen into the trap of getting excited about technology instead of asking why it matters and what positive change you can bring to people’s lives.

Following a problem-centric approach led us to reframe our collaboration portal as something that solved a tangible thing people cared about, namely the trials and tribulations of managing a complex legal project using Word processing tools. As a result, people got the point quickly and were interested in finding out more.

#3 Remove biases and test assumptions

Lawyers often transition into legal innovation or technology roles to act as the “voice of the lawyer”. This was how I always framed my role. Having been a lawyer myself, I understood very well the problems lawyers experienced on a day-to-day basis.

Over time, I have found that this thinking is problematic. The problem is that not all lawyers are the same. Real estate lawyers are not the same as finance lawyers. No two finance lawyers are the same. By appointing a single person to act as the voice of the lawyer, you will end up implementing or building technology that works very well for that one person, but not for anybody else.

For example, central to our collaboration portal was the ability to process comments received on a contract from another set of lawyers. The workflow for this feature was based around how I had worked, which was to go through each change individually and add it into our own version of the document if we accepted it.

But this isn’t how everyone worked. Some people took a different approach and edited the draft they have received from the other lawyers — removing comments they disagreed with. There were good reasons for this approach, and because we didn’t accommodate it, it meant we lost an important set of users.

Lawyers moving into technology roles have a huge head start. They understand the industry, the language and the context. But they of all people must be extra critical of making sure they are removing their own biases and testing their assumptions. This is important both when assessing what problems you are solving for people, and in implementing or building solutions.

#4 Think of customers, not clients

As a lawyer, I had clients, not customers. I felt offended when people referred to my clients as customers — possibly because it devalued the highly specialised services I offered to people.

Working in technology is different, because you are generally not implementing a solution just for a one or a handful of people. Our collaboration portal would have been useless if it had only worked for one client. It had to work for a much wider group.

Understanding the needs of a wide group of people is difficult. First, you must understand the constituents of the group. For our collaboration portal, we had to decide whether our user group would be litigation teams as well as transactional teams. Second, you must understand the needs of that group. To do this effectively, you must not assume — otherwise you are building for yourself, not the group. At the same time, you must not directly ask, because people often do not know what they want.

The key is not to ask direct questions such as “do you want a document checklist feature”. You must start by asking open questions that elicit problems, for example “tell us about how you currently work with documents”. Rather than you directing the discussion, you are letting users give their own perspectives on what the main issues are. As a technology person, your job is to take stock of what people are saying, draw the threads together, and identify the key problems you need to solve. Only then can you start to think of the solution (which may, of course, not always actually be technology).

Working in technology has been a huge mindset shift for me, and one that continues today. I still have crises of confidence, and the sense that I am not achieving anything. But the reality is that this is a different world. A technology project is the culmination of months and years of work, rather than a few late nights in the short term.

I found life as a lawyer was often about clearing my inbox or ticking items off my to-do list. This is not how I have found technology. It requires a different way of thinking and requires you to show empathy and strategic skills. Lawyers who spend time in technology roles will go back to practice equipped with many helpful strings to their bow.

This article was originally published in the Modern Lawyer