3 ms·

>left out the first part about team size and then postulate that you don't need large teams? If you have to undergo an activity so large you think that "consen

>left out the first part about team size and then postulate that you don't need large teams? If you have to undergo an activity so large you think that "consensus" building is first and foremost the most important thing then that team is now a detriment to the overall prosperity of the organization. That is to say, consensus building is an organic part of smaller teams, not a notable activity. If you need leadership or specific people to do this, the team is too large for any real "serious" productive effort. And I don't mean technically. And before people say "well maybe you just haven't...", no I guarantee you have, but more importantly I am far from the first person to say this. Many people including those we would consider "fathers" of our industry have stated this ad nauseam.

PH95VuimJjqBqy 3y ago
agree wholeheartedly. The biggest problem with the post you responded to is this idea that decisions can't be revisited, that they're set in stone. Or that they're all equal. Neither is true. _sometimes_ a decision needs to take longer because the ramifications are broad and recovering from a poor decision is difficult. this is rare, but does happen. More importantly, if your company is struggling in this manner on a regular basis, you're working in a top-down authoritarian manner and are not giving the teams themselves (the boots on the ground, aka the executors) enough autonomy. There are solutions to these problems but they generally involve not enjoying the authoritarian nature of both company hierarchies and software in general.
groby_b 3y ago
Please, do show me a place that runs, say, a 100+ person team where there isn't a significant amount of consensus building. And if you believe all useful activity can be done by less than 100 people, you might want to acquaint yourself with actual team sizes for most major software. Yes, small and valuable teams exist, but a lot of stuff requires large teams. Even a simple chat app, praised for being extremely lean, ran on a 35 person team (WhatsApp). Linux is running at ~1000 contributors, with a lot of coordination via lkml and side channels. It has a management structure, via Linus + lieutenants. OpenAI has ~500 folks. (I'm happy to hear counterexamples here - just because I don't know about them doesn't mean they don't exist) Communication & consensus overhead is real. Hierarchical structures evolve repeatedly for exactly that reason. The attempts at non-hierarchy are merely hiding that complexity - either via large losses (the OSS model where PRs just get thrown away if the maintainers don't agree, and that work is 'lost') or via informal groups. (Good reading: The Tyranny of Structurelessness) (BTW: Would love to see quotes from those "fathers") What you _can_ achieve in small teams is technical breakthroughs, and first working models. There's a reason skunkworks efforts exist. And even there, it's worth noting that the original SkunkWorks effort (XP-80) succeeded because it had a very strong manager, not because they just had a bunch of people in a room. What you can't do with a small team is productionize for a large audience from there.

PH95VuimJjqBqy 3y ago

agree wholeheartedly. The biggest problem with the post you responded to is this idea that decisions can't be revisited, that they're set in stone. Or that they're all equal. Neither is true. _sometimes_ a decision needs to take longer because the ramifications are broad and recovering from a poor decision is difficult. this is rare, but does happen. More importantly, if your company is struggling in this manner on a regular basis, you're working in a top-down authoritarian manner and are not giving the teams themselves (the boots on the ground, aka the executors) enough autonomy. There are solutions to these problems but they generally involve not enjoying the authoritarian nature of both company hierarchies and software in general.

groby_b 3y ago

Please, do show me a place that runs, say, a 100+ person team where there isn't a significant amount of consensus building. And if you believe all useful activity can be done by less than 100 people, you might want to acquaint yourself with actual team sizes for most major software. Yes, small and valuable teams exist, but a lot of stuff requires large teams. Even a simple chat app, praised for being extremely lean, ran on a 35 person team (WhatsApp). Linux is running at ~1000 contributors, with a lot of coordination via lkml and side channels. It has a management structure, via Linus + lieutenants. OpenAI has ~500 folks. (I'm happy to hear counterexamples here - just because I don't know about them doesn't mean they don't exist) Communication & consensus overhead is real. Hierarchical structures evolve repeatedly for exactly that reason. The attempts at non-hierarchy are merely hiding that complexity - either via large losses (the OSS model where PRs just get thrown away if the maintainers don't agree, and that work is 'lost') or via informal groups. (Good reading: The Tyranny of Structurelessness) (BTW: Would love to see quotes from those "fathers") What you _can_ achieve in small teams is technical breakthroughs, and first working models. There's a reason skunkworks efforts exist. And even there, it's worth noting that the original SkunkWorks effort (XP-80) succeeded because it had a very strong manager, not because they just had a bunch of people in a room. What you can't do with a small team is productionize for a large audience from there.