What to Expect When Instructing a Technology Expert Witness

This guide is written for solicitors and in-house counsel instructing a technology expert witness in proceedings in England and Wales. The procedural framework described is that of the Civil Procedure Rules, and CPR Part 35 in particular, though much of the practical guidance applies equally where I am instructed in international arbitrations under JAMS, LCIA, or DIAC rules.

Whether you are instructing a technology expert for the first time or looking to get more from the process, this article sets out what to expect at each stage, from initial contact through to oral testimony.

The expert’s duty to the court

The starting point for any expert engagement is CPR 35.3: the expert’s overriding duty is to the court, not to the party instructing them. The Practice Direction to Part 35 reinforces this, requiring the expert to provide opinions that are independent, objective, and uninfluenced by the pressures of litigation.

In practice, this means a good expert will tell you what the evidence supports, even if that is not what you hoped to hear. That candour is more useful than an opinion that does not withstand cross-examination. If a preliminary review suggests the technical evidence does not support your client’s position, it is better to know that before exchange than to discover it during the hot-tub.

Initial consultation

Most instructions begin with an introductory call, typically 30 to 60 minutes, in which the legal team outlines the dispute and the expert assesses whether the matter falls within their expertise. This is a two-way process. The expert will want to understand the technical issues, the court or tribunal, the procedural timetable, and the likely scope of the work. You should expect the expert to ask direct questions and to be honest about the boundaries of their knowledge.

At this stage, the expert should also confirm that there are no conflicts of interest and that they have the availability to meet your deadlines. Technology disputes can involve anything from source code repositories and database schemas to mobile device forensics and AI model architectures, so it is important that the expert’s experience genuinely matches the technical subject matter, not just the broad category. A software engineer is not automatically qualified to give evidence on digital forensics, and vice versa.

The letter of instruction

A clear, well-structured letter of instruction makes a significant difference to the quality and efficiency of the expert’s work. The most effective letters of instruction I receive tend to share certain characteristics:

Defined questions: Specific questions for the expert to address, rather than a broad invitation to “review the technology issues.” The more precisely you frame the questions, the more focused and useful the report will be. Where the court has given directions specifying the issues for expert evidence, these should be reflected in the letter.
Background summary: A concise factual narrative of the dispute, identifying the parties, the relevant systems, and the key events. The expert needs enough context to understand what they are looking at, without being buried in the full trial bundle at the outset.
Identified materials: A schedule of documents, data, and systems to be made available, with an indication of which are most important. For technology disputes, this often includes source code, databases, system logs, project documentation, and correspondence.
Timeline: A realistic timetable setting out when the report is needed, any court-directed deadlines for exchange of reports, whether there is a joint statement stage, and the trial window.

If the scope of the technical issues is unclear at the outset (which is common in technology disputes) it is perfectly reasonable to instruct the expert on a preliminary basis, asking them to review a subset of materials and advise on the questions that can usefully be addressed. This can also help with applications for permission under CPR 35.4.

The expert report

The report is the central product of most engagements. CPR 35.10 and the Practice Direction set out the formal requirements: the report must contain a statement of truth, a declaration of the expert’s duty to the court, details of the expert’s qualifications and experience, a statement of the facts and instructions upon which the opinion is based, and a clear indication of any areas where the opinion is provisional or qualified.

Beyond these formal requirements, what distinguishes a good technology expert report is the ability to translate complex technical concepts into language that a judge, who may have no technology background, can follow. This does not mean oversimplifying. It means explaining what a system does, how it was built, what went wrong, and why it matters, in terms that are precise without being impenetrable. A report that only a software engineer can understand has failed in its purpose, however technically rigorous it may be.

Depending on the complexity of the matter, the report may take anywhere from a few weeks to several months to prepare. The timeline is driven primarily by the volume of technical material to be reviewed. A disputed software codebase of several hundred thousand lines, for example, requires substantially more time than a review of email metadata. I always discuss realistic timelines at the outset so that there are no surprises when directions questionnaires or CMC dates approach.

Joint statements and discussions with opposing experts

In many proceedings, the court will direct the experts to meet and produce a joint statement under CPR 35.12, identifying the issues on which they agree and disagree, with reasons. These discussions are conducted without the parties’ legal representatives present, though the agenda is typically agreed in advance with the solicitors.

In my experience, the joint statement stage is one of the most valuable parts of the process. It narrows the technical issues for trial, often significantly. Where experts agree on a point, it ceases to be contested, saving court time and costs. Where they disagree, the joint statement sets out each expert’s position clearly, giving the judge a framework for evaluating the competing opinions at trial.

Preparing your expert for this stage is straightforward: ensure they have access to all relevant materials, agree the agenda in good time, and trust them to engage constructively with the opposing expert. The goal is clarity, not advocacy. Solicitors sometimes worry about losing control at this stage, but in my experience a well-prepared expert who understands the issues will narrow the technical dispute more effectively than one who has been over-managed.

Oral testimony

Not every engagement reaches trial, but when it does, the expert should be comfortable giving oral evidence. This means explaining their conclusions clearly under examination-in-chief, responding to cross-examination with precision and composure, and, if directed, engaging with the opposing expert in concurrent evidence (sometimes called “hot-tubbing”), which is increasingly common in the Technology and Construction Court and in heavy commercial litigation.

Oral testimony in technology cases presents a particular challenge: counsel and the judge may not share the expert’s technical vocabulary. The expert must be able to explain, for example, why a particular pattern of code commits is significant, or how a database query demonstrates that personal data was shared with a third party, without losing the audience. The best oral evidence is clear, measured, and directly responsive to the question asked.

Timelines and costs

Technology expert engagements vary enormously in scope. A focused review of a single technical issue might take days; a complex software IP dispute with multiple codebases and forensic analysis might span months. As a rough guide for proceedings in England and Wales:

Preliminary assessment: 1 to 2 weeks for an initial review and advice on the merits, often useful before or alongside an application for permission.
Full expert report: 4 to 12 weeks depending on the volume of technical material and the complexity of the issues.
Joint statement: Typically 2 to 4 weeks after exchange of reports, depending on the court’s directions.
Trial preparation and testimony: 1 to 2 weeks of preparation, plus attendance at trial.

Costs are usually charged on a time-spent basis, with regular reporting against a budget. I provide detailed fee estimates at the outset and flag any changes in scope as early as possible. There should be no surprises.

Getting the most from your expert

A few practical suggestions for solicitors and in-house counsel working with technology experts:

Instruct early. Technology disputes often involve large volumes of data and code. The earlier the expert is engaged, the more effectively the evidence can be identified, preserved, and analysed. Early instruction also allows the expert to input on the scope of disclosure, which in technology cases can be critical.
Share context. The expert does not need to see every document on the case file, but understanding the broader dispute, including the commercial context and the legal arguments, enables a more targeted and relevant report.
Ask questions. If something in the expert’s report is unclear, raise it before exchange. A good expert will welcome the opportunity to clarify their reasoning, and the report will be stronger for it.
Be candid about weaknesses. If there are aspects of the technical evidence that concern you, tell the expert. It is far better to address potential vulnerabilities early than to encounter them for the first time in cross-examination.

Technology disputes tend to be high-value and technically complex. In my experience, the quality of the instruction, and the working relationship between the legal team and the expert, has a material bearing on the quality of the evidence that is ultimately put before the court. The process works best when it is collaborative, transparent, and focused on assisting the court in resolving the technical issues in dispute.