It is hard for political Data Teams to set goals. Coming up with work to do is not the problem: we often sit on large backlogs of technical debt, dashboards to create, and infrastructure to build. The challenge lies in sticking with the plan.
Our teams are under-resourced. We are expected to do two to three times the work as our tech counterparts with a fraction of the resources. It can be challenging for our data teams to do anything but respond to the day-to-day demands of the organization. I know so many progressive data professionals that barely tread water. Our inboxes are overflowing, our calendars are full, and every Slack notification ping sends us into a panic.
To compound upon these challenges, our work is volatile. Our activities and programming are tied to the chaotic, ever-changing political landscape. Your candidate drops out; a bill suddenly has a narrow opportunity to pass; there is a new funding opportunity to pursue a new program or research experiment; a climate disaster hits the country, and you’re in rapid response mode.
I mean, who among us has not attempted to set goals only to realize six months later you haven’t accomplished any of them? Setting intentions is one thing, but when your organization's needs change, your original plan might no longer make sense.
You can read all that and conclude that goal setting isn't worth it. I know if I were to bring up setting OKRS (objectives and key results) with my old coworkers that it would be met with groans and eye-rolling. The anecdotal evidence is stacked in favor of abandoning goal-setting altogether and giving in to taking your work day by day.
However, I have a different take. I think a roadmap can be one tool in your toolbox as a political data leader to fight for the funding, capacity, and space you need to do good work. You can present your roadmap as an argument: that if your team is expected to X for the organization, Y is needed in return for your team. It unearths all the invisible things your team is responsible for in order to produce the more visible products (namely dashboards and reports)
In this article, I want to walk you through how I create a roadmap with my Data Team and then use it as a tool to advocate for the resources my team needs.
Building a roadmap
For this blog, I am assuming you are building this roadmap virtually like I am; however, this agenda could very well be adapted for in-person use. A virtual tool I love to use for meetings like this is Miro. Miro is a collaborative whiteboard space with dozens of pre-made assets to assist you in idea generation, retrospectives, icebreakers, and more.
1. Pre-work
I first assign my data staff pre-work to prepare them for an idea generation session. This pre-work consists of an exercise to reflect on the previous year. I start by preparing a document outlining the previous year's goals and a symbol indicating whether we met the goal or not.
I ask my team to read through the document and respond to the following prompts:
Why did we achieve the goals we did?
Out of all these achievements, which are you most proud of and why?
What stopped us from achieving every goal? Was there a change in team priorities? Did we get sidetracked?
Were we too ambitious in our goal-setting? Or not ambitious enough?
If you did not make goals for the previous year, you could lead your team through an exercise to note accomplishments and indicate where your team fell short.
2. Lead an idea generation meeting
After getting the juices flowing, it is time to gather the team and lead an idea-generation workshop¹. I like to set aside a least an hour and a half for this full-team activity.
Here is a rough agenda that I tend to use for these workshops:
1. Orient the team to the exercise
Like all good meetings, I communicate the purpose and expected outcomes for our time together. I explain to the team that over the next hour and a half, we will walk through a series of exercises to generate ideas for our team's roadmap and leave the meeting a sense of what the team believes it needs to focus on. I also use this time to explain the decision-making process behind the roadmap. For my team, I make it clear that while this session is designed to gather feedback from every member, ultimately, I—as the team director—will design the final roadmap.
2. Review the pre-work together.
Then to kickstart the idea-generation session, I lead the team through a group exercise to review the pre-work. On Miro, I present a matrix with one axis for work we intended/did not intend to do and another axis for work we accomplished/did not accomplish.
I use Miro to set a 5-minute timer (with music!) and ask the team to fill out the matrix using the sticky notes on the board.
When the timer is up, I pose the following questions to the team:
Of all the work this team achieved, what are you most proud of (celebrating wins is crucial to this work! You cannot only focus on the work that is yet to be done—it is not good for morale).
What do you notice about what we did not accomplish?
What patterns do you see on this board? Did we bite off more than we can choose?
What external factors acted as barriers to us accomplishing more work?
The purpose of this exercise is to unearth blindspots on your team. For instance, do you tend to overestimate capacity? Did you not take into account the baseline of work required, such as responding to tickets, managing your CRM/s and voter contact tools, and/or maintaining infrastructure in production? We are not trying to grill our teams but instead to illuminate what new strategies and techniques are needed to make a better road map.
2. Present organizational priorities
Next, I present a timeline of the organization's priorities. This is the canvas for which I build my team's roadmap around. To construct this timeline, I spend a couple of hours in conversation with key leaders and organizations on staff before this workshop, asking them about their priorities for the year. As I conduct these meetings, I am looking out for key races and election dates (both primary and general), programmatic dates (for instance, my organization hosts an extensive candidate training program), and fundraising and compliance timelines (as an example, we do an annual true-up at the beginning of each year). I know that it is impossible to plan for everything that will happen in the year, but in conducting all my meetings, I am aiming to account for around 70% of my team's expectations.
I take all this feedback and build a timeline visualization for my team (an example of one is above). These deadlines become the bricks of our roadmap that we must not only build around but build in support of. For example, if we know we have a critical primary race we not only know that we will not have much room in March to take on large projects but can work backward to understand what we need to build in February and January. We can take this"work backward" approach to all key deadlines on our timeline.
3. Idea generation
After giving the team a couple of minutes to review the timeline in the workshop, we can finally jump into idea generation. I prompt my team by asking them, "Given the timeline we just reviewed, what must our team do this year to meet the organization's needs? And, what can we do to go above and beyond those baseline needs?"
Because that prompt is very broad, I present my team with "buckets" of work to build ideas around. For my team, it is natural to break our work into the categories of analytics, engineering, and data & tech support. For your team, you may use totally different buckets. The point is to give your team something solid to build their ideas around (as opposed to making the idea generation session a total free for all).
I then set a 3-minute timer for each bucket and let the team generate as many ideas as they can under that time limit. As with any good idea-generating activity, no idea is a bad idea. We are going for quantity over quality. One silly idea could trigger a brilliant thought in another team member.
4. Voting on ideas
Now it is time to vote on all those ideas we just came up with. You almost certainly created more ideas than one team could feasibly tackle. We use voting to determine alignment among the team and, in turn cull the responses.
In Miro, I open a new voting session and give every 4-6 votes. You want to keep the number of votes per person small, despite whatever complaints your team may throw at you. Limiting the number of votes each team member gets forces people to make tough decisions and prioritize what will be crucial to your team's success.
Review the ideas that received the most votes when the voting session is over. If there is still time left in the workshop, you can ask the team for their commentary on what rose to the top. Regardless, at this point, you should have more than enough material to start piecing together a roadmap.
4. Finalizing the roadmap
Your role as a data leader is to then take your team's ideas and turn them into a concrete plan. This is more of an art than a science. Here are the questions I tend to ponder as I create my final roadmap:
What absolutely needs to get done this year?
What would be nice to get done this year, and when would we be able to work on it?
Is there something I know needs to get done that my team did not flag?
If nothing else changes about my staff capacity, what do I think is a reasonable amount of work?
What months will we be able to focus internally on our infrastructure?
What months will we need to be more attuned to the organization's needs and programs?
By the end of this activity, you should have a 2-3 page document listing the key areas of work and projects your team needs to tackle, and by when.
Your roadmap as a tool
You thought you were done? After you have gone through all that work to build your Data Team's roadmap, the real fun begins. Your roadmap serves two purposes: 1) it is a data-team-facing project management tool to guide your work, and 2) it is an external-facing tool to communicate your needs to your non-technical staff.
Here is a scenario I imagine many of you have been in before. An organizer comes to you and wants to know how many doors you knocked on in a particular race quickly to report back to the campaign. But to answer that question, you first need to track down your doors data, which could consist of data coming directly into the warehouse from your in-house voter contact tools, partner data that has been emailed to you via raw CSVs, and vendor data that is sitting on someone else's laptop. Maybe among all this, you notice a bug with your VAN canvass data—the data were logged wrong, and you need to take the time to resolve the error. And then, once you have managed to track down all the data, you have to normalize everything into a standard data set. Only then can you report back out the number of doors you knocked. All that is to answer a one-off question. If you are being good, you will do even more work to build robust, evergreen pipelines to answer this question more quickly and accurately in the future. The work you did between receiving the initial request and reporting the number often goes unseen by our organizers and other non-technical staff.
My favorite explanation of this phenomenon is from Emilie Schario, who made the "building a data team" iceberg meme pictured below. The meme entails an iceberg with the section above water labeled "pulling a number real fast" and the area below the water all the work needed to support such a task. If I were to build my own data team iceberg, a large section would be dedicated to cleaning messy organizing data and other labels for VAN maintenance, engineering and maintaining syncs, managing my Python development environment, and resolving dbt production run errors.
As progressive data leaders, our job is to communicate the chunk below the tip of the iceberg in a way our non-technical staff can understand. Your roadmap is now one tool you can use in that conversation. When you next meet with your manager, boss, or executive team, you can present your roadmap and explain the value to the organization if you can complete your plan. The key is translating data and tech work into organizing and political wins. For example, if you can have three weeks to build a set of new engineering syncs in Q2, you can talk about how your organizers will have access to more accurate volunteer data in VAN and, in turn, better recruit for shifts for the next election. If through this exercise, you have realized that your team needs another full-time staff member to conduct its work, you can leverage your roadmap in your budget justification. Whether it is more time to focus on internal-facing syncs and infrastructure, increased funding to hire staff or better tooling, or simply more grace from the people relying on your team's outputs, your roadmap is now an essential part of your metaphorical toolkit as a progressive data leader.
In a world where so many of us are underpaid, under-resourced, understaffed, and overworked, a progressive data leader's role is to advocate and organize for that funding, resources, staff, and boundaries. We do that work by building relationships with our staff, sharing our vision, and advocating for what we need. You can leverage your roadmap in those conversations to illuminate the volume of work output by your team and what inputs are required in return. I hope that through this road mapping exercise, you emerge in a slightly better spot than you started out in.
Wrapping up
Your roadmap as a living document. Make a plan to check in on it regularly. I like to start each quarter with a retrospective and a review of our roadmap. And while we are at it, do not be afraid to kill your darlings. As mentioned at the start of this post, the conditions in which we conduct our work rapidly and chaotically change. If you need to adjust your plans halfway through the year, that is okay! The idea is not that you never abandon your goals but do so with intention. It is one thing to switch gears to a new program to meet the needs of an emergent political crisis than to fail to meet a goal because you got swept up in the day-to-day support ticket work. Being mindful is the name of the game.
If you work in political data and have had success with setting goals and building roadmaps, I would love to hear from you. What tactics and strategies did you employ to make your goals stick, and how did your non-technical staff react to your goals? If you still swear that OKRs a psyop from Google, I would also like to hear from you. You can leave your thoughts in the comments below.
¹ I use the word "idea-generation" specifically and maybe a little bit pedantically. In college, my favorite engineering professor drilled into me that "brainstorming" was just one idea-generating activity. It has been years, and I still use "idea-generating" as the general term and "brainstorming" to refer to the act of a group of people proposing ideas in response to a prompt during a time limit.