As a potential employee, should I frown on "zerg hiring"?
In my job hunt, it's incredibly common for me to run into startups that have say 3 people and then have the CTO tell me "We just closed a round of funding, so we're looking to hire 3 or 4 more programmers." Experience has taught me that more often than not, these kinds of companies are trying to solve their problems by throwing more people at them (and overestimating how much that would help). I mean, I oftentimes get the impression that too few of the people at these companies have stopped to consider the ramifications of doubling their staff. But at the same time, startups oftentimes just have a lot of problems that need solving and the sheer quantity of companies that say this is overwhelming.
When I hear startups say things like this, should I take points away from them?
Hiring Venture Capital Employees
6 Answers
When I hear startups say things like this, should I take points away from them?No, but you should start thinking. Thinking about the startup's product, market and people. And start asking further questions to get more information.
The information you're looking for as a possible new employee isn't in the "hiring fast" part. It's in the:
- methods the company uses (development methodology fx)
- in the people (are they smart?)
- and especially in the "product/market fit" (do they know their customers needs, do they have data to validate their understanding, or do they seem like they'll get there soon?).
-
+1 I completely agree with Jesper. Do your due diligence to see if this is a good company or a wanna-be-good company. – John Sjölander 14 years ago
When I hear startups say things likeGenerally yes, although it depends. Personally I try to hire a new person after I'm happy with the last hire and his/her relationship with the team.
this, should I take points away from
them?
If you are hiring 2-3+ programmers at a time in the middle of a project, there is a big chance that you are doing it wrong. If you are doing this to speed up in the short term or hit a deadline you definitely doing it wrong, and you should go and read a copy of Mythical Man Month.
They can have legitimate reasons but "we got money, we need to grow quick" hires are generally bad idea.
-
My perspective, as a project manager on many software projects, is that for the *development project* it's almost never good to add many new people fast. Team dynamics, keeping up quality, training needs etc are real problems for the project. But for the *company* it's often good. If the project team members are good, the project development velocity still goes up in the short term, and the business benefits from this faster time-to-market. – Jesper Mortensen 14 years ago
-
Jesper have you read mythical man month or do you know the idea behind it? (about short term speed) I think that book with empirical data and lots of data on the web can found proves that this just doesn't work in the short term even when new people are good. Obviously there can be exceptions. – The Dictator 14 years ago
-
Yes, I have read almost everything Fred Brooks has written, including "The Mythical Man-Month". Brooks's law is that "adding manpower to a *late* software project makes it later" (my emphasis). In other words, Brook's law applies to projects which have already gone *bad*. Wikipedia actually has a nice counterpoint: http://en.wikipedia.org/wiki/Brooks%27s_law#Exceptions_and_possible_solutions – Jesper Mortensen 14 years ago
-
I see your point, to be honest unfortunately hiring is not one of my good skills hence I cannot comment much on good hires. A good hire can help a lot. – The Dictator 14 years ago
-
@Jesper - I think you're missing the forest for the trees a bit. The main point Brooks was trying to make was that more people != faster pace. – Jason 13 years ago
It's a problem if bottlenecks prevent you from using them effectively to complete large projects faster than you would have without them. You could have them tackle projects or address issues down the assembly line, but if that causes your startup to lose focus on clear goals, then reevaluate your decision.
"Zerg hiring" - What an apt analogy. The same is true for zerglings attacking a defensive wall in Starcraft. If the wall is too narrow (bottleneck), your zerg will fail to break through the wall and simply be picked off by marines on the other side.
Throwing people at a problem is a method as old as dirt. I've run operations in startups big and small. The bigger the company, the more likely they will be tossing some people to solve a problem. Rarely does it solve the issue. In my startup we don't hire in groups. We add one at a time. Once we have "indoctrinated" one employee in that functional area, only then do we think about hiring another one.
That said, if you like the people and you believe in the idea + execution, join them. Just make sure to value options and/or stock grants at ZERO. If monetary compensation and benefits meet what you think you are worth to this company (and what they think you are worth too) - join them. You might just get lucky.
Endemic in developer-driven startups is the attitude that says - we have some unsolved problems, so the next dev we hire can solve them. But if we keep doing what we're doing (only faster), we'll likely keep getting what we're getting (only worse).
You're right to be watching out for that. And at the same time, when things start working, this could be a sign of success.
So look at the team. What skills, expertises, contacts etc are needed, and who's covering what? Is that leaving gaps? What's being done about those?
I have a bias towards startups that tackle the commercial questions early, and build learning.
And I have a bias against startups where the founding team delay hiring into their own areas of weakness.
So I'd suggest getting the best view you can of the whole enterprise - why not ask to see the funding document that got them through that last round, so you can see how they've been pitching to investors.
In the end it will come down to some objective factors and a whole lot of subjective ones. If you're in the happy position of being able to choose between a range of opportunities, try and optimise on both axes.
I second Pierre's answer. This outfit may have plans for staffing that required funding, and they just closed a round. Who is the development team right now? Are the executives doing it until the engineering team can be built? Should the CEO and CFO/CMO/VP Marketing be coding along with the CTO that you spoke with? (It's a team of three, right?) Aren't there other duties required of them as the company grows, such that they need others to take over on the coding?
Pardon me if this hits a nerve but I spent 15 months in a 'temporary' engineering role until we closed a round of funding. That's because an investor became a no-show right after I joined ... it took a lot longer than a couple of months (how long we figured I would be on the development team) to find their replacement. That meant 15 months of development by day and doing my 'real job' evenings and weekends with whatever energy remaining, taking only one weekend per month for downtime.
