Have sessions with people making them understand the best practices and why they need to be upheld

Review best practices annually to make sure they still make sense and are aligned to the technology.

Make sure that the best practices are upheld by having the QA team check them on the projects they're allocated to, on a regular basis

Have 'team champions' (config specialists or higher, with a good understanding of Darwin and our processes) gospel working principles and best practices within their teams.

Update the Darwin configuration space on Confluence, making sure that the config team is aware of the config guidelines / principles by sharing these pages with the team and ad-hoc meetings (where/when there is demand)

Enforce config principles / guidelines on new client implementations by making sure that config leads understand and are aware of these

Have config specialists include measurable best practices in their objectives (e.g. % of sites built having the proper naming for effect rules and numbering - if not 100%, failed)

Join new client project meetings, ad-hoc, upon request by Config leads, after they've asked Technical Experts or Senior Config specialists about the feasibility of a project and have not reached a conclusion, to remove documentation ambiguity on complex builds/specifications

Review the most common BDS templates and remove redundancies / ambiguous information from the template themselves.

Change the BDS to an online tool that holds the documentation for each project, having it be dynamic, easy to change and easily convertible into Darwin configuration. (I do not agree with having Darwin the source of truth for clients. Quality, without clearly outlined specifications, is extremely difficult to measure)