I hear you. I do. How do you get 20 teams working on disparate codebases, and probably languages, to share their knowledge across teams? How does a team working on Java benefit from something someone found in Django from another side of the company? Organizations need standards. Developers require it. We want the thing we are programming against to not change right? We want our codebase to build when we say build. All tests green. Happy. Productive. Engineering leadership needs to organize standards around engineering culture and tooling, it could be championed by a team that did it, or by research. It doesn't matter. What matters is that leadership facilitates communication into what is working, what isn't, why, and what can we do about it?

At the micro-level, tools help, no doubt about it. At an org level, communication helps (documentation is a form...). Even if using different tooling, concepts and strategies are the same. This isn't to take away from the argument that this tool the OP posted is pretty awesome.

If you want change, be the change. Evangelize the tool through your org, not just your team. If your org is silo'd, break those barriers down with a friendly lunch-n-learn or lightning talks session. We tout empathy for our customers, how about empathy for our coworkers too? Others may have the same pain...