My Year Working in Politics: 10 techie takeaways

10 takeaways from a techie working in politics.

January 5, 2021 | 📍 New York, NY

1. Naming for internal projects matters- avoid terms that signal extra complexity.** The internal stakeholders (the middle layer between you and clients) that see your product might not be comfortable scrolling through the github repo or asking technical questions. They probably don’t have the time or desire to read through the documentation. You need internal stakeholders to want to use your product in order to deliver value to clients. Think carefully about internal product naming and communication to avoid signalling extra complexity that scares away internal users.
2. Watch out for dependencies between projects, this quickly becomes a source of fragility. In US politics, insights across forecasting, resource allocation, and message testing can inform modeling approaches to products in each category. This makes it very tempting to add outputs from one product to the inputs of another. Warning: this rapidly becomes a hellish chain of interdependent parts that will blow up in insidious ways if not thoroughly documented, tested, and controlled for in the case of failures. Add github tags and make baseline independent product versions easy to revert to.
3. People are passionate about all parts of the machine being built. People (especially techies) take significant paycuts to work in politics because they are passionate about impacting this space. This translates to almost everyone feeling a strong sense of ownership and emotions running high. Recognition, validation, and affirmation seem to matter here more than in other work environments because everyone cares a lot and politics is tense.
4. Make documentation and modeling outputs as accessible as possible If information isn’t consumable, people won’t see it and as a result we are less likely to catch bugs and data errors. Do not expect people to look at sql tables. Put things in spreadsheets with conditional formatting (ie pretty colors) and add daily or weekly email notifications as things change. The best model is the one with outputs people actually look at.
5. Be very clear about next steps at frequent time intervals. Signpost dev vs. prod versions. Because emotions run high and product accessibility differs, it's easy for folks to feel left out of the communication loop. Put all possible stakeholders in a slack room and bullet out product updates and next steps. Be clear on which updates are “dev” or experimental changes and which updates are “prod” versions that will be included in shipments. Let people know rough estimates and uncertainty around timelines. Since not everyone has a clear idea on how much work a technical ask may be, its important to set expectations.
6. Centralize information with outputs and track refresh times. A huge pain point were the communication silos that existed and product information being separated across teams and repositories. This is exacerbated by the cyclic nature of politics that results in high team churn and tight deadlines that make it difficult to onboard new people. To help avoid losing information, empower people to access your product by putting documentation, modeling metrics, metadata, and other outputs in one place. Add “date run” columns to tables and spreadsheets so that client-facing people can easily see when the data was last refreshed and play a part in identifying bugs or etl issues.
7. Consistency with past shipment results is important. Machine learning in politics means using modeling approaches to explain real-world phenomena as they are unfolding. Our clients typically have many years of experience in politics; when they think our models are wrong they have usually been right. As we come to conclusions about the world and communicate these data-supported narratives to clients, its important that 1) we recognize our client’s priors and 2) these stories align with previous ones told or we provide good reasons for why they don’t. As a result, there is pressure to have a sprint of calls and experiments before any client shipments begin in order to validate our modeling and framework assumptions. We are not in a position where our clients can catch our bugs for us. This is a challenging development environment.
8. Don’t let communication break down- maintain recurring meetings with your core team. Trust and good will can break down fast when emotions run high, not everyone can access the code/product, and people are overworked, underpaid, and sleep-deprived. Check-in with your teammates. Meet with them at recurring intervals. Its easy to feel like you’re alone in the trenches when you are building out a product solo that other companies would dedicate entire teams to. Recurring check-ins will help.
9. Be a psychologically safe place for your coworkers. Politics is not known as a space that is safe for iteration and risk-taking. Give your coworkers permission to fail. Foster a community where you ask each other to think bigger. Support them during meetings that they are in and not in. Encourage them to take time off and offer to pick up on-call rotations or engineering tasks. In a field where people are quick to check you, let your coworkers know that they can be authentic around you.
10. Schedule rejuvenation. Machine learning and politics is new, as in barely around 4 years ago. Working in this space is hard. Coding in this space is hard. You will fuck up. While you may be aligned with the vision of what you are building, if you don’t take time to rejuvenate you won’t have the creativity and the clarity to handle the waves of the political news cycle. Don’t wait until you are burnt out. Schedule in mindfulness practices, yoga, walks, calls with friends, eating delicious italian food, or other things that give you energy from the start. Treat these calendar blocks as sacred. Rejuvenation gives you space to make the vision, the why, clearer.