How I work
Four things I keep coming back to. None of them is original; most were learned the slow way, on real teams.
A team's real standards are the ones it sees enforced
Values on a wiki page count for very little. People calibrate on what actually passes: the review nobody commented on, the deadline that quietly dropped the tests, the behaviour that went unaddressed in a meeting. That is the culture, whatever the document says.
Small releases teach more than big plans
Scope can almost always be cut; dates usually cannot. Four reversible steps tell you whether you were right, and cost far less when you were not, than one large launch built on assumptions.
Most of the work is understanding the problem
Before agreeing on an architecture or approving a refactor, I want two things written down: which problem it solves, and how we will know it worked. Without them we are choosing by taste.
Context travels further than rules
Practices imposed from above last until the next deadline. Explaining why a decision exists, and leaving the how to the people doing the work, takes longer to start and holds up much better.