Two weeks ago, we celebrated yet another great Hackday judging event at LinkedIn. For the April 15th Hackday, over 50 employees submitted a combined total of 29 projects for the contest. We saw incredible product concepts, developer tool innovations, internal corporate applications, and even a few ideas so good they’ll likely ship as products in the coming weeks. At this point, it feels like every Hackday is better than the one before it.
Most of the engineers who work at LinkedIn have also worked at other great technology companies, and in the past year there has been an incredible swell of feedback from new and old employees alike that LinkedIn Hackdays have become something truly special. Creating the LinkedIn Hackday has been an iterative, experimental process, so I thought it might be useful to capture some of the details on how LinkedIn Hackdays work, and more importantly, why we run them the way we do.
It’s funny to think about it now, but the original LinkedIn Hackday had an unlikely catalyst. On December 14th, 2007 approximately 100+ LinkedIn employees moved into a brand new space on the first floor of 2029 Stierlin Court. It was the first time that LinkedIn had designed a workspace from the ground-up, and it included a large number of LCD TV’s on the wall. The goal was to immerse the product and engineering teams in real-time feedback and data from the LinkedIn community, and each of the TV’s was driven by small Mac Mini.
The “Pure Energy” contest kicked off right before Christmas, with a goal of using some of the seasonal downtime to produce cool, internal applications that we could effectively “hang on the wall”. The prize? Brand new iPhones for the winning team. The only rules? The application had to reflect real usage of LinkedIn, it had to run continuously (so it could be left up 24×7), it had to be designed for display on a 720P monitor (1366×768), and it had to run in either Safari or as a Mac OS X screensaver.
Five projects were submitted, and several became staples of our decoration in 2029 for all of 2008. (Coincidentally, December 2007 was also the first time we pull the live Twitter search for “LinkedIn” up on the wall for everyone in Product & Engineering to see at all times through the day). The winner of the “Pure Energy” contest, NewIn, still lives on in an upgraded form, in both the LinkedIn reception lobby as well as on LinkedIn Labs.
We’ve learned a lot in the past four years about how to make Hackdays successful at LinkedIn, but at a high level, there are ten key ingredients that make LinkedIn Hackdays work.
- For Engineers, By Engineers. This may be obvious, but Hackdays are highly optimized events around engineering culture. There may be a lot of opinions about what would be considered “fun” or “useful”, but for Hackdays, in the end, is designed for engineers. This effects everything from the timing, the prizes, the venue and the communication around it.
- Spirit of Exploration. Hackdays have an opinionated culture, and one of those opinions is that with software it is infinitely better to learn by actually doing, rather than reading / talking. It’s part of why people go into engineering in the first place. This is one of the reasons that we celebrate hacks that are purely to learn a new language, environment, algorithm, or architecture. This is not just a fun thing to do – it’s an incredibly effective way to expose talented engineers to new technology, and more importantly, set a tone that we should always be learning.
- Independence. Hackdays are a day of true self-determination. At LinkedIn, we believe that small, cross-functional teams build the best software. Teams do a great job looking at product metrics, customer requests, and innovative ideas from the team, and then prioritizing what to work on. Hackdays are a day to break free, and work on whatever you personally find interesting. If you have a great idea, this is the day to help make it a reality.
- Company-wide Event. Hackdays may be optimized for engineers, but everyone is invited and included. Some of the best Hackday projects come from an engineer, web developer and product manager working together. We’ve had entries from almost every function, and from multiple offices. Most importantly, hackday projects are shared with the entire company on the intranet, and Hackday Judging is an event that everyone is encouraged to attend. Winners are announced to the whole company. It’s incredibly important to cement hackdays as a part of company culture, rather than something that lives within the engineering function.
- Executive Attention. Believe it or not, it wasn’t until 2010 that we stumbled upon an obvious truth. Executive attention matters. Actions speak louder than words, and when executives make a point to attend, reference, and discuss hackday projects, it makes a huge difference to the entire organization. At every LinkedIn Hackday Judging event, you’ll now find at least three of LinkedIn’s senior executives on the panel.
- It’s a Contest, but Loosely Enforced. LinkedIn Hackdays are thrown on Fridays, with the submission date for projects due at 9am on the following Monday. Teams are limited to five people, and projects have to be presented live for Hackday Judging to be considered for prizes. Having rules for hackdays is a delicate balance – if you are too weak on enforcement, people lose faith in “the system”, and you’ll get discontent from the people who follow them. However, too tight on the rules, and you break the independent spirit of the event.
- Hackday Judging, or Hackday Idol? Hackday Judging has morphed over the years into an “American Idol” like event. The hackdays themselves are relatively independent and quiet. It’s the judging that is the main event. Teams are given two minutes to demo their hacks. The panel of celebrity judges is given a minute to asks questions, and then it’s on to the next project. We serve lots of food & drink, and try to make it a fun event. (Typically, I fill the role of Ryan Seacrest. Yes, I know that my mom would be proud.) There is a lot of laughing, a lot of cheering, and we try to make a good time for everyone. Most people who attend leave the event incredibly inspired by what their co-workers come up with. More importantly, once people attend, they tend to come back again (or better yet, enter their own projects.) We now have everyone in the company help judge by tweeting out their favorite projects with the project name and a #inday hashtag.
- Lots of Prizes. We give prizes to every team that present a project at Hackday, typically a reasonably sized Apple gift card. Winning teams get larger dollar amounts. We have 5-6 regular categories, so there are always multiple winners. Some times, we give additional prizes for stand out projects, but that’s up to the judges. The reason for gift cards is logistics – giving out iPhones, iPods, Flip cameras, etc sounds like a great idea, but too often you get winners who already have one, or who don’t want one. (The Apple bias bugs some people, but the truth is we’ve experimented with a wide variety of prizes, and people on average seem to really prefer these. We did notice that our college interns preferred Amazon gift certificates, however…)
- Path to Production. Some hackday projects are so impressive, there is a natural desire to shout “SHIP IT!” In reality, however, hackday projects can vary significantly in their technical and product appropriateness for a large scale production environment. At LinkedIn, we’ve now found multiple ways for people to share their hacks. Some projects live on hosted on internal machines, and are used by employees. Some of our best internal tools have come from previous hackdays. Other projects are built over the LinkedIn Platform, and can be launched to end users on LinkedIn Labs. Some projects are actually extensions of our production codebase, and actually become live site features. (Example: The 2010 Year In Review email began as a Hackday Winner, as did the inline YouTube expansion in the LinkedIn feed.)
- Learn & Iterate. We are big believers in continuous improvement, and I don’t think there has been a single hackday where we didn’t add some improvements. We constantly try out new things, and stick with the ones that work, and shed the ones that don’t. The pace of innovation has dramatically quickened as hackdays became more frequent, and as the company has grown larger.
Common Issues & Questions
It would be impossible to capture all the common questions about hackdays here, but I thought it was worthwhile to capture a few persistent questions that we’ve debated in our process of creating LinkedIn Hackdays.
- I have a great hackday idea – how do I find engineers to build it?
This is a really well meaning question, typically from non-technical employees, who are excited about the idea of hackday, but lack the means to implement it themselves. The most reliable way that people solve this problem is by talking about their idea broadly, and effectively evangelizing the idea of forming a hackday team around it. In the past, we’ve tried throwing pre-hackday mixers, usually around a technical topic, to help people find teams, but it’s had at best mixed success.
- I want people to build features for XYZ – how do we get people to do it?
This question typically comes from a product manager, executive, or business owner who sees hackdays as a massive amount of valuable potential engineering effort for their area. In this case, the short answer is that hackdays are about independence – the more you try to get people to do what you want, the more energy (and innovation) you sap from the system. That being said, we’ve seen quite a bit of success where teams sponsor “special prizes” for a specific category on a given hackday. Example: an iPad 2 for the project voted best “developer tool”. This approach seems to provide the best balance of independence and incentive to generate the desired result.
- How do we get all hackday projects live to site?
This question assumes that the goal of all hackday projects should be to go live to site. However, given the education and innovation mandate of hackday, there are actually quite a few projects that are not intended to go live to site, and that’s not a bad thing. The way that we’ve handled this question is by providing both a variety of mechanisms for projects to “go live”, as well as prize categories for projects that are not based on being a “shippable” feature.
- How can we spare a day from our priorities for a Hackday?
In some ways, this is the big leap of faith. For anyone who has attended any of the recent LinkedIn Hackdays, it’s hard to imagine this being considered seriously at this point. However, at small companies, there are always more things to do than time to do them. The decision to have hackdays is largely based on the belief that giving people time to learn by doing and to pursue independent ideas will pay off in multiples, not just in the projects themselves, but in the attitude and energy it brings to the company overall. In some ways, you can view it as an HR benefit that also has a measurable positive impact on culture, internal technology, and product innovation.
- How do we get people to participate?
The ten ingredients above reflect the system that we’ve devised, but the truth is it took time for hackdays to build into a culture fixture at LinkedIn. In 2008, we threw two hackdays, and had about half a dozen teams enter each. However, as the company celebrated each hackday winner, we saw demand pick up. We had a major breakthrough in participation when we launched the “Hackday Idol” format for judging in early 2010, and since then we’ve seen incredible growth in the number of participants and projects.
I’ve got a few new innovations ready to roll out for the May 20th hackday. Not to spoil the surprise, but we’ll be rolling out for the first time a new “Hackday Masters” designation and category, for people who have won at least three hackdays.
Hopefully, the Wizard of In will smile down on us, and as always reward those who seek to bend code to their will.
13 thoughts on “Why LinkedIn Hackdays Work”
Awesome post. Hackdays are definitely one of my favorite things about working at LinkedIn.
BTW, one point you missed: hackdays are how you get employees to dream of and build stuff for your company all night and all weekend. And love it.
I also believe the frequent public judging allows people to see the quality bar for a winning project, so they know what they need to exceed if they want to win.
Of course, not all hackday projects are about releasing production quality projects, but I think this has helped focus people on both what types of projects to build, but the level of thought and polish needed.
Great advice for anyone running a hackday. I’m a big fan of empowering engineers and think your tip #1 is the most crutial (as well as getting us Product people out of the way).
One other tip we’ve found that engineers love for Plaxo Hackdays (we call them Haxo’s) is having lots of Stan’s Donuts on hand in the morning (http://bit.ly/iuwq93). Mmm…
Point #9 – Path to Production – could / should be a whole topic in and of itself. Yahoo has had a pretty successful hackday for quite a few years if judged by most of your points, but it gets very complicated once you have to figure out which product to pair a great hack with. Should this be a feature in Mail? Something on Flickr? Maybe part of Yahoo News?
How do you guys determine what should be yanked from your existing roadmap in order to slot in a new feature idea from a hack day? How do you help the team that owns the receiving product area avoid churn (or even feel jilted?).
My experience so far leads me to feel like hack days are really just trying to fix an engineering culture that could use a bit more flexibility on a day-to-day basis. But I don’t mean that to sound critical, obviously it’s complex either way.
Phil, avoiding the fate of Yahoo hackdays has been an active topic of discussion over the last year. I can understand how that experience can leave you skeptical.
If you re-read the points above, however, what you’ll see is that they apply in the most flexible and quick-to-ship cultures. Software is something you best learn by doing, but not everyone wants to take a big veer in their day-to-day to explore new areas. Hackdays are not just license to explore, but also literally an incentive to. A lot of engineers find time on nights and weekends to explore new environments, and that’s commendable. Hackdays can take that activity out of the shadows, publicize it, reward it, and thus encourage it. Facebook, for example, prides itself on the speed at which new engineers can push code to production. However, they still celebrate Hackdays for this reason.
Some of the issues you are raising assume that the point of Hackdays is some sort of alternative product prioritization process. That’s one of the warnings I include in my post above. Hackdays are contests, meant for inspiration and education. They should not be treated as a substitute for HR programs like Google’s 20% time, or other techniques to give engineers more access to “passion based” assignment.
Pingback: Links: 5-10-2011 | Aaron Johnson
Pingback: The LinkedIn Blog » Blog Archive 10 Ways to make Hackdays Work «
Pingback: 10 Ways to make Hackdays Work | CITI Recruitment - IT Jobs - IT Recruitment
You guys do a great job at LinkedIn and I think all companies should have Hackdays!
A couple of innovations I would like to see on LinkedIn are a built-in referral mechanism similar to Referralkey and the ability to add attachments into the email system.
I like the idea of Referralkey but don’t see the need for another professional network if LinkedIn had this functionality. It is also a bit limiting that I can’t send email attachments to my LinkedIn contacts.
Hope this is of interest!
Pingback: ‘Twas The Night Before Hackday « Psychohistory
Pingback: Welcome Adam Nash! « Greylock VC
Pingback: Joining Greylock « Psychohistory
Pingback: Greylock Hackfest: Talent & Inspiration « Greylock VC
Comments are closed.