By Michael Barr
Cross-examining a technical expert is not a contest about the technology. Attorneys who try to out-argue an engineer on their own subject usually lose, and lose in front of a jury that can tell. The openings are almost never in the conclusions. They are in the scope of the work, the method that produced it, and the distance between what was examined and what was claimed.
Your own expert should be finding these for you. That is one of the more valuable things a consulting expert does, and it is work that happens before the deposition rather than during trial preparation.
Start with the inventory, not the opinion
What did you examine. What did you not examine. What did you ask for and not receive. Those three questions establish the boundary of the analysis, and everything useful sits at that boundary.
An expert who reviewed three of eleven releases has a defensible position if they say so and explain why. Many do not say so in the report, and the gap between the materials list and the breadth of the opinions is the most reliable opening there is.
Separate what was observed from what was inferred
Technical reports blend the two continuously, usually without meaning to. The code shows a function exists. That the function runs in the shipped configuration is an inference. That it runs in the accused manner is a further one.
Walking an expert back through their own chain, one link at a time, tends to surface at least one step that rests on assumption rather than evidence. Doing that calmly is more effective than challenging the conclusion, because each individual step sounds reasonable and the accumulation is what does the work.
Ask what would have falsified the conclusion
A method that could not have produced a different answer is not a method. Asking what result would have contradicted the opinion, and whether the expert looked for it, tests whether the analysis was investigation or confirmation.
This question is also the one a Daubert motion is built around, so the answer has value beyond the moment.
Test the sampling
In any matter where the corpus was too large to read, something was sampled. How was it selected, why is it representative, and what is the basis for extending a finding from the sample to the whole. Experts who chose a principled sample answer this well. Experts who went where they expected to find something usually reveal that under a few questions.
Check the expert against their own prior work
Publications, prior reports, and earlier testimony are discoverable and are frequently inconsistent in small ways that matter. The goal is rarely a dramatic contradiction. It is establishing that the witness has described the same mechanism differently when nothing was at stake.
Probe the boundary of the expertise
Technical fields have layers, and most experts are strong in one. A software expert opining on a hardware failure mode, or a circuit designer opining on development process, is operating at the edge of their competence and usually knows it.
The question is not whether they are qualified generally. It is which layer of this problem they have personally worked at. Our field guides, such as what makes a great electronics expert witness, set out those layer distinctions in a form that makes the question concrete.
Find out who actually did the work
Large technical reviews are performed by teams. The testifying expert should have directed the analysis and be able to defend it as their own. Where they cannot say how a particular finding was produced, or who produced it, the opinion has a foundation problem that is worth developing carefully.
The close
The productive lines against a technical expert are procedural rather than substantive: what they looked at, how they chose it, what they inferred, and where their expertise runs out. None of those require the examiner to know more about the technology than the witness.
They do require somebody technical to have read the report closely and marked the seams. Get that done early enough that it can shape the deposition rather than only the closing. The same questions, asked of your own expert first, are the core of our guide to preparing a technical expert for deposition.
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.