Digital Collaboration for NGOs: 5 Signs Your Team Is Stuck in the Past
Most NGOs bought modern collaboration tools years ago and kept working the old way inside them. This post covers five legacy habits that quietly slow teams down, why each one persists, and how to score your own organization before you spend anything on new software.
Key Takeaways
- More technology will not fix this. Digital collaboration comes down to default habits: the method someone picks when they need to share a file or ask a question. Those habits shift through process, reinforcement, and time.
- Email attachments, direct messages, and standing meetings are the three most common legacy habits.
- Data gatekeepers are usually a symptom of unclear ownership, not necessarily people protecting turf.
- Without a single source of truth, every other habit gets worse, because nobody can point to the current version.
- Score your organization first. Most teams find their biggest wins in behavior, not procurement.
If you have ever worked for an NGO or international organization, you know the software stack already. Microsoft 365 or Google Workspace, Teams or Slack, a cloud drive with plenty of storage, maybe a project management tool someone set up two years ago and abandoned.
Now think about how the work actually flowed. A spreadsheet named Q3_Indicators_FINAL_v4_JB_edits.xlsx arriving as an email attachment. A program manager asking a question in a direct message that four other people needed to see. A weekly call running an hour so six people could each give a two-minute update.
The tools are modern but the habits are from the 2010s. That gap is where digital collaboration actually breaks down, and it costs you duplicated work, decisions nobody can trace, and field teams waiting on someone's reply. Another platform will not close it.
This is rarely anyone's fault. These habits were sensible when bandwidth was scarce, offices were physical, and cloud tools were new. They simply outlived the conditions that created them.
What is digital collaboration?
Digital collaboration is how a team shares information and makes decisions using digital tools rather than physical presence. In practice it covers four things: where files live, where conversations happen, how decisions get recorded, and who can reach the data they need.
Each of those four areas has a default habit attached to it, and each one can quietly slip back to how the sector worked a decade ago. The five below are the ones we run into most.
Five legacy habits and what to do instead
1. Emailing attachments over sharing a link to one file
What it looks like: A file goes out to eight people. Three reply with edited copies. Someone merges them by hand. Two weeks later, nobody knows which version the donor received.
Why it happens: Email is the one tool everyone knows, and an attachment feels safe because you can see the file. A link requires trusting that permissions are set correctly, and most staff have been burned by a "you don't have access" message at least once.
What to do instead: Keep the file in the cloud and send the link. In practice that means Excel Online or Google Sheets for anything with numbers, and a shared doc for text-heavy work. This means one file, one location, and edit history built in.
Fix the permissions problem once rather than per file. Set them at folder level, or change the organization's default sharing setting so anyone internal can open a link without requesting access. Those settings are what cause most access issues, and correcting them is usually a ten-minute change in the admin console that nobody has been asked to make.
Watch out
Version control sits at the core of many issues a team faces. When several copies of the same indicator tracker circulate by email, your reporting figures depend on which attachment someone happened to open. That can lead to data quality issues.
2. Direct messages over shared team channels
What it looks like: Most of the organization's knowledge lives in one-to-one chats. New staff have no way to find it. When someone goes on leave, their context goes with them, and any question addressed to them waits until they are back.
Why it happens: A DM feels considerate. You are only bothering one person rather than a whole channel. It is also faster in the moment because you know exactly who has the answer. In an office you would lean over and ask, and a DM is the digital version of that.
What to do instead: Default to a shared channel and reserve DMs for anything genuinely personal or sensitive. Organize channels around work rather than hierarchy (e.g. one per project or topic). A shared channel keeps work visible to everyone who might contribute without demanding that anyone answer right away, which is what asynchronous communication means in practice: people respond when they can, not when they're pinged.
Tip
Before you interrupt someone, ask whether the question can wait a few hours, or even a day. Usually it can. GitLab's Remote Manifesto is worth a read on this: don't try to mimic an office, and don't pull someone from their work if you don't have to.
For teams working across time zones, this is the difference between work moving overnight and work waiting for one person's morning. The test is simple: if a second person could benefit from the answer, the question belongs in a channel.
From the field
A program team spread across Nairobi, Geneva, and New York moved their project questions from DMs to a shared channel. Questions that used to wait 8-12 hours for a reply now got picked up by a colleague in another time zone within the hour.
3. Calling a meeting over writing an update
What it looks like: A recurring call where each person reports what they did. Decisions wait for the next meeting. Colleagues in three time zones join at inconvenient hours to listen to updates that could have been read.
Why it happens: Meetings feel productive and they create accountability. They are also the only coordination tool many managers were ever trained on, so any ambiguity about who is working on what turns into a calendar invite.
What to do instead: Status updates are information transfer, so write them: a short weekly post in a channel, or a project board everyone can read on their own schedule. A shared whiteboard or comment thread often gets a design decision further than a call because people contribute when they have actually thought about it.
Key insight
Writing also forces clarity on the person asking. Putting a request in a sentence exposes the vague ones before they reach anyone else, and half the time the writer works out the answer while drafting the question. In a meeting, an unclear ask gets absorbed by whoever responds fastest and the confusion surfaces later.
Use live meetings for what they are genuinely good at: working through a hard decision, and building rapport. Teams that have talked about something other than deliverables give each other the benefit of the doubt when a message reads badly, and they ask each other for help sooner.
Tip
Try one change for a month: replace your weekly status meeting with written updates in a shared channel, and keep a shorter call for open questions and catching up as people. Teams that do this usually get hours back in their week, and they end up with a searchable history of what happened instead of relying on whoever took notes.
4. Gatekeeping data over granting access by role
What it looks like: One person exports the report every month. One person holds the primary contact list. Requests queue behind an individual, and when they are out of the office the information stops flowing.
Why it happens: This is almost never people guarding turf. It is unclear ownership plus real anxiety about data protection. Someone became the de facto custodian of a dataset because nobody defined who should have access, so restricting it felt safer than opening it up.
What to do instead: Grant access by role rather than by individual. Decide who needs to read, who needs to edit, and what genuinely must stay restricted, then give teams self-service access to everything else through a shared dashboard or reporting layer.
5. Scattered copies over one source of truth
What it looks like: The budget exists in three places. The activity plan lives in a slide deck, an email thread, and someone's notebook. Every meeting starts with five minutes of establishing which number is current.
Why it happens: Each copy was created for a good reason at the time, usually to answer a specific request quickly. Nothing ever retired the previous copy, so it carries on with a life of its own.
What to do instead: For each type of information, name the one place it lives, and make every other reference a link to it. For example, your project plan lives in the project tool, indicator data lives in the M&E system with definitions held in your monitoring and evaluation framework, and policies live in the document library.
Take a budget revision. If everyone opens the same file, they see the same number. If not, the decision to cut or extend an activity rests on whichever version someone happened to open, and someone spends the next week reconciling them.
From the field
In a recent user discovery exercise, staff described their reporting process as "sending the tracker around." In practice that meant five people moving the same file by hand every quarter. Once we mapped it, the fix was a shared workspace and clear ownership, not new software.
What good digital collaboration looks like
| Legacy habit | Modern default |
|---|---|
| Emailing an attachment | A link to one file, with edit history |
| Direct messages | Shared team channels |
| Standing status meetings | Written updates, with decisions recorded |
| One person runs the reports | Role-based access and self-service dashboards |
| Information spread across copies | One named home per type of information |
Score your organization's digital collaboration
Give yourself one point for each statement that is true most of the time, not just on your best week.
| # | Statement | Point |
|---|---|---|
| 1 | Files are shared as links, not attachments | |
| 2 | Most work conversations happen in shared channels | |
| 3 | New staff can find project context without asking anyone | |
| 4 | Status updates are written, not presented | |
| 5 | Meetings have an agenda and produce written decisions | |
| 6 | Program staff can access their own data without a request | |
| 7 | Each type of information has one agreed home | |
| 8 | Access is granted by role, not by individual | |
| 9 | Work continues normally when a key person is on leave | |
| 10 | Colleagues in other time zones are not disadvantaged |
8 to 10: Your default habits are healthy. Focus on keeping them as you grow and onboard.
5 to 7: The tools are in place and the habits are inconsistent. Pick the two lowest-scoring statements and change those default habits deliberately.
0 to 4: Legacy habits are shaping your work. Start with a single source of truth and link sharing, because the rest gets easier once those hold.
How we work
We are a fully remote team, so digital collaboration is not aspirational for us. These habits are how anything gets done at all.
Conversation happens in Slack, in channels rather than DMs, and we rarely send internal email. Project management and code both live on GitHub, so the discussion about a piece of work sits next to the work itself. Decisions get written down, because in a distributed team an unwritten decision effectively did not happen. None of this is fancy tooling. It is a small number of tools used with discipline, which is also the advice we give to organizations. These same habits form the foundation for AI adoption: if your team cannot collaborate on a shared document, connecting AI to your organizational data will not work either.
Key insight
Digital maturity, especially at later stages, is rarely about the software you use. It shows up in the number of default habits your team embraces without being asked.
Where to start
Technology and habits have to move together. A new tool with old habits tends to recreate the old workflow in a nicer interface, and new habits without the right tool ask people to work harder. In our experience, neither shift happens on the day a new tool goes live.
Key insight
People need a reason to change, and "the new tool is better" is rarely enough. They need to see how their own work benefits, or what it costs them to keep doing things the old way.
Less time on reporting, fewer meetings, not being the bottleneck when you're on leave: those are the payoffs that get people to change how they work. Habits then form through repetition, active leadership, and enough time for the new way to feel normal, usually months rather than weeks.
So resist the urge to fix all five habits at once, and resist the urge to buy something. To choose where to start, we use the same test we apply to features when designing an M&E system: is it desirable, meaning your team can see what they get from it; is it feasible, meaning you can change it with relatively low effort; and is it viable, meaning it removes a cost the organization actually feels.
Link sharing usually scores well on all three, which is why it makes a good first move. Change that one default habit, let it hold for a month, then pick the next. The same principle applies here as in how we build digital solutions: start small, get feedback, then extend. Organizations that try to change everything at once usually revert to their old ways within a quarter.
This post draws on ideas from books like Nolan Bushnell's Finding the Next Steve Jobs: How to Find, Hire, Keep and Nurture Creative Talent, which argues that the environment and default habits a team works within often shape its output more than the tools it is handed.
At Hikaya, we help NGOs and nonprofits worldwide modernize how their teams work together, from shared data access and reporting workflows to the day-to-day collaboration habits that make a new system stick.
If some of these patterns sound familiar and you are not sure which one to tackle first, that is a good conversation to have early. Start a conversation with us, or see how we approach discovery and design in our process.