I work in a company which does hackatons without any goals. You can do something cool on the product, or you can attend some course or if you really want, you can keep working on features (there's no pressure to do so). It's essentially just 4 weeks in a year when you're free to choose your work. There are also some small prizes which for me do nothing, but for somebody might bring extra motivation.
I think it's great in non-obvious ways. People often choose to improve product in small ways which would be otherwise hard to justify to prioritize in the product backlog. Small quality of life (either user or developer) improvements, platforms improvements, refactorings, optimizations of the CI jobs etc.
Hackatons are often marketed as something for the employees to enjoy, perhaps for the organization to be healthy, to produce new ideas, but I also see tremendous value for the long term technical health of the product as well.
I get what you're saying. Hackatons shouldn't be time when technical debt is being paid, and fortunately in my organizations it's not the case. We do get enough time to refactor etc. but it's still kind of hassle to go through that process of defining the task, bringing this up, putting it on the product backlog, discussing it and only then doing it.
Hackaton inverts this and gets rid of all the process - do whatever you want without talking to anybody and only if it works out, we can discuss it, merge it etc.
I think it's great in non-obvious ways. People often choose to improve product in small ways which would be otherwise hard to justify to prioritize in the product backlog. Small quality of life (either user or developer) improvements, platforms improvements, refactorings, optimizations of the CI jobs etc.
Hackatons are often marketed as something for the employees to enjoy, perhaps for the organization to be healthy, to produce new ideas, but I also see tremendous value for the long term technical health of the product as well.