Advocacy Tech Spaghetti and How to Avoid It

Tech spaghetti is when various software/app programs start to combine and twist around one another without any sort of guiding principle, and at the end of the day no single person in an organization knows why all of the software is there and how it is all supposed to work together.

Too often advocacy orgs use too much technology, inadvertently creating a tech spaghetti problem. How do you know if you use too much tech? If you are holding multiple pieces of tech together with humans who have to do data input and transfer, and you don’t have a good answer to how and why the tech stack works the way it does, you have too much tech.

Tech Spaghetti In Your Office

We are all guilty (collective we being those who this blog is mainly for, i.e. those who already give a damn) of wanting technology so badly that we use too much of it. This is a small paradox I want to touch on, because it is also true that we need to integrate technology more fully into our strategic vision of advocacy, at both the organizational and community level, and need to have a goal for its use.

The paradox is small, because it is easily resolvable: we try to compensate for a lack of time spent training on how to use and maximize the value of technology we do have by bringing on additional technology “solutions” that, in the end, take us farther from simplifying our lives via automagic/automation. (Think about, for example, how much you have really customized your case management system to take advantage of its full suite of options – chances are that you are using only a fraction of available features.)

As a result, it is possible to produce a jumble of tech spaghetti within ones organization relatively quickly, because we live in a time when adding new software takes just a few clicks on the internet. Tech spaghetti is when various software/app programs start to combine and twist around one another without any sort of guiding principle, and at the end of the day no single person in an organization knows why all of the software is there and how it is all supposed to work together.

Ways to Untangle the Tech Spaghetti

You have to think of advocacy organizations like a finely tailored machine; alternatively, think of projects within the organization as their own individual machines An machine has a specific set of goals it is designed to accomplish, and a set of protocols to accomplish that goal again and again. Within the context of Duck Duck Goose flexibility is of course necessary, but this means that flexibility needs to be built into the assumptions underlying the machine.

Adding technology to that machine shouldn’t be done haphazardly, just like adding random electric parts into the motor of your car shouldn’t be done on a whim. Yet, we do that all of the time.

What I have learned working with honest to God real computer developers and development teams is that app product designers who are good at their job never start with untested assumptions about why a piece of tech is good for a particular org. Rather, they study a family of organizations or individual issues, and work to develop a detailed definition of a problem that tech could solve.

This is exactly the same process that orgs themselves need to go through.

An Easy Exercise

I am in love with the Strategyzer line of products. They are an accessible set of resources to help you think through the pains and jobs that define your organization. Usually this is an analysis conducted on customers or target client group you plan to serve, but it is just as well done on yourself when you are thinking of becoming a customer for a particular tech product.

Using this matrix as a base, the first thing you could do is take your team through how it is that you currently accomplish whatever task it is you wish to automate or improve the automation of. You should go through it in detail from every conceivable angle.

For example, if someone is registering a new client for a mass detention project, which requires going into the detention center, start with the phone call or office visit that precipitates the visit and from there ask: how do we take information in at the first point of contact (paper form? digital form? hand scribbled notes?); then where does that information live (excel sheet? google sheet? Airtable? in your drawer?); then, what happens after we get the information into wherever it is that it goes (does it go into another database? do you create a visit list? do you forward it to someone else?); what kind of software do we use to transfer the case? or create a visit list?; this goes on for a while…

What I have seen visiting projects around the country and talking to advocacy leaders is that this process often reveals a long list of tech products that are filling discreet roles in a service process. A form program is often taking in information from phone or online consults; one, though usually several, free database programs are holding on to the information; case management systems and scanners hold on to different versions of the same info; hotlines are run through discreet software packages.

And due to the fact that there is not really an ecosystem of software that caters to the needs of advocates – not in the same way that various ecosystems cater to real estate agents or doctors for example – the task of connecting the various systems is rarely automated or intuitive, because the software companies simply have not built out the necessary functionality.

Usually but not always there is one, or at most two people that understand how all of the tech is supposed to work together.

Mapping this out, figuring out where the redundancies are, and then figuring out if anything that’s available can be a more wholesale solution for the pains and jobs identified becomes possible, but the work here has to be done.

A Final Word on Tech Spaghetti

I think it is incumbent on tech companies in the advocacy space to work together with organizations to build APIs that can talk together. By opening up our programs we can offer solutions to Tech Spaghetti and other problems.