101–110 of 136 posts
Does anyone know who else was involved in constructing this memo? "There will be no other form of interprocess communication allowed: no direct linking, no direct reads of another team’s data store, no shared-memory model, no back-doors whatsoever" Was Bezos deeply enough involved in Amazon's engineering to set those rules himself, or was the text of the memo influenced by a senior engineering group that he was worki…
Many people may not know this but Jeff Bezos clearly has a technical background as evidenced by this blurb from his Wikipedia entry: “graduated from Princeton University in 1986. He holds a degree in electrical engineering and computer science”. Of course he’s more known for his decision-making ability as an executive but he clearly has a solid understanding of computing fundamentals as his memo on Amazon S3 characte…
And his first office was literally for one desk. He clearly did some of the tech work himself.
Does anyone know who else was involved in constructing this memo? "There will be no other form of interprocess communication allowed: no direct linking, no direct reads of another team’s data store, no shared-memory model, no back-doors whatsoever" Was Bezos deeply enough involved in Amazon's engineering to set those rules himself, or was the text of the memo influenced by a senior engineering group that he was worki…
The "text of the memo" is really just the article's author not understanding the context of Steve Yegge's years-later retelling, from which that text comes. "His Big Mandate went something along these lines" (Yegge's words right before the quoted text) doesn't even imply there was a singular 'memo' involved, and definitely (and obviously) wasn't meant to say that the text was actually what Bezos wrote. So the footnot…
Here's a mirror of the original essay: https://gist.github.com/chitchcock/1281611
Ha, ha! You 150-odd ex-Amazon folks here will of course realize immediately that #7 was a little joke I threw in, because Bezos most definitely does not give a shit about your day.
As a current Amazon employee I can confirm this is no longer the case or only applies to such a select few pieces of software that it doesn't actually mean what you think it does. The amount of day to day stuff that is relied upon that runs on greasemonkey scripts and web scraping is insane. API's for a ton of things don't exist or are have heavy gatekeeping. (eg. contact x to get onboarded to our API and they just g…
No API, no bonus.
What followed was 18mths of people building enterprise messaging systems and "buses" of various types. Hundreds of pages of documentation on APIs was prepared and released.
I think 2 API's with maybe 40 methods actually went live.
There were no bonuses
Many people left
The people who stayed were unhappy
It never happened, everyone quietly forgot about it after 18 mnths.
The CIO stayed for another 3 or 4 years - he only left when a new CEO came in due to internal promotion. The new CEO used to run one of the P&L's/business units and hated the CIO with a passion.
So... it's not the API mandate that made the difference at Amazon.
As a current Amazon employee I can confirm this is no longer the case or only applies to such a select few pieces of software that it doesn't actually mean what you think it does. The amount of day to day stuff that is relied upon that runs on greasemonkey scripts and web scraping is insane. API's for a ton of things don't exist or are have heavy gatekeeping. (eg. contact x to get onboarded to our API and they just g…
And from all the comments on this post, it sounds like that’s a pretty rational course of action.
I am experiencing the polar opposite of this mandate. The systems in my organization are always built to require human touch-points. What's worse, our CTO mistakes these menial interactions as "teamwork" and "collaboration" when they are really just toil to compensate for the lack of platform-level thinking. I love how a CEO can put this so bluntly, upend everyones work for a couple of years and build a juggernaut because of it.
The idea runs parallel to one I have been championing throughout my career with SOAs which I call "self serve architecture". I want others in the organization to be able to pick up use my services to their benefit with zero input or help from me or my team. I tell my team to design the API as if it were GitHub's API.
Practically, that means - There are up-to-date and easy docs that cover what you need to know. - People can gain access on their own (via some existing workplace/team based credential). At most we have to add them to a list somewhere. - The system will protect itself and inform users against problematic use (quotas, throttling, and visibility into this) - You have visibility into who your users are and what they are doing such that you can assess value, learn from usage, and communicate to consumers when necessary.
Earlier quoted context omitted.
// And then we carved out an exception and made it so our places where we work are run as oppressive dictatorships... That's just a bunch of random words you're saying. Reality: we're building a company so we can create wealth and support our families and achieve something. We have a plan for doing it. If you're not following the plan and just sabotaging everything, you're doing exactly that - sabotaging. This is dif…
Famous last words before Boeing green lighting the faulty MCAS system (against engineering warnings) that killed multiple hundreds of people? Dictatorships are great when the leader is perfect. Problem is that they never are.
How far does this principle scale? I've heard of this strategy and thought "that's kinda cool." Amazon is obviously successful in its domain, so it would be easy to assume some causality. And yet, there's another big tech company, fruit symbol I think, that has played the long game of continually fine tuning the interaction points to make the integration of their parts more than the whole. They get credit for attenti…
It's sort of hard to compare these approaches, since it's not like Amazon and Apple only have 1 principle that they follow. I'll try to analyze them in a generic way. Disclaimer that I don't have experience in marketing or executive leadership. Apple's focus on design allows it to charge higher for its products and to build new high-margin products that people end up buying. It allows them to "scale" revenue by enter…
Except that for AWS, paying for the service(s) doesn't get you any support at all. So this idea about Amazon's behavior on its marketplace doesn't really map to AWS. Customers there have to choose to receive customer support, and pay for it separately.