[tristor]

> Ah sweet, even more problems to deal with then.

Whether or not adding more people is a problem greatly depends on the existing workload and where in the development cycle those folks are added. It also depends on the quality of the people. My comment was certainly not advocating for putting more meat into the grinder in favor of chasing the mythical man month.

My point was more that if you can magic your way into 1.5x the features for 3x the code, and it's "alright", you can probably add 1.5x to the top-line revenue over the same time frame. A 1.5x increase in top line revenue, especially at a larger organization, is absolutely massive and opens up many possibilities, including hiring significant additional headcount. The headcount comes in /after/ this magical moment, not prior to or in the midst of. And yes, if you have 3x more code, you'd probably want more people to help manage resolving technical debt, fixing bugs, and generally dealing with the ongoing keep-the-lights-on work that is inherent in that.

[HWR_14]

I'm amazed that as a PM you think features linearly drive revenue. This has not been my experience.

[tristor]

It greatly depends on what the "features" are. We're being intentionally very hand-wavy here. If you are adding features that are incremental for existing customer markets, then of course it's not going to drive linear revenue (it may not even drive /any/ additional revenue), but if those features open up new markets and use cases it can grow revenue beyond linear for effort. It all depends, and we're not being specific enough to say one way or the other since this is a contrived hypothetical with vague inputs.

[jashmatthews]

Engineering output doesn't even scale close to linearly, though. You _might_ grow revenue 1.5x but now you have 3x as much code/system and need 6-9x as the engineering headcount.

We probably just took a nice small/medium profitable business and completely fucked it.