Live data from Hacker News

The 2002 mandate for internal communication systems at Amazon

sametab.com

31–40 of 187 posts

Re: The 2002 mandate for internal communication systems at Amazon

#31
post #9

Earlier quoted context omitted.

I strongly believe that Steve was exaggerating for effect here. In my 17 years at Amazon I have never seen or heard of a threat of this nature. The overall intent of the email was to tell teams to decouple, decentralize, and to own their own destinies.

Yes, IIRC in Steve's original blog post he points out that that particular point was not in Bezos' email and notes he put it in there for dramatic effect.

What I remember from Yegge’s blog post was that the “have a nice day” bullet point was a joke; Bezos doesn’t spend much time worrying about how each employee’s day is going.

Re: The 2002 mandate for internal communication systems at Amazon

#32
post #6

> 6) Anyone who doesn’t do this will be fired. So I've never worked at a company over 150 people. Is this... a normal thing for an email? Maybe I'm just one of those softies but an email with that line would throw me off my day and cause a serious hit to my morale and confidence of working there.

This is Yegge's over-the-top style of humor, none of these are actual quotes from the email.

To be fair, "do this or you're fired" is just assumed of every request at Amazon, because they follow through on it often.

Re: The 2002 mandate for internal communication systems at Amazon

#33
post #10

Earlier quoted context omitted.

Some methods I've commonly seen in Enterprise Duct Tape: Screen scrape the other service and do data exchange via a Selenium script. Directly interact with the other service's database. CSV files and nightly batch jobs.

This is one of the niches where (S)FTP and batch processing is still alive and kicking.

Yeah, SFTP + CSV file is still the standard for enterprise software.

The problem is that these kinds of things have to be built to the lowest common denominator, which is usually the customer anyway. The customer in enterprise software is usually not a tech company they typically have outdated IT policies and less skilled developers than a pure tech company would have. Even if the developers are capable of doing something like interacting with a queue they also need to be supported by a technology organization which can deal with that type of interaction.

Some times you get lucky and someone in the past has pushed for that kind of modernization. Or your project really won't work without a more advanced interaction model and you have someone in the organization willing to go to bat for tech enhancement.

But otherwise the default is "Control-M job to consume/produce a CSV file from/onto an SFTP"

Re: The 2002 mandate for internal communication systems at Amazon

#34
post #2

Yegge's post was very interesting reading, and I took similar learnings away from it. I was at Amazon at the time, however, and there were things that certainly weren't true any more: >3) 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. The only communication allowed is via service inte…

Was Amazon the first major company to invest fully in SOA for internal use like this?

Re: The 2002 mandate for internal communication systems at Amazon

#35

> 6) Anyone who doesn’t do this will be fired. So I've never worked at a company over 150 people. Is this... a normal thing for an email? Maybe I'm just one of those softies but an email with that line would throw me off my day and cause a serious hit to my morale and confidence of working there.

Not in such language, but it's absolutely the case that large companies can have emails come from the very top that include language like "subject to disciplinary action and possible termination" for failing to do some required thing. Sometimes it's phrased as "corrective action up to and including termination." It's normal in that this is something that shouldn't throw one for a loop (and in my experience the calls to action have more to do with regulation compliance than any how-to-do-your-job mandate) but it's not very frequent. Such language is usually limited to appearing in an employee handbook or conduct guide that everyone is supposed to have read and agreed to which spells out repercussions for behavior against such or other misconduct.

Re: The 2002 mandate for internal communication systems at Amazon

#36
post #23

I wish the actual body of the email was available and published. I’ve only read Yegge’s account of the note and didn’t see it in any of Bezos’ books. I suppose it’s nice that the email, or really any amazon emails, has not been leaked.

I only could find his autobiography. What other books does he have / wrote?

Re: The 2002 mandate for internal communication systems at Amazon

#38

> 6) Anyone who doesn’t do this will be fired. So I've never worked at a company over 150 people. Is this... a normal thing for an email? Maybe I'm just one of those softies but an email with that line would throw me off my day and cause a serious hit to my morale and confidence of working there.

It is quite usual in global consulting organizations. The format is always like this: "X has happened, is happening or may happen. X is bad. Any Y or Z actions identified in our workforce related to X will be subject of termination of employment."

Re: The 2002 mandate for internal communication systems at Amazon

#39

I worked at an organization that had a similar declaration. Here's how it played out: 1. Everyone is super excited for other teams to share their data 2. Everyone wants an exception from sharing their own data because it's too hard or too sensitive to share. 3. Eventually everything gets shared, but it takes 3-4 times longer than it really should.

[deleted]

Re: The 2002 mandate for internal communication systems at Amazon

#40
> While the third point makes all the difference in the world, what Amazon really did get right that Google didn’t was an internal communication system designed to make all the rest possible.

> Having teams acting like individual APIs and interacting with one another through interfaces over the network was the catalyst of a series of consequent actions that eventually made possible the realization of AWS in a way that couldn’t have been possible otherwise.

Google has worked this way since time immemorial. That’s what protocol buffers are for: to create services and pass data between them using well defined interfaces.

Post reply on HN