We’re building out our data and analytics capabilities at GameChanger. This means that we’re facing conflicting priorities on the type of work that needs to get done. On the one hand the team needs time to focus on delivering the new products and projects that will help us tomorrow. However, we also need to make sure that the rest of the company gets the information they need while we build out. You can sum up these two constraints as:
- Don’t break the business
- Protect the team so they can make forward progress
In this post we’ll explain what we’ve put into place in the form of process to accomplish these two goals.
The Process
The main process vehicle we deployed is called the Data Interruption Process. The purpose of the process is to field any incoming requests from other teams and the business and shelter the team from continual interruption. As in software, we want to limit the expensive effects of context switching. The members of the team rotate weekly as the current person on Interruption duty. Before we get into the actual work and process for the person on Interruption (who we refer to as the Interrupter), let’s take a look at the other side and see how requests get submitted.
A Request
We use Trello to plan and track work at GameChanger. So for this it was obvious that we needed a Trello board to hold requests. An example of this board is seen below:
From the board it’s easy to get started. You can also see who’s currently On Deck, which helps to know where to direct questions.
When someone has a request for the team they go to the board and copy the request template. It contains a set of questions to answer to help qualify the nature of the request.
- Hypothesis
- What are you trying to figure out?
- Action
- What will you do once you know the answer to this?
- Data
- Population - such as objects (games, teams, users, etc.) and what filters
- Measurements - which metrics are needed
- Segmentation - for example sport and age
- Due Date
- When do you need this by. Not required.
By having this template in the card we’re trying to minimize the amount of roundtrips and back and forth trying to clarify what’s actually needed. We’re also trying to nudge team members towards filing requests with an actionable outcome. This is mainly to avoid the more research type questions. We also encourage requesters to plan out their requests in advance so we can avoid the “OMG I need this yesterday everything is on fire”-type of requests.
It’s important to manage the expectations and for that reason we have a stated Service Level Agreement (SLA) of filed requests of 24 hours. This means that you can expect a response to your request within 24 hours. This does not mean that the request will be filled and completed in a day, but rather that you’ll get a response on whether it can be accepted and completed and when.
The Work of the Interrupter
The successful Interrupter does three things:
- Manages requester expectations
- Triages daily
- Delivers on accepted requests
This leads us to the daily routine of the person on Interruption. At least once every day before standup the Interrupter will triage incoming requests. There are four outcomes of this triage:
- No:
- Won’t do, is not appropriate, not possible, etc.
- Moves request to the “No” lane.
- Need More Info:
- Not enough information to accept request. Interrupter will work with the requester to clarify.
- Goes to the “Need More Info”-lane.
- Accepted:
- Request accepted and the Interrupter will work on it during the week. The Interrupter communicates with the requester about when they can expect the completed card.
- Goes to the “Accepted”-lane.
- Move to Product Planning:
- Request is deemed too big to be fulfilled through the Interruption Process and will be included in the regular Product Planning process.
- Moved to Product board.
Once the work has been completed the card will be moved to the “Done”-lane and later archived. The Interrupter updates the card with the results, including details about what was done to obtain the results. Examples of this could be CSV files, SQL queries, etc. That way we keep a record of what was asked and how it was filled. We can later refer back to this if we need to run a request again, or if we want to dig into how we obtained a result.
Wrap up
The Data Interruption Process fits a pattern that’s useful outside of data requests. It’s basically the same pattern we employ when setting up On Call rotations and having a designated person for external contact. Keeping the balance between supporting and delivering to external stakeholders, while at the same time having enough uninterrupted time to get forward moving work done is key to running an effective team. We’ve had great success in employing the Data Interruption Process, and would recommend it as a pattern to others.