How to effectively communicate technical decisions to non-technical stakeholders

our tech lead is really struggling to communicate complex architecture decisions to product managers and executives. he's brilliant technically, but when he talks about eventual consistency, database sharding, or re-architecting our event bus, their eyes glaze over. i need to help him translate these deep technical concepts into terms that non-technical stakeholders care about: risk, cost, time, and business value. how do you effectively frame a discussion about technical debt or a major re-architecture in a way that resonates with product and business leaders? what analogies or communication strategies have you found most successful for bridging this gap?