I recently left my job at NGP VAN, where I had been for about 8.5 years. As I’ve written before, it was a wonderful time, and I’m really glad to have been able to contribute to the progressive movement in such a meaningful way. Since leaving I’ve given a lot of thought to the things I learned there, and what I take away with me. There are all sorts of lessons, large and small, but here’s the most important insight by far.

Software is organizing: the two are in some ways very similar pursuits, which have a great deal to learn from one another.

The best organizing is a blend of listening and leadership, in service of progressive change. The organizer listens to her followers, and unites those followers together in pursuit of a goal that will improve their lives. That same basic process is evident whether you read Letter from Birmingham Jail, Rules for Radicals, or the Audacity of Hope. What is crucial for a successful organizer is the vision to see what that goal is. Just as importantly, the organizer must also have the vocabulary to describe that goal, and to share it with her followers in a way that brings them together. That is why organizers are so often remembered for their oratory: everything from Ain’t I a Woman? to Women’s rights are human rights is an example of striking language that breaks through the mold of conventional discourse to paint a picture of something we have not seen before.

Now, I never wrote anything half, or even a tiny fraction, as eloquent as Letter from Birmingham Jail. But I did write quite a bit - in fact my main responsibility, for the better part of the last few years, was documenting the API, and explaining it to a variety of clients, technical partners, and other third parties. In rather pedestrian terms the goal of all that communication was to help other software developers make successful API calls which would then be used to exchange data from one place (usually a third-party app) to another (usually the NGP VAN API). The mechanics of a successful API call are not very tricky, and we were able to document that part quite readily; indeed, there are even tools which will automatically generate documentation of API mechanics. The difficult part of the job was always in bridging the gap between how one person (usually a software developer for one of our clients) saw the world, and the way I saw the world: that is to say, in translating one data model into another. On a typical day, for example, I’d help a third-party app developer figure out which API routes to use to translate data from that app into data that NGP VAN users could query and analyze: when someone uses app XYZ to indicate she plans to vote, how should that data appear in the API so that a field organizer using NGP VAN can see progress towards a vote goal?

The software was only ever as good as the data model underneath it, and the ease of communicating that data model to stakeholders. That was certainly true for me, but I think it was true for all of my colleagues as well, even the ones who didn’t interact with outside parties very often. Every single thing a software developer does on the job is the description and modification of a data model. Sometimes that work is developing code to validate data before it goes in a database; sometimes it’s writing an email to explain how the code in question works; sometimes it’s attending a meeting to estimate what it would take to change or improve that code. We all did quite a bit of that, and I include in this statement everyone in the company, not just those writing DDL statements or posting pull requests in Github. After all, even the most sophisticated sales presentation needed to provide an explanation of what the system does and how it does it.

At the heart of it all is a data model, which is to say, a way of describing the world that is actionable. It’s actionable for software, obviously, in that there’s a body of code which interacts with the data, processes it, and moves it around. But it’s also actionable for the user, who can (by way of an interface) view the data, reason about it, add to it, and so forth. Sometimes the data model is rather trivial: there are at least a dozen different vendors in the progressive technology space who use the word “event” to refer to a real-world gathering of people at a certain time and place, with a certain agenda. Sometimes it’s quite complicated: the NGP VAN model of “districts” turns out to be quite subtle and in some cases counter-intuitive, owing to the fact that political districts take all sorts of shapes and sizes throughout the country. Indeed, even the use of the word “districts” to describe things as varied as voting precincts and county water boards is not entirely obvious at first blush. But that is the point - the data model helps provide a kind of vocabulary that allows us to move forward.

What software does, in essence, is to paint a picture of the world as it could be, and to provide a data model which describes that vision and makes it actionable. The best software is based on insight into the lives of its users, and feedback from them. The best software developers are able to listen to that feedback, translate it in terms of a data model, and create something new which changes the world for the better. And that, give or take a few curly brackets, is also what the best organizers do.

Now, to take some perspective: the best social change organizers do things that are orders of magnitude more astounding than even the most elegant and transformative software ever written. Civil rights, women’s rights: these achievements are decidedly more significant than widespread adoption of Linux or the proliferation of apps in an app store. And social change organizing requires depths of courage that is well beyond anything a software developer will encounter while tracking down a bug. I certainly don’t want to give the impression that we can replace social change organizing with more and better software: that is preposterous.

Instead my point is that there are some similarities between the two, and that software developers have a great deal to learn from organizers. There are lessons from organizing that should be near and dear to every software developer’s heart. For example, Saul Alinsky’s second rule of organizing, “Never go outside the expertise of your people.” Woe betide the software developer who makes something too complicated for her users to understand! There are also lessons that may be surprisingly useful in software. Take Alinsky’s eleventh rule: “If you push a negative hard and deep enough it will break through into its counterside.” It sounds a little bit like “move fast and break things”, but with quite a bit more world-wariness.

Viewed through the same lens, I think there is also a great deal for organizers to learn from software developers. As it turns out, communication about a data model has a vast literature surrounding it, and huge quantities of money and energy have been spent puzzling out exactly what it means and how to do it best. We have entire fields of study - such as user experience, data architecture, and so forth - that have quite rigorously analyzed how to communicate about the real world in an actionable way. I think there is no industry that is quite so obsessed with understanding the problems that people face in the real world, and formulating good, sometimes breathtaking, solutions to those problems. And in this practice, there is a good deal of valuable insight for organizers.

As it happens, I’ve been lucky enough to work with a wide variety of organizers, and to have read a fair amount about organizing over the years. I’ve also been lucky to spend quite a bit of time coding. And it’s been incredibly fascinating to see just how much the two pursuits have in common.