In his Production Oriented Development, Paul Osman suggests a number of practices and principles. The post not only makes great points, but includes fantastic links. A few specific thoughts:

Engineers should operate their code

Strong agree. I sometimes refer to the ability to operate code well as full-full stack, and lump it together with the ability to participate in design and strategic planning (what should we build next, how should we maintain, when should we sunset) as a horizontal dimension labelled SDLC. This, combined with the traditional vertical assessment of skills (does the engineer have capabilities in the canonical web stack layers of front-end, back-end and persistence) provides a two-dimensional assessment of skills and starts to let you assess team strength visually.

Make Deploys Easy... deploying should be a frequent and unexciting activity

Again a strong agree. On every team I've built or inherited, one of the primary changes I look to make is encouraging more frequent deploys. Multiple deployments per day is best, but at a minimum deployments should happen weekly. Cliche, and also true: Teams that don't deploy weekly, deploy weakly.

Boring Technology is Great

I like this with an and: And, one technology (boring or exciting) beats three. One of the frustrating aspects of technology orgs is that the more time goes by, the likelier it is that there are multiple ways of solving the same problem. Usually there are solutions that "are only used in the legacy code" and then some officially sanctioned solution which is to be used everywhere going forward - or at least until the eng leader who's driving its adoption leaves the company. Believe it or not, I consulted for an org once that was using each of Microsoft SQL, PostgreSQL and MySQL - and had a great story for why they were doing so!

Trust the People Closest to the Knives

Really the only point I mildly disagree with. Actually it's more of an "and" because I would never say you shouldn't trust the people doing the work. I do think there's a higher level perspective that's usually lost when a team is in the weeds. Especially if that team skews early-career and doesn't have the wisdom yet to either see the big picture or to see time trajectories (aka where what we're doing today is likely to lead us in 3-5 years). This brings to mind the old saw of people asking for faster horses. Every tech org needs a Henry Ford, and your Fords probably aren't on the front-lines holding knives. (And if they are, promote them for goodness sake)

Simple Always Wins

This. So many times. The best enemy is not down the hall, it's not your rival app team, the Ops group, customer support or sales or 'leadership' or even the customer. The best enemy of any team is the intangible, and for a mature tech org that's already won their small fights against the impossible, complexity makes the perfect enemy to rally around.