Solidarity in the small stuff
Finding the time to prioritize less exciting work
I’m always looking for new ways to bring people on my team together, especially in times of change and uncertainty. Sometimes it means looking for ideas in less intuitive places. I previously wrote about how to keep team members engaged by finding alignment with their expertise and interests, and that inevitably, every team will have to complete some necessary work that no one is excited to do. Besides distributing the tasks as evenly as possible, creating solidarity within a team is a great way to inspire some motivation.
The engineering department at Fitbit held an event on the last Friday of every month called “Dev Awesome Day.” Everyone in the org agreed to suspend meetings and avoid any new software development, instead focusing solely on tidying up what had already been written. This included cleaning up tech debt, creating unit tests, or writing clarifying documentation.
The Data Science and Analytics team also participated, and we spent our Dev Awesome Days cleaning up our Airflow jobs, refactoring messy SQL queries, and adding useful dataset information to our team’s central data wiki. Because it was an observed ritual across the entire Engineering org, it was less prone to interruption, and everyone felt good at the end of the day when we were able to see what we accomplished together. Sometimes I would even bring in donuts for our corner of the floor.
When I joined Mozilla in 2019 as the head of the Firefox Data Science team, I wanted to bring the spirit of Dev Awesome Day with me. I decided to start by having the team focus on documentation, something we were in dire need of. To get the ball rolling, I kept the definition of the term fairly loose; documentation could mean either something beneficial for the team (such as onboarding materials, information on data provenance, etc), something helpful for our product stakeholders, or something for the public, such as blog posts about how data worked at Mozilla.
I floated the idea with a few members of the Data Science team and asked if they’d like to have a manager-sanctioned day of no meetings to do some writing. I suggested that they could meet up more informally that day, either at a local coffee shop if they were based out of an office, or over an open Zoom link for the full-remote employees. For the less socially-inclined, if someone preferred to hang out at home, knowing that others were working on documentation at the same time hopefully made the task a little more motivating. We decided to try it out one day in June of that year, and would think about making it a monthly occurrence if it worked.
I referred to it as a “Documentation Day” (or “Doc Day” for short). I asked the team if they had any better naming ideas, and one clever person suggested that we call it “The Doc Days of Summer.” There’s nothing like a pun-based name to get more people excited about participating, and very soon, the rest of the extended Data team joined in as well. It became kind of a fun game to come up with the name for each monthly Doc Day, and we continued the event with such titles as “Doctoberfest,” “Guy Docs Day,” and “The Winter of our Docs Content.” My favorite Doc Day naming candidate (which was ultimately vetoed due to length and the fact that it was a stretch) was for Beyoncé’s birth-month of September: “If You Liked It You Should Have Written a Doc About It.”
Anyway1, tactically I sent out a Calendar invite that included a Zoom link and a meta-doc (i.e. Google Sheet) for everyone to throw their ideas in so that anyone who wanted to collaborate or find inspiration could use it as a resource. My only requests were that the Data team block off their calendar several weeks in advance and to think of some areas of documentation to work on ahead of time.
The biggest challenge was making sure everyone actually did block off their calendars and to give stakeholders enough notice so that they could prioritize the day for thoughtful writing. At Fitbit, the whole company recognized and supported the Engineering org’s Dev Awesome Day, which meant that there was less interruption. Generally though, Doc Days were a success, and we did manage to clean up and add a lot to our documentation, taking it from one of those things that always ended up on the back-burner to a prioritized task that the team made time for.
Bonus Tip: Getting Adoption
When rolling out a new idea to an organization, I always test it first with a small subset of the team. It’s usually difficult to get the tone right on the first try. Just like shipping an MVP, you can learn where the rough edges are in practice with a small test group and find areas to improve before committing to the idea at a larger scale, which is more costly if it doesn’t work out. Drumming up excitement with a smaller team is also easier, and that excitement can be contagious when rolling it out to the broader organization. I did that with Doc Days, as well as half a dozen data team branding initiatives. From a maintenance perspective, I also consider what kind of time commitment I need in order to keep it going. For Doc Days, it was a simple calendar invite and a new tab in the Google Sheet once a month, so the investment was really low. I’d love to hear other ideas managers have put into practice on their teams, and how adoption has been!
Ok one last pun that went out with the February Doc Day calendar invite, in poem form:
A Docs Day Valentine, by Mark Reid and Emily Thompson
“Roses are red,
Good docs are too;
Someone's gotta write 'em,
why not you?”