That applies to problems that can be solved by 1 person.
But huge majority of the problems require whole teams of people to solve, especially in the commercial world. Senior engineer who can 2x team of 10 people is better than a single engineer who is 10x himself.
Honestly I don't know if there's any case where a team of 10 on a project would outperform a (good) engineer or two.
Half of the 10 engineers will do nothing, the other half will have different views of what to develop and will face off one another heading into opposite directions.
Usual development work in a company does not require 10+ workers and couldn't be split over 10 workers even if you had that many.
Some interesting problems require more than 8-10 people, no matter how insanely great they are. I work at a highly interdisciplinary biotech startup. My instrument SW team is eight guys, the tools-for-scientists team four, mathematicians are about five, etc.; then you have a bunch of physicists, chemists, biochemists, etc. etc. I'd rather suffer the problems of a large company than work on a more pure software problem.
> However, as soon as you have a slightly larger team, these decisions will usually not be made by one single person. If you have a large project with dozens or hundreds of engineers, you'll have dedicated teams for some of these tasks, making their own desicions.
Another interpretation of this is that 10x programmers get dragged down when they have to work on teams that are too large or don't grant autonomy.
Multiple software engineers working to solve the same problem in isolation will arrive at different solutions. Some may work better than others, but that's irrelevant; what's important is that these different engineers will have all achieved a complete understanding of the problem and its solution, and when they collaborate on a new, more complex problem that builds on what they've already done, they each bring their own unique perspective to the table.
This is why side projects are so absolutely crucial to a software engineer's mastery of his or her craft; by working through a problem alone, the engineer not only gets a better understanding of the problem, but is also able to apply diversity of thought to a team's problem set.
Yeah. According to the Mythical Man Month (or was it Peopleware?), when someone gives you 100 software engineers to do a project, what are you supposed to do? Set up 10 teams of 10 people, don't tell them about each other and make them all do the same project.
The argument is that you are going to be better off doing that and picking the best one at the end, than you are running the project with 100 engineers in the first place.
If you have top-notch engineers, it takes very few of them to manage very complex problems. At that level there is also an advantage to having few people: it reduces the communication and coordination overhead. Assuming the general rule that a great engineer is 100x as productive as a typical engineer, reducing overhead is 100x as effective as well.
It doesn't work this way for all situations. In the case being described here, the data is huge and the algorithms are complex, but it sounds like the software itself is probably rather small. That makes it suitable for a small team of very good engineers. In situations where the software is huge but none of it is particularly complex, you're better off with a large team of average engineers. (Of course, if you put very good engineers into that position, they will probably re-factor your software down to something more manageable.)
My point isn't about throwing manpower at a problem, it's about diminishing returns. The notion that if you put two people on a problem they will be able to solve it twice as fast is a logical fallacy. That's a fact, not a platitude. That being said, if you put 100 people on the problem, you may be able to solve it quickly, but even then you will eventually reach a point where adding more people does not add any more benefit. That's what I wish more non-technical folks understood.
Three is probably a good number, if they are decent engineers. Throwing more people at a problem has diminishing results very, very quickly in software, unless the project can be broken down into mostly independent teams. Even then integrating the work into something coherent can easily be more challenging and time consuming than just having a tiny skilled team own the project soup to nuts.
This may have been true back in the times of the applications (when I was also a developer), but, speaking from 40+ years of experience myself. I agree, most significant projects need more than one person. There may be outliers, but back then it was the normal, now it's not.
Also consider games, back then one or two guys could do a game, now all but the outliers are done by large teams.
Unfortunately I'm pretty sure he's right. Large orgs doing projects with 30-40 engineers... don't get anything done. But people somehow have the belief that 30-40 engineers is what it takes, whereas 3-4 ones would get it done faster, although with a lot less of the details polished off. But in a quarter of the time.
There's just too many people in tech, because tech needs too many people. Once we have better tools to reduce complexity and allow teams to be much much smaller, many of these problems will vanish, because a engineering team will consist of 1-3 wizard engineers who control all aspects of the tech. We simply do not need to have teams as big as they are, for what we're ultimately doing.
Yes, more engineers working on the same problem = slower time to actually releasing anything. Unless you can find a way to divide the task into parts that don't impede the others, adding more people will make things take longer time.
Team / interpersonal communication overhead, planning overhead, and dealing with less skilled members of the team can easily make 4 engineers roughly as productive as one very skilled engineer, just at 4-5x the cost once you include the increase in product/project management required by multiple people. We tolerate this generally because eg upskilling peers is important to scale a company, but pre-PMF it's a huge advantage to have just the one outstanding engineer.
It depends on the situation. There are cases where a senior engineer outperforms three or more warm bodies and cases where two warm bodies would be much more preferable, it depends on the content of that job.
And I have witnessed a case where simply removing "one senior engineer who has worked on this particular software for years and therefore knows his way around it" was a key part of finally getting that software on track, as he was providing literally negative value.
Also, relying on particular single people who "know their way around" some code is an organizational smell - if you have such a dependency then that's a management problem/business risk that needs to be fixed. You do need shared ownership and people who can replace each other, and (except for the very short term) a better engineer will be more productive than a worse engineer who has been stuck on maintaining that code for years.
If you put two people on the exact same problem, sure. But, software systems are made up of LOTS of problems, a large amount of which can be solved in parallel.
That's why it's a platitude. It gets bantered about by developers as an explanation about why we just can't go any faster (hiring people is a lot of work after all), but in reality they CAN go faster with more people working on the various problems that make up the system.
Of course there is a point of diminishing return. The management costs come into play. The communication inefficiencies. The process issues. Those can be largely solved with good leadership, however.
It's a rule that is only true when it's true, which doesn't make it that useful to me. I've grown teams on multiple occasions from one or two developers to much larger numbers. While productivity may not have increased linearly, it sure made the projects go much faster. Hell I'd argue that doubling a two person team more than doubled productivity just because the external drags tends to be more distributed which reduces the context switching developers are having to do.
I think there are many more shades of grey that inexperienced founders just don't recognize when they're bound to that idea.
The author is exactly backwards on the issue of team scaling.
Even if I grant his premise that 10x engineers don't exist (which I don't), let's just presume 2x engineers exist. So is a team of four 2x engineers equivalent to a team of 8 1x engineers? No -- the smaller team is vastly more effective, because of the n^2 communication problem.
This is why strong individual performers are so valuable. Give me my top pick of 10 developers, and we will ship the product at least as fast as any organization of any size. Bigger organizations can still work on more separate projects in parallel, but they won't out-develop us on any particular one.
But huge majority of the problems require whole teams of people to solve, especially in the commercial world. Senior engineer who can 2x team of 10 people is better than a single engineer who is 10x himself.
reply