I’ve been reflecting on some of the challenges I’ve faced across multiple organizations trying to leverage the power of technology to create positive social change. This reaches way back to my work as a Peace Corps volunteer, up through grad school, my time as a contributing editor at OLPCNews, and through multiple NGOs balancing tech, impact, and budgets.
Obviously, there’s no definite one-size-fits all approach to implementing technology in any sector, much less the world of the international NGO that stretches from hip online platforms to how to best use dusty Nokia feature-phones.
Here are the principles I’ve come up with to date. I took these to Twitter in a lively discussion, and want to expound upon them a bit more:
- Build for sustainability. Minimize what you have to build yourself, and leverage existing platforms This means giving strong preferences to open source platforms or at least existing services that meet a set of criteria (their service meets your needs, you own your data, shared values, track record...) For any service, someone, somewhere has already built a powerful framework that will be constantly updated and improved, and bakes in thousands of features (security, translation, powerful content management, mobile interfaces, etc.) which will be effortless to turn on when you discover you need them. Focus your precious software development budget on the much smaller number of things that are custom to your work and don't exist. This greatly reduces the initial dev costs as well as ongoing maintenance costs.
- Seriously, don't build it yourself. You are probably not the special snowflake. Benefit from the work of others. Yes, there are exceptions, but try not to be one, focus on your unique value, and stand on the shoulders of giants for the rest. It's not just building on any tool, though, it's selecting an open source framework or commercial platform without exposing yourself to risk (with open source, the only risk is that the platform becomes less popular, with commercial systems, you are somewhat dependent on their services, so you need their skin in the game via contracts and exit practices) Regardless of the path, a solid selection means you enjoy the vast benefits of 80% of the work being magically upgraded and improved over time without further investment.
- What you do build, build for flexibility You need architects, not just interior designers. How you build your product matters, and you need to consider the functional and informational architecture. Make sure your architectures is flexible and secure. This will be supported or even forced upon you by wise decisions in the platform you're building on top of, and will make adding new tools/widgets/features/etc. so much easier in the future. Send wireframes to your designers. Send an architectural discussion and a spec document to your developers. A sketch of a webpage on the back of a napkin is fun, but it's not product design.
- Build in security. This means protecting your technical infrastructure, having HR policies, testing your code, and protecting the data your users are trusting you with. This can be annoying and feel like a time sink -- that is, until you get hacked and have to send out that email to each and every user about resetting their passwords, checking their credit card bills for fraud, or worse. It's past time we respect the private data of those we're trying to help. -- No really. SSL, encrypted passwords, secure systems - don't be the NGO whose PLWHIV/A internal database with names and addresses gets leaked online.
- Context. No tech tool works without respecting local context. Learn from flame-outs like Play Pumps and OLPC. OLPC is particularly valuable, because they followed all the rules above, but absolutely ignored and resisted dealing with context at the outset, and it really hampered their vision. This goes beyond translation, it means working closely with the community you hope to have a positive impact on, creating targeted guides and trainings. Dealing with context goes deep and goes beyond technology, so I don't want to get lost in the weeds here, but no matter how awesome and amazing your tool may be, without relevance, it's not going to go very far.
- Draw borders Create some minimal distance and padding between your vision and usability, between mission goals and minimum viable products, between perfection and function. It takes a lot of self-control, wisdom, and humility to not fall into the trap and drink one's own kool-aid about how unique your project/platform/needs are, justifying building from scratch, not worrying about security, and presuming the context will work itself out. Envision what will happen to the project when you leave - maybe you have a life-changing event and need to quit the project in a week. Is the team empowered to continue forward without you? Will the next person sitting in your seat curse your decisions, or even be able to make sense of the project? The best way to do this is to hire smart people who are willing to disagree with you - and trust them.
2016 UPDATE: This recently got a ton of twitter-love (thanks to the amazing https://www.fabriders.net , https://twitter.com/FabRider/status/715549773172981760 ), so if you’re reading this, you should definitely check out the Digital Principles at https://digitalprinciples.org/