Hackfests, also called hackathons or fedex days (because you “ship in a day”), build team cohesion and allow for exploration of new technologies and processes.
FusionAuth has been doing hackfests for a few years now. I wanted to document the what, why and how of them.
What is a hackfest?
Having spun up hackfests at three different companies, I have a firm idea in mind when I propose them. Briefly, it’s a day for people to work on whatever they want.
There are a few basics:
- they are internal; this is not an event for customers or any other external audience
- everyone should participate
- people’s schedules should be clear on the day
- it occurs at a fixed date and time
- there’s a schedule
- it happens “on the clock”, during normal working hours
As far as what people can choose to do with the time, there are two, and only two, rules:
- no scutwork. This is not a day to catch up on busywork that you’ve been putting off.
- at the end of the day, you have to present what you worked on. This audience typically includes your boss.
I find the second rule is a forcing function for the first. Most people don’t want to “present” a clean inbox to their bosses because they spent the entire day answering emails.
However, it makes sense to address some common concerns:
- How will we make time for this?
- Can non-technical folks participate?
Let’s take these one at a time.
Making time
If hackfests are important, you can make time. Be flexible.
At one place I worked at, the hackfest started an hour later in the day because customer service employees plowed through all the tickets they could at the beginning of the day. They then set up their vacation response. The same strategy can be used with a sales team.
A hackfest is similar to vacation. I always feel behind when I take vacation, but the change of scenery and the perspective make it valuable for my work productivity. (To say nothing of the fact that vacation makes life more enjoyable and that I don’t view everything through the lens of “will it make me productive”.)
Scheduling is also important. Make sure you pick a date and time weeks in advance. Don’t spring the idea of a day away from normal work on anyone. If possible, schedule it weeks away from internal and external deadlines, including the end of the quarter. Be flexible if issues pop up the day before which mean that some folks can’t attend. If someone can’t make it, they can’t. They may be able to attend the presentation and support the concept and the employees who participated.
In short, you can make time. I’ll discuss more on the value you and your team can get from a hackfest below.
Non-technical hacking
What about non-technical users? If you are trying to involve the entire company, as we do at FusionAuth, what on earth do sales, marketing and other non-technical folks do?
Isn’t the entire point of a hackfest the app or code improvements delivered?
I’ve participated in sales and marketing efforts. I can say with certainty that folks in those departments can participate in a hackfest. You just need to set expectations around the end product.
Above, I didn’t say “present your code” at the end of the hackfest, but rather “present what you worked on”. The work product of a hackfest can take a lot of different forms:
- Documents
- Mockups
- Reports
- Presentations
- Demos of a tool
Like any other discipline, sales and marketing have tools, processes and strategies which can be examined and improved. Here’s a list of possible hackfest projects for a sales or marketing team member:
- Trialing a new sales tool, either a separate application or a part of your CRM you haven’t fully explored.
- Kicking the tires on a new marketing channel. Been wondering about how to advertise on LinkedIn? How to build a podcast? What outreach to influencers looks like?
- Refining a rough sales process.
- Reviewing competitor’s messaging, website or tool to see how your solution compares.
- Building a plan to enter an entirely new market: “how can we sell into India? What channels do we need to sell to telcos?”
- Reading and summarizing reports about your industry and its future technical or social directions.
All of these feel like “hacking” to me; they’re about problem solving, unconventional thinking and stepping out of the grind for a bit.
That’s the main purpose of a hackfest.
Why run a hackfest?
The value of stepping out of the grind is one of the most important attributes of a hackfest. Having a dedicated day gives people permission to perform this valuable task regularly.
Hackfests are valuable for all employees. Executive and senior employees are always busy. A day where they can “follow their nose” and explore something new is rare. Frankly, a free hour can be rare some weeks. Hackfests, by their nature, carve out the time.
Junior team members, on the other hand, benefit less from the time and more from the permission. They see the business with fresher eyes and may bring recent experience with modern tools and processes.
But they may feel constrained by the unceasing flood of tickets and tasks that occupy their days. A free day means autonomy, stretching in new directions and gaining skills they might not otherwise get a chance to acquire, such as presenting to a group.
There are other benefits too. These include:
- Cross-team collaboration. Are you an engineer curious about devrel or sales? Are you a marketer who wants to work on a project with an engineer to learn what coding is like? A hackfest is an opportunity to work on such projects.
- Learning new skills. If you are a coder, you can practice your writing. If you work in devrel, you can work on a sales rollout. And everyone gets the chance to practice public speaking skills.
- It’s just plain fun to work on something you choose and show it off to your teammates.
- Explore non-urgent problems. If there’s an itch you’ve been meaning to scratch but never seem to have time to, a hackfest is a perfect day to work on it.
- Discover new efficiencies and capabilities. These often arise from hackfest efforts.
- An appreciation for other team members. Through watching presentations and interacting on teams, everyone will learn the concerns and experiences of their team members.
- Celebrating failures as part of exploration. Especially if senior people lean in, participate, and present a failure as a learning experience, a hackfest can build risk taking habits in a friendly environment.
How do you run a hackfest?
Here’s a step by step list of tasks for running a hackfest.
This assumes you are running one in a smaller organization or team, between five and thirty people. Larger organizations may take longer, or shard larger groups of people into smaller sets.
- First, get buy-in from leadership. This includes setting participation expectations for them and their team. If you don’t have this, it’ll be tough to run a hackfest.
- Write up an expectations and FAQ document, including information such as what you can expect at a hackfest, what the rules are, and the length of presentations. Make sure you make it clear that it’s not all about code delivery.
- Set a date and time, ideally a few months in the future. This makes it easier to get buy-in. Fridays are good, but make sure the chosen date doesn’t collide with deliverables or holidays. Reserve at least one whole day. Some teams do a few days or a week, but I don’t have experience with hackfests longer than a day.
- Add the event to everyone’s shared calendar. Include a link to the expectations and FAQ. Hackfests usually kick off at 9am and end around 5pm. Encourage people to start thinking about ideas.
- A week before the big day, send out an email reminder, with the expectations and FAQ link as well as any ideas you’ve come up with.
- At 8:30 on the date previously scheduled, set up if needed, and remind everyone that hackfest is happening that day.
- At 9am, kick off with a brief announcement about the schedule and goals, and answer any questions about the day.
- After that, build an idea list. People can add their ideas to a shared document or write them on a whiteboard.
- After ideas are shared, encourage people to talk about their ideas to others. The goal is to get folks excited about working together. Suggest people sign up for teams working on interesting ideas. After a few minutes, folks will hopefully coalesce into teams. If some people want to work on their own, that’s okay, but try to encourage team formation.
- After this, everyone goes off to work. If you are a virtual team, it can be nice to have a dedicated chat channel people can hang in.
- Determine when presentations should start. The exact time depends on how many teams you have. Each team should have at least five minutes to present and five minutes for questions. With five teams, and a desired end time of 5pm, presentations should start at 4:10 pm.
- About an hour before the presentations are set to begin, remind folks to sign up for a slot. I like to use a google spreadsheet.
- Five minutes before the presentations begin, remind everyone again. If in-person, shepherd everyone into the presentation room.
- Begin the presentations. Your job is to make sure to cut off anyone running over time, and to emcee the questions.
- After presentations, ask everyone to put their artifacts in a shared folder. People can also add any discovered, valuable tasks or features to the appropriate project management tool. Don’t expect to push anything directly into production from a hackfest.
- After presentations are done, ask for feedback about hackfest mechanics, clean up and pat yourself on the back.
In-person
If you are running an in-person hackfest, there’s additional planning and work:
- You’ll need quiet space for the teams to work together.
- Determine where the company is buying lunch from and how you’ll place and pick up the order.
- Presentations should be in a room with a screen and projector.
- Drinks (alcoholic or non-alcoholic or both) make the presentations a bit more fun.
- You’ll want to break for lunch around, well, lunchtime.
Remote considerations
If you are running a hackfest for remote employees across multiple time zones, make sure you consider the impact of the day on their lives.
Reach out to people outside of the core time zone and ask what their tolerance is for starting later or earlier in order to overlap and work collaboratively.
For example, if your core time zone is USA/Denver, but you have employees in the Pacific and Eastern time zones, ask if the people in the east can work later and if the folks in the Pacific area can start earlier.
You can also schedule people based on their time zone. In the above example, someone in the Eastern time zone would present in the beginning, to minimize the impact on their day.
Non-employees
I’ve participated in hackfests with contractors. I like to invite them, but make it clear that there’s no expectation of attendance, in contrast to employees.
Work product examples
Here are some examples of hackfest projects that we’ve done here at FusionAuth:
- Building an SEO focused topical minisite
- Exploring GraalJS
- Prototyping applying kickstart documents to existing FusionAuth instances
- Implementing an auth solution on Azure AD B2C
- Examining sales tools like Apollo IQ
- Adding hashes to our software downloads page
- Recording a commercial to explore video editing solutions
- A screenshot automation tool
Some of these were exploratory, others are currently under active development, and some are deployed in production.
What if someone doesn’t want to participate?
If you’ve properly cleared the decks for people, limited the amount of time a hackfest is going to take, and have highlighted the fun, teamwork and autonomy, hopefully everyone will want to participate.
What if someone has no desire to participate?
Don’t make them. Don’t force anyone to participate.
Doing so is counter to the idea of a hackfest. You don’t know why they are not interested. They might be stressed about a work task, they might have had a bad experience in the past, they might not enjoy the idea of presenting in front of their peers.
Invite them to the presentations, but make it clear that hackfests are an optional event and if it doesn’t work for them this time, they’d be welcome in the future.
Summing up
Hackfests are a low cost way to let people on your team explore ideas, work together and learn new skills.
I hope you consider running an internal hackfest for your company or department.
