I'm a technology leader in Colorado speaking about serverless computing, team building, devops, and leadership development.
01 December 2017
Reblogged from developer.bombbomb.com
I’ve had the enormous fortune to lead an engineering organization comprised of women and men who delight in challenging one another every day. This camaraderie leads to better products, more creativity and a happier workplace. At BombBomb we often get to work on really cool stuff that pushes our ability and knowledge, but at the same time these tasks are often that: assigned work. It’s gotta be done, but how can we really lean to the other side and let engineers run wild?
In the spirit of freedom and innovation BombBomb held it’s first hack week in the Spring of 2015. No sprint planning, nothing assigned, just five days of developer-driven creative expression. We didn’t go in completely blind, we’d read up on Spotify’s similar tradition. So the rules were simple:
It was awesome. People played with ElasticSearch, WebSockets, and new ways to engage BombBomb staff with customers. Some of these projects were the seeds that became crucial everyday systems at BombBomb.
We knew this was a new staple: a week in spring to experiment and impress. We get the whole company together at the end of the week and show off what’s possible. We also learned to document these more thoroughly, and produced great round-ups on BombBomb Hackweek 2016 and Hackweek 2017. You should really explore those posts to get some deeper insights on some of my favorite projects, like:
Annual hack weeks are a hit, no doubt, and I’d recommend them as an innovation-rich, deep team-building exercise. You can really have them crescendo in an event for your whole company and its larger sphere. But, what happens the other 11 months of the year? On the positive side, hack week takes on a mystique, a real treat to look forward to in the spring. People link back to their presentations, or work in bits of time to polish their experiments into products. On the flip-side, we hired nearly ten new developers this year since the last hack week, so to them hack week is a little unreal yet.
We wanted a mechanism to allow our engineers to follow their passions more regularly. We read a bit: Google has their 20% time allowing about a day a week to experiment. LinkedIn has InDay where each month employees spend a day exploring themes such as: “giving back, relationships, learning, wellness and play.”
We liked a number of these approaches and so, starting September 2017, we broadened our hack culture to include a monthly Hack Day on the first Thursday of the month.
For the most part it’s been a success. With the limited time, projects have been far more prototypical than what comes out of a full week, having a little more of a what’s-possible flair. There’s a bit less planning and communication: two engineers happened to tackle speech transcription projects separately and unbeknownst to one another on the same day. Quite the surprise at demo-time the following morning. With the smaller time-box practicality is rearing its head: a pair of engineers went on a day-long documentation clean-up spree. Good, small works.
Having the single days is certainly less of an event than the week-long blow-outs, and the standing date ends up clashing with crucial deadlines. There’ve been a number of incidences of developers not being able to participate. They’re happily granted a rain-check, but something is lost. It’s not perfect. We’ll keep tinkering.
Making time for focused, professional play in the workplace is a real challenge. But I’m a believer. Deadlines are important, customers need you, and that production alarm doesn’t take a day off. We need to be flexible: in 2016, Spotify converted their Hack Week into Fix-It-Week.
Not everyone’s projects fly, sometimes people end up with just lessons. But that’s okay. We’re fortunate to have these opportunities, and an environment that’s sympathetic (if not downright enthusiastic). I’m looking forward to Hack Week 2018; the future is bright!