The Test Pyramid is not something you implement, but more a guideline showing how to spread the testing efforts. Also it should be a guide to prevent an Agile anti-pattern "the ice-cream test cone".
A possible way to enforce creating automated tests is to set a test-coverage standard. You can use a code-analyses tool (e.g. SonarQube) to monitor trends on this. These tools can even deny pull-requests or send alerts.
You can start with a minimal test-coverage of let's say 35%, this forces everyone to write at least one test for the code. Later you can say new code must not trends it below 35%. Some months in the future you can upgrade the percentage to 65% or higher. Xp teams have a target of 85 up-to 100% coverage. For legacy code-bases this is a dream you might achieve, set realistic targets. Also keep in mind testing is the goal, not coverage.
Focus on trends not the exact numbers. New code should not bring the current code-coverage statistic down, the number should always go up.
To train & convince developers in automated testing I have started doing Coding-Dojo's with my current teams. In the dojo sessions we use TDD techniques to get the developers familiar with unit-testing and writing good tests. Each iteration we do one 1,5 hour session. In parallel we watch & discuss an UncleBob's CleanCode video each iteration, some also focus on TTD and code test-ability. This is time demanding, but most developers do not have the free time to learn outside of work. I really think developers should grow each iteration and learn how to make testable and maintainable code.
Other sources: