The best companies will do something like “20% time”, leaving one day a week or something to work on whatever, which is fantastic for stuff like this. Some of your employees almost certainly have the best ideas, if you just trust them with the space to prove them out.
Great way to get cool stuff like this without unpaid labour.
The place I work says they do this and will claim with a straight face that our sprints are budgeted to allow approximately 20% slack time.
This is of course not even remotely true in any practical sense. I have not received an explanation for how it’s even possible when sprint targets are intentionally set at slightly more than was done in the previous sprint, every sprint.
Haha, you’re not wrong. Ours tend to ebb and flow with whatever urgent priority upper management has set as well, and it tends to take slack alongside our tech debts. Our management is listening and getting better though, I’m hopeful that in a few years we truly will catch up on our tech debts and have all our managed products in good shape at once.
That said, even in that environment, we’ve had some pretty incredible 20% success stories. Some of my own experiments from when I’ve had the time have become proper released features, although I mostly use it to skip the bureaucracy and address my pet peeve tech debts, which isn’t the point but is nice to be able to do. And one of our major internal products, with a large dedicated team and roadmap, began as one developer’s 20% project a few years back.
The best companies will do something like “20% time”, leaving one day a week or something to work on whatever, which is fantastic for stuff like this. Some of your employees almost certainly have the best ideas, if you just trust them with the space to prove them out.
Great way to get cool stuff like this without unpaid labour.
The place I work says they do this and will claim with a straight face that our sprints are budgeted to allow approximately 20% slack time.
This is of course not even remotely true in any practical sense. I have not received an explanation for how it’s even possible when sprint targets are intentionally set at slightly more than was done in the previous sprint, every sprint.
Haha, you’re not wrong. Ours tend to ebb and flow with whatever urgent priority upper management has set as well, and it tends to take slack alongside our tech debts. Our management is listening and getting better though, I’m hopeful that in a few years we truly will catch up on our tech debts and have all our managed products in good shape at once.
That said, even in that environment, we’ve had some pretty incredible 20% success stories. Some of my own experiments from when I’ve had the time have become proper released features, although I mostly use it to skip the bureaucracy and address my pet peeve tech debts, which isn’t the point but is nice to be able to do. And one of our major internal products, with a large dedicated team and roadmap, began as one developer’s 20% project a few years back.
There is a saying (paraphrasing) that sadly is almost never implemented.
“Don’t tell your employees what to do, hire really smart people and listen to their ideas”