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.
Sign up for CIO Asia eNewsletters.