At first glance, the legal industry and software development seem worlds apart – lawyers work with contracts and developers work with code. But with modern advancements in LegalTech enhancing legal services and creating efficiencies in everything our lawyers do, our worlds are closer than you might think.

Linklaters’ lawyers from our Structured Finance Group recently collaborated with the firm’s in-house Technology Development team. We looked at the similarities and differences in our work and what we can learn from one another. We concluded that there are a number of key aspects that all legal professionals, not just our own lawyers, can learn from modern software development practices. We thought that others might find it interesting to read about some of the key themes we discussed and consider how they might apply to their own work.

Su Clarke, Software Development & Testing Manager at Linklaters commented:

“It was great to explore the parallels between our two worlds. Understanding more about each other, exploring the synergies and thinking about where learnings could be shared.”

Language

To learn from others, we need to start by ensuring that we are speaking the same language, or at least working with a good translator. It quickly became clear from our discussion that there are many similarities in what we do and how we do it, but they are often shrouded in different terminology. Once you break that barrier, it becomes easier to assess the parallels and work out what we can learn; for example, contracts vs. source code, document management vs. ‘git’ repositories, modular programming vs. the master definitions schedule, error handling vs. dispute resolution – the list is endless.

‘Should lawyers learn to code?’ is now a bit of a tired trope in legal innovation circles. Like learning any new language, picking up some coding skills allows you to communicate more richly with a new group of people and benefit from a greater diversity of thought, background and ideas – that has been the experience of people participating in Linklaters’ Coding Club initiatives.

However, we use our respective languages in different ways across the two fields. Whilst ambiguity is usually a bug in software and the languages used are built around a level of precision that can be reduced to binary logic, as lawyers we often use the ambiguity of our chosen language as a tool. Sometimes this is to cater for the complexity of the world and human interactions and sometimes this is to find an uneasy compromise between otherwise intractable positions. As lawyers and developers, we are going to increasingly find ourselves living on that boundary, between clauses calling for ‘reasonable efforts’ which a computer may never be able to interpret, and payment terms written into code or quasi-code that a computer can implement more reliably and efficiently than any human intermediary. Breaking down language barriers will help us as lawyers deliver solutions to our clients that make the most of both worlds.

How we work

Alongside what we do, we also talked about how we do it. Software development has been a dynamic field in terms of thinking about how the work is delivered. At a high level, both lawyers and developers engage in knowledge work. Although we work in different domains, it is about our creative ability to understand and solve complex issues for our clients and to deliver projects on time and on budget. 

Our Technology Development team employs agile software development practices with the aim of enhancing collaboration between team members and maintaining focus on the requirements. An example of this is undertaking projects in ‘sprints’, with each sprint usually lasting between two to three weeks. This allows for a process that breaks down the scope of work into manageable tasks, with a built-in discipline around limiting the requirements that are dealt with in each sprint. The team uses ‘Kanban’ boards to visually depict tasks and holds frequent (typically daily) stand-up meetings to plan and prioritise work for specific projects. They also have frequent checkpoints (or ‘retrospectives’) in their cycles to reflect on what has gone well, what could have been done differently and, if required, to make changes to the process to facilitate a smoother delivery of the project. 

Although we lack the bold ‘agile’ branding, lawyers already use some of these principles – our lawyers interact with clients just as developers would with key stakeholders, gathering requirements and making sure they are properly understood and agreed upon when a matter starts. A well-run complex deal is planned out in advance and runs to a cadence of document circulation, comment and revision. We run wash-up sessions after a deal closes (often with the client) to work out what was done well and what could be done differently.

Despite the similarities, there is also a lot here for lawyers to think about. When is it appropriate to conduct more formal ‘retrospectives’ at key milestones in a matter to course-correct and refine our approach before the matter ends? Lawyers by training are always seeking perfection; but are there times when it is better to get a ‘minimum viable product’ in circulation to give stakeholders a feel for how things will develop and solicit feedback? How do we deliver efficiently when the commercial reality of a deal leads to frequently shifting requirements after the work has started? More controversially, would we get more done if we had all our meetings standing up? 

It is easy to fall into the trap of thinking about innovation in law solely in terms of LegalTech. There is opportunity here to tweak and reshape the way we work together, and truly innovative lawyers will always use the technology as a means to that end, rather than as an end in itself.

Dan Hibbert, Lead Developer at Linklaters stated:

“Agile methodologies and practices will not work for legal without adaption – but the point of agile is that you are meant to tweak it for the environment you are in.”

Quality control and review

Agile software development focuses on identifying problems and fixing the bugs as early as possible in the process because it reduces the risk of delivering poor software to their customers.  One form of this is ‘pair programming’, where two developers work together and frequently switch roles between the ‘coder’ and ‘reviewer’ – two heads are better than one in discovering the best design and resolving issues. Another form is the frequent release of software so that features can be tested rather than waiting until the product is ‘done’ before starting the testing phase. Testing itself is a distinct discipline in the world of software development, calling for its own mindset and skillset.

Accuracy and avoiding mistakes are at the heart of what we do as lawyers, so there was a lot of interest in what we can learn from these methods. Our lawyers are regularly trained on ways to reduce risk and avoid mistakes and again we saw many similarities in philosophy and approach. ‘Quality control’ in the legal world is typically achieved through effective supervision and review by the partner or managing associate, with that reviewer playing the role of tester, running through possible scenarios and considering if the drafting achieves the expected outcome. As a close-knit team, we sometimes also rely on ‘peer review’, asking one of our colleagues to ‘cold read’ a provision and check that they interpret it in the same way without the benefit of the broader context of the negotiation. There is certainly scope in some cases to do this more formally. Drawing from ideas in Atul Gawande’s book ‘The Checklist Manifesto’, we have also found checklists to be a useful way of stress-testing our drafting and ensuring that we learn from experience. Although it is an alien concept, we are also interested in whether ‘pair drafting’ could be used efficiently to eliminate errors and reduce cost – innovation is after all about trying new things!

Applying concept to practice

A test bed for the collaboration between law and technology at Linklaters is Nakhoda, our internal start-up. Nakhoda is responsible for ISDA Create, a document automation platform used by financial institutions globally to negotiate their derivatives documentation. Linklaters’ lawyers work in Nakhoda and learn to write technical feature requirements, to keep track of work product on Kanban boards in an agile context, and to communicate directly with developers and understand their thinking to resolve issues arising along the way. Lawyers also learn to develop approaches too, and undertake acceptance testing of the features they track. Bringing in process management skills, honed on matters to the development context, lawyers learn the importance of agility, iterating and streamlining working processes.

To sum up

This is just a flavour of the wide-ranging discussion that was sparked when we put a few lawyers and developers in the same (virtual) room. We think there is huge opportunity to be found in these collaborations, part of our ‘One Team’ approach at Linklaters. We hope that this piece has provided some food for thought about how your team works and what we can learn from others.

Tom Quoroll, Capital Markets Partner at Linklaters commented:

“We’re working in a rapidly changing environment which is increasingly disrupted by technology and new business models. Our colleagues in software development have been at the heart of this change and there is a lot we can learn from them, not just about the technology itself but also about how we can work together to deliver the best service for our clients in a complex and changing world.”

Article authors: Tom Quoroll, Partner, Su Clarke, Software Development & Testing Manager, and Dan Hibbert, Lead Developer at Linklaters.