5 ms·

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 vers

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.

fuzzythinker 9mo ago
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.
rapidfl 9mo ago
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.
- sowbug 9mo ago
  If your self-esteem is sufficiently resilient, you can exploit the same human tendencies behind Cunningham's Law (the best way to get the right answer on the internet is not to ask a question; it's to post the wrong answer). Check your crappy end-to-end proof of concept into the team repository, and your teammates will be so horrified and outraged that they'll fix it faster than any sprint could have planned.
  - rapidfl 9mo ago
    yeah there are ways, but is it good for your career lol Also the one person who has to review it before checking in needs to be resilient too
- songodongo 9mo ago
  Bad feedback can be more helpful than good and is often the only type of feedback a product gets. And you may not have received that feedback if you didn’t ship. It’s better to get that information early.
  - rapidfl 9mo ago
    I personally agree with the premise to ship early, with some rough edges, etc. But teammates may not be supportive. You need the whole team to have that mindset/culture.
sowbug 9mo ago
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.
llmslave2 9mo ago
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.
- samiv 9mo ago
  I wish people who ship crappy software didn't ship it and would let someone else ship something better instead. It really sucks when the first mover / incumbent is some crappy half assed solution. But unfortunately we live in a world where quality is largely irrelevant and other USPs are more important. For example these little weekend projects that become successful despite their distinct lack of quality Linux kernel - free Unix. JavaScript - scripting in browser Python - sane "perl" Today on GitHub alone you can probably find 100 more featured and higher quality projects than any of these were when they launched but nobody cares.
  - ryandrake 9mo ago
    While we're wishing for things that are never going to happen, I wish users would stop adopting crappy half-assed first-mover software, causing them to gain momentum and become the defacto/dominant solution.
    - samiv 9mo ago
      That's the other side of the value added coin. Users sometimes find value even in the half assed software. Someone was once talking about the "solving the right problem wrong" vs "solving the wrong problem right".
      - 9mo ago
tjwebbnorfolk 9mo ago
Same. Mine is: existence is the most important feature.
crystal_revenge 9mo ago
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!"
astrojams 9mo ago
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.
dartharva 9mo ago
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.
eikenberry 9mo ago
Sounds a bit like a rephrasing of the old "it is better to ask forgiveness than to ask permission".

fuzzythinker 9mo ago

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.

rapidfl 9mo ago

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.

sowbug 9mo ago
If your self-esteem is sufficiently resilient, you can exploit the same human tendencies behind Cunningham's Law (the best way to get the right answer on the internet is not to ask a question; it's to post the wrong answer). Check your crappy end-to-end proof of concept into the team repository, and your teammates will be so horrified and outraged that they'll fix it faster than any sprint could have planned.
- rapidfl 9mo ago
  yeah there are ways, but is it good for your career lol Also the one person who has to review it before checking in needs to be resilient too
songodongo 9mo ago
Bad feedback can be more helpful than good and is often the only type of feedback a product gets. And you may not have received that feedback if you didn’t ship. It’s better to get that information early.
- rapidfl 9mo ago
  I personally agree with the premise to ship early, with some rough edges, etc. But teammates may not be supportive. You need the whole team to have that mindset/culture.

sowbug 9mo ago

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.

llmslave2 9mo ago

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.

samiv 9mo ago
I wish people who ship crappy software didn't ship it and would let someone else ship something better instead. It really sucks when the first mover / incumbent is some crappy half assed solution. But unfortunately we live in a world where quality is largely irrelevant and other USPs are more important. For example these little weekend projects that become successful despite their distinct lack of quality Linux kernel - free Unix. JavaScript - scripting in browser Python - sane "perl" Today on GitHub alone you can probably find 100 more featured and higher quality projects than any of these were when they launched but nobody cares.
- ryandrake 9mo ago
  While we're wishing for things that are never going to happen, I wish users would stop adopting crappy half-assed first-mover software, causing them to gain momentum and become the defacto/dominant solution.
  - samiv 9mo ago
    That's the other side of the value added coin. Users sometimes find value even in the half assed software. Someone was once talking about the "solving the right problem wrong" vs "solving the wrong problem right".
    - 9mo ago

tjwebbnorfolk 9mo ago

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

crystal_revenge 9mo ago

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!"

astrojams 9mo ago

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.

dartharva 9mo ago

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.

eikenberry 9mo ago

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