We have many cases where colleagues with different experience levels are in a meeting and discussing potential software design(s). And another set of engineers who don't "get it" and would rather simplify everything - by simplification I mean "simplify to their understanding" and not necessarily adopt the suggested principles/practices in our domain.
At times, meetings have been derailed just so that we get provide a knowledge dump, which is exhausting with all cross-questioning/teaching etc., and then are they on board.
We've had discussion where we've explicitly given them some knowledge dump and provided links/books/references to follow up on the others. However, the "follow up" never happens and we're back to square one. It seems there's resistance in putting up the effort to "read up about it" and then come back with questions/clarifications/suggestions vs. argue about it right there and go back not feeling convinced and just leaving it at a stalemate.
What are good ways to "motivate peers" to "study/learn" new things vs. derailing meetings to explain everything to them?
UPDATE: This is not as straightforward to "Google it". It's more difficult than a keyword search but more of understanding underlying concepts and why things are done/preferred in a particular way. At times, books do a much better job than Google. The idea is probably to go a little deeper into the topic and make sense of the disparate sources of information to understand something that may take a few hours worth of mulling/understanding vs. a few minutes of Googling. It's about "lack of domain expertise" and unwillingness to "build it up" vs. "explain it to me right now".