

Ask HN: Does hiring help? - anonymouscto

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?
======
btilly
_Software 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
Awesome 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
Hiring 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...)

------
maxdemarzi
Does 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
We 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
>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.

------
jorgem
It 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.

