Scaling yourself
This week’s post brought to you by this tweet:
Whether you’re a solo data person, or embedded within a team, as organizations grow, reorganize, and evolve, you’ll find yourself with more and more things to do. Congratulations, you’re on your way to becoming an experienced data scientist! Careful about keeping your head above water.
Workload will creep up on you
In the modern work era, there is ALWAYS more work that could be done. It could come from factors outside of yourself, such as the company is growing and therefore generating more work that needs to be taken care of. Or it could come from within yourself, in that the work has always existed and wasn’t being taken care of, but as you grew as a professional, you started seeing opportunities to do something that needed doing.
Either way, having your scope expand is a natural part of becoming a seasoned worker. After the first 6-12 months, you’ll finally understand what your role at a company is, how things outside of your immediate view sorta first together into a functioning whole. This is when you start having more and more visible impact on everything.
Given all these responds for you to have more work to do, it’s very easily go from “taking on more things that you can handle” and slip into “buried deep underwater” before you even realize your stress levels have hit an all-time high.
I’ve been through these cycles enough that I know to check myself for those signs, and it STILL happens here I’ll find myself underwater and need to do a reset to get back to a healthy position.
Eventually you’ll need to scale up
When work loads continue to grow, things start entering a very awkward point where there’s more work than 1 person can completely cover, but not enough work to justify having 2 people around. The specific circumstances of your organization determines just how far do the limits of stretching a single person get pushed.
For larger, cash-flush organizations with long term strategic plans in place, they might be able to hire a second person to take up the load sooner, while a struggling organization might be resigned to never hiring anyone.
Whatever the ultimate cause, you need to find ways of handling this situation, because unlike the first 6months of taking on a job, it’s not going to get better. I’ve written about staying afloat as a new data scientist before, those techniques of saying no and managing upwards will help to a degree, but it won’t be enough. A year in, you can’t rely on “getting a better understanding of your job” to bring significant improvements. to your life any more.
So what needs to happen is you need to find ways to make yourself scale better.
#Webscale!What you’d want to do is get more more efficient with your time. Generating more practical impact per hour of effort put into things. Note that I’m emphasizing “impact” here and not simply “productivity” or “work”. You want the most bang for your time spent, because you should be working a finite, and hopefully fixed, amount of time every day.
WARNING: Don’t fall into the trap that if you get more efficient and can churn out more charts per hour that this is a good way to scale yourself. Simply generating more output faster is one way to “scale” your work, but can quickly hit practical limits and risks complete burnout if all you’re doing is pushing yourself instead of making efficiency and process gains.
Build automation
When the job “Data Scientist” comes to mind, writing code that does some form automation is pretty high up on the list of things we do. After all, we’re supposed to have programming skills and if you can’t use them to automate away a certain level of drudgery in your day, why the heck do you have those skills to begin with?
There’s usually some way to automate a repetitive task. You might not be able to find a perfect end-to-end automation, but anything that takes a lot of time and energy to do repeatedly should be made as easy and error-free as possible. Having machines and computers taking some of that work away from stressed, fallible humans just makes sense.
The thing to balance is the time needed to do the automation, against the time you’d save. xkcd has a wonderful little comic that has a chart of “how much time you save making a thing more efficient vs how often you do a thing” to give you a good sense of how certain time savings can massively compound themselves.
Cut out things that are unproductive time sinks
Take a look at your workday calendar and be brutally honest to yourself. Are there large chunks of wasted time on there? There are probably lots of places where you’re supposed to be working, but you aren’t.
No, I’m not talking about your lunch break, nor the 5th trip to the kitchen to grab a snack during the day — breaks are important to keep your effectiveness and mental health up, keep those. I'm talking primarily about useless meetings.
Data positions are naturally cross functional positions. We have to work across multiple teams and organizational boundaries. That very often means having lots of meetings with people to make sure everyone is aligned on goals, priorities, and tasks. For a single project, you might be dropping in on engineering standup meetings, UX design reviews, maybe leadership metrics reviews, or a million other things.
Some of those meetings are useful for you to attend. Some are not. Ask yourself how often do you have something important to contribute to, or get anything out of, a meeting? Do you really need to be at any of them? Could you get away with going to none at all?
Earlier in my career, I wound up being the lone data analyst supporting 5 product teams doing 5 separate projects. I was invited to all their various meetings, and it became obvious that it was physically impossible to attend them all. So I had no choice but to stop going to some, but I attended multiple ones “to keep abreast of things”.
(If you’re wondering why I was added to those to begin with, it’s because I was added to the collective team calendar. It was all or nothing.)
Then the workload from all the teams started piling up so I started working in a bunch of less important meetings, just paying enough attention to chime in when a data-related question came up and I had something to contribute. A couple of weeks of this silliness, it became obvious that I wasn’t even needed in most of those meetings either. If anyone had any questions that were in my wheelhouse, they knew to come to me directly anyway.
So, I just started declining most meetings. Instead, I made sure that I had at least one friendly person who I’ve worked closely with before, and they’d act like my surrogate. They’d let me know if something comes up that needed my attention and I could follow up on it there. If the meeting leader realized that there’s a significant quant component to a specific meeting, they’d make sure to let me know my presence was necessary. Sure, everyone loses out on those quick on-the-spot answers that can really make a brainstorming session flow, but everyone agreed it was an acceptable tradeoff.
While there’s always a risk of being forgotten if you don’t attend most team meetings, when I made it understood what my workload was, people were understanding and worked with me. It was to their benefit that I got time to get them the information they needed for their project than to have me sitting in a chair at a bug triage meeting or something similar.
Build processes
Usually, when people think about processes and bureaucracy, they think of friction. They envision long lines at the DMV and countless government forms that need to be filed. How is creating process (ew!) going to help make me more productive and impactful?!
Lots of ways!
First, processes lower mental workload. When a good process for work is in place, things go smoother because everyone knows what to expect and how things should play out. There’s no need to reinvent the wheels because the process lays it out for everyone to see. Even something as simple as a checklist will minimize errors and help things flow.
Second, processes that everyone agrees on will act like social contracts. Imagine you keep getting bombarded w/ “small requests” from people that start scope creeping and disrupting all your other work. To deal with the flood, you get every team to agree to a new process: “Projects classified as ‘small’ by the team will get ~2 hours of work in a week. Anything more needs triaging and prioritization from the team lead.” This forces everyone to agree that their projects need to be time-boxed. Anything larger needs to face scrutiny from team leads who can say something just isn’t important enough to work on.
Finally, processes is like automation’s younger cousin. It’s a way to organize labor, like an assembly line. When a formal published process doesn’t exist, individuals have control over how things go, what gets done. This is going to vary person to person and no two results would look the same. When a process exists, it helps you swap people in and out and the process itself should be robust enough to give fairly consistent results despite personnel changes.
Which leads to…
Train others to do things
You probably work with lots of people from all sorts of positions. You’ll likely notice that some folk “get it” more than others. They’re generally more attentive and curious about your work, and in general you likely have a good relationship with them.
Sometimes, the opportunity presents itself where you can train such people to do stuff for themselves and their team. You can make them more quant-y. It’s the whole teaching people to fish thing. Maybe you’ve helped teams set and define their success metrics multiple times now, and one person is consistently the best at coming up with good metrics, able to foresee troublesome issues.
Imagine what would happen if you taught that person to lead metrics workshops for their team, and you take up the role of reviewing and signing off on the things they come up with.
How hard would it be to train that person to do this? Probably not too much, since they’ve been a great participant before. They also bring their own expertise and views to their team, which can be a strength.
How much time and effort would that save? Probably quite a bit since the workshops might eat up multiple days of work between prep, workshop, and final reporting/analysis.
But that person isn’t a data professional, what if they make a mistake? Well, that’s why you build a process around it. Have the workshops templated/checklisted so the most important things are always done. Make sure everyone understands what’s good. With some planning and process, you could offload the time-consuming work onto someone. Finally there’s a sign-off process to make sure that nothing goes too far without a checkup.
What do they get out of it? Aside from picking up new skills and experience, folk who wind up doing this work also is seen as having more impact on their team. They’re helping lead an important effort, one outside of their stated expertise. These efforts can help teams move quickly because there’s one less bottleneck (namely, you). Assuming everyone is getting something out of it, it seems to be a net positive.
Make it clear that scaling is happening
The one dangerous thing you need to be careful about when scaling yourself out for this is that you absolutely need to make it known that these efforts are happening.
There comes a point where no matter how efficient you are at scaling your impact out, you simply can’t get any more done alone. You’re going to need help, aka, you need to justify hiring another data person to help with the load.
But if people, huge groups of people, are all getting their data needs largely filled in reasonable time, it actually works against the case of “we need to hire someone.” By the time you’ve scaled yourself to doing 1.25, 1.5, maybe even 1.75 people’s worth of work, it’s time to begin having the long conversations about expanding the data team.
I’ve literally had situations where I was support as many as NINE product teams in parallel for a length of time, and things largely ran. I couldn’t be everywhere but I was around “enough”, and had successfully got a bunch of other people to be my team liasons where they’d bring me project ideas, work with me, then largely be the “face” of the data work to the teams since they made their own unique contributions.
Fast forward a bit, and after a few reorgs, my product count is lower but the workload grew and the scaling tools I used to support a ridiculous number of teams actually caused trouble in that we had to push harder than necessary to get approval to hire someone.
=\
About this newsletter
I’m Randy Au, currently a quantitative UX researcher, former data analyst, and general-purpose data and tech nerd. The Counting Stuff newsletter is a weekly data/tech blog about the less-than-sexy aspects about data science, UX research and tech. With occasional excursions into other fun topics.
Comments and questions are always welcome, they often give me inspiration for new posts. Tweet me. Always feel free to share these free newsletter posts with others.
All photos/drawings used are taken/created by Randy unless otherwise noted.
Some Counting Stuff swag from RedBubble is available for print-on-demand here.