Data Clinic and Data Requests @ Ro

Or, “How to Get Everyone the Data Services they Most Need at a Crazy-growth Organization”

Here are some of the processes, tools, and resources we provide to business units at Ro to get them the data support they need:

2x Daily Data Clinic

Every day at 10:30am and 4pm we hold “data clinic” in the company kitchen area. This is an office-hours style resource where anyone can come for any sort of data assistance, from pulling a specific number from Looker to unstructured training to Excel tips and tricks to sound boarding for analytic brainstorms.

Kevin, presiding [photo credit: Danica]

Data clinic was implemented for two main reasons. The first is to provide easy access to the data team for anyone at Ro, no matter what it is you want to figure out or get done. The second is to keep the data team generally focused on the projects that have been strategically prioritized by all of the business departments; the data team is a helpful group, and we were having difficulty not always treating ad hoc questions we were getting via Slack / in-person as the most urgent thing that we needed to be doing. With data clinic, business departments get their day-to-day questions answered and the data team gets to be its happy and helpful self while still remaining focused on top strategic projects.

There are a few rules of office hours (where would we be without rules?!). The first is that all attendees must sign in using a Google Forms link that we provide. These responses all automatically go into a Google Sheet, which we then use to track who is visiting and what questions people are asking — this information is very useful as we work to improve availability/accessibility and also build out supplemental resources like training, documentation, etc. The sign in form also serves to ensure that attendees are aware of the other rules of data clinic. The second rule is that nothing done in data clinic is considered “officially verified”. This refers to a separate process we have for verifying data that will be going on large presentations, official communications, etc — the process is quite rigorous and strict, and we want to emphasize that someone shouldn’t use office hours to pull a completely new stat that will then get sent to news stations, for example. The third rule is that nothing begun in data clinic will be worked on by the data team outside of data clinic. This is to make sure that requests are not circumventing the prioritization process. To be clear, if we think that an issue surfaced in office hours needs to be escalated or handled immediately, we take appropriate actions to do so.

Sign-in form — this gets logged in a spreadsheet where we add supplemental information about why that individual came to office hours

One of the primary uses for data office hours is filing larger data requests through our service desk system. We’ve found that data requests filed with the help of someone on the data team are often more effective — in the sense that the immediate action-item and the larger context of the request are both very clear and therefore can be acted upon quickly — than without.

Data Service Desk

A screen-grab from the data team’s service desk homepage

A larger request for the data team (i.e. something that can’t be accomplished within office hours) starts as a Service Desk ticket (we use Jira’s Service Desk plugin). These tickets usually then get moved to one of our project board queues.

Here is our form for “General Data Request”:

A screengrab from the “General Data Request” form

Regarding the field titled “The Larger Question”, we ask this to make sure that the specific request will actually benefit the requester in the manner that they are intending. Also notice that data requests need to be approved by a point person within the requester’s department (usually the department’s head). This was implemented in partnership with the department heads — we’ve found that department heads are an excellent first-pass at prioritization, as they can prioritize all of the requests from within their department against each other.

Data Verification

Data Verification is a separate and elaborate topic. The summary version is that new reports for officially circulated metrics must go through a data verification process — there are several versions of this process, depending on the metric’s type/source and also what the stakes are.

Bugs and Outages

Bugs and outages are reported to us in our Slack channels and default to immediate priority unless determined otherwise. Generally, we like to think that we have lots of automated outage/error checking and that we catch rare outages before they get reported, but on occasion it’s still business users who are the first to catch that something’s amiss.

The way we determine whether a reported bug/outage is real is by asking the person “Is this something that was working before and stopped?” This helps us distinguish cases of individuals trying something new unsuccessfully.

“Misc” Queue

Every member of the data team has up to 45 minutes per day allotted to miscellaneous tasks taken from the “misc queue”, which is entirely separate from our main tasking queue. This allows us to address small asks in a quick manner. At the same time, the daily time cap prevents these asks from stopping work on high priority projects.

Jira Queue Transparency

We’ve given nearly full view access for our Jira boards to anyone who might want to make or follow a data request. This allows business teams to see how their requests have been prioritized relative to other requests — if they think that this prioritization is incorrect, we welcome them to surface this with us and we will work with all stakeholders to see if a reassessment of the queue ordering is warranted.