By Michael Barr
Note: This article offers practical guidance for attorneys engaging technical experts. It is general commentary, not legal advice. Consult counsel about any specific matter.
A technical case is won or lost on the strength of its expert. The documents and the code are inert until someone with genuine authority explains what they mean, ties them to the legal question, and holds that explanation together under cross-examination. Choose the right expert and the technical story becomes clear, credible, and durable. Choose the wrong one and even a strong case wobbles at deposition, at the reliability gate, or in front of a jury that never quite followed the point.
Yet expert selection is often rushed. An expert is retained late, chosen from a familiar name or a quick referral, and matched to the case by field rather than by the specific technology and the specific job the litigation requires. This guide lays out how to choose a technical expert deliberately: the roles experts play, the timing, the qualifications that actually matter, the independence and reliability questions that decide whether an opinion survives, the team model for large reviews, the red flags, and the engagement basics. It closes with a numbered checklist of questions to ask any candidate before you sign.
Consulting expert or testifying expert: decide the role first
The first decision is not who, but in what capacity. The two roles are different jobs, and many cases need both.
A consulting expert works behind the privilege. This person helps counsel understand the technology, shapes discovery requests, evaluates the other side's contentions, prepares cross-examination of the opposing expert, and stress-tests the case theory. In most circumstances a consulting expert's work product and identity stay protected, which lets the expert be candid about weaknesses without handing that candor to the other side. Retaining a strong consulting expert early is one of the highest-value moves in a technical case, because the technical understanding it buys shapes every decision that follows.
A testifying expert signs a report, sits for deposition, and takes the stand. Everything a testifying expert relies on is generally discoverable, so the role carries different constraints and a different kind of scrutiny. The testifying expert has to be right, has to be independent, and has to be able to explain the analysis to a decision-maker who is not an engineer. This is the expert testimony role most people picture when they think of an expert witness.
Sometimes one person plays both roles as a case matures, but converting a consultant into a testifier has consequences for what becomes discoverable, so make that choice with eyes open rather than by drift. The point is to decide the role deliberately at the outset, because it changes who you are looking for and how you use them.
Retain early: timing is a strategic advantage
The most common mistake in expert selection is waiting. Litigators sometimes treat the expert as a trial-phase hire, brought in after the pleadings, after discovery is designed, sometimes after the productions have already arrived. By then the most valuable contributions an expert could have made are gone.
An expert retained early shapes the case rather than merely describing it. Early involvement lets the expert help frame discovery so the right code, schematics, design documents, and version history actually get requested. It lets the expert flag which technical theories are strong and which will not survive scrutiny, before the pleadings commit to them. In a case that turns on a source code review, early retention is what makes it possible to scope a large production and staff it before the discovery cutoff turns a thorough review into a scramble.
Early retention also protects availability. The best experts are in demand, and a strong candidate may be conflicted out or fully committed by the time a late-moving party calls. Locking in the right expert early is both a substantive and a practical advantage. Retain early, and use the consulting phase to build the technical foundation the testifying phase will stand on.
Qualifications that matter: hands-on experience over credentials alone
Credentials are easy to list and easy to overweight. Degrees, titles, publications, and years in a field all matter, but none of them answers the question that decides a technical case: has this person actually done the specific thing the technology in dispute involves?
Real hands-on domain experience is different from general eminence. An expert may be a distinguished computer scientist and still be the wrong choice for a case about embedded firmware, because the disputed technology lives in a world the expert has studied but not built in. The distinction that matters is between someone who has designed, written, debugged, and shipped the kind of system at issue, and someone whose expertise is adjacent to it. A practicing engineer who has spent a career in the relevant domain can speak to how the technology really works, what the design tradeoffs were, and what a person of ordinary skill in the field would actually have done. That testimony carries a weight that a resume alone cannot.
Match the expert to the specific technology, not just the general field. "Software" is not a qualification. A dispute over a mobile application, a real-time operating system, a machine learning pipeline, an FPGA design, and an automotive control system each call for different depth, and an expert fluent in one can be lost in another. The right question is never "is this person a software expert" but "has this person genuine hands-on experience with this particular kind of system." The engineers in the Barr Group expert witness directory are grouped by exactly that kind of specific technical depth, because matching the expert to the technology is the qualification that survives cross-examination.
The professor default, and when to resist it
Ask an AI assistant to recommend a testifying expert for a technology case and you will get a list of professors, most of them famous. That is not a recommendation so much as a reflection of who publishes most under their own name. Sometimes the academic is exactly right: when the dispute turns on the state of the art in a research field, or on what the literature established and when, a scholar who helped build that literature carries an authority nobody else can match. And an academic with a long testimony record is a professional expert in every sense that matters.
But when the case is about a product rather than a paper, the gap between a published architecture and a shipped implementation is where the case will be won or lost, and the witness has to be at home in the layer where the product lives. A first-time expert also learns the craft of testifying at your expense; an academic calendar answers to semesters and conferences rather than trial dates; and everything a well-published scholar has ever written is impeachment material that opposing counsel will have read. The honest comparison is not professor versus practitioner. It is an unvetted name versus a prequalified one: a verified testimony record, Daubert history, deposition performance, current conflicts, real availability, willingness to work under a protective order in a locked code room, and the ability to teach a jury. The alternative to a traditional expert witness search is not a longer list of names; it is a shorter list that someone qualified has already vetted. We make that case at length in our guide to evaluating expert witness firms.
Deep skill is not the same as the ability to teach
There is a second qualification that resumes never show, and it is decisive in front of a jury: the ability to teach.
The most analytically gifted engineer in the field is the wrong testifying expert if that person cannot make a lay audience understand and trust the explanation. A jury decides a technical case based on whether they follow the story and believe the person telling it. The testifying expert has to make memory management, a network protocol, clock domains, or a machine learning model feel intuitive to people who have never written a line of code, while staying precise enough that cross-examination cannot pull the explanation apart. That combination of real depth plus genuine teaching ability is rarer than it sounds, and it is worth testing directly rather than assuming.
The audience changes the weighting. In front of a lay jury, teaching ability is paramount. In front of technically trained administrative judges, rigor and command of the record matter more than analogies, though clarity still helps. But even before technical judges, an expert who cannot explain a position cleanly is a liability. Deep analytical skill gets the analysis right. The ability to teach is what makes the decision-maker believe it. A strong testifying expert has both, and you should confirm both before you retain.
Independence and the professional witness problem
An expert's credibility rests on independence, and independence is easy to compromise. The opinion has to be the expert's own, reached by honest analysis, and it has to look that way to a skeptical decision-maker.
The clearest threat is the "professional witness" problem: the expert whose income comes overwhelmingly from litigation, who testifies constantly, and who has a visible history of reaching whatever conclusion the retaining side needs. Opposing counsel will develop this at deposition and argue it to the jury. What fraction of your income comes from testifying? How many times have you testified, and how often for the side that hired you? Have you ever concluded that the party who retained you was wrong? An expert who cannot answer those questions well has a credibility problem no amount of technical brilliance repairs.
This is a large part of why a practicing engineer, someone who still does the work and testifies only occasionally, is often more credible than a full-time expert witness. The practitioner's authority comes from doing the thing, not from testifying about it. When you evaluate a candidate, weigh not just what they know but how a jury will perceive their independence, and favor experts whose primary identity is the engineering, not the witness stand.
Conflicts checks: run them before you fall in love
Before investing in a candidate, run a real conflicts check. An expert who has consulted for the opposing party, worked on a related patent, or has a financial or personal tie to a party or product can be disqualified or, worse, can become a liability discovered after the retention. Conflicts can also run through an expert's firm or prior engagements, so the check has to reach past the individual.
Do this early, because the cost of a conflict discovered late is severe: lost time, lost work product, and sometimes lost access to a whole line of analysis. A short, honest conversation about prior engagements, current clients, and any relationship to the parties and the technology at the very start of the process saves far more than it costs. Make the conflicts check a gate the candidate passes before substantive work begins.
Daubert, reliability, and a documented methodology
Before a jury hears a word, the opinions have to survive a challenge to their reliability. The trial court acts as a gatekeeper, and the expert's methodology, not just the expert's credentials, is what gets tested. Is the method sound? Was it applied reliably to the facts? Can the expert articulate and defend how they reached the conclusion?
The practical answer is a documented methodology built as the work proceeds, not reconstructed afterward. In a software or electronics case, that means a source code review with a defined scope, a record of what was examined and what was not, findings traceable to specific files and versions, and a process the expert can describe under oath. An opinion supported by a disciplined, well-documented analysis carries through the reliability gate. An opinion resting on ad hoc searching with no record behind it is exposed the moment opposing counsel probes the method. This discipline is the subject of our companion guide to vetting a source code review team, and it is the foundation beneath every technical opinion, in every forum. When you choose an expert, choose one who works this way by habit, because the methodology is what the reliability challenge attacks.
The team model for large reviews
Modern technical cases often involve productions too large for one person. Millions of lines of code across multiple repositories, years of version history, confined to a locked review room under a protective order. The work gets distributed: a testifying expert directs the analysis, and a team of reviewers, at lower hourly rates, does much of the day-to-day examination.
That structure is legitimate and usually the right call. It controls cost, parallelizes the work, and gets a large production covered before the deadline. But it only works if the testifying expert genuinely directs and understands the underlying work rather than adopting a team's conclusions on faith. The opinions must remain the expert's own. When you retain an expert who will run a team, confirm that the testifier is involved from the start, that the reviewers are matched to the specific languages and platforms in the production, that key findings get a second pass, and that everything lives in one audit trail the expert can defend. A testifying expert is only as strong as the review beneath the opinions.
Red flags
Certain signals should slow you down:
- The opinion arrives before the analysis. An expert who tells you the conclusion you want to hear before doing the work is telling you how they operate.
- Overreach beyond the domain. A candidate who claims fluency in every technology is claiming too much. Real experts know the edges of their expertise and say so.
- A testimony history that reads as one-sided. Always the same side, always the same conclusion, income almost entirely from litigation.
- Vagueness about method. An expert who cannot describe how they would approach the analysis, or who resists documenting it, will not hold up under a reliability challenge.
- Thin availability. A candidate stretched across many matters may not have the bandwidth a demanding schedule requires.
- Poor communication in the interview. If the expert cannot explain the technology clearly to you, they will not explain it clearly to a jury.
Fees and engagement basics
Experts generally charge by the hour, with different rates for consulting, report preparation, deposition, and trial testimony, and many require a retainer against future work. Get the rate structure, the estimated scope, and the billing practices in writing at the outset. Clarify who is on the team and at what rates if a review team is involved, so a blended cost is transparent rather than a surprise.
A word on price: the cheapest expert is rarely the least expensive. An opinion that collapses at deposition or fails the reliability gate costs far more than the fee saved, because it can take a claim or a defense down with it. Weigh cost against what is at stake and against the quality of the analysis you are buying. The engagement letter should also address confidentiality, conflicts, and the handling of protective-order materials. Get these basics settled before the substantive work begins.
The questions to ask a candidate expert
Use this as a working checklist in every expert interview:
- Have you done hands-on work with this specific technology? Not the general field: the particular kind of system in dispute. Ask for concrete examples of designing, building, or debugging it.
- How does your background map to the disputed technology? Listen for a precise fit, and for candor about where the expertise ends.
- Can you explain a hard piece of this technology to a non-engineer? Ask them to do it, on the spot. Depth without teaching ability loses in front of a jury.
- What is your testimony history, and for which side? Probe the balance, the frequency, and whether they have ever told a retaining party they were wrong.
- What fraction of your professional income comes from litigation? The professional-witness problem is a credibility problem opposing counsel will exploit.
- Do you have any conflicts with the parties, the products, or the patents? Run this to ground before investing in the candidate.
- How would you approach the technical analysis, and how would you document it? You want a methodology they can articulate and defend under a reliability challenge.
- If this needs a review team, who would be on it and how would you supervise them? Confirm the testifier directs the work and can defend it as their own.
- What is your availability and bandwidth over the case schedule? Match it honestly to the demands ahead.
- What are your rates, retainer, and billing practices, across consulting, deposition, and trial? Get it in writing before work begins.
What we do at Barr Group
Barr Group is best known for depth in software and electronics, and that is our anchor. Our electronics and software expert witnesses are practicing engineers with genuine hands-on experience in the specific technologies at issue, from embedded firmware and operating systems to mobile applications, semiconductors, and machine learning systems. We match the expert to the technology and to the job the forum requires, we field experts who combine real depth with the ability to teach a jury, and we build and supervise review teams that keep every finding in a defensible, documented methodology. Behind those recommendations sits a database of more than 10,000 technical experts, and the recommendation itself is free to the attorney: the work we sell is subtraction, shortening the field to the few prequalified names worth your call.
We are also a broker across the full breadth of technical expertise. When a matter reaches beyond our core into damages, medical devices, materials science, and other specialized fields, we draw on a wider network to field the right expert for the job. The selection discipline is the same in every field: hands-on domain fit, independence, a documented and reliable methodology, and the ability to explain it. Whether you need a behind-the-scenes consulting expert to shape the case or a testifying expert to carry it to trial, we help you match the expert to what the matter actually demands.
The takeaway
Choosing a technical expert is not a box to check late in a case. It is a strategic decision that starts early and shapes everything downstream. Decide the role, consulting or testifying, and retain early enough to shape discovery and the case theory. Weigh hands-on experience in the specific technology over credentials alone, and confirm the expert can teach, not just analyze. Insist on independence, run the conflicts check up front, and require a documented methodology that will survive a reliability challenge. For large reviews, make sure the testifying expert genuinely owns the work of the team beneath them. Watch for the red flags, settle the engagement basics in writing, and ask the hard questions before you sign. The expert is the foundation of the technical case. Choose deliberately, and choose the person who fits the job the case actually requires.
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 involving computer-based technology and software. HIRE AN EXPERT