Furthermore, in some cases I think it is a great idea.
I've seen to many "interesting" technlogies being crammed into projects just because devs needed them on the CV.
If people can test out everything they want without having to claim that they need it on a project it can save ourselves a lot more than 15% on any project or product that lives for more than a year or two.
At work we are still sometimes suffering because of how cool Redux once was.
No, but I might prefer a plumber from a company that pays their plumbers to train and work on the latest 'tech' in their down time. I might even be willing to pay a 15% premium, especially if I'm looking for a 'cutting edge' solution for my bathroom.
You really don’t want a "cutting edge" solution for your bathroom. You want a boring one that you will be able to maintain by yourself for years with standard tools from the store.
And I truly think it’s the same for your codebase.
Given the choice, I would absolutely go for the plumber that spends some of their time practising difficult plumbing jobs and doesn't just do routine cases. Even if they are 15 % more expensive. I honestly believe they'll be much better equipped to handle anomalies, should they occur.
Looking at it further, I would ignore a 15% difference if it came with any enticing reasonable. Any small difference in quality is certain to return me much more than 15%.
I wouldn't expect to have professional development overtly included in a short term contract, either. I'd expect a much higher hourly rate to pay for it though, amongst other things.
I'd expect if the plumber worked for a plumbing company they'd probably invest some time and money into skills growth, and pay for it out of the money they charge you.
Because it makes sense. Learning should be part of most professions. People attend conferences and workshops. Companies pay for travel, accommodation, participation and other expenses. Giving your employees time to learn something new with a side project is incredibly cost-effective in comparison to external learning opportunities.
Besides the things others have said, some major innovations started as corporate-sponsored pet projects. Gmail is a commonly cited example. I believe many of 3Ms successes (including post-its) also belong to that category.
While I absolutely support the idea that employment should include professional development, let's be wary: first, of survivorship bias, and second, of perversion of incentives.
How many side projects, at Google, and then at other places, didn't turn into runaway successes?
More importantly, if you tell management "you should let us work on side projects because it could make the company millions of dollars", watch how fast "did you use your 15% time to invent anything that is marketable this week" becomes a part of your performance review, and your "side project for personal development" becomes "PMs breathing down your neck asking for progress and status".
Oh, no, I would be surprised if more than one in every 100 pet projects as much as break even.
But that's the point. Your run-of-the-mill incremental improvements with a fairly certain ROI of 0.5 % or 2 % is what you spend almost all week doing. Then you have a few hours of doing whatever you want. And a very small fraction of those things will have a ROI of thousands of percent. And you won't know when it happens until it's happened.
If you apply the other principles described in the blog post, you will probably save more than 15% of your time so if you spend 15% of your time learning everyone is still better off in the end.
If you do not offer the possibility to learn to your employees they will try to learn while working on a project which is where problems come from : speculative programming or hype-driven-development.
Speculative engineering often gets a bad wrap, mostly because people mis-characterize it. For example: a feature is written up for a product that talks to X third party system. The same organization has other teams using X system. Wouldn't it be wise to abstract that integration work out to allow other teams to use it instead of building their own, especially in the agile world where teams are highly autonomous? This is often characterized as speculative engineering, when in fact it's engineering for scale.
It begs the question, what is your boss more likely to say YES to? 15% raise, or 15% self learning time? (For me it is NO to both, but the self learning time is probably more realistic)
When I introduce this, my criterion is that whatever pet projects people work on during work hours should make the lives of people at the company better, if successful.
Beyond that, I don't care if it's cancer research, self-driving bicycles, an email client someone else at the company uses, or a script to automate some commonly performed actual work task.