Share

From politicians who confuse hashtags and hashing, to business colleagues who look perplexed when the CIO mentions a new blockchain proof of concept, it’s clear that the tech sector needs to brush up its communications skills.

This is a sector packed with jargon and buzzwords. Review a few tech websites and you’ll see references to terms such as “bi-modal”, “fog computing”, “red teaming”, “cognitive computing”, “UX, “virtualisation”.

It can be difficult for outsiders to crack this code.

Now, at this point, I suspect you might be thinking, this is a little “pot calling the kettle black”. After all, we lawyers have a reputation (often justified) for using complicated language that is difficult for the lay person to follow. However, in my profession’s defence, over recent years, there has been a real drive for ‘plain English’ in contracts, particularly when dealing with consumers. 

The tech sector needs to take similar action. It’s in our interest to demystify and simplify. If we want government to make tech law that’s fit for purpose, the UK to become a more tech savvy nation, and our businesses to become digitally transformed and competitive, we need to be able to better communicate technical concepts and information. We need to speak the same language as policy makers, executives and consumers. That means cutting through the jargon. It also means focusing less on the technology itself, and more on what the technology can do and what the benefits and challenges are. 

We are seeing efforts by the industry to address this issue. For example, Alphabet’s tech incubator Jigsaw is collaborating with the Washington Post on a Sideways dictionary which aims to demystify technology. It provides helpful analogies rather than traditional technical definitions (e.g. Bitcoin is described as “like digital gold”).

In our technology contracts, clarity is also vital. The parties’ technical and operational teams may understand what they are referring to in the requirements or services schedule, but in the event of a dispute, the contract will ultimately be interpreted by a judge. All too often, I see wording which is vague, unclear or capable of multiple interpretations. Careful thought needs to go into the schedules at the pre-contract stage.

So, if you are tasked with writing a schedule for a technology contract, how can you make the schedule as clear as possible for the parties to manage, and, ultimately, for the courts to interpret if a dispute arises?

Here are some suggestions.

- A judge will look at the words in the contract, rather than what the parties thought the contract meant. Technology professionals often use expressions which are not terms of art and mean different things to different people. Accordingly, you need to define key terms. When creating definitions, avoid jargon and use lay terms. It’s vital that the contract makes sense to those who come to the transaction without having been closely involved in drafting or negotiating it – they won’t have background knowledge to fill in any gaps.

- By all means, use acronyms if helpful, but remember to define them if they are not well known terms.

- Don’t include substantive rights and obligations in the definitions. The definitions should act as a glossary only.

- Err on the side of caution. Details may seem obvious to those embedded in the deal or with deep technical knowledge. But take a step back. Is the position clear from what’s actually written down?

- Simplicity is best. The contract needs to be usable and workable by those that will manage it. Use intelligible and precise language. Use logical sequences, numbering, bullet points and other formatting to make it easy to read. Use tables, charts, diagrams, and worked examples.

- Make explicit who is obliged to carry out each activity (“the supplier will”, “the customer will”) to ensure that obligations are legally enforceable. Including lists of actions that don’t specify clearly who is responsible for those actions are not helpful.

- Make sure obligations are properly aligned to business outcomes. And try to be specific when detailing obligations, rather than relying on general language such as “in accordance with good industry practice”.

- Specify when something must be done – whether it’s by a certain date, or at a particular frequency, rather than rely on more generic language (“as soon as reasonably practicable”, “regularly”.)

- There may be some issues that genuinely cannot be resolved pre-contract. But try to limit ‘agreements to agree’ as much as you can. Where they are necessary, build in detail regarding the timescale and mechanism for reaching agreement.

- If you are incorporating ancillary documents (requirements, specification, policies) and not annexing these to the contract, describe these clearly (i.e. with date and version number) to avoid any version control disputes later on.

- If supplier obligations are to be subject to customer dependencies, specify these carefully and don’t rely on vague general language. Otherwise, there is a risk that the required relief won’t be available when you need it.

- Look out for, and avoid, inconsistencies between, and within, schedules.

- Don’t simply blindly copy or incorporate template schedules or schedules from other deals. Consider carefully your business requirements for the particular deal. Remember that an example document from a signed deal is likely to reflect a negotiated position, rather than your desired starting point.

- Don’t underestimate the effort required in writing, reviewing and completing the schedules. Start early and dedicate sufficient time and resources to the task

- Lastly, share early drafts of the schedules with your legal team and executives. Schedule drafters may not be experienced in contract preparation. If concerns are not resolved at an early stage, the schedules may need significant re-writing. Not only could this adversely impact the project timetable for the deal, it could cause challenges if the schedules have been shared extensively with the other side.

Find your next job with computerworld UK jobs