4 ms·
Ask HN: Does hiring help?
My philosophy tends to be to do few things very well, but my co-founder (who has a controlling stake in the company) is hungry for features at the expense of quality. We continue to incur code debt with little regard for the consequences. We're positioned well for fundraising and have enough to hire now, so his answer is always that if we hire a large enough team, we'll be able to do all of the things he wants. Have you found this to be true? Does it actually get easier to build a product with a lot of independently valuable but largely-unrelated features when you hire a handful of hackers?
- maxdemarzi 16y agoDoes your software development plan consist of a bunch of random thoughts inside your co-founder's head? If so, sit down with him, plan it all out, estimate it and then consider hiring again. At least you'll have a better idea of where you are going.
- anonymouscto 16y agoWe tried that, but we've gone down the "agile" rabbithole pretty far -- we use tracker and adjust our near-term plans almost every day. And by we, I mostly mean he. In fact, a big issue is that features keep getting broken into parts and then only the first 70% of the work is done before he decides something else is The Most Important Thing. I've been tolerant of this, because I'm fairly pragmatic about the realities of early-stage startups, but it's gotten us to a point where we've developed several full startups worth of partial features. In theory, if we ever return to all of them, it'll be valuable, but I've started worrying that this is a strategic issue not an artifact of capacity constraint. I'm hoping I'll find someone who's been in this situation before who can advise.
- pbhjpbhj 16y ago>it's gotten us to a point where we've developed several full startups worth of partial features This is a negative character trait, IMO, one I share. I find it very difficult to finish things, I have enthusiasm to start and ideas a plenty but once the idea is fleshed out and the result can be seen I find I have no motivation to physically complete. Recognising this I know I need to work in a team with people who are good finishers to counter this negative aspect of how I work. Perhaps, your co-founder is like me, perhaps they haven't realised or don't think it matters or are simply hoping someone else will finish everything off for him.
- anonymouscto 16y agoI should also add we're not really in the earliest stages anymore -- we launched and have active users.
- jorgem 16y agoIt gets harder, because you have lots more overhead managing all those new people and their tasks. But in general, if you hire well, a team can do more than one person can.
- btilly 16y agoSoftware Estimation mentions some interesting research on team size versus calendar months to implement a project of fixed size. The upshot is that a team of 2 does work faster than a single person. A team of 3-4 works a bit faster still. A team of 5-7 works slightly faster. And then teams go slower! You get back to the same territory at around 20 developers, and after that productivity scales smoothly. (Albeit with horrible productivity per person.) This real-world data confirms and quantifies the observation made decades ago in The Mythical Man-Month that as a flat team grows, the overhead for communication grows as the square of the team size, while the effort available grows only linearly. There are techniques to organize teams in a more structured way to avoid this pitfall. But the drawback is that the necessary procedures, documentation, etc significantly reduce individual productivity. Oh, and to this add the fact that any time you hire more people you have to accept a temporary drop in productivity as that new person comes up to speed. I don't have a figure for programmers, but for general office work a month is standard. And I'm sure from anecdotal evidence that programming is worse. Much worse. On top of this, as I'm sure you know, the more code debt you have, the slower it becomes to implement new features, and the more risk you have when you do so. Plus you're setting the foundation for an environment that the best programmers simply will not wish to work in. What is the cost of that? There needs to be a balance. You can't try to create pristine code. But don't discount the costs of a poor foundation, and don't plan on being able to hire past its limitations. That way lies disaster.
- anonymouscto 16y agoAwesome answer, and very reassuring. Thanks! I'll target <= 6 for now, assuming I'm allowed by the team I hire to keep coding ;). I guess I'm less concerned with technical debt and more concerned with the product debt, which is a closely related concept I haven't heard discussed much. By product debt I mean partially-thought-through features rushed out the door that have been forgotten about. Even if the code is perfectly-factored, the product can come across to the end user as buggy because of product debt. I'm concerned that hiring hackers (even the very best hackers) will in fact exacerbate this problem, because we'll be able to push even more partial features out the door. At what point to you loop around in a startup and revisit/remove old features? Of course there are no hard and fast answers, and I appreciate the comment about balance. I'm trying to gather more perspectives and experience on this to better inform my position on this.
- 7402 16y agoHiring is not easy. Hiring the wrong person is hugely worse than not hiring anyone at all. The easiest hire is someone with whom you've already worked and who is known to be reliable. But once you've exhausted that pool, you're with the rest of us, dealing with the 1000s of resumes from people who don't bother to read the job requirements, the dozens whose experience has at least some vague partial overlap with what you're looking for, and the handful worth interviewing. So, "we'll just hire a large team" can be a solution, but before it's a solution, it will be a problem. Ironically, if the tasks to be done are _truly_ independent of each other, then it is easier to scale up development by hiring and working with multiple software developers: they don't have to work with each other, the code one writes has minimal interaction with the code someone else writes, and if someone isn't working out, (s)he can be fired and a replacement found without affecting the rest of the work. Or you can hire contractors for the independent tasks, that might be even easier. (I personally like systems that are more integrated - I think they have a better feel and higher value than a system that's just a collection of tools - but maybe what you're building fits well with a collection of separable tasks...)