Surviving as a Data Team of One

I often meet with advice-seeking newly-minted analytics people. Typically, they’ve joined a small startup with no data infrastructure and are looking for advice on how to do a good job.

It's on them to make the company's data queryable (usually with a data warehouse, though a Postgres read replica is often fine for a while) along with a dashboarding tool and various ETL pipelines. Some day they'll hire a team, but for now they are a data team of one for the first time.

Having been in that position before, I've made my share of mistakes and seen others do the same, so most of the advice I give to different people tends to be similar.

This post is the first of a series and isn't about technology. A fact that is often missed by those new to the role is that a major part of the job involves human relationships and communication rather than technology.

The Request Mountain

The first weeks on the job will consist of quick wins: you'll run basic queries that answer questions your co-workers have had for a while (for example, the first analytical query I ever ran was one listing which countries paying users were located in).

This will quickly cement you as the 'data person' in the company and people from different departments will start coming to you with query requests. Your CEO will likely be one of the worst offenders.

But the requests will pile up. You won’t be able to provide instant responses anymore. You may not communicate delivery expectations adequately, leading to frustration (both expressed or not) on behalf of those who are waiting on you. You may even get frustrated and put people off asking you for data help.

Mitigating the Mountain

There are some things you can do to alleviate this situation. Chief amongst them is realising that people don't know how hard it is to dig up data. Something that may take you a full day to wrangle into a presentable state may be falsely assumed to take five minutes.

All human relationships (even work ones) are lubricated by communication. From this realisation stem a few recommendations (it's no accident that they are ones that apply to most jobs):

1. Designate priorities

Because your internal customers will rarely know the effort involved in satisfying them, some of their questions will be idle curiosities rather than business-critical ones.

Rather making a confrontational demand in the form of 'Tell me how this is important to the business', establishing a priority ranking can be more cooperative: 'I'm working on these priorities for Sales and Marketing: can you help me understand where yours fits?'. This works particularly well with drive-by requests from the CEO.

2. Communicate delivery dates and delays

This will involve effort from you but will result in a more peaceful environment: 'I can deliver this in a week as I'm handling these other tasks first'. As delaying factors come up, share them. The alternative is your co-workers living in a state of frustrated mystery, not knowing when they'll get what they asked for.

3. Make a task board and share it with everyone

This way people can see where their task is in your queue without having to ask you for updates.

4. Meet with other departments once a week

You’ll engender peace of mind if Marketing/Sales/Finance/Product each know that they have a predictable, dedicated meeting with you where they can bring up requests, get status on deliverables and priorities, and get your help to tighten ill-defined questions.

5. Alleviate your workload by automating

Is the customer support team constantly asking for the same user attributes to help them deal with support tickets? Are sales people asking for the same product usage data over and over again? Are the marketing folk regularly asking for user CSV dumps?

Consider piping data to other departments’ systems so they can act on it without bothering you.

Similarly for requests on trends. Are you constantly asked how many users signed up this month vs last month? Make a dashboard and share it.

6. Last resort: hiring

Those who have never been managers sometimes don’t realise this is an option. If you’re overwhelmed and easily see a month’s worth of work for another person, consider hiring someone (congratulations, you’re now a manager).

Hiring should be a last resort: it’s expensive in more ways than monetary. The previous recommendations should stem the need for a while.

In a future post, I’ll cover how to best organise a data team at a growing startup. Until then!

‍