What's wrong with "best practices"? I get the feeling the best practices you're complaining about are TPS reports, whereas I'm thinking more like "don't ship to prod on Fridays".
I’m talking about the actual term “best practices”, and not the actual practices themselves. The term is an ineffective way to communicate something.
Managers and engineers alike should be able to explain what they do in terms that can be connected with concrete actions / concerns and understandable business goals. Terms like “best practices” are ineffective at doing that. Just like there are code smells, this is a “communication smell” and makes me suspicious that there are underlying problems or weaknesses in the speaker’s ability to communicate clearly. “Best practices” also implies some kind of independence of situation which is fictitious.
“This team doesn’t use best practices for deploying code” -> unclear.
“This team doesn’t use CI/CD, engineers spend too much time resolving merge conflicts, and we see too many regressions make it into production” -> clear. If you need to put it in a bullet point, you can say something like “improve velocity”, “ship fewer bugs”, or “less downtime”.
I’m a fan of ambiguous or unclear language, but “best practices” strikes an unfortunate balance of sounding like it means something but wasting your words saying not much at all.
If you, say, have 30 teams whose projects come together into a product with a 99.9% SLA, you can’t have each team make completely independent judgments of what practices are best for their situation. You can try to, and many growing companies do. What you inevitably find is that the aggregate set of problems is too large, even when every team has a plausible story for why their individual situation makes sense.
The only solution is to write down a “best practices” manual and insist that everyone must follow it, even if they don’t think some practice or another is necessary in their situation.
I would name the document something like “development standards” or something like that. I’ve this called “meeting the bar” or “engineering excellence”. I like “meeting the bar” because the implication is that you haven’t succeeded if you don’t do what’s described. I like “engineering excellence” because it implies that you’ve gone beyond the minimum. I don’t like “best practices”.
I also wouldn’t insist that everyone must follow it. You have minimum standards (everyone must follow) and a set of expectations which are higher than that (everyone should follow). I think it is a kind of common error to make long lists of standards that everyone must follow. It’s better to prioritize. The minimum standards should be short and connected to the most critical concerns like security, privacy, or legal liability.
IMO, 99.9% SLA is not really that hard anyway, but I get what you mean. That’s like 2 whole hours of downtime per quarter.
Alternative terms for your practices docs: just call it “development practices” or something. This makes it a little more clear that it’s not a dumping ground for every practice people think is good / best, but only for what people actually care about, which is the development practices that your team has adopted. You can say something like, “Best practices according to research is X, but our team is adopting Y because we believe Y is promising.”