Hacker News new | past | comments | ask | show | jobs | submit login

Two-way doors always bothered me, because reality isn't black and white. Most decisions I've seen given fall in the grey space. Invariably deciding whether a problem was a 2 or 1 way door was politicized. Managers always argued for tech tech debt "because we could walk it back later so it's a 2-way door". Of course when such decisions backfired, it was always the engineer that "didn't Have Backbone" or "failed To Be Right A Lot", with leadership concluding that was a 1-way door and now everyone just had to "Disagree And Commit" instead of paying back the debt.

Over my 9 years there, I saw every LP used towards politics or malicious compliance. Even reading them now, it all comes across as "just so the right thing"... written in a way that sounds like there is some deeper truth.




Totally agree on the abuse of LPs in general. Abuse of "disagree and commit" is a pet peeve.

Two-way doors are often misunderstood imo. It's not about the decision it's about the cost of reversal. If you have Option A and B, then sometimes the cost of implementing A + validating A + business cost of A being wrong + reverting A + implementing B < bikeshedding the A-vs-B decision in advance.

Everything's grey. The principle is about realizing which side of the inequality it's probably on.


To combine with previous "techdebt" mentioned. I dislike tech debt, as term because it causes false analogy. Prefer friction, which is how much harder/longer development becomes as compared to your original estimate.

While observing friction you get better idea and can consider actual cost of techdebt. There are many situation where you may care less for techdebt, you have a dev script that looks bad, but you likely just gonna replace it fully when time is right.

Yet friction is painful as it slows you. Debt analogy perhaps becomes more viable now, with high interest rates. This is what tech debt is, its not debt on 0% interest rates, its debt in high interest rate scenario, everything slows down.


Amazon's "leadership" principles are related to leadership in the same way a jellyfish is related to Smuckers.

That's not saying they don't serve a purpose or don't influence the culture, just that their title is a bit Orwellian and "Be Right A Lot" is a pretty shitty principle for any culture.

I think my main criticism of Amazon would be this point:

> Some companies rely on metrics which they do not quite understand. Metrics are proxies for their in-world representations, not actual factual truth indicators.

Not just in the literal sense, though I do think Amazon labors over metrics more than any other company I know, but in the corollary sense that process a means to achieve a goal, not the goal itself.

So many times with Amazon and management that comes from there they really only know the Amazon process without understanding why any of those things were done in the first place. They're the proverbial cook cutting the end off a roast because their grandmother's pan was too small 50 years ago.

This happens at all software companies but Amazon seems to be all about process over people and generate managers who know the process even if they don't know why it is the way it is.


> "Be Right A Lot" is a pretty shitty principle for any culture.

strongly disagree.

The difference between competence and incompetence is how often you're righter than wronger (it's a spectrum of course).

mindset is one of the most difficult things to fix, but the correct mindset is going to allow you to be righter more often and that is how you rise above those who are not.

_anyone_ can be right occasionally in the same way that anyone can hit a series of keys on a piano correctly. But a master pianist is going to be able to do it much more often.


I think what you're getting at is that principles (and systems) are only as good as the individuals tasked to operate them. I too saw a lot of the same of what you mention during my time there -- people parroting the surface level jargon and really abusing the concept without ever cutting to the core of what the concept should have lead them to if they faithfully executed on it. Unfortunately, I don't know if there's a good way to solve for this as a company scales to Amazon's size.


Amazons leadership principles are great actually, I still have a card sized copy with me years later.

Thing is, as all more culture realted things, they are a two-edged sword and up for interpretation. And that allows to use them in a malicious way (this cultural aspect, PIPs and the preformance review cycles, is really bad, I agree). A ls always, just how those principles are applied depends a lot on leadership, some are great other not. Amazon's problem is, the normal bell curve of leadership talent gets tranformed into a bath tub curve by their hirong and promotion standards: You either have great people at the top end or bad ones at the other wothout any mediocre ones balancing and cushioning this.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: