A capstone, in three conference rooms

In January, quantum computing was mostly a vocabulary problem. By April, it had become a judgment problem.

This is what I remember from a four-month Columbia SIPA Capstone for Wood Mackenzie: three rooms, three versions of the same question, and a team slowly learning what a useful answer looks like.

The first room: admitting what we did not know

Six of us began with different backgrounds and no claim to being quantum physicists. The assignment was broad: assess where quantum technologies might matter in energy, and when.

At first, every paper seemed to require three others before it could be understood. Terms such as variational algorithms, error correction, and quantum amplitude estimation were individually definable but difficult to connect to an operating decision. The temptation was to collect impressive applications and call that a forecast.

The better move was slower. We built a shared glossary, divided the application areas, kept a common source list, and met in person each week. Our notes became more useful once we started recording uncertainty as carefully as conclusions. “We do not know yet” stopped being a failure and became a research task.

My part focused on energy finance, a Monte Carlo explainer, and the summary framework that compared applications. That meant repeatedly translating between two questions: can a method produce a technical advantage, and would that advantage be worth anything after data, integration, hardware, and organizational costs?

The second room: making the comparison fair

By the midpoint, we had six application areas and too many incompatible ways to describe them. Battery chemistry was not directly comparable with grid optimization. Quantum sensing did not belong on the same hardware timeline as fault-tolerant quantum computing. A promising algorithm did not necessarily imply a promising business case.

So the deliverable changed from a catalogue into a matrix. We assessed each area against three shared dimensions:

1. time to value;
2. fit between the problem and a plausible quantum advantage; and
3. implementation cost relative to the benefit.

The scores were less important than the discipline behind them. A common framework forced us to expose assumptions that prose could otherwise hide. It also made disagreement productive. When two people scored an application differently, we could ask whether the difference came from hardware timing, the classical benchmark, or the economic value assigned to an improvement.

That midpoint review also made the standard clearer: every claimed advantage had to survive comparison with the best available classical method. “Quantum could do this” was not enough. The relevant question was whether it could do the job better enough, soon enough, to change a real decision.

The third room: saying less, more precisely

The final month was mostly subtraction. We removed claims that had outrun their evidence, separated sensing from computing, and made timing conditional on capability rather than calendar year. We tightened the distinction between technical fit and commercial readiness. We replaced smooth adoption stories with thresholds: value may stay nearly flat until accuracy, scale, and workflow integration cross a useful line.

The final presentation felt calmer than the work that produced it. That was a good sign. The framework could carry the argument without theatrical certainty, and the team could explain where the evidence was strong, where it was directional, and what would change our view.

What stayed with me

The interesting part was not becoming fluent in a new technical vocabulary. It was learning how a group of generalists can earn a point of view without pretending to be specialists.

The visible work was research, interviews, modeling, and slides. The enabling work was more ordinary: agendas, shared definitions, rotating notes, source hygiene, and deadlines that meant the same thing to six people. Coordination did not sit beside the analysis. It was part of the analysis, because inconsistent inputs produce inconsistent judgment.

I also learned to wait longer before committing to a thesis. Early in a project, certainty feels efficient. Often it only makes the research defensive. The useful answer emerged after we had enough structure to compare unlike things and enough humility to keep the caveats attached.

By April, we could explain the six applications. More importantly, we could explain why some attractive claims did not yet deserve confidence. That is the version of expertise I trust: not having an answer immediately, but knowing how to build one that can show its work.

This essay describes my own learning from the academic project. Client materials, private conversations, contact details, and other team members' work are intentionally omitted.