[raxxorrax]

It is probably a bit dependent on what exactly you do. I am mostly an embedded dev and I often begin to show the tool chain we use from requirements analysis to firmware. And also the tooling around that for generally organizing your work. A certain phase for orientation should always be given an and some team members need to put in effort to train new developers.

But you can also take advantage of that if you task new members to maybe evaluate these tools or a specific one. That way they have a task beyond familiarizing themselves, which is often a blurry goal. The task also requires to get to know the tools employed to be able to compare them to alternatives.

That way you can also leverage the fact that someone new maybe doesn't have the same blinders yet and it can take work off you to keep up with developments in the field.

It takes a bit of time though, since newcomers are also a bit reluctant to tell you that the tools you use are suboptimal. You maybe need to encourage them to speak their mind.

As I said, it is a bit dependent on the field. Perhaps this approach is terrible for web devs, because the amount of alternatives is staggering and a lot of it comes down to opinion and personal preferences. So maybe this is terrible advice here.