Zanbato Hack Week Fall 2016

The Zanbato engineering team believes that many of our best engineering ideas come from outside of our own codebase. When engineers are working in the same codebase and stack for a long time, it’s easy for coding practices to get stale. To foster a sense of growth, we have been doing a mini-20% time on Friday afternoons where engineers can work on whatever they want.

However, we recently skipped a few Friday afternoons to work and finish up a project. To catch up, we decided to do our very first Hack Week. Many companies have some form of regular hackathons, but we decided to do ours differently.


The rules were pretty simple:

First, projects must be hosted publicly on GitHub. This provides enough visibility for engineers to interact and see what each other were working on

Second, projects cannot be directly implemented in the Zanbato product. Most corporate hackathons are focused on addressing backlogged tasks or developing new product ideas. Such projects would be compatible with our existing stack, which wouldn’t provide enough technical difference or even psychological distance for it to be the learning experience we wanted. Instead, we wanted everyone to feel explicitly freed from “working” so to speak.

Third, the scope of the project should be about a week. Ideally, the project would have a MVP in one week but a larger scope for continued effort. Engineers learn a lot in maintaining codebases over a long time, and Hack Week could be a starting point. However, it feels good to have something done and presentable in a week.

Fourth, the project should use at least 1 new framework or technology. Engineers can learn a lot just in starting any project from scratch, but we were heavily emphasizing learning in new paradigms. Many of us ended up building web apps with different stacks, but we were open to anything involving code.

Fifth, each project should be teams of only 1 or 2. As a team of only 7 engineers, we needed small teams to get sufficient diversity. Many companies setup hackathons to be cross-functional. That seems like a great idea, but given the size of our team and the schedules of non-engineers, this wasn’t feasible for us.

Since this was our first week, we decided not to have a theme either since most engineers already had a project in mind.


Before Hack Week, everyone wrote up their idea (or ideas) on a white board. Not only was this a way to find like-minded teams, it also showcased many ideas to get everyone brainstorming and planning.

During Hack Week, we replaced our morning standup with a Hack Week standup. We kept “what you did yesterday” and “what you plan to do today” and also added “something you learned yesterday” to keep ideas flying around.

Everyday, we also had a different Hack Week activity that was announced during standup. Since coding is mostly solitary, these activities broke up the coding and got engineers working together. Over the week, we did:

  1. Ideation. Talk about the problem you are trying to solve with your project and what your solution is (without talking about code). Be product managers and designers
  2. Architect. Talk about your tech stack and how you plan on building your project. Get feedback on any technical issues you are running into
  3. Pair program. We typically don’t pair program, so Hack Week provided an opportunity to try it out
  4. Test and review. Do a short demo of your project and get feedback. Figure out what to polish before presentations
  5. Present.

We did 5 minute presentations on Friday afternoon with the following suggested structure:

  1. Motivation
    1. Problem being solved by your project
    2. Technical goals (if any)
  2. Your solution
    1. Product development
    2. Demo
  3. What you learned
  4. Next steps
    1. What you will build if you are continuing with this project
    2. What else you plan on working on/learning if you are not continuing


Overall, we had very positive responses from the team about how Hack Week went. Compared to the usual Friday afternoons, we found it much easier to work on a real project in a 40+ hour chunk rather than 4 hour chunks. Several engineers were happy to finally have time to focus on that backlogged idea and see it become reality.

We had good diversity in technology choices from some people who used the Zanbato stack plus one new technology, to others who used completely new technology. Both ends of the spectrum found value in it: either it was a good way to reinforce fundamental ideas or it was a good way to see something totally new.

Hack Week originally started as catch-up for our Friday afternoons, but the team saw them as quite different. Due to the differences in frequency and duration of the free time, we actually worked on different things rather than just rearranging time. Regular, short free time is better for short exploration, tutorials, and learning, whereas the longer Hack Week was better for working on a real project.

Going forward, we haven’t quite figured out the appropriate schedule for mixing hacking in with our normal work. However, everyone was enthusiastic enough that I foresee us trying to integrate both in the future!


If you’re interested, here are some of the projects we worked on: