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.
Here’s a very common problem that I hear when talking to other people working in the user research and data science space, they constantly get asked to do the same sorts of research work to the point where they’re frustrated and exhausted and want to change jobs. I’ve heard of analysts lamenting on how they’re constantly just building dashboards, researchers who have only done survey research for years, and endless other variations of the theme.
This is despite the fact that data folk of most backgrounds can (with some effort) fill in for others in day-to-day office work. There’s much more overlap that specialization. So once we solve the same sets of problems for a period of time, we inevitably want to take a break and do something different, if only for a change of pace.
Organizational niches
One reason this “happens” is that teams are created to fill in niche use cases. A data science team gets spun up to do experiments because the existing marketing team don’t have the data engineering skills and the research team isn’t interested in doing that type of work. A UX research team is hired on to do survey work because the data scientists have taken up all the logs analyses and experiments. The marketing team took up running A/B on ad copy first and somehow the DS team reports up to the CMO.
There’s complex organizational politics and turfs involved.
These entrenched domains are probably the trickiest to break out of because other teams might feel like you’re encroaching on their turf. It’s theoretically possible to reach out and form some kind of partnership — often in the name of “y’all are very busy doing important work, so let me do some of this stuff to speed up turnaround with your approval”. Sometimes that works, sometimes not. If you have the interpersonal communication and organizational skills to navigate this, then go for it!
Sometimes, if there’s enough organizational distance, I’ve seen people just go and do their own thing anyways and ignore that it’s “supposed to be the work of another team”. Occasionally this works because it generates value and eventually gets executive backing. Other times it fails or gets shot down with a “why aren’t you consulting with the team that actually does that?”
Many people do the calculus in their head and they often choose to switch to a different team or company than take the risk. Changing positions often comes with an additional benefit of a pay raise as well. I’ve spoken to a lot of folk from some very large employers complaining that they’ve done only surveys for years and were desperate for a change of pace. Their solution was to jump ship.
A self-made hell of good intentions
But let’s say that the structural barriers aren’t nearly as big of a concern. Or your job title, like Quantitative UX Researcher, actually does mean that you have a vast array of skills you employ to do your job. Instead what happens is that they keep getting requests to do the same things over and over. By itself, that might not be a problem since sometimes it’s the correct tool for the job, but usually it’s coming at a huge volume that would eat all of their work time (and then some). Keep this up and suddenly you’re known as “the guy who does dashboards!” and now every team that ever thinks they wants a dashboard for anything comes banging on your door.
While the term “slippery slope” gets thrown around quite a bit, this is probably one of the rare instances where it applies. What starts as one team getting a dashboard because their project needed it puts a clear example in their head of work that you can do. Next project they have is similar enough, and they get another dashboard because it’s appropriate for the task, and now they’ve cemented the notion in their minds. Other teams see this fancy new dashboard and want one too. Word gets around and before you know it you’ve been type-cast.
Now, not all requests for a dashboard, or any single method, would be a valid request every single time. Those would be the time to push back hard on what the appropriate method is for the specific problem at hand. This at least gives you a chance to show that you can do other things. The people requesting stuff won’t have any idea what you’re capable of without you showing them, so the onus is on us to make sure they’re aware that we can do lots of things.
But pushing back on requests isn’t enough. This is because if you’ve been type-cast into a certain role, people won’t even think to come to you with other sorts of requests. Why would I ask “the dashboard guy” how to predict how much traffic we should be expecting in the store on rainy days? Fighting against this is much more difficult.
The basic idea for breaking out of that is still quite simple, you need to show that you can do other kinds of work. The problem is the path to achieving that goal.
I’ve seen instances where people had some success with some friendly management support — they’d get invited into project meetings at a phase where “dashboards” isn’t appropriate for the task at hand. In those meetings, the data person finds a way to contribute, such as by volunteering to answer some questions that come up using data.
Another way would be to just overhear some questions from a team and proactively do a quick analysis to shed some light on the question, all unprompted. A chance conversation at the water cooler, can sometimes lead to these opportunities. The important part is to grab the opportunity.
Finally, one other way I’ve seen is a data team/person will run off and do their own project that brings value, and then share it broadly. This is like doing analysis, getting a team agree to make changes based on the analysis, get a big win, then stand up in a big all-hands meeting to show off the results. Obviously this takes a ton of time and work in the background, but it will also turn quite a bit of heads. Even a scaled down version where you just do an independent analysis and bring it to a team can have a similar effect.
That does assume you have time to work on a side project. Which is why any of these methods are significantly easier with the help of support from people up above. They’ll help you clear off some time for these explorations.
And sometimes nothing works
I wish there were magical ways to fix organizational disfunction, but nope. There’s just too many factors involved and despite your best efforts, sometimes things just fall flat. Managers and executives can be fickle creatures. Office politics can be as toxic as you want to imagine. Sometimes you’re just not able to spot a situation where your abilities can be allowed to shine.
I’ve even seen situations where one methodological hammer is the best solution for a given space - there’s whole classes of questions that tend to lend themselves to survey methodology like political polling with other methods taking a more limited role.
Changing an organization is a ton of often thankless work. So, if you really do feel trapped and sick of the work you’re doing. Do what many other successful people have done before.
Move on.
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
There’s a bunch of data people on Bluesky right now, but it’s a weird invite-only meme-fest so IF that starts becoming a thing in the future I’ll start mentioning it here.
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.
Guest posts: 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. You don’t need any special credentials or credibility to do so.
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