Readme's that actually talk about the purpose of the service and where it fits into the whole and helps the developer form system level understanding, runbooks

Readme's that actually talk about the purpose of the service and where it fits into the whole and helps the developer form system level understanding, runbooks that have step by step guides and reasons for alerts and errors, design discussions, design documents, sometimes pair programming on harder areas, appropriate tests, appropriate comments, real code reviews where the reviewer seeks to understand the code and the change, idiosyncrasies written in the readme, purposefully deconstructing silos of information (spread responsibility/knowledge) and removing single points of failure by having less experienced folks get trained up and begin taking on responsibilities that were siloed and updating onboarding documentation while doing so, group code reviews on tricky changes, communicate issues and solutions to the team at large, team alert reviews, team error reviews, graphs and metrics have descriptions in plain words describing customer/user impact, and probably some other things we do.