The inexperienced Scrum Master becomes a secretary
There are not many Scrum Masters with experience. Therefore, employees are often retrained as Scrum Masters when Scrum is introduced. Usually by a coach who advises the entire company on the introduction. This can succeed if the coach has enough time for it and does not do it on the side, but unfortunately this is not the case in my experience.
The even worse alternative is the Scrum Master trainings: they often last only one or two days and teach the procedural basics, but this is simply not enough to be successful without further guidance. In my estimation, this is due to the fact that you can imagine very little under the role of the Scrum Master and comparisons to well-known traditional roles that exist in classic software development are not possible. A style blossom of this is to think of a Scrum Master as a project manager or team leader.
Typically, a new Scrum Master receives an appeal to internalize the Scrum values and a printed copy of the official Scrum Guide. This is a good start, but of course it is far from enough. What exactly is "Servant Leadership"? What does this mean in everyday work? How should you help the product owner to manage his or her product backlog efficiently? How do you help the development team create high-quality products?
Ultimately, the Scrum Guide and many sources on the Internet remain only approximate. Paying attention to the adherence to the Scrum events and organizing them (the not yet so independent team will not do this, especially at the beginning of the conversion to Scrum) and removing impediments, i.e. obstacles for the team, are the only somewhat clearer tasks. And that's why an inexperienced Scrum Master naturally pounces on it. At least he or she knows pretty much what needs to be done for these. And so the new Scrum Master quickly sticks to trivial organizational tasks. This effect tends to be even self-reinforcing: When introducing Scrum in a company, the typical impediments are interruptions by people from other departments who come into the team space and have questions. The Scrum Master then politely but firmly asks you to refrain from doing so. Accordingly, these employees are insecure and do not know how and when they are allowed to communicate with the team. If the Scrum Master does not clarify this, it will result in receiving the requests by e-mail instead, with the request to forward them to the team at the appropriate time. This is how the Scrum Master becomes an e-mail router. Over time, the development team mistakenly thinks that the Scrum Master is the "universal organizer" for the team and that it has to work that way.
My tip for "fresh" Scrum Masters: get to know experienced Scrum Masters as soon as possible and exchange ideas with them! Understand very well what the division of tasks between the product owner and the development team should look like and coaches them exactly on this point. The faster the refinement meetings are collaborative, the faster the entire team feels comfortable and becomes more confident in the application of Scrum. This provides peace of mind and thus time, time to develop yourself as a Scrum Master, because this role is almost everything but an organizer and secretary!