One technique I picked up from a colleague that I adopted on my most recent project, was having regular architecture review sessions. We ended up having these twice a week and it was a forum where we could review designs as a team. We were able to extend these sessions to include people like the security and infrastructure architects as well as the design lead for the project.
Being a fairly disorganised person we ran these sessions in the early stages as a free-flowing meeting more as a general discussion. As we progressed to align to project schedules and all that good stuff we were a bit more organised and had an agenda and had a minute taker to capture all those juicy bits of feedback that were raised in these sessions.
I found these sessions to be beneficial for the team firstly we developed a behaviour in the team of bringing designs in the early stages of forming to these sessions. With the varied experiences of everyone in the room there was some great alternatives presented that ultimately helped us come up with a better design. This behaviour was also good in that the team was happy to bounce ideas around in these forums, people have a tendency to take feedback personally but I think we got to the point where the feedback was constructive and in some cases was intentionally sought by the author.
Given the size of the team these sessions also provided a great forum for the team to get visibility of parts of the design being completed by others. If we had not had these sessions members of the team would have known their parts of the systems intimately, but not had a good end-to-end knowledge of the design. As we had a broad audience outside of just the architects, over time as we reviewed all of the components of the design there was a good history built up about how we go to the final design and the interconnectedness of all of the components.
The way the project unfolded people were assigned areas of the design more to meet the schedule than any natural strengths around domains. These sessions allowed the collective knowledge of the team to be harnessed to review the design. So although someone who had a history using ETL tools may not have been designing that component, within the Architecture Review meetings they were able to impart their knowledge on that part of the architecture.
Having picked this up and applied it to my first project it is definitely a habit to instil into a project of any size. Look for that balance between a free-flowing discussion and a regimented meeting that runs to an agenda. Get that balance right and you create a great forum where the behaviour of the team as a whole can be fostered to build a high performing collaborative team.