It depends on the size of the team.
On small teams you have to get your hands dirty and leadership is leading by example through strong problem solving and technical excellence.
On large teams, it's about leveraging expertise and building consensus.
On small teams you have to get your hands dirty and leadership is leading by example through strong problem solving and technical excellence.
On large teams, it's about leveraging expertise and building consensus.
Is it though? This is touted fairly often, but rarely often does it actually make effective teams or organizations.
It does make for great career advancement though! Which unfortunately being great at advancing your career doesn't make you a great engineering manager.
Why? Isn't the more important thing making the correct decision, and choosing the correct direction, and executing it correctly? You don't need large teams for that.
I have often found companies go through a cycle. There's a building the "people pyramid" cycle, then there is a distillation that happens when companies actually need to execute in a competitive environment.
No, but I also don't think larger teams are smarter than smaller teams. Quite the opposite in my experience.
I'm not sure how you took my message to mean "myself."
Most decisions are far from that. There are multiple different proposals, with different set of trade-offs. Choosing the right trade-offs requires broad input with many different perspectives. Which means a large number of people who have now presented something that's the right answer from their perspective - getting folks to see each others points, and agreeing on what the best outcome is requires a good chunk of consensus building.
> You don't need large teams for that.
You are literally replying to a post that said "the bigger the team is, the more important [...]", left out the first part about team size and then postulate that you don't need large teams?
Yes, consensus building is a much less important thing with a small tightly knit team of a few people. Once you're past a dozen or so people, it's quite important. Add a couple partner teams of the same size, and you'll fail without it. Spectacularly.
And some problems require 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.
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.
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.
The root of consensus is the word consent: it's about buy-in, not about unanimous agreement. It is customary to choose the direction with a small team -- but you still need the rest of the people to understand those decisions and why they were made. If people don't understand the context of the work they're doing, it's impossible for them to make the correct judgement calls for the tasks they're working on.
To get people in larger teams to work together efficiently, you need either consensus building or micro-management. I know which one I prefer.
you're the one who is mistaken here, consensus is absolutely about getting everyone to agree to something. If you're not doing that then it's bog standard communication of decisions made.
Which is important, but is not "building consensus". Lets be accurate in our wording.
There was a proposal for a new branching strategy some 3-4 months ago. The team is still debating things.
Not only that, but one of the developers specifically asked the manager to make a decision, he punted, insisting that the team should be the one making the decision.
What makes it worse is that the decisions themselves don't actually matter, we just need a decision made and then communication on what that decision is. Something I expected to happen over 1-2 weeks has taken almost half a year now.
it's nuts.
At my current company I've had money thrown at me hand over fist and a large part of the reason for that is I don't build consensus, I DO instead, which means every project I've been a part of has come in on-time with the features requested (with compromises of course). Apparently they've had a distinct inability to deliver much before I came along.
"Consensus building" is the same as saying politicking in meetings. That doesn't mean I haven't built relationships with people, but it goes without saying that no one in a larger company is a 1 man band.
But when people call out consensus building specifically they're not talking about the usual coordination that has to happen, they're talking about consensus being the predominant activity and you can't get shit down that way. It's ok if not everyone gets their say in things.
I think the opposite is true, it's about leading people, not getting everyone to compromise.
You share initial vision, take feedback, then share final vision and tell people "this is where we are going". Inevitably, some people will dislike it or not share in the vision. You meet with them and try to incorporate ideas that help achieve goals. If not, you help find them a new role that (hopefully) they'll enjoy.
IMO as a leader of any scale, your job is to mentor (or set up mentorship), set goals, layout reasons and help people feel pride in the accomplishment. It's not to hand hold or build consensus around the vision. Everything else is tactical and can be negotiated to an extent (timelines, implementations, etc), but should be largely delegated.
It is very unlikely that your ideas always get to be the best ideas. If you are ideas are consistently the best, probably your hiring bar is low.