A common outcome of a hackathon is a demonstration to the engineers how much faster they can work when the don't have to deal with: other engineers, product managers, mandated company tools and company release processes. Not sure that is something most companies want to teach.
Agreed on having to have a good enough culture around people, processes, and tools.
On the other hand, if your problem is more about animosity between groups or individuals than broken processes and an unwillingness to have them change, then there's merit. Having engineers partner on non-critical projects with other engineers, product managers and other non-engineering staff can build up an understanding of their value and purpose, as well as just letting each to know the other as a person.
I like the partner idea. My only real gripe with hackathons is the transience. I don't like the "here work effectively for just one day, and then back to your silo" feeling of a transient event.
If you have them often enough, I think the transience factor isn't a problem. The tempo of Facebook hackathons seems pretty good to me - somewhere around 8-10 weeks or so between the last three.
Doing it once or twice a year in isolation is probably too infrequent to get lasting value - the positive value might have a total lifetime of about 4 months, so I'd suggest three or four times a year is a minimum - unless you have some other mechanisms that try to solve the same issues that hackathons do.
I think it would be better to try taking google's 20% philosophy and making it a "Hey, do you have an idea? No? Well, join this team for the hackathon!" Run it on four days a month in a row but during normal hours. This allows people to talk about it and not burn out.
I'm assuming that most teams do not program in their spare time for fun.
At Atlassian (where Bitbucket now lives), we do something called FedEx (who can ship a product the fastest.) It's a 2-day sprint, where you write up a Shipment Order detailing your crazy idea, giving other people a chance to help you out if they find it interesting. At the end of it, you present what you've done, and everyone votes for a winner.
It's always a lot of fun, and this, in addition to the 20% time we get, means we get to work on really cool things which sometimes even make it to the public.
I've experienced both short code sprints and hackathons, and I can recommend both.
At Yola we had a series of short code sprints to focus as much attention as possible on a particular project - no interruptions, specific outcomes, everyone fully present. Authoritative decisions came faster due to high-bandwidth communication between everyone with a stake (and that spilled over a bit after the sprints).
Meanwhile, hackathons at Facebook seem to continue the aims of bootcamp - promoting discovering more about people, code, and technologies that you won't usually interact with on your usual team/job. After the day (or two) recovering from hacking all night, everyone seems a little more energised.
At Q42, the company I work for, we have a yearly hackathon. We start Friday morning and then depending on individual circumstances work until anywhere from Friday night to Sunday night.
One of the resulting projects is http://www.soundmatch.me/ -- enter your Last.fm username and it will generate a Spotify playlist based on your music recommendations.
My company has a week long hackathon every 8 weeks. I'm new to the company and so have not participate in one yet. But in asking about them they are seen as very positive. Many hackathon ideas make it into the product (some have been absolute game changers) or improve company processes/tools, they make the developers happy, and give an outlet for where more interesting and/or controversial ideas can get a chance to air.
At Spotify, we have hackdays every sprint where we can do what we want as long as it is in some way related to Spotify, e.g. new client features, exploring new server thingamajigs or writing libspotify bindings for other languages. Finished hackday projects are demoed at the sprint demo. It happens that the product development team sees something they like, so hackday projects can turn in to real sprint stories.
At Twilio we've held internal hackathons with great results. We usually do them when we have a new product that we want to test internally before releasing to a slightly wider audience. This has helped the whole company get familiar with new products which leads to good feedback and better support once the product is live.
We at Skyscanner did a 24 hour hackathon a few months ago for our FlyScan product. It was quite hectic but did a great job highlighting the strengths and weaknesses of our release process from conception to release to marketing. It's definitely an enlightening experience.
I wish my company knew what a hack-a-thon is. That is what I get for working for a fortune whatever to big to fail blah blah...But I agree, side projects spawn innovation, it is an fantastic idea. It is a great way to build techie networking with each other, people who ordinarily struggle with that. big benefit for the corp on that I think.
