Actually, as a boss I frequently do look kindly on that. I'd much prefer to have that built into assumptions and explicit upfront.
Sometimes I may say "can we do that on our 1K user side project instead?" but I think that if you are managing developmental resources and you are not allowing them learn new things, you are not following a strategy that is likely to work out long term.
You adjust the schedule as required and don't do it for projects with tight deadlines.
The truth is if you don't ensure your developers career development is baked into your schedules then you get a combination of high turnover, unmotivated engineers, and engineers who learn on the clock "in secret" by making decisions that are best for them rather than best for the company.
All of these cause far more problems and are harder to account for than being upfront in the first place.
> and engineers who learn on the clock "in secret" by making decisions that are best for them rather than best for the company
Yes, and possibly not even consciously. Without that constant reminder of the pitfalls and learning curve of new technology, it's easy to convince yourself it's all upsides, or at the least undervalue the downsides.
Easy, you spec out doing it "conventionally" and pad with a reasonable first guess to do something unconventional.
Oh we need that in 2 weeks? And its about one weeks work the old fashioned way? Well try something else fun for a bit less than a week. Sometimes you win, sometimes you lose.
Sometimes you can do both in parallel. In the real world there's always wall clock time delays imposed by whatever. So when you're stuck waiting for whatever, learn as much as you can about XYZ till the main line is unblocked.
Sometimes I may say "can we do that on our 1K user side project instead?" but I think that if you are managing developmental resources and you are not allowing them learn new things, you are not following a strategy that is likely to work out long term.