Negative productivity for 3 months seems like a very conservative estimation. Most places I know have people commit to the code base pretty early. Quite often the onboarding process already has them commit small stuff. You might say...well they are only doing small things like fixing minor bugs but that's a minor bug a more experienced developer doesn't have to fix.
If you also assume that people strengthen their own understanding of a topic if they teach it new engineers don't drain resources if they ask other developers questions. They might make your other workers more productive in the long run.
At the very least I'd argue that the time other devs spend on onboarding isn't wasted 100%.
I suppose the dynamics change if you hire fairly bad people who make things worse with their early commits but that mostly means your hiring process (and most likely your code review or whatever measure you set up to prevent bad code) is broken.
> If you also assume that people strengthen their own understanding of a topic if they teach it new engineers don't drain resources
In practice I've found this assumption is only true if you have very small growth/turnover. I.e. If you hire a new engineer once every couple of years it's probably the case, but if you hire a new engineer every few months it isn't.
On average I'd say we have our senior engineers spend 40-50 hours total in the first month teaching/helping a new senior dev. Probably a similar number of hours in the second month, and then it drops to maybe 10 hours/month for the next year.
From what I have seen a new senior dev is around 10% of the productivity of a existing senior dev for the first month, 20% for the second, and rapidly reaching 80% by the end of a year.
So they are at 1 unit/hour of productivity for the first month and add 160 units of productivity for the month. However, senior devs, at a cost of 10 units/hr, have spent 40-50 hours helping them at a cost of 400-500 units of productivity.
Second month they add 320 units but cost another 400-500. By the third month they add maybe 450 units and only cost 100 units. And at this point they have managed to pretty much break even.
Of course if you assume training costs are not a real cost but rather beneficial for your existing senior devs then the new senior dev looks productive from the first month. But then you are really just talking past each other.
I'm guessing it depends on the company... at my last place (small startup so makes sense) I was expected to be productive the first week and actually got in trouble for looking at non-work stuff every now and then :p
Meanwhile some of my friends at large companies "train" for weeks. Pretty interesting difference.
If you also assume that people strengthen their own understanding of a topic if they teach it new engineers don't drain resources if they ask other developers questions. They might make your other workers more productive in the long run. At the very least I'd argue that the time other devs spend on onboarding isn't wasted 100%.
I suppose the dynamics change if you hire fairly bad people who make things worse with their early commits but that mostly means your hiring process (and most likely your code review or whatever measure you set up to prevent bad code) is broken.