Audience-Calibrated Communication

The same architecture decision requires three different explanations for three different audiences — and delivering the wrong explanation to the wrong audience is as ineffective as delivering no explanation at all. The CTO does not need the API specification. The engineering team does not need the business justification. The CFO does not need either — they need the cost, timeline, and risk implications. Audience calibration is the practice of designing the explanation for the receiver.

1. Executive Communication Lead with the business outcome. Then the cost and timeline. Then the risk. "This architecture delivers the customer-facing AI capability in 12 weeks at $180K, with a known risk around data integration that we are mitigating through a phased rollout." No technology names. No component descriptions. Business language only.
2. Technical Leadership Communication Lead with the architecture decision and the trade-offs. "We are using event-driven architecture for the order processing pipeline because it satisfies the 99.9% availability requirement. The trade-off is eventual consistency with a 2-second propagation delay, which is acceptable for this use case." Technology names are appropriate. Diagrams are expected.
3. Engineering Team Communication Lead with the implementation implications. "The event-driven pattern means you will consume from a Kafka topic, process idempotently, and publish results to a separate topic. Here is the contract specification. Here is the error handling pattern. Here is the testing strategy." Specific, actionable, and sufficient to start building.