How engineers and business people handle uncertainty
I've seen conversations stall over a word as ordinary as customer.
An engineer hears all the definitions still missing: legal names or nicknames, merged accounts, privacy flags, and the edge cases nobody has considered. A business colleague may mean the common case that drives revenue today and expect the definition to evolve as the team learns.
Both are trying to protect the product. The engineer sees expensive rework ahead. The business colleague sees an opportunity disappearing while the team debates a class diagram. Meetings multiply because each side is managing uncertainty in the way its work has taught it to.
I recently listened to Barry O'Reilly on The Architect's Paradox: Embracing Uncertainty in Software Architecture. It gave me better language for this tension and for the change I've felt in moving from engineering into architecture.
Two useful ways of thinking
In a business discussion, the definition of a customer can stay loose while people test whether an idea is worth pursuing. A changing market or an unexpected customer response might force them to revise the plan anyway. Waiting for every definition to settle would make some decisions impossible.
An engineer implementing that idea has to decide what to store and which rules to enforce. The code can compile perfectly and still represent the wrong idea of a customer. Looking for ambiguity is one way to avoid discovering that after the data has accumulated.
The split is hardly clean. Plenty of engineers are comfortable with ambiguity, and plenty of business colleagues want precise definitions. I find the distinction useful only when it helps explain why a particular conversation has become stuck.
Trouble starts when either group expects the other to use the same approach. Detailed technical questions can feel like red tape to the business. Loose narrative requirements can leave an engineer wondering what, exactly, they are being asked to build.
Leave room for assumptions to change
When I worked strictly as an engineer, my instinct was to protect the codebase from ambiguity. Architecture has required me to make decisions with incomplete information and accept that some assumptions will be wrong.
Now I ask how the design might respond when our current model of a customer, product, or order changes. We can model the likely changes, put boundaries around the uncertain parts, and explain the cost of that flexibility to engineers and business colleagues. Other areas can remain simple until we have evidence that they need more.
The podcast introduced residuality. O'Reilly describes repeatedly applying random stressors to a proposed architecture, then working out what would let it keep operating when its assumptions fail. I took that as a reason to look beyond the changes we already expect. Some extra complexity may help the system adapt, but I still need to explain what it buys us.
My first response to the podcast exposed my own habits: "If we follow SOLID, future change is already covered." The Open-Closed Principle helps, but it keeps the discussion at class boundaries. I had zoomed in too far.
I still run into this when I propose a design that can look slightly off-target for the immediate problem. Engineers may break down the requirement, isolate the abstractions, and suggest something cleaner for today's case. Their pushback is reasonable. They're optimizing with the information in front of them.
I'm also trying to account for what might happen when a new market or product variant changes those requirements. I need to explain which assumption worries me and how the proposed boundary would help us change it. Otherwise, the extra complexity deserves the pushback it gets.
Translate the uncertainty
The architectural role has put me between these perspectives. Part of my job is translating business goals into technical choices without demanding that everyone learn to speak in code. Another part is making the uncertainty visible so the team can decide where flexibility is worth its cost.
I'm still learning where that flexibility pays for itself. When I can't explain which change I'm allowing for and why it's plausible, I have a hard time justifying a more complicated design to the team.