Late to the Table

On what it costs when the right questions arrive after the room has already been shaped

I keep getting called into technology procurement discussions after the process has already been running for a while. Not always late in the sense of irreversible decisions, but late enough that the vendor has already shaped the room. There’s a deck. There’s been a walkthrough or two. Some of the questions I’d want to ask in the first hour have already calcified into assumptions. The most awkward version is when the conversation has moved to legal and financials, and you have to find a way to say “by the way...” and pivot the whole room back to technical fundamentals. Nobody loves that moment.

I sat in one recently. A large-scale digitalization project. The proponent walked through the architecture, the workflow, and the AI components. The system was genuinely well designed in many ways. But within the first hour, I already had a list of questions I couldn’t shake.

Not niche questions. Things like: what happens when the valuation check at the end contradicts the payment that was already collected at the front? What does the risk model do at the boundaries of its training data? Where exactly in this process does the AI output become a legal input? Who holds the encryption keys, and is that written anywhere?

I wrote them all down after the meeting instead of interrupting. The setting felt too high-level to go deep. But the questions were about the basic design logic of a system that would sit at the center of critical operations.

This happens a lot. The details vary. One time, it was an AI platform embedded in a legacy system. The vendor was good, and the demo was compelling. The product was genuinely capable. But the organization wasn’t ready for it, and saying that out loud required slowing a process that had already built up momentum. I flagged it anyway. We all took a step back. That was the right call.

I’m not an infrastructure expert, nor a procurement specialist. But I’ve spent years sitting in dissertation and thesis defenses, and that trains you in something specific: how to ask the question that exposes whether the foundation actually holds. I’ve been in enough of these rooms, across enough of these projects, that I’ve developed a sense for what questions need to be asked. And these days, when something in a technical document genuinely confuses me, I can go deeper with an LLM before I walk into the room. I’m not the most technically prepared person at every table. But I’ve learned to be curious in the right directions.

That’s really the point. The gap between knowing a technology and knowing what to ask about it is wide, and most organizations sit somewhere in the middle. The technical depth required to scrutinize an AI risk engine or a cloud architecture is not evenly distributed, and it shouldn’t be expected to be. Organizations buy technology all the time without anyone in-house being fluent in the infrastructure. That’s normal.

The issue is knowing when that gap matters.

There’s a spectrum to these decisions, and not all technology procurement deserves the same level of rigor. On one end, you’re subscribing to a SaaS tool that half the industry already uses. The risk is low. The questions are mostly about fit and cost. On the other end, you’re acquiring a custom system that will transform operations, carry legal weight, sit on sensitive data, and run for a decade. The treatment should be completely different.

The mistake is treating both ends the same way, or not knowing which end you’re on.

For anything that sits toward the high-stakes end, the right technical advisers need to be at the table before the vendor has already shaped the room. Before the architecture gets locked. Before the workflow assumptions get embedded. That’s not because the vendor is suspect; it’s because procurement at that level is a governance act, and governance requires people who know what to look for.

When those people arrive late, like I often do, the questions still get asked. They just arrive after some things are harder to undo.