They are pretty insightful. Particularly this one:

> 3. Bias towards action. Ship. You can edit a bad page, but you can’t edit a blank one.

I have my own version of this where I tell people that no amount of good advice can help you make a blank page look better. You need to have some published work before you can benefit from any advice.

I liked that one, too, but for an additional reason.

Typing that first character on the page reveals the problems you didn't even know existed. You don't have a keyboard. You do, but it's not plugged in, and you have to move an unexpectedly heavy bookcase to reach the USB port. You need to learn Dvorak. You don't have page-creation privileges and need to open a ticket that will take a week to resolve. You can create the page, but nobody else is able to read it because their machines aren't allowed to install the version of the PageReader™ plugin that your page requires (and you'd need a VP exception to downgrade your PageGenerator™ toolchain to their version). And so on.

All these are silent schedule killers that reveal themselves only once you've shipped one full development (and deployment!) cycle. And as ridiculous as these example problems seem, they're not far from reality at a place as big and intricate as Google.

I wish Google would be biased a little more towards quality and performance. Their user-facing products tend to be full of jank, although Gmail is quite good to be fair.

In general I think the "ship fast and break things" mentality assumes a false dilemma, as if the alternative to shipping broken software is to not ship at all. If thats the mentality no wonder software sucks today. I'd rather teams shipped working, correct, and performant software even if it meant delaying additional features or shipping a constrained version of their vision. The minimalism of the software would probably end up being a net benefit instead of stuffing it full of half baked features anyways.

The problem is I've worked at at least 5 companies that professed a strong "bias for action" and it nearly always meant working nights and weekends to ship broken things that ultimately hurt the user and then moving on to the next big leadership project to do the same thing again, never looking back. The exception of course would be when leadership finds it's broken in 5 months and complains about poor engineering practices and asking why engineers can never get things right.

I've heard all the truisms listed in that post in my 14+ years at many companies that aren't Google and in all cases there's a major gap between the ideal and the reality.

This entire list reads to me as "I got paid 10s of millions of dollars to drink the Kool Aid, and I must say, the Kool Aid tastes great!"

Disagree. There's levels to this. Not all bad pages are better than blank ones. Ones that harms user data or worst is worst than blank pages.

The problem with this approach is that once you've started with a "bad" draft and enough people have signed on, you're locked in to its trajectory and can't do foundational rewrites even if you were within the feasible window. It'll just end up being a bad product overall.

Starting right is important.

Sounds a bit like a rephrasing of the old "it is better to ask forgiveness than to ask permission".

I’m a big fan of Amazon’s leadership principles. One of them is bias for action. I worked at AWS for a few years and I’d be in a meeting and someone would say bias for action and we’d all know what we needed to do.

Same. Mine is: existence is the most important feature.

It is good only if the whole team believes it.

If the team mates have a different mindset, they see it as half baked or hacky. And if there is ever some bad feedback, they just use it as a "I told you so" and throw you under the bus.