The biggest mistake people make with specifications is waiting until a formal review process takes place to get feedback on its contents. Reviews should be used to confirm and refine, not to make a first pass and a final decision at the same time. This is another reason why a design process is so important: it means that design decisions have had many iterations, and the authors have had lots of chances to incorporate good suggestions. Team leaders should make this happen by being available for informal earlier reviews and by making the draft specs available on the intranet. But this isn't to say that spec review meetings should be a cakewalk; everyone should walk into the review process with a very clear idea of what is expected of her.
There are different ways to review specifications, but most of them involve a meeting where the document is read or discussed to someone's satisfaction. How formal or informal this meeting is depends heavily on the culture of the team, the attitude of team leaders, and the nature of the project. But however it's done, the goal is to answer the same two questions: "Is this specification sufficiently detailed to guide us through development?" and "Will the result satisfy the requirements and goals for this part of the project?" There are certainly many more specific questions to ask, but they all derive from these two key ones. The process of review should be directed at answering them confidently.