When I’ve started writing this article, it was already outdated; as a matter of fact, during these days the 2nd Edition of the Firebreaks is happening.
Firebreaks were one brand new initiative that we tried for the first time three months ago; you may have already read something about it, but we never had the chance to properly describe what is it, why we decided to do that and how it works.
First of all – as you might guess – we didn’t invent this ceremony; on the contrary, it is something that we copied and adapted to our organization.
In short, Firebreaks are a huge, challenging and inspiring initiative, with all the Engineering, Product, Design and Analytics teams involved.
Now that I hope I’ve got your curiosity, we can dive deep into it!
What is it?
The concept of the Firebreaks is quite simple: it’s a full week, entirely dedicated to Research and Development exploration. 🤓
Every squad puts on hold their daily activities, and people can propose and work on ideas to improve Everli. It’s a concept quite similar to Google’s 20% project or Spotify’s Hack week.
There are just very few rules because we didn’t want to do complicated stuff. Every idea that came up from the Firebreaks needs to respect the following criteria:
- it must improve Everli, in some way;
- it can go live, meaning that the implementation must be at least minimum viable;
- it must be cost-free, meaning that no one could buy anything (computational power, fancy domain name…)
Why did we do this?
The best concise explanation that I can give is the one that I stole from the GOV.UK website:
“Every squad work using iterative agile methodologies, and aim to deliver value to users incrementally and often.
This way of working is intense. Nobody can sprint all of the time. People need some time to pause and recharge.
Firebreaks are not just for taking a break. They’re also an excellent opportunity to pursue other work that’s of
interest to them and of value to the organization. This includes things such as prototyping innovative new features,
fixing technical debt and trying out new technologies.
Firebreaks also serve as a natural breakpoint as teams wind down their old missions and prepare to start their new ones.
This gives us a bit of a buffer in which to resolve pending issues that remain for the next quarter (e.g.: product roadmap)."
Firstly, one can think that Firebreaks are an occasion to let the team take a break, and that’s absolutely correct; but there’s definitely more than that.
Innovating is crucial in organizations like ours; but innovation it’s not something that you can plan, it doesn’t work as an algorithm, right?
Saving time to unleash people’s creativity it’s an excellent opportunity to quickly add value to the company, and this can be done for example by prototyping new features, trying out new technologies or fixing technical debt.
Moreover, it’s also a way for increasing people’s engagement and motivation.
Ultimately, it can be a natural breakpoint: this is why we set the last week of the quarter as the Firebreaks week.
How does it work?
As a first step, we need to collect ideas💡! A few days before starting, every company’s internal component (Demand, Operations, Retail & Catalog) prepared a simple file for this purpose.
Everyone added their ideas in this file, quickly explaining what was it and why they believed it should be done.
Then, on Monday morning, the first day of the Firebreaks, every author would have to pitch their own ideas in front of the team, in order to convince others to build them and answering to questions and challenges, eventually.
At the end of the pitches, everyone must choose the idea for which they want to participate. After a few refinements and iteration, we finally had mini-teams, which ranged from 1 to 5 people (because yes, also solo-work was possible!)
Then, for one week, everyone cleared up their agenda and started working on their project. 🚀
If you were wondering, though, we know very well that urgent support may be needed: this is why support for critical bugs or severe issues was guaranteed.
At the end of the week, it was showcase time!
On Friday, finally, we gathered together, and everyone had the chance to present the work in front of the extended team🎤. All Tech, Product, Design and Analytics participated; since the projects were many, we dedicated an entire day for the demo.
In 5 days, 80 people collected more than 1 hundred ideas and worked on 33 projects with great satisfaction. We gathered a promising 85 as NPS! 🙌
Keep in mind that Firebreaks are not a competition but in order to make it a little bit more challenging and fun, we decided to give four awards to some projects.
At the end of the presentation, therefore, everyone had to vote for their favorite projects in 4 categories:
- the most fun 🥳
- the most ready to use (in the sense that Done is better than perfect) 💼
- the most useful 😍
- the most wow 🎇
What did we learn, after one week?
Well, firstly, that we need more awards because 4 are not enough!
We learn that if you give freedom, you reduce communication overhead by relaxing processes and making people work tightly knitted, even with little time we can build a bunch of cool stuff (but this is not something we learned actually, we already knew that 😉)
We learn that, even if it’s hard, you can do team-building and have fun even in a completely, 100% distributed and remote environment (but we all can’t see the time when we can do this together, in the same room!).
We learn that we definitely needed it. It was a breath of fresh air for many.
But of course, Firebreaks wasn’t perfect; it was our first time, and we learned that we can improve.
The main takeaways from the feedback are:
- agenda could be optimized, probably too much time was dedicated to pitches and the Friday presentation was quite long.
- we need to find a way to support more non-tech-centric projects because Firebreaks are not a hackathon
- increase “cross-contamination” between components, this is hard because we’re many, but we’ll think about it.
(and in case you’re wondering, we implemented some changes in the 2nd edition)
We’ll keep firebreaking, of course! 🔥🔥🔥
The first initiative has been a great success, and we’re pretty sure that also the following ones will confirm the enthusiasm!
Author: @marcorisi (CTO)