Democracy at Work Is Bad
11 comments
I saw this quite a bit in recent years at Amazon. As leadership became laser obsessed with growth (at any cost), we increasingly hired managers who could talk a big game: those that were extremely well prepared for interviews. When it came time to manage their teams, they’d leave decision making to a team vote.
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.
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.
Shackling accountability is no way to run a team.
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.
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.
This is not matter of democracy, more this is matter of correct organizational structure.
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.
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.
BTW in federal structures exists thing named consensus, and in democracy also used many systems different from simple rule 1 person = 1 vote - quorum, quotes.
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).
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).
[deleted]
This approach doesn't have any relationship to democracy that I can see.
It is very common to delegate organizational work. But it only works if the manager exercises their competence to check and guide the work.
It is very common to delegate organizational work. But it only works if the manager exercises their competence to check and guide the work.
Related to democracy, because the decisions are delegated to team vote, even though team is not experts in making those decisions.
The team voted, but they don't have real authority here. Could they vote to not make the decision? Could they vote to depose the manager and replace them with another teammate?
Your real problem is that the manager might be incompetent.
Your real problem is that the manager might be incompetent.
I agree, a business should have a roadmap from management not the other way around
No argument from me...
However, a business org with roles is different from the political voters without roles. Organization roles have an accountability for the decisions made and they are expected to be experts in their domain. A voter in a democracy is not expected to be accountable for his decisions (there are no wrong votes) nor is expected to be expert in choosing a leader. A democracy is not meant for making decisions at work in an organizational context.