Attention: As of January 2024, We have moved to counting-stuff.com. Subscribe there, not here on Substack, if you want to receive weekly posts.
Happy new year! I hope you all managed to get a bit of rest during the end-of -year lull that inevitably happens in countries that celebrate the string of holidays at the end and start of the year.
Speaking of lulls in work, now’s a good time to talk about how every endeavor has rhythms to it.
An easily understood one would be handling a company’s finances and taxes. Income and expenses come in and have to be tracked regularly. Every month’s finances are usually closed out for reporting reasons. Every quarter there’s usually a more thorough financial report prepared. Finally, at the end of the fiscal calendar, there’s a large effort to take all the company’s financial activity for the year, close the books and generate the annual financial reports. There are phases of extra busy times (like tax filing season), while other days are have less intense work.
A typical software development cycle has a period of planning and deciding what project to take on next, followed by defining requirements, specifications, user stories. Then there’s some aspect of technical planning and review before we actually start writing code out. To end it all, there’s various stages of Q&A testing, preparing for release, before finally launching the new software out to users.
Every work function has its own unique quirks and rhythms to it. Sometimes, like finance teams, the rhythms are largely imposed by outside forces like regulators, investors, and the calendar. Other times, your job inherits rhythms from other functions — for example, since I’m primarily a support function for software development, I have very busy periods when teams are trying to understand users as they put together their product plans, then I barely hear from them when they go heads down for weeks doing their engineering work. Finally I’ll hear from from the teams again when they’re preparing to launch and need me to make sure all the metrics are set up right to track how the launch experiments go.
Not fighting the rhythms is important for avoiding burnout
The end of the year is an inevitable slow period for my work. Teams are usually winding down their existing development (if they haven’t already all stopped and gone on holiday). I’m sucked into a bunch of planning discussions to help teams figure out what they want to do when everyone returns in 2023, but no matter how you look at it, there’s less work that HAS to be done.
In my much younger years, I’d definitely be taking the time to load up this quiet period with projects that I had wanted to do during the year but was too busy to get around to. Maybe I’ll have a chance to finally see whether I can show that reading our documentation makes users more or less likely to buy something. Maybe I can put a few days into trying to make sense of the infinite browsing paths that exist within the product. Maybe I’ll finally try out that new ML algorithm I saw in a talk in the summer. Anyways, when you’re sitting on a sea of data that automatically grows every day, there’s no end to the amount of work and mischief you can create for yourself.
But, I also now know that come January and February, there’s going to be a big wave of work that comes in when all the engineering teams all start needing user research to support their 2023 Q1 plans. The fact that there’s so many teams doing separate projects means everyone will want bespoke research on completely unrelated topics. I’m going to have to work through that wave of work, get everyone something usable quickly, and wait for them to go into heads-down development mode.
Now, I take a MUCH more balanced approach to filling the quiet periods with interesting work that also leaves a lot of breathing room for when the inevitable work wave comes. Maybe I actually will take a couple of days to play with some new ML techniques I saw, but I’m not going to stress if I fail to get it to work after a few days. I’m certainly not going to do extra work outside of typical work hours to “get ahead”. A career is a giant marathon and it is best to take every opportunity to rest that presents itself.
On the flip side, when the big waves of work comes in and I’m swamped, I might have to take a couple of extra hours here and there to clear urgent tasks off my plate. When that happens, I also make sure to do my very best to tighten the scope of work requests and communicate with all the stakeholders that I’m at or above capacity and things will projects need to have their priorities clarified. Trying to do everything will just as easily lead to burnout despite being fully rested and prepared for the wave.
Once you see your own rhythms, watch everyone else’s
It’s generally easy to pay attention to the business rhythms of your own work. You’re usually the one executing the tasks and know exactly when you’re busy and when you can take that long lunch break.
It’s significantly more difficult, but more useful, to gain an understanding of what everyone else’s rhythms are. Have executives sometimes come to you asking for reports and numbers? Ever get a crunch of requests from the sales team around the end of summer? Notice a flood of interesting requests whenever a team comes back from an off-site event? Many of those are probably tied to some kind of regular cadence of work.
Knowing how everyone else’s work can have an effect on your own workload is gives you two big benefits. The first obvious one is that you can somewhat plan ahead for them. If you just know that you’re going to get a ton of requests for numbers right before performance review time hits because everyone wants hard data to back up their claims, then you can decide whether you’re going to entertain those requests or choose to work on some other work. Being able to see into the future, even imperfectly, is generally considered a good thing!
The other big benefit is that if you want to influence other teams, say trying to convince them that fixing a certain issue found in the data (like a retention issue) is worth their time, you will have a much easier time doing so if you present your case during or before their planning/scoping cycle than when they’re 3 of 8 sprints into their current big feature release that they promised the VP of Engineering. That’s not to say if you find some important bug that you’ll be ignored, but larger scale projects aren’t usually decided at the drop of a hat. This becomes increasingly more important if you want to have a bigger impact across and organization.
Enjoy your couple of days of new year ramp-up
As of this week, the vast majority of teams will have most of their staff just returning from their holiday breaks this week. They’re going to orient themselves, check the past week or two of unread emails, then start getting into gear to do the real work that they’ve planned on doing this quarter. Which means that as data people who are support those efforts, we’re going to get just a handful of days more of quiet while everyone starts to think about what kinds of questions they need answered.
Enjoy it while it lasts!
If you’re looking to (re)connect with Data Twitter
Please reference these crowdsourced spreadsheets and feel free to contribute to them.
A list of data hangouts - Mostly Slack and Discord servers where data folk hang out
A crowdsourced list of Mastodon accounts of Data Twitter folk - it’s a big list of accounts that people have contributed to of data folk who are now on Mastodon that you can import and auto-follow to reboot your timeline
Standing offer: If you created something and would like me to review or share it w/ the data community — my mailbox and Twitter DMs are open.
New thing: I’m also considering occasionally hosting guests posts written by other people. If you’re interested in writing something a data-related post to either show off work, share an experience, or need help coming up with a topic, please contact me.
About this newsletter
I’m Randy Au, Quantitative UX researcher, former data analyst, and general-purpose data and tech nerd. Counting Stuff is a weekly newsletter about the less-than-sexy aspects of data science, UX research and tech. With some excursions into other fun topics.
All photos/drawings used are taken/created by Randy unless otherwise credited.
randyau.com — Curated archive of evergreen posts.
Approaching Significance Discord —where data folk hang out and can talk a bit about data, and a bit about everything else. Randy moderates the discord.
Support the newsletter:
This newsletter is free and will continue to stay that way every Tuesday, share it with your friends without guilt! But if you like the content and want to send some love, here’s some options:
Share posts with other people
Consider a paid Substack subscription or a small one-time Ko-fi donation
Tweet me with comments and questions
Get merch! If shirts and stickers are more your style — There’s a survivorship bias shirt!