Here's how you can adapt your communication style as a computer engineer to diverse audiences.

The audience's technical expertise, subject familiarity, and interests should be determined initially. When talking to other engineers or technical team members, use industry-specific vocabulary and provide extensive technical explanations. When engaging with non-technical stakeholders like managers or clients, simplify the terminology and focus on the big picture rather than the minutiae. Avoid technical terminology, acronyms, and incomprehensible jargon. Knowing your audience helps you anticipate their questions and concerns, making your conversation more engaging. Tailoring your message to the audience's understanding and interest helps you communicate simply and effectively, improving decision-making and teamwork.

Even within the same group of fellow engineers, one still needs to be mindful of each engineers' background. Computer/Software engineering is an extremely wide field spanning across multiple domains. Thus, you cannot always assume that fellow engineers are specialised in the same domain as yourself. In such cases, it is good practice to be patient and explain your thoughts and ideas in a slightly simplified manner while still being able to use common technical terms.

Even if you work on the deep end of backend, there is a way to explain what you're doing. All you have to do is think from the perspective of the end goal of the overall task. If you're switching away from PHP, it's "obsoletion leading to maintenance costs down and speed up"; if you've unwrapped a loop in assembly, it's a "minor speed-up that will scale to +7%(?) performance in <a task>". When preparing for a talk, always consider that whatever you do, it serves a purpose on the user end, or it helps the team.

As an engineer, you know that even if your thoughts are faster than any representation of them, at some point it's just too much and you need to organise your task into manageable steps. Making slides for the broader audience leans into the same concept — you use flowcharts for logic, pie charts for speed profiling, sheets for data, and provide quick descriptions of the current situation or the end goal. This little will already be good enough.