Direct answer
Three habits that compound because they're small enough to do daily and social enough to spread on their own: writing or updating a test alongside the code you're touching rather than as a separate later step, a weekly small-group code walkthrough where one person shares something interesting they wrote or found, and leaving code slightly better than you found it on every touch. Measure adoption with leading signals and success with a trailing signal a few months later, not a mandate announcement alone.
Structured elaboration
Habit one, daily: test alongside code. When touching a function, write or update its test in the same sitting, before moving on, instead of batching "add tests" as a separate task for later, which in practice usually means never. It's a small discipline per instance that compounds over months.
Habit two, weekly: a code walkthrough. A thirty-minute session where one person shows a piece of code they wrote or found interesting, a clever refactor, a tricky bug fix, a design decision they're unsure about, open discussion rather than a formal review. This spreads a tacit sense of what good looks like faster than a written standards document, and normalizes talking about code quality socially instead of only through review comments.
Habit three, on every touch: leave it better. A small, scoped improvement to whatever code you're touching, renaming an unclear variable, adding a missing test to an adjacent untested function, tightening an interface, bounded so it doesn't turn into unplanned scope creep on an unrelated ticket.
Measuring adoption and success: adoption is easiest to see as a leading signal, the share of merged pull requests that include a test change alongside the code change, walkthrough attendance and rotation of who presents, a count of small non-ticket cleanup commits. Success is a trailing signal reviewed monthly, the trend in review comments flagging a missing test, self-reported team confidence in the codebase from a short survey, and whether the same module keeps showing up in incident postmortems. Pair the adoption metrics with an occasional spot-check of quality, since presence alone can be gamed with a trivial test just to tick a box.
Worked example
A backend team of six adopts these three habits. In the first two weeks, the tech lead presents first at the weekly walkthrough to model the tone, informal rather than a performance review, then rotation cycles through the rest of the team. By the end of the first month, the share of merged pull requests including a test change rises noticeably from roughly half to nearly all, tracked from the pull request diff data rather than self-report. The leave-it-better habit shows up as a steady trickle of small cleanup commits alongside feature work, loosely tracked by a "cleanup" tag the team adopts as a commit-message convention. At the three-month mark, the team reviews together: review comments flagging missing tests have dropped noticeably, the walkthrough has surfaced two design issues early that would previously have only been caught in a later incident, and a quick anonymous survey shows most of the team feels more comfortable navigating the codebase than before, that combination, not any single number, is what the team uses to call the habits working.
Trade-offs and pitfalls
A daily habit that's too heavy, a full test-suite update on every touch, gets abandoned under deadline pressure, it has to be small enough to survive a genuinely busy week or it won't actually compound. The weekly walkthrough can slide into performance theater or quiet gatekeeping if the same senior person always presents and others feel judged, deliberately rotating presenters and keeping the tone informal matters as much as the format itself. The leave-it-better habit, left unbounded, turns into scope creep that annoys reviewers and slows down unrelated pull requests, it needs an explicit norm that the cleanup stays small and is mentioned in the pull request description rather than silently bundled in. And measuring only activity, walkthrough attendance, test-change percentage, without ever spot-checking quality risks celebrating habits that technically happened but didn't actually raise the bar.
