See, conversely I can think of semi-legitimate arguments arguing the opposite - which may explain why these patterns are so entrenched in the modern workplace.

> Do not promote based on tenure

Maybe not solely on tenure ala the government, but the people most likely to understand your company's particular problems and history are those who have been around for quite awhile.

Having someone who can say "We tried A last time and it didn't work because of reasons B,C, and D so what's changed?" in a position of (relative) power is invaluable to avoid repeating mistakes.

> Do not promote into people management roles based on individual contribution

Agreed that someone who doesn't want to be a manager shouldn't be one, but experienced ICs can make pretty ideal managers: They've been on enough projects to make (more) reasonable estimates, they know some of the potential blocks and complications, and they can likely stay a couple steps ahead of their team.

Sure, just because you're hung doesn't mean you have to do porn, but it's easy to see why companies would be eager and even pressure experienced ICs to become managers.

> Choose values that are specific to your company... Stick to them

Why? Shouldn't we re-evaluate our values as time goes on and we gain new information?

It's hard to imagine a contentious set of values (i.e. if your company values are "Don't be evil," then fine) that shouldn't be constantly re-evaluated as time goes on.

> If someone does not add something that no one else in the meeting does, remove them.

Ouch, this sounds like an insidious one that you could abuse heavily to do the committee thing that the OP rails against.

If you want something to go through: Invite only people who agree. If someone calls you on it and asks why you didn't invite more opposition voices, reply "I didn't think Alice had anything to add that Marie didn't, so I didn't invite her." or even just feign ignorance in the name of small meetings.

If you want something to get stuck in committee hell: Invite lots of people with different opinions that will never reach anything close to consensus. Don't invite any two people who agree, because "the other person isn't adding anything."

> Define success first, as objectively as possible. If you have to change the definition of success, it should be because what you're building will be fundamentally flawed without pivoting

That's suuuuper hard to do with anything that's even remotely considered a moonshot.

It also sounds like a good way to waste a shitload of time not actually doing any work. If the project is "upgrade our codebase from Ruby 1.9 to Ruby 2.3.1" then I can spend months dreaming up all sorts of useless bullshit metrics that define "success".

> Have one clear decision maker

Sounds like a formula for a shitty dictatorship. Even the CEO isn't the one clear decision maker.

> Effort can correlate with success

It often does.

> but certainly does not predict it

It often does.

> Writing code at 2am is not a priori more valuable than at 2pm

This kinda sounds like you're shaming people who have different circadian rhythms. I know plenty of night owls who do their best work at 2am and take it easy after lunch.

> Getting into Stanford likely means they thrived in high school. That may correlate with success, but certainly does not predict it.

It also might mean that they:

* Know how to manage their time effectively

* Are fairly mature and forward-thinking

* Are good with delayed gratification

* Are generally intelligent and capable of picking things up quickly

because certainly people who meet those criteria often find themselves at places like Stanford (with luck thrown in, certainly).