Democracy at Work Is Bad

Should the team have a demo at the end of a sprint? Should we have a daily standup or even have a stand up at all? Is it the senior or principal engineer’s role to motivate people who aren’t delivering?

The problem was: Amazon expects a lot. It’s not the most human friendly coporate culture in the first place. Now you mix in people who interview well but can’t walk the walk. So manager after manager, you see an SDM earning $400K a year who outsources decision making, especially tough decisions, writing road maps, and he or she wants the “team” to make every decision - even when the team is not performing or doesn’t understand the vision to begin with.

This type of manager would “lead” their team to a disaster, and often times, some poor SDE 1 or SDE 2 would somehow get thrown under the bus.

That being said, there's value in ICs contributing to a roadmap, if they're trusted. Being a 'leaf node' and closer to customers can make people more in touch with problems and solutions a business could implement (at least, that's the theory). But in most organisations the customer and business problems are well-removed from engineers / designers leading to lower quality insights from those people; but in either scenario it always seems like management is out-of-touch.

I as an IC would personally be fine having a bit of 'skin in the game' if the risk:reward ratio was more favourable, but that does seem rare at modern corporates.

What I mean, remember Conway rule, that software created by organization got imprinted image of organization structure.

Imagine, making Linux distribution with totally flat structure - this is obvious that kernel must have much higher priority than LibreOffice, or Odoo, or PHP, even considering, that PHP devs number is much larger than kernel team.

What structure mean for priorities - if kernel will be bend for PHP best, we will have kernel, which good handle PHP specifics, but all other tasks will be handled worse, and this is not what customers want now (they want mostly good display speed, second priority good network/disks speed which will obviously demand PHP dev).

So normal modern software development org must have federal organization structure, with departments dedicated to important things, and high level voting should be very limited, and departments should not have rights to interfere to other departments doing.

BTW same problems exists in joint-stock companies - there also much better if major shareholder(s) are also interested in most priority parts of software, and when software architecture changed, also should change structure of ownership.

Consensus, mean, two things: 1. Things differentiated by level of abstraction - less abstract usually subordinated to lower level. For example, question who will wash windows usually on lowest levels of organization, and for this corresponding department got budget, access grants and resources. 2. Things of highest level of abstraction only accepted if nobody vote against them (in large organizations counter-vote may require more than one vote, for example in joint-stock companies usual rule, for veto need 10%+1 votes).

It is very common to delegate organizational work. But it only works if the manager exercises their competence to check and guide the work.