Hack Weeks: Building for Fun and Profit

We devoted a week to technical experimentation at Lattice — and here's what we learned.
Michael Neth
 — 
Software Engineer

We devoted a week to technical experimentation at Lattice — and here's what we learned.

The best startups are innovation machines and the engineering, product, and design (EPD) teams are essential parts of that machine. Keeping this machine running smoothly takes a lot - a safe environment, great leadership, solid product direction, and plenty of time off to rest. But consider one more thing: We’re all builders at heart, and having the opportunity to flex our own creative muscles by owning a project from idea to execution is a huge energy boost. This is what a hack week is all about: Pause the normal roadmap, get creative, and have some fun building!

Why run a hack week?

Even the best teams get into ruts, deal with tedious work, and want a change of pace. With well-planned roadmaps and tight deadlines this isn’t always avoidable. Participating in a hack week can break this up. Taking a week away from your normal work routine to work on creative projects is like taking a new route to work; it can refresh your brain and increase your creativity

When working in pods or product teams, it is too easy to focus only within this small group of coworkers. But (depending on the size of your startup) there are many other talented and amazing people in your company. Hack weeks are a great opportunity to work with people outside of your normal team, to make new work-friends, and to network.

Even though they are outside of the normal work routine, hack weeks can still have outsized business impact. So many of our favorite products started off as a hack week or 20% time experiment (for example, Gmail and Spotify’s Discover Weekly). Whether it is exploring a brand new business opportunity or having the freedom to prototype a new feature in your existing software, hack weeks are perfect opportunities to try to explore the future.

Hack weeks at Lattice

Here at Lattice, we’ve run 2 hack weeks in the last 2 years and are currently planning our next mid-year hack week. We had the same goals in mind (change things up, work with people outside of our pods, explore new product ideas without heavy investment) and after running the hack weeks everyone felt recharged and made new friends within the company.

Our first hack week was in person, during our winter 2019 holiday party week. All of our remote employees (including myself) flew into San Francisco for the week. For many of us, it was the first time meeting in person! As you can imagine, this was a perfect opportunity for a hack week that mixed up teammates. The theme of this hack week was “Engineering Self-Care” and was an Engineer-only hack week with the goal of building out solutions to help us engineers do our job easier or more enjoyably. Several great ideas, some fun experiments, and even some product prototypes came out of this amazing week. But most importantly, we got to spend time together with coworkers from other pods.

Our second hack week was held the first week of 2021 and (like everything during this time) fully remote. It was definitely more difficult to coordinate and run a fully remote hack week but we learned some great lessons that we’ll share with you. This hack week was also EPD-wide and had several (optional) themes. Despite being remote, we felt the same benefits with changing up our focus, flexing our creativity, and working with coworkers from across the EPD organization. Unique to this hack week, we even made a commitment to eventually develop the grand prize winner into a full Lattice product (stay tuned for more)!

So if you’ve decided to run your own hack week, we hope you’ll consider our suggestions to make it great.

Keys to hack week success

Rules for running your hack week can be pretty loose (it should be inspiring and fun after all). However there are a few things that we consider necessary.

  1. Dedicated time
    This is the most important requirement for a successful hack week. You can’t expect participants to focus fully on new ideas if they are still worried about finishing sprint goals or finishing other tasks. So clear the plate, finish tasks the week before, and get dedicated time to hack.
  2. Have a plan for incidents and high priority customer issues
    Not everything can be ignored for a whole week. You want to preserve as much focus time as possible for the participants, but also can’t let the company catch fire in the meantime. Consider a short-duration on-call rotation over the different hack week teams. This can avoid derailing an entire project for too long during the week and keeps the responsibility of responding to customer needs fairly distributed. If a team has already had to respond to an issue during hack week, consider pulling them out of the rotation for the remainder of the week.
  3. Provide a safe space for experimentation
    If participants are too worried about the viability or quality of their project they may end the week without much to show. Hack weeks should be considered a special period of time where our normal software development process takes a pause. Make it clear that code quality or the polish to immediately ship is not necessary for the hack week. Keep code changes in a separate branch and don’t require code reviews. It may be nice to show customer research or product validation, but requiring it will slow teams down. Viewing finished projects together at the end of the week is the goal!

These are the most important things to get right, but there is more to consider and a few things to tweak when running a remote hack week.

Running a remote or hybrid hack week

Lattice EPD has operated in a hybrid remote/on-site model for many years, but in 2020, like many of you, the whole company transitioned to 100% (quarantined) remote work. Having everyone remote when organizing and running our hack week was definitely more challenging, but we prepared as best we could …and learned many lessons that we can share with you.

  • Have a solid plan …and a back-up plan for synchronous team formation and communication
    The very first day of our 2021 hack week happened to be a day that both Slack and Zoom had an early morning outage. Since these are our 2 main communication methods, this proved very challenging. Eventually Zoom service was restored so we were able to kick off hack week. Without Slack, our plan for team-formation channels fell apart. We instead used Zoom breakout rooms for team formation and communication. This was ok, but made it very hard for everyone to browse and find the right project to join. So plan in advance how team formation should work and make sure to include one or two backup options just in case. Any time lost solving technical issues is time lost for hacking!
  • Consider defining projects or forming teams in advance of your remote hack week
    Our 100% remote hack week encouraged project pitches and team formation on the first day of the hack week. In past hackathons, I’ve found this to be a really fun process: get up in front of everyone, make your best project pitch, and then try to recruit teammates! But we found that this didn’t translate very well in a remote format. Pitches were fun, but we saw the previously mentioned problems with project browsing and recruiting. Some people were also left stranded after teams formed. So for our next hack week we are planning to use an async planning forum in advance of the hack week. A few people did this in advance of the last hack week and they found it was more inclusive to different thinking styles, and helped them to feel comfortable knowing what they would be working on for the week.
  • When running a hybrid hack week, always include your remote participants
    Our first hack week was in-person, but we had a set of engineers in other countries that couldn’t fly in. Because everyone was excited to interact in person and draw on real whiteboards, we sometimes failed to include our remote project members. That wasn’t a great experience for them. So make sure all important team planning happens in async documents and/or video meetings to include your remote participants! While you are at it, have video chats ready for project presentations and award ceremonies.

Other things to consider when planning your hack week

  • Encourage IC volunteers to participate in planning
    Getting individual contributors involved in planning the hack week is a great way to make sure the team is heard. Planning a larger scale event for the whole team is also a great way to flex leadership skills and to have (hopefully) a good success to talk about during performance reviews.
  • Categories, Prizes & Swag
    Should you include categories and prizes? This totally depends on your startup! Consider this an item to discuss with your volunteers in planning sessions. Categories can restrict some creative ideas but they can also help to narrow focus. At Lattice, one year we ran an engineering-only hack week with no categories and only the theme of “Engineering self-care”. Earlier this year we ran an Engineering, Product, and Design hack week with 4 main categories, 1 company choice vote, and a grand prize (Most ready to ship). Both had their pros and cons and we’ll remain flexible when planning.
  • Avoid risking major roadmap milestones when scheduling
    This can be a hard one since, as startups, we tend to move fast and ship often. When scheduling your hack week do your best to avoid the week before and after major launches. The week before a release is often needed to quickly respond to last minute fixes and polish. The week after a release is when customers start to get their hands on and is often when the most customer issues are reported. Alternatively, be open to shifting roadmap dates around the hack week.
  • Avoid promising a launch date for projects
    It can be tempting to see a great hack week project and immediately try to ship it. But keep in mind, we’ve paused our normal software development processes for this project. There could still be a significant amount of work to prepare this project for general availability. Your product teams also likely have a well thought out roadmap and it may not always make sense to change those for a hack week project. Instead, consider the work during hack week as a spike or prototype and use that as an artifact for future roadmapping.

Your hack week can be as unique as your startup. We hope our experiences convince your company to run a hack week and our suggestions help it to run smoothly. Make it your own, use your company values to guide planning, and remember that the hack week is for fun first and profit second.


more articles