Imagine the following scenario. You and a colleague have written an architecture proposal to implement Contract Testing into the system, so most services can benefit from it. You've built a working proof of concept, all using internal frameworks, protocols and the existing messaging system, because you don't like reinventing the wheel but when you're already driving a custom-made car, you think it's if not better at least less friction-inducing to use existing building blocks instead of introducing new tools into an already complex system.
It works, it is simple (python, git and json), it plugs into the existing services ecosystem and automatically builds the schema definitions of modern services, and with some extra love can theoretically be made almost 100% compatible even with the old legacy ones. Everything seems ready to showcase and proceed to ask for time and resources to make it a real project.
You begin to finally present it at the architecture committee in all it's glory. After five minutes talking about how it's implemented, somebody asks: "I'm sorry... what exactly it's contract testing and what does it add?" 💥
That is the moment when you realize you made a huge mistake... You assumed everybody, being senior roles, had knowledge of the basic pillar: what is contract testing, why is interesting and what problems it solves or aids to ease.
The meeting shifted to some improvised explanation and a brief "next steps", but it felt like the magic of the technical approach was lost, it missed the hype train. Nobody can measure the quicker test development or the added safety net for releasing new service versions without breaking others if they don't know that's a problem and there's a certain way to solve it.
You don't need to go to the other extreme and explain everything like you're a five year old, but you should always include a basic introduction to the topic.