Do all the things like ++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatarSign Up
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple APILearn More
Amazon had a principle, "leaders are right, a lot." If you didn't come with data to back your decisions, you didn't stick around. I'm perfectly okay with that practice, largely eliminates tyranny of the majority.
On the new feature side, every task you work on started with a design document. That design document presented the case for and strategy of your implementation.
You would have the opportunity to get it vetted by an unaffiliated team of peers and principal engineers, which was time that could be used to refine the idea. You then present it to your team for general agreement on the design and spot checking. You'd run a few drafts and then get the buy in.
On the failure side, when an issue occurred, you were expected to be able to produce data showing the root cause analysis for that failure and propose a resolution. If you couldn't produce that data, and you had no idea (completely byzantine), you would likely be scrutinized as a team, and as an individual when performance review time came around.
In any case, you are required to present your case in a self-explanatory fashion to peers, who are also skilled engineers. It's tough but fair.