This post was written by Katie Falkenberg from Good Good Work, with input from The Engine Room. Good Good Work is a co-operative working to change the way the social sector approaches tech and design challenges. At The Engine Room, we were interested to hear more about their approach and the way they see things. This post explores a common challenge for civil society: how to better develop and share technology development.
Pretty much everyone in our modern world needs technology to get their work done, including in the nonprofit space. As problem-solving technologists in this sector, we see a lot of requests for proposals (RFPs) from organisations looking for support with a technology project. The majority we see both fall short of addressing project needs and don’t tap into the power of sharing and collaborating. We want to dive into why that is and what we can do about it.
The fallacy of being unique
One common problem we see coming out of the nonprofit world is groups sending out requests to build new tech tools, which actually already exist. Here’s a generic example:
“Our team is looking to build a social platform for professionals in the sawmill industry. We have a list of requirements for this custom system. The budget line items are as follows.”
This kind of request throws up red flags in our organization. But why?
Thoughts from a development team
The first concerning item is the desire to build a new platform. As a rule of thumb, a new platform – especially a social one – will take a lot of time and energy to set up. Getting new users requires a lot of nudging (or prodding) and maintenance is likely to be expensive. That said, there are certainly cases when a social platform for an industry or community is helpful. In these situations we often encourage people to consider using an existing platform. We might recommend Mighty Networks, Scuttlebutt, Slack, Loomio, or maybe even Facebook. Why? They’re free or cheap and have dedicated technologists constantly maintaining and improving the platforms.
The second concern is the existing list of requirements. From a human-centered design perspective, providing solutions first is a dangerous approach. Instead, we’ve found it works best if you start by sharing your goals and how the technical person you’re searching for will help you achieve them. Focusing on the problems at hand, rather than what you might think is the solution, allows the technical person to lead you to the best way to address them. (It’s also easier on you! You want to bring your expertise – on your organisation and mission – to the table and allow your collaborators the space to bring theirs – technical skills and tools.) It might take a little longer to start from a problem- or goal-first approach, but you’ll save money, time, resources and heartache in the long-run.
The third concern is the budget. While overall budgets are important and help a development team know what kind of resources have been set aside for the work, setting it strictly with line items at the beginning doesn’t set the stage for collaborative problem-solving. It’s not an issue of the budget itself, it’s more an issue of work feeling fixed before it even begins. It can set a tone of non-collaboration or one-way power structure which doesn’t bode well for a cooperative relationship. Providing a high-level price range is a much better approach than making an itemized list of services.
What’s actually happening here?
After seeing many instances of this kind of ask, we end up wondering, What’s really going on here? And why does it keep happening?
I have some theories. They may not cover all the cases that exist, but they shed some light on this common – and usually detrimental – practice of thinking that building from scratch is the only or best option. They often include:
- Equating cost with quality (the more expensive, the better)
- A lack of awareness of existing solutions, often due to the complexity of the tech landscape
- Inexperience in building or maintaining tech tools
- Not having an understanding of future maintenance cost
- A desire to feel unique
- Attraction to new and shiny tools
- The perceived incentive to overspend and therefore secure bigger budget next year
- Lack of internal accountability or a tech maintenance plan for existing tech (e.g. having a failing legacy system needs to be rebuilt)
- Excitement for a new internal project
Why this isn’t a special case
Does this feel familiar to you? Maybe you’ve been part of an organization that’s requested or engaged in this kind of work. Or maybe you’re currently part of an organization that’s thinking about putting out an RFP for some tech work. If so, the good news is that your organization likely doesn’t have a very unique technical problem – in fact, we hardly ever see a truly unique challenge – and therefore likely doesn’t need a unique technical solution.
The fact that the example above – and many problems non-profits come to us with – isn’t a special case is a good thing! It means that there’s no need to spend all that extra money and time crafting something bespoke. Instead, you can use a simple or shared product, save time and money, and promote a sense of community.
Why sharing = winning
The reason why special cases are rare, and uniqueness is often a fallacy, is typically because we have similar human needs. Similar human needs lead to similar technical challenges for groups as well (e.g. I need a CRM, event registration system or email marketing client, etc.).
In some cases, existing technologies can be used to solve these technical challenges – from large enterprise technology solutions like Everyaction, to smaller open source options like CiviCRM. The key here is doing some research, or hiring someone to help with discovery, to figure out what solutions may already exist. We always suggest groups consider this option first.
Other groups can work together to build shared technologies. These are groups for whom existing solutions are not an option. Though it might seem like their next step is creating a new solution that fits their particular constraints (timeline, technical features, budget, etc), that’s not what we’ve seen works best. Instead, there are often other groups with similar problems, looking for similar solutions. Bringing these different groups together to build shared solutions makes financial sense, helps build stronger communities and contributes to a brighter shared future.
Saving money and time
Imagine if instead of paying $15,000 for a uniquely catered, one-off, custom system, you gathered seven teams with the same needs and had each of them pay $3,000 for a shared system. Having $21,000 in the bank would allow a technical team to build that same custom system and spend the remaining money on documentation, additional modules, help with implementation, ongoing support and the like. On top of that, the additional savings for each group could be applied to their other needs.
Building communities & resilience
From a cultural standpoint, working together to build a shared resource makes communities stronger. It creates a network and strengthens loose ties between groups. It builds solidarity and shared trust. It decentralizes power and demystifies technology. It provides a “platform” for exchanging knowledge and skills. And it reduces the need for proprietary software. If you really want to get into it (we hope you do!), you can check out the movement to build cooperatively owned platforms.
Finally, the reality we face as social changemakers is in some ways dire. Civic spaces are shrinking, while corporate power is becoming more consolidated. Globally, citizens are losing trust in their governments. If we’re going achieve our mission(s), we’ll need to be more effective. And we can be! To do that, we need to be smarter about the resources we have, waste less and share what we can.
It’s true, some resources are harder to share. Tech resources though — when built to be open source (or free) and long-lasting — are inherently easy to share. Let’s start there.
Good Good Work is a worker cooperative based in Denver, Colorado. They support folks doing good work on the front lines of change by combining technological expertise, design thinking, a mindful eye to culture, and considerations of interpersonal dynamics to group challenges.
The Engine Room is an international organisation that helps activists, organisations and other social change agents make the most of data and technology to increase their impact.