I flip the conversation from explaining how systems work to showing what problems they solve.
Instead of walking through technical architecture or system specifications, I start with the business problem. "Users are dropping off at this step because the current system creates a 3-step process where they expect 1 step." Then I show the technical solution that fixes that specific problem.
The key is connecting system behavior to business outcomes. When I need to explain why we should modernize a legacy system, I don't talk about code architecture or technical debt. I explain that the current system creates manual workarounds that cost the business time and create risk.
Visual mapping works better than technical diagrams. I draw simple workflows showing how users move through systems, where they get stuck, and how technical changes remove those friction points. Stakeholders understand user journeys better than database schemas.
I also use session recordings and real user data. Instead of saying "the API integration needs optimization," I show actual footage of users struggling with slow loading times and explain how technical improvements solve those specific problems.
This approach works because it frames technical decisions as business solutions. Stakeholders don't need to understand the technical implementation - they need to understand how it affects outcomes they care about.
Technical architecture becomes strategic when you connect it to measurable business results.