"There's a big feature coming up. How many engineers do you need?" Someone asked me, and I had no idea.
At the time I was one of three engineers working at a startup with an intern we had hired to distribute some of the feature development work. This question startled me as I had never correlated the "size of the project" to the "number of engineers". Until then, we had grown very organically where team members mentioned that they were running out of bandwidth or overburdened with too many things and needed more people to come on the team.
I told them we had enough engineers to get started, and they disagreed. "The upcoming project is too big to be done by four people." This was startling to me because I didn't think we needed more people to "get started".
The entirety of project management today is a game of estimating the number of people you need for a project, how to manage expectations between them and ensuring work gets done on time (And also that not too many people are hired to slow things down - More on this later). To a degree, I disagree with the approach engineering organizations take in trying to estimate the number of engineers a project will require.
I feel this results from attempts to "commoditize" people where you want a framework to estimate the output one person will give you. And it's a hazardous thing to do.
I read an article recently where McKinsey claimed to be able to measure developer productivity. Needless to say, it wasn't received very well from the engineering community.
There's a difference between raw work and creative work
I've mentioned this in some of my previous posts, Engineering at its core, is a curious and creative field. As "architects" of today's and future codebases, you always have to balance things between what works today and what might become technical debt tomorrow.
At the same time, it takes immense effort to plan for the future, collaborate and solve problems that haven't already been solved. It's like finding a path through a forest that hasn't been explored before, there's no point in setting targets like "We'll cover 50% of the forest by day 2".
It's even more evident at smaller companies where the difference between good code and bad code could mean the difference between having 100 users vs. having the ability to suddenly take on a million users if the company goes viral (This is a double-edged sword that talented and creative engineers have to account for and balance, over-optimize and you're increasing complexity and taking away time while you're trying to survive. Under-optimize and you're digging a grave for when things go big).
There are also infinite ways of writing a simple solution, let alone a complex one and each engineer writes things based on their patterns, principles and knowledge, which means no two engineers will give you the same output.
That's simply an outcome of the work being extremely mind-driven and no two people's minds and thought process works the same way.
How do you quantify creative work?
Since our childhood, we've been subjected to "grades", and the coveted "A+" or "O" in our schools and colleges have always inculcated a sense of supremacy (Make no mistake, I was one of those people being driven by those grades and felt it make me superior to other people). The problem with grading, as countless articles and studies have pointed out before me, is their objectivity in nature.
Why do people hate standardized tests? Because they take away all the nuance of an individual and reduce them to a number at the end which becomes a standard for grading.
How do you quantify a subject like Art, Music or Philosophy into grades that are standardized across people who all perceive their craft differently? If the beauty is in the eyes of the beholder, doesn't it put a lot of bias into the process?
In Software Engineering, the core concepts are objective, but their applications are not. How you write code might be god-like to one person and garbage to another, and so would be the pace at which you write code.
How do you quantify a developer into the number of lines of code or number of features shipped? What one engineer delivers with 100 lines of code, another might do with 10,000 with a lot of complexity and take 10 other developer's productivity with them.
When working or starting on a project, there is only a limit to which one can predict the number of software engineers needed, after that, it's just an optimization problem of their abilities and their drive.
It is my opinion that:
The best engineering teams have grown from organic pipelines, where driven individuals come together to build and explore.
Any team that values/prices incoming talent more than existing talent is going to attract job hoppers who are there only for the money and consequently is going to over-hire.
I also don't mean to say that a single software engineer is capable of building the entirety of a system like Google, absolutely not, but to look at Google and say "They have fifty thousand engineers, we might also need the same number" is a comparison of two very different companies at very different times.
You never need too many engineers to get started, and there are never "too few engineers" on a project that's still in the works.
Looking back, Google was started by a few people and those people had an outsized impact on the future of the company, one could say the code they wrote defined the product for eternity and that's the beautiful part of it all, they didn't start with a problem statement and say "We need 25 engineers on this", it most likely grew as the work and scope of the problem grew.