Originally posted at the Civis Tech Blog.

Endless Hackweek Banner

Last year, all fired up from an Eric Ries talk, I pitched Gabriel on a radical idea. “What if we had hackweek every week?” The results have been exciting: we’ve produced internal tools that we use every day, released new features that went right into production, contributed new code to the open-source community, squashed of some of Tech’s least favorite bugs, and even prototyped major technical projects that made their way into the development queue and been staffed with large teams.

https://civisanalytics.com/blog/engineering/2016/02/29/2016-endless-hackweek/

Hackweeks align with one of our most important values at Civis: promoting autonomy. For people doing technical work, that means having voice in the direction our products and offerings take, so they don’t end up as just the implementation arm of a business group. One of the best ways to do that is to give engineers permission and encouragement to try out risky ideas on their own, putting resources behind ones that pan out. That also lets us actually test hypotheses about new designs or technologies, instead of trying to guess what will work and relying on meetings and consensus. You have to make a space where it’s OK for those projects to fail, which means setting aside time for engineers to experiment, to hack, outside of their regular work.

The traditional approaches have some drawbacks:

  • Company-wide hack weeks meant that some people got left out, either because they had conflicting deadlines or because they had to man the ship or the phones while everyone else hacked. It was important to me that our systems team, for example, be able to schedule hack time when they wouldn’t be interrupted by urgent tickets. We also saw a hack week hangover, where people spent extra days afterwards trying to put finishing touches on their projects, and had to deal with a show and tell meeting where the entire company wanted to present. Collectively those factors made holding hack weeks more expensive, and harder to hold as frequently as we wanted.
  • Weekly hack time on Friday afternoons, and later all day every other Friday, was seldom enough contiguous time to make progress on an ambitious project. Anything that required setting up a new environment, installing a new package, or just thoroughly reading the docs could leave hackers with little time to write code, and having to set the project aside for a week or two between session meant a lot of that work would need to be repeated.
  • Telling engineers to take 20% time at their own discretion meant less senior and less confident engineers were less likely to assert their right to hack, and put the burden on busy teams to make space in their schedules rather than having the team help them make that space. Worst of all, it could introduce subtle pressure across the organization to not take risks. If people feel they’re evaluated by their total output, they’re incentivized to work 95% or 100% on sure-bet projects rather than setting aside time to swing for the fences. In retrospect, the solution was obvious; we wanted the structure and contiguous time of a delineated hack week, but spread out across the year like our free Fridays or like totally unstructured 20% time would be. We could get there by giving everyone a full week at a time, and staggering the weeks so that only a few engineers are hacking at once. Each week we give a group of engineers all week to hack, telling them to set aside their normal work and cancel as many meetings as they can. Once we’ve gone through the whole team we start back at the top, spaced out so everyone gets a hack week four times a year.

Staggering means we can schedule around deadlines and make sure we can line up the backup to let even the most critical team members step away from their day jobs for a week. It means only ever having a handful of hack week presentations at a time, so great ideas are less likely to be missed in the shuffle and so that everybody gets a chance to practice pitching their technical ideas. Most importantly, it also lets us concentrate more support resources on a handful of people hacking each week. We’ve been able to go way beyond giving people a week and telling them good luck. Instead, we’ve built a structured accelerator to make sure hackers have the design and infrastructure support they need to complete their projects, to maximize the chances that those projects make the jump into production, and to make sure we learn as much as we can even from projects that don’t go as planned.

Moving to running hack week every week has let us:

Give more time for each engineer or team to present and share what they’ve built or what they’ve learned. - Give engineers whole weeks at a time to pursue an independent or experimental project without taking the whole team offline. - Collaborate with our colleagues on the Product, Design, and Data Science R&D teams without swamping them with 25 projects at once. I’ll dive more into our program and how it works in my next post. Stay tuned!

https://civisanalytics.com/blog/engineering/2016/02/29/2016-endless-hackweek/