A couple of months ago, I wrote about “Scaling yourself”, as in, finding ways to make your work processes more efficient so that you an keep working on important stuff. This means avoiding unnecessary meetings, sending surrogates to meetings, delegating things to others, etc. They’re all super important skills to learn as you start moving on in your career.
But I wanted to take a look back at things and reflect on the potential negative sides of scaling yourself when it goes too far. Because everything can be taken to too far.
I should note that this is a topic that I’m in the middle of learning how to deal with now, so I doubt I have the more well-rounded analysis that I normally write. I’m sure there will be gaps and things I haven’t experienced or thought of yet.
So, first, let’s get really good at self-scaling
I come from a looooong history of working at small startups. Specifically, ones where they’re still at the stage where every single headcount is very precious. That means that I’ve grown very good at making things work out given the resources at my disposal.
It means that there’s rarely the budget to hire a dedicated engineer to help out with data engineering issues, nor is hiring a second analyst in the foreseeable future. The companies would rather spend the money on getting another person (or two) in one of the other departments. For the most part, I’ve agreed with those decisions because I mentally know that I can support 4-5 separate product teams worth of people at a sustained pace (almost double in a pinch, but it’s unsustainable for the long term). If you assume that each engineering team is something like 3-8 people (eng, PM, other cross-functional roles, etc), the engineering headcount needs to grow a ton to justify cloning myself.
In order to keep had above water with so many teams and context switches, I effectively trained myself to scale to extreme lengths, putting in all the tricks I wrote about in that original scaling post and more.
But probably the one thing I did that I briefly mentioned in the post but didn’t really elaborate on was how I learned to scale and negotiate my work scope. Essentially, my work itself became a highly scalable resource.
“I’m swamped this week, instead of a full deep dive into a topic, can I run a couple of quick queries that puts good estimates and bounds around the question to get you unblocked instead?” With responses similar to the above, I can cut a project that would normally take 1-3 weeks of concentrated work down to something that I can run in the background in a couple of hours. If somehow we get unexpected results, we can then decide if things are important enough to actually dedicate more time to the project.
So what are the risks of scaling work that way? Well, to scale work down, you essentially have to make lots of assumptions. First you need to know that the behavior you’re trying to estimate can be fairly approximated by whatever method you choose. You’re going to need to be really really good at understanding what’s lurking in your data and knowing the limits you can push with it.
Next, you also need to be really good at translating business/engineering questions into something that both you and your stakeholder agree is a good approximation method. Let’s say someone asked me how many people are going through a specific checkout funnel because they want to know if they should update it. The problem is that funnel is very poorly instrumented. It would take a couple of days to get an engineer to instrument it, and they don’t really want to. Or we can go use raw server logs and make some guesses. Either one is not ideal and will take a lot of time.
But I know how to approximate people entering and leaving the funnel based on how it sits within everything else. So I can say “well, we know most people get to this funnel from these points, and they exit at this point. We can get a rough ballpark estimate this way. Sound good?” Very often, they’ll agree that the method sounds good, and so they agree. I run the analysis, which is much quicker since it’s using existing tooling, and it turns out that the funnel isn’t being used very much. Eng decides that it’s better to start planning how to just eliminate the whole thing instead. My work is done after maybe a day of tinkering, the stakeholder is happy because they got a usable answer and a clear direction they want to move in. I get to move on to my next task.
So, how can any of this go wrong?
Well, in the example the stakeholder feels absolutely no pain. They come to me wanting a question answered. They of course want it “done right” with proper methods, but they’re not the expert on methods, I am. So I pick a decent approximation method, which always has a risk of being wrong, make sure they understand the limitations, but ultimately give them an answer that provides a useful direction they can put to use.
The same stakeholders don’t really know how many other things I’m potentially juggling, and how close to capacity I may be. If I had fewer things on my plate, maybe I could do a more thorough analysis and find something unexpected — like how maybe the top customers worth lots of revenue use that flow they’re now planning to kill. While such a blind spot is bad to have, it’s not usually the end of the world because later analysis during plan refining would’ve picked up on it. It’s still an ugly surprise when it happens, though.
The risk of the person feeling no pain is that when it comes time when I’m well and truly at capacity, you start getting reactions like “Wait, we were doing fine all this time, now we need a second analyst?”
You add to the fact that if you have been scaling heavily up by avoiding various unnecessary meetings and such, and suddenly you run the risk of being having all your impact and influence become invisible. Thankfully I work with wonderful people who credit my work appropriately and actively encourage me to present my work higher up so that I’m not forgotten. But it can definitely happen.
The key point here that in larger organizations where your work gets seen by lots of people who rarely (if ever) talk to one another about your work, it’s hard to make the case that they need to add more data people. There’s no work that couldn’t be done whenever they make a request, and they might not be fully aware of what epistemological compromises have been made to give speedy approximations. So in their eyes, all is good and dandy.
Sadly the most consistent way I’ve encountered to combat this issue is that you sometimes need to let people feel some pain in the form of “Sorry, I absolutely just can’t put this new project on the plate because [list of all the other things]”. Sometimes it involves not taking approximation shortcuts for project that just needs proper rigor, sometimes it’s carving out time for building critical foundation projects.
The hard part is learning how to balance the desire to be helpful in the short term, with what will be helpful in the longer term, and giving the right projects attention. Sometimes, there really are sudden projects that absolutely require high priority attention NOW, and in that case, someone else feels the pain of getting bumped off the list. It’s a complicated situation that requires a lot of communication and business skills, because it’s all about getting people to accept that there must be short term pain due to constraints.
Either way, thus far, the way I’ve been learning to navigate these complicated waters is with the help of various people up the management chain. They’re at least up aware and supportive of my work, and give me the backing to say “no” to various people when it’s necessary. Also, they’ll help me word “no” more diplomatically when it comes to communicating such to people way above my pay grade, because that’s a whole dance in and of itself.
Are there other ways to help solve this problem? Very likely.
For example, if there’s a consistent way to make sure everyone has a sense of how full my plate is with other projects, that’d be one way to avoid the issue. But broadcasting that also takes a significant amount of effort communicating that information out to people. You can’t just say “here’s my list of bugs/requests on this dashboard” because people don’t have much reason to check it. This sort of concentrated effort to push out status updates is something I’m fairly horrible at, so it doesn’t really work well in my case.
I’ve also seen other people make things work out by building process around the problem, something like a backlog review process that has broad buy-in and acceptance among the various teams. The problem is that it takes a lot work to get people to agree to spend the time on a regular basis, as well as having enough new content to justify holding such a meeting. Obviously such an expensive meeting (just think of the salary-hours involved!) would never revolve around a single team, let alone person. So whoever runs that meeting needs to have access to enough power and influence to pull that many teams together.
Maybe you’ve seen or experienced other ways of handling the problem? Feel free to tweet/email me, or leave a comment. It’d be nice to have exposure to other solutions that have worked for others.
Totally unrelated to anything, but this photo tweet is amazing and worth your attention.
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.
All photos/drawings used are taken/created by Randy unless otherwise noted.
Supporting this newsletter:
This newsletter is free, share it with your friends without guilt! But if you like the content and want to send some love, here’s some options:
Tweet me - Comments and questions are always welcome, they often inspire new posts
A small one-time donation at Ko-fi - Thanks to the folks who occasionally send a donation! I see the comments and read each one. I haven’t figured out a polite way of responding yet because distributed systems are hard. But it’s very appreciated!!!