Coaches usually mean well, but they often come from a management background in an organization where work is assigned to developers and answers mainly come from management. This creates a pattern of developers expecting problems to be solved by management. We want to create a new pattern, where they solve most of the problems on their own.
Coaches need to coach developers through these pattern changes. This requires emboldening them and sometimes creating a void that they must fill themselves.
A good practice for coaches is to ask questions - even questions they might know the answer to - and to wait for the answer. The practice is to silently count to 10 seconds after you ask the question. Don't be surprised if it takes 6-7 seconds before someone speaks up...long silences can be uncomfortable for a developer who knows the answer, but is a bit shy in speaking up. If you get to 10 seconds and no one has spoken up, ask a bridge question; a question that is easier to answer and gets you halfway there.
Coach: "Are we on track to hit our sprint goal this week?"
Silent count to 10.
Coach: "OK, are there any things that you might be worried about?"
After a few seconds a developer speaks up: "I'm not sure I'm creating the right animations for the melee".
Another developer speaks up: "I can sit with you after the meeting and go over what we need".
Creating a pattern of solving problems among developers, without direct management supervision will give you one of the greatest benefits of self-organization. Having eight people solving 90% of the problems is a lot more efficient and effective than you being the bottleneck.