Effective (training) firehose sipping

Jan 13, 2026

Hi, my brain is full.

Okay it's not actually full, but definitely tired from having to learn how everything works. When I started at Google, people there called it "drinking from the firehose" and honestly the sentiment applies to almost any job I've ever had. For example, it took me a solid couple of minutes to figure out how to send a meeting w/ a video conferencing link in it today because doing so needed me to install some plugins, sign into integrations multiples, and other silly things thanks to the company using a system I wasn't familiar with. It's just one of the dozens of silly "I really should know this already" things that pop up during this process that happen and you'd forget about within a week. Onboarding to an organization is all about this.

My general advice for anyone that has to go through this process is to always expect to take about three months to just barely come to an understanding of what is up and what is down. By then you'll have a rough idea of where things are, what work is being expected of you, and roughly how to execute on that work. It then actually takes an additional three months, so six in total, before a new hire actually has a solid idea of what they are supposed to be doing. I don't think there's a bulletproof way to shrink this time down in a meaningful way. There's too much "stuff" that exists outside of the immediate "Do this task!" work that barely comes up once a quarter, that it takes a half year for these less-common events to happen enough to learn about them.

THAT SAID. There's stuff that can be done to at make sure some slice at new work light comes into clarity sooner than later. For us data professionals, it's usually going to be questions around data, because we can't do any work without having at least some data.

So where's the data?

I've been at enough places to know that this question has only one answer – "It's complicated". This has been true for tiny startups of less than thirty people, and just gets worse as organizational history and headcount scale out. The answer is never "in this single database right here", because inevitably data lives across multiple systems. Even if all the production software data all lives in a single database, you're probably/should be running off a replicated database instance for analytics use. Even if you have that analytics clone, the financial data lives "somewhere else", there's some data that lives in a vendor like your ad platform, or social media, or an app store. There's going to be data that's not officially part of the analytics process, like server logs, which in yet another universe. None of these systems typically talk to one another (sometimes by design).

There's data everywhere you can choose to look, but knowing where stuff is isn't actually useful. Out of all that data, only a limited subset of it is going to be important to you right now. All the rest of the data may be useful to you in the future for other projects and concerns, but there's rarely any project that needs "ALL" the data simultaneously.

So your actual job is to figure out what is the data I need to start doing my job immediately, and how do I get access to that data?

Figuring out the answers to those questions is surprisingly difficult in many instances. Unless you can ask a person who has direct personal experience doing that exact kind of work, it's entirely possible that no one might actually know the answer. You might have to ask people who don't know but might provide contacts to someone else who might know, search documentation, and just overall pay attention and listen when others are discussing data to see if you can get an idea of where everything is.

My longer career experience has given me a better idea of the various patterns that data systems typically take, so it's easier for me to make guesses at how things are done. For example, if I see that there's a bunch of dashboards being used by people I'm going to assume there's at least some centralized analytics data warehouse/repository somewhere. That DW might be storing pre-calculated data cubes and there's a whole infrastructure backing that process up. If I see live "real time" ticking data I'll at least expect special dedicated data handling processes to power those very specific use cases. If I hear that various metrics come from systems with different names, I'm going to assume there's some complicated stuff and tech silos going on.

Making these guesses about what "might exist" helps me ask better questions of people when data topics come up. Oh, I've never heard of that system before, what's on it and how does stuff get in there? Wow, what's the latency on this live data feed? This data is owned and maintained by the analytics team, but does the sales and marketing team have their own data?

It's still going to take a ton of brainpower to figure out what actually exists and how to bring things together, but coming at the problem proactively makes you less at the mercy of whether a colleague happens to mention something critical completely unprompted.

What are the decision-makers paying attention to?

Data work sounds cold and objective, but at its core, it's a very social function. What analytics and research ultimately do is help the organization as a whole make sense of what is going on. Metrics are a social phenomenon where as a group we agree that certain things are important to measure, track, and adjust our decisions in order to affect. If you plan on being that lone wolf analyst that waltzes in, magically looks at "all the data" and declares "what is actually important!", you're going to have an long and painful battle ahead of you.

Instead, organizations existed before you joined and will continue to exist after you're long gone. That means they have already valued things, measured them, and made sense of the world in the context of preexisting metrics. Some people focus purely on revenue and money, others might care about user satisfaction, while another might care about NPS (ugh). They could be doing crazy things like making decisions based on the phase of the moon. Whatever method they're using, as "the new guy", you're going to want to at least know what the metric of the day/quarter/year is first. You might wholeheartedly want to change things to something "better", but you need to see where the current start point is, who the players are, and figure out a plan to bring about change. Pure mathematical correctness alone is not enough because change management is a social process.

What do other data folks have to say?

Working with data directly means soaking in the painful reality of "working with data". Within the same organization, even if they're in completely different job functions or silos, these fellow data professionals will have knowledge to share because you'll be sharing a surprising amount of pain points despite not even working in the same area.

Guess who's probably struggled with the IT team setting up R to do data processing work? Who worked with engineering and IT to spin up a mini website to host a custom visualization or tool before? Did someone actually manage to get access to an obscure system that others have failed to get?

If anything, these internal conversations are more fun than anything you'll ever find in public because fellow employees can largely speak freely without having to worry about NDAs and most legal issues. Some of the most fun stories pop up in such situations, and I love hearing such stories as much as I like sharing them.

Probably the most interesting thing to hear about are feature quests, "~~~ would be so much better if we had [something]". Those usually highlight the most painful gaps. Sometimes it's simple stuff like getting certain kinds of software processes approved, while other times it's a giant IT project. It's often not your job to address those issues, but I've always learned interesting things hearing about them.

The rest? I dunno. You'll figure it out.

Subscribe!

Standing offer: If you created something and would like me to review or share it w/ the data community — just email me by replying to the newsletter emails.

Guest posts: If you’re interested in writing something, a data-related post to either show off work, share an experience, or want help coming up with a topic, please contact me. You don’t need any special credentials or credibility to do so.

"Data People Writing Stuff" webring: Welcomes anyone with a personal site/blog/newsletter/book/etc that is relevant to the data community.

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 — homepage, contact info, etc.

All Tuesday posts to Counting Stuff are always free. The newsletter is self hosted. Support from subscribers is what makes everything possible. If you love the content, consider doing any of the following ways to support the newsletter:

Consider a paid subscription – the self-hosted server/email infra is 100% funded via subscriptions, get access to the subscriber's area in the top nav of the site too
Send a one time tip (feel free to change the amount)
Share posts you like with other people!
Join the 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. We keep a chill vibe.
Get merch! If shirts and stickers are more your style — There’s a survivorship bias shirt!