I have been working in the social sector for a while now. Long enough to see the same technology mistakes happen again and again, across different organisations, different countries, different causes. And to be honest, I have been part of a few of them myself.
This is not a finger pointing exercise. These mistakes are easy to make. Non-profits are stretched thin, underfunded, and under pressure to show results. Technology feels like it should help. And it can, but only when it is done right.
Here is what I have seen go wrong.
1. Treating technology like a magic fix
Something is not working. Donor tracking is a mess, reports take forever, and communication between teams is falling apart. And someone says, “We need a CRM” or “We need new software.”
Maybe. But more often than not, the real problem is the process underneath. If your workflow is broken, software just helps you do the broken thing faster. I have seen organisations spend months implementing a system only to realise they automated a process that did not make sense in the first place.
Start with the process. Draw it out on a whiteboard if you have to. Figure out where things break down. Then look at technology.
2. Chasing the shiny new thing
A new program manager joins. They used Asana at their last job, and now they want everyone to switch from Trello. Or someone reads about a hot new platform and suddenly the current system is “outdated”.
I get it. New tools are exciting. But switching systems is expensive and disruptive, and it seldom solves the actual problem. Most of the time, the issue is not the tool, it is how the team is using it (or not using it).
Before pushing for a change, spend a month actually understanding the current setup. Talk to the people using it daily. You might find the problems are fixable without blowing everything up.
3. Assuming “free” is actually free
This one burns slowly.
A volunteer developer builds you a custom donor portal. A tech company runs a pro bono project for three months. A fellowship places an engineer at your org who sets up a whole new system. Everyone is happy.
Then the volunteer gets a full-time job. The pro bono engagement ends. The fellow moves on. And now you have a system that nobody on your team understands, cannot update, and cannot fix when it breaks.
I have seen organisations accumulate three or four of these “gifts” over the years. Each one made sense at the time. But now they are sitting on a pile of systems that do not talk to each other, built in languages nobody on staff reads. That is not free. That is debt.
The question to ask before accepting any donated tech work: what happens when the builders leave?
4. No buy-in from leadership
This one is frustrating to watch because the tech side can be done perfectly, and it still fails.
If your ED or board does not care about the new system, does not use it, does not ask for data from it, does not bring it up in meetings, then nobody else will either. Staff figure out pretty quickly what leadership actually values. If the CRM is not one of those things, they will keep their spreadsheets and move on.
I have seen great implementations die quietly because the people at the top treated it as “the IT team’s project”. It is not. Technology adoption is an organisational change. It needs to come from the top.
5. Keeping technology separate from programs
This is a funding problem as much as anything.
Most non-profits think of technology as overhead. It is the thing the IT person handles. It sits in its own budget line, separate from programs.
But think about it. Your case management system is program delivery. Your donor database is fundraising. When you keep tech separate, it does not make it into grant proposals. Funders do not fund it. And then everyone wonders why the systems are falling apart.
I would love to see more organisations write technology into their program budgets from day one, not as an afterthought when things start breaking.
6. Not investing in training
An org spends six months picking a system and another three months implementing it. The big launch day comes. And then… they send around a PDF user guide and expect people to figure it out.
People do not. They go back to email and spreadsheets because that is what they know. Three months later, someone says, “the new system is not working.” It is working fine. Nobody learned how to use it.
Training is not a one-time event. People forget, staff turns over, and the system gets updated. You need ongoing support, not a single webinar.
7. No data strategy
Here is a scene I have seen too many times. It is the end of the quarter, a funder report is due, and someone is frantically copying data from three spreadsheets, a Google Form, and an old Access database into a Word document.
Non-profits collect a lot of data. But most of it is collected because someone asked for it, not because anyone planned what to do with it. There is no single place where it all lives. Nobody owns it. And when you need it, it takes days to pull together.
You do not need a fancy data strategy. You just need to decide: what are we actually tracking, where does it go, and who keeps it clean? That is it. But almost nobody does this upfront.
8. Copying bigger organisations
I have seen a 15-person NGO try to implement Salesforce because a large international organisation was using it. They spent a year on it. It was way too complex for what they needed, way too expensive to customise, and they ended up using about 10% of it.
Just because a tool works for a 500-person NGO does not mean it works for you. Your needs are different. Your budget is different. Your team is different.
Pick something you can actually manage with the people and money you have right now.
9. Building systems without asking the people who will use them
A consultant comes in, talks to the ED and the program director, designs a system, and rolls it out. The field workers who enter data every day? Nobody asked them.
Then the system launches, and it does not match how work actually happens on the ground. People create workarounds. They skip fields. They keep a parallel system on the side. And leadership can not understand why the data is garbage.
If you want people to use a system, involve them in building it. Not as an afterthought, from the beginning.
So what ties all this together?
None of these are really technology problems. Every single one is about people, process, and priorities. The tech is just where it becomes visible. Technology is just a tool.
I do not have all the answers. I have got plenty of things wrong over the years. But if there is one thing I keep coming back to, it is this: slow down. Understand the problem before you buy the solution. Talk to the people doing the work. And plan for what happens after the shiny new thing is not shiny anymore.
Not exciting advice. But it is the stuff that actually works 🙂
Good luck!
