Put fifteen capable people in a room and ask how one field should post to the general ledger, and you will get fifteen defensible answers. Finance wants it one way so the close behaves. The integration architect wants it another way so the interface stays idempotent. The vendor has a third opinion, shaped by the last client they configured. Each answer is reasonable. None of them is, on its own, right, because right depends on constraints no single person in the room can see in full.
This is the part of a large implementation that surprises people who have only run small ones. On a small project, the hard part is knowing the answer. On a program that spans finance, IT, procurement, and eight vendors, answers are cheap. Everyone arrives with one. What is scarce, and what actually moves the work forward, is the question that makes the real constraint visible to the whole room at once.
So we have stopped trying to be the smartest answer in the room. We try to be the source of the sharpest question.
Why scale makes answers cheap
Every group on a program is solving for something real, and something different. Finance is solving for a close that ties out and survives audit. The integration team is solving for flows that rerun without double-posting. Procurement is solving for approvals that match policy. The business sponsor is solving for a date. None of them is wrong. They are answering different questions while believing they are answering the same one.
Hand that room a decision framed as what is the right answer, and it splinters along those lines, because each group is genuinely optimizing for its own constraint. Reframe the same decision as a question, and something useful happens: the constraints come out from behind the preferences, where everyone can finally see and weigh them together.
What a good question actually does
A good question is not a stall, and it is not curiosity for its own sake. It is a tool that does specific work. It turns a turf position into a stated requirement. It surfaces the assumption nobody said out loud. It moves a decision off of seniority and onto evidence. Done well, it narrows the room rather than reopening it.
These are the ones we keep coming back to, across very different stacks and very different teams:
- What breaks if we're wrong about this? Sizes the risk before the debate consumes a day. Some decisions deserve a war; most are reversible and do not.
- Why does it need to be that way? Turns a preference into a requirement the rest of the room can actually evaluate, or quietly retire.
- Who lives with this after go-live? Finds the real owner. The person who maintains it at quarter-close should outweigh the loudest voice in the workshop.
- What is the data doing today? Replaces opinion with observation. The system already behaves some way; look before you legislate.
- What are we optimizing for here — the close, the integration, or the user? Names the tradeoff out loud so the group chooses it on purpose instead of discovering it at cutover.
The discipline is in not answering
The hard part is not asking. It is resisting the answer when you are the consultant in the room and the pull is to earn your seat by resolving the debate on the spot. We understand that pull. But the lead who supplies every answer trains the team to bring problems and wait. The lead who asks the better question trains the room to surface its own constraints, and that room keeps working when we are not standing in it.
This is not the same as endless discovery. A question earns its place only if it closes something. The test is simple: does the answer it produces survive contact with the other contexts in the room? If finance's answer collapses the moment the integration team hears it, the question did its job early and cheaply, which is exactly when you want to learn it. A question that only reopens the debate is not a right question. It is noise wearing the costume of rigor.
Being decisive still matters, and on the calls that are one-way doors we are direct about the recommendation and the reasoning behind it. The difference is what we are decisive about: which question is worth the room's time, not who gets to be first with an answer.
It ties back to the ledger
The systems reconcile at the end because someone asked, early and precisely, what reconciliation would require of each platform along the way. The right questions are how a program of competing, reasonable, incompatible answers resolves into one that holds. Get them right, in the right order, with the right people in the room, and the answer tends to arrive on its own, already agreed to by the people who have to live with it.
That is the quiet part of the work. It rarely shows up in a status report. It is the reason the numbers tie out anyway.