[gausswho]

I don't like to look askance at alumni of particular employers, but I have had one too many a poor experience from ex-Amazon hired into leadership roles. The above matches my experience.

For me, the worst casualty as various lackeys followed arrival (also ex-Amazon) was the choking out of candidness. Second worst was turning the company into a document factory.

[mrbonner]

You have me at “document factory “. Writing a doc is good to convey your intentions. Revising a doc for the fucking 20 times because of unsettled sentences, paragraphs are a waste of time.

[q7xvh97o2pDhNrh]

Do you mind saying more about "the choking out of candidness"?

I know they've got their "leadership principles" kool-aid [1] at the interview stage, but I always assumed that a seriously profitable and hard-working company (which they seem to be) wouldn't waste time mincing words.

[1]: https://www.aboutamazon.com/about-us/leadership-principles

[gausswho]

With the incoming cabal there were many meetings of reading doxuments and solicitations for feedback. But it became apparent veey quickly that the confused muddle of documents were their wishes. Being candid, by say raising feasibility concerns, would only get you a fiesty rebuttal followed by being ostracized from future decision making.

What was a very social confident team at peace with asking vulnerable questions turned into a team where people took care to avoid trouble. The cabal preceding reading-meetings with gibberish, and after reading time received feedback of tense silence.

[q7xvh97o2pDhNrh]

That sounds rather grim; I'm sorry you had to go through that.

It sounds like it just underscores the reality that, no matter what process a team uses, there's no substitute for psychological safety.

[pottertheotter]

Can you elaborate on the document factory part?

[chef-steph]

Not OP, but have worked in a similar situation run by ex-Amazon leadership. Project leaders focus mainly on writing docs on their "ideas". These docs are then spread around to other project and org leaders. Most of their time is spent reading or commenting on these and planning meetings for feedback. Typically the last people to read these documents are engineers who then have to make sense of and build whatever was laid out in the documents. Many times after all this is done the project is then shelved or engineering shuts it down so it was a waste of time.

Project managers can then point to these documents as promotion material and take credit for "leadership".

Obviously I'm being a bit harsh here and that in no way represents the average - but it is something I've seen too often.

[wilsynet]

Both Amazon and Google have document writing cultures. If you want to propose an idea, you write a doc about it.

The value of a doc writing culture is that writing things down encourages rigor and thoughtfulness. Docs can be widely distributed, and you can read it, think about it, and add comments. Exchanging ideas can be asynchronous rather than meeting oriented.

But also it can all get a bit carried away (because these artifacts become an important component to promotion).

I work at Google, which is a doc culture. But I worked most of my career at startups where we never wrote anything down. Overall, I prefer doc cultures. But yes, left to it’s own devices it can seem like you are working at a doc factory.

[user_named]

I worked at a startup without any documentation. The cto knew everything, because he'd been in every meeting and made every decision. Everyone else became somewhat helpless due to lack of information.

[jeffbee]

Doc culture is better than the alternative. 95% of docs get thrown away because half-way through writing it you realize it cannot work. In the absence of the design doc, you will instead hand-wave your way through the design phase and realize the mistake after several people have wasted time actually implementing it. It is a very, very good thing to know whether your idea solves or does not solve the given problem, at the earliest opportunity.

[danjac]

There's a happy medium. Even a startup can do with some well-maintained READMEs. But the problem with startups is churn, which makes for docs that rapidly go out of date, and the only thing worse than no docs is out of date docs that lead you down the wrong path.