The sort of tenets Amazon uses are generally vague enough to abused by management constantly. I wouldn't say they are "popular", rather forced down your throat. They're constantly mocked and poked fun at by ICs.

A good tenet is unambiguous in application and interpretation. There's no way to misuse a good tenet. Some of Amazon's are incredibly easy to abuse: frugality, disagree and commit, be right a lot. Here are some strong ones that may or may not be useful to your company:

If a decision is easy to reverse, don't spend to much time figuring out of it's the right decision.

Prioritize paying for something over building something assuming the annualized cost of an engineer is ~$X (e.g. $1MM).

Document and test internal systems as if you were selling them to a customer.

Simple, repetitive and dumb over complex, convenient and smart.

Plan to throw the first iteration away.

Be honest, and be honest to customers.

Always assume disaster can and will strike at the worst possible time. Better safe than sorry.

Prioritize people over processes. This means don't follow some dumb process if it makes everyone upset. Change the process.

Admit when you were wrong.

My understanding is the latter list are closer to how tenets are used (per the article and from some arms-length experiences). The three “some of Amazon’s” that you object to are LPs and are indeed not framed as tenets.

I’ve generally thought of tenets as smaller in scope; “on this team/project, our tenets are _____” They would keep overall company vision in mind, but would break it down more specifically to the local situation, helping to guide people to a common understanding of “we have a generally frugal culture/LP, but in this case, we will value speed over cost in this type of trade off”.

> The three “some of Amazon’s” that you object to are LPs and are indeed not framed as tenets.

They are indeed LPs but they were effectively framed as tenets everywhere possible. I'd be wary of this sort of Amazon culture creeping into other orgs.

> Admit when you were wrong.

Not this one. This one has no plausible opposite. It's just going to lead to weasel-y debates. You can't remind someone else to admit that they're wrong, because they don't think they're wrong.

+1 — (to paraphrase parent’s point, which I think people are misunderstanding…) this is great advice for people to follow in general, but not something you can bring up in a contentious meeting to help get to an agreement.

That's been my experience as well, but I think that's less due to management malice than it is a combination of a lack of understanding for what tenets are for (being useful decision facilitators rather than a blend proclamation of corporate mambo jumbo), and a lack of decisiveness. It's very amazonian to ask for both top quality, and shortest cost and delays at the same time. Since that is not physically achievable, resulting tenets are bland.

Note that the leadership principles are also a form of tenets, with their own internal contradictions that is waved away by a usual "it's a constructive tension".

> A good tenet is unambiguous in application and interpretation

Are tenet and non-functional requirement about the same thing?

Iiuc no, because a requirement is a characteristic of a piece of work. A tenet might guide you to stipulate a req.

That was a helpful link. Could you give an example of a tenet you find more convincing?

And if you like seeing a bunch of middle-aged mostly white dudes act like teenage mean girls over whether to add new tenets to their already too long list, after getting mildly intoxicated doing insipid team building exercises for low-end prizes, just attend one of their principal engineer summits and see just how full of you know what this rabbit hole really is.

Oh wait I think they stopped doing that after they "lowered the bar" for being a principal engineer there so much that most of them can no longer code. And that's how there was a sudden explosion of senior principal engineers...

Oh a downvote how quaint. So let's double down and talk about how when I was part of senior leadership there all we did was talk about who we were going to fire instead of what we were going to build. They were called "unregretted attritions" because people couldn't be honest about just randomly firing people who easily got past our ridiculous coding interviews and standards and no tenet could ever fix that.