It is really hard to manage, or explain what we can’t see.
Based on this statement, we should continuously look for ways to reveal the important implicit concepts in software. It is our chance to explain what software is to people who don’t look at lines of code all day long. 
WYSIATI
Questions like « How do I introduce -whatever practice or concept- in my daily work ? » have the same answer. We have to make explicit whatever we want to introduce, and reveal the consequences of what is lacking.
We have to explain which problem is solved, and how.
As long as an implicit problem is not explicit, nobody will care, it is human nature. Thinking Fast And Slow explains it very well with WYSIATI : What You See Is All There Is. We are naturally biased to neglect what we can’t see.
Make the design explicit
There are several ways to reveal a design, from high level design (modules and contexts) to low level design (Class and Functions). It starts with manual diagram, but it is mostly revealed by unit testing and living documentation.
Manual diagrams are an explicit representation of what we think our software should look like.
Living documentation is generating the representation from our code, giving information on our actual code, to know if it’s aligned with what we think it should be.
Unit testing is both a design and a testing tool. Code that cannot be tested easily was poorly designed.
We could also use static code analysis with products like Sonar or NDepend, to track cyclomatic complexity or coupling.
These tools among others help to reveal our design, not only what we think it is, but also what it actually is. Based on this feedback, we can sense and act to improve the software. Without this information, it’s almost impossible to know what could be improved, because we have potentially no idea of what is wrong in the first place.
Make the predictability (debt) explicit
Missing code coverage, voluntary design shortcuts, build breaks and defects are interesting metrics to track to reveal our software predictability. We can also track less technical indicators like overall team and customer mood.
We could unlikely keep our software predictable without revealing the consequences of low predictability.
Make the domain explicit
Our code should be aligned as much as possible with our domain.
Good alignment between code and domain means that a domain problem becomes a code problem.
The alternative is to deal with domain problems AND code problems, which could be really different.
If we’re not aligned with our domain, we’ll bring technical problems instead of business solutions.
We should reveal our domain in our code, using meaningful names for the business (Ubiquitous Language), and protecting domain centric code from infrastructure with hexagonal architecture (for example). 
DDD core concept
Make the implicit explicit is a core concept of DDD. And it resonates a lot with the idea of WYSIATI .
It is a key to improving our collaboration with non-IT people, because they can’t understand something invisible to them.
It is a key to improving our software design, because we are not able to manage what we can’t see.
Make the implicit explicit is hard because it is endless work, but it is required to have stable foundations in a DDD project.
As usual Brian Gibson helps me to improve the language in this post. Thanks man!