Trainings don't work. What does work is pair programming but you have to do this effectively. Say you have 3 buckets, frontend, backend and infrastructure. Ideally, you want to pair someone who has very full infrastructure and backend buckets, with someone who has an overflowing frontend bucket. Mix and match. There's no value in pairing two more backend oriented engineers together.
There's also no value in categorizing things in frontend and backend, if you just have a frontend engineer that throws things over the hedge to the backenders garden, you're going to have a shit shoveling contest and this doesn't work. Of course, you should still have people specialized in certain domains, but you should try to share knowledge within your team as much as possible and try to broaden's people experience instead of having people work on their own little islands. Pair someone with a backend background on a big frontend ticket with an experienced frontender and before you know it you'll have two full stack engineers that'll possibly grow to become a "10x" or whatever that means.
Code reviews are critical and it's important to have someone in your team that carries a big stick and isn't afraid to use it. This is a sensitive thing I've noticed, I've worked at companies where I wasn't the only 10x engineer, and the code reviews there were a joy because I was getting very valuable feedback. It wasn't so much that my code was wrong, but more something like `{} as MyInterface` could also be written as `<MyInterface>{}`. There were a lot of style related comments. What I notice in my current team is that people feel like this is unnecessary, but I always felt like it is valuable when another engineer suggests something like "maybe you could abstract this?" because it introduces a bigger picture that I may not have thought of before. It's very loathsome to carry the big stick, but I feel like if I dont, we're going to go back to the old patterns of not writing tests, not thinking about architecture.. Those kinds of things.