By Michael Barr
The deposition of a technical expert is usually won or lost in the three weeks before it. Not in the deposition itself, and not in the last-minute session the night before. By the time the court reporter swears the witness in, the report is served, the exhibits are fixed, and most of what opposing counsel will use has been sitting in the file for months.
I have been deposed, and I have watched experts I recommended get deposed. The failures cluster into a small number of preventable patterns, and almost all of them are visible weeks out.
Read the report as opposing counsel will
Every sentence in the report is a commitment. The useful exercise is to go through it looking for the ones that are broader than the evidence supports, because those are the sentences the deposition will be built around.
The pattern to hunt for is the general statement in a technical paragraph. "The system always writes the log before acknowledging" is a claim about every version, configuration, and code path. If the expert examined three releases, the sentence should say so. Narrowing it in the report costs a clause. Narrowing it under oath costs credibility.
Reconcile the expert against their own prior work
Everything the witness has published, testified to, or written in a prior report is discoverable and is being read right now. So read it first. A paper from eight years ago that describes a mechanism differently, a deposition in an unrelated matter where they took the opposite side of a methodological question, a conference talk that oversimplified.
None of these are fatal. All of them are damaging when they arrive as a surprise. The expert who can say "yes, I wrote that, and here is why this case is different" stands their ground. The one hearing it for the first time does not.
Establish exactly what they did and did not examine
The single most productive deposition line against a technical expert is the inventory question. What did you review. What did you not review. Did you ask for anything you did not get.
An expert should be able to answer that from memory, precisely, including the gaps. Gaps are not weaknesses if they were reasoned. "I did not examine the 2019 branch because the accused products shipped from the 2021 branch" is an answer. "I am not sure whether I looked at that" is a problem, and it is one that a lab notebook or a review log prevents entirely.
Rehearse the methodology, not the conclusions
Counsel tends to prepare experts on what they found. Opposing counsel usually attacks how they looked. How was the sample chosen, why is it representative, what would have shown up if the conclusion were wrong, what other explanations were considered and rejected.
An expert who has articulated their method out loud, to somebody who pushes back, answers those fluently. One who has only ever written it down tends to reconstruct it live, which sounds like improvisation even when it is correct.
Practise the boundary of the expertise
Technical experts get drawn outside their lane, usually politely. A firmware expert is asked about a mechanical failure mode. A circuit designer is asked what a reasonable software process looks like. The answer is not to refuse the question. It is to answer the part within the expertise and say plainly where it ends.
That is a skill, and it feels unnatural to competent people who are used to having a view about everything nearby. It is worth rehearsing specifically.
Fix the exhibits problem early
Technical depositions run on documents: code excerpts, schematics, logs, and the expert's own working files. Which of those are discoverable, which were relied upon, and which are drafts is a question that should be settled long before the day. An expert who has kept a clean working record has a short answer. One who has not spends the afternoon explaining a folder.
The one rehearsal that matters most
Have somebody who is not on the team ask the expert to explain the core opinion in five minutes, and then push on it. Not a friendly walkthrough. A genuine attempt to find the soft edge.
We do a version of this before recommending anybody, which is why our vetting takes longer than a database search. The criteria are set out in our guide to vetting a source code review team, and the deposition is where every one of them gets tested.
The close
Deposition preparation for a technical expert is mostly the work of making the report say exactly what the evidence supports, and making the expert fluent in how they got there. Both are done in advance or not at all.
If the expert cannot survive a hostile hour from a colleague, they will not survive six from opposing counsel. That is a reason to find out in the conference room rather than on the record.
Note: This article offers practical guidance for attorneys engaging technical experts. It is general commentary, not legal advice. Consult counsel about any specific matter.
Barr Group's team of electronics and software expert witnesses provide experienced and unbiased source code reviews, expert reports and testimony for product liability, patent infringement, software copyright, and trade secrets litigation. HIRE AN EXPERT
Get a matched recommendation >
Free, confidential, conflicts-checked, and our fee is built into the expert's hourly rate, so we are paid only if you retain.