[jrauser]

I've seen a couple companies try to adopt the Amazon-style narrative, and they both failed. I think the only way it can happen is if leadership demands it and is absolutely unrelenting. People will resist at first, but in time (years) they will come around. Some people may have to exit the organization and be replaced for this change to work. Amazon's organization circa 2004 was large and resilient enough to support this kind of change. A random startup might not be able to.

There are important norms in Amazon's culture that support this method. Time is always set aside at the beginning of the meeting for people to read the paper. They know that no one will read it before-hand, so they make time in the schedule. Also, the main document is at most six pages, but you can supply an endless number of appendices. This gives people a place to put supporting information that feels too important to cut entirely.

[maxxxxx]

" I think the only way it can happen is if leadership demands it and is absolutely unrelenting. "

I should add that the leadership should do it themselves and lead by example. When we introduced Agile the developers were the only ones who went to training while management continued as usual so our Agile quickly devolved into micromanagement. Same for code reviews. It's very important that the more experienced devs closely follow agreed-on coding styles.

[jrauser]

I agree completely. It's also important that the audience can actually tell the difference between good writing and poor writing and give useful feedback. You can't just ask people to write and hope for the best.

[maxxxxx]

That’s why leadership has to lead by example and not just tell people to write well.

[travisjungroth]

> They know that no one will read it before-hand, so they make time in the schedule.

That's an attitude of acceptance (is that the right word?) that I find inspiring.

I've felt that meetings would be more productive if the person presenting had to prepare some written material, and we all had to read it ahead of time. That way we have some shared base level of knowledge and the discussion can be done at a higher level.

Inevitably, some people don't read the doc. Some of them are honest and the presenter is nice and catches them up quickly. (If all of this information can be transferred in 1 minute, then why did I get a 5 page doc?). Or worse, people pretend they read it and didn't.

You could try to build some culture around "making it a requirement" (shaming them if they don't?) but, more often than not, the person who didn't read the materials is the biggest boss in the room, and enforcing requirements up a corporate org chart is a fool's errand.

So, someone at Amazon was like "fuck it", realizing that half the point of a meeting is just forcing people to work on something by putting them in a room together. And rather than complaining that that's kinda dumb (which it is) they just decided to increase the quality of work that happens in those meetings by setting aside 10 minute for reading.

[macintux]

> I think the only way it can happen is if leadership demands it and is absolutely unrelenting.

This seems like it would apply to any meaningful culture change. Too often "buy in" is passive at best.

I think I'll steal your "absolutely unrelenting" phrase for next time I need to have a conversation with management about a real change.

[sandGorgon]

typically startups work on chunks of work/product/features that have a radically shorter half-life than something that an Amazon works on. Do you think that could be a reason ?

Is this a method that brings agility only to large orgs ? If you had to do a startup, would you use the narrative method to develop a new feature/UI,etc ? Maybe you make it two pages rather than six...but still.