Download to read offline
Editor's Notes
- #2 Hi I'm Keith, I work at SIMLab, we're a nonprofit that helps organizations around the world use technology to build more accessible services. I'm going to talk a little bit about thinking about technology in the context of a larger system, and how you can use this way of thinking to plan, execute, and evaluate technology projects more effectively. We see a lot of technology projects that use what I like to call "underpants gnome logic".
- #3 That is, step one is build an app. Step two is sort of jazz hands, and step three is the problem is fixed. And this isn't a great way to make technology—
- #4 it is a great way to make a lot of money disappear.
- #5 So how can we plan projects to avoid this type of trap? We argue that often, your technology problem probably isn't a technology problem.
- #6 That is, whatever you're trying to do from a pure technology perspective--the transmission of information--has almost certainly been solved by someone in some domain. It's just a matter of finding where that solution is, and applying it to your context. But that doesn't mean you don't have any problems. Often, your technology problem may be another type of problem in disguise.
- #7 For example, your technology problem could be an information architecture problem. So if you have a flowchart
- #8 for say, getting a green card in the US, you might be ready to turn this into an app. And this looks really complicated. But look at some of these questions:
- #9 Are you a spouse or unmarried child;
- #10 are you an unmarried son or daughter and 21 or older;
- #11 are you a married son or daughter;
- #12 and are you a spouse, unmarried child under 21, or adopted orphan? Technology may not solve this, as much as say, refactoring the structure of how you ask questions. Our other hope is that technology will help make us more efficient, and help us build better processes. And it can! But your problem then is really a process problem,
- #13 which means that technology project that you build needs to examine the human processes first--So, if you're creating an application to help people get IDs, you might first look at the requirements to get IDs,
- #14 which would include a birth certificate. And you might see that a birth certificate can be obtained at the department of vital records.
- #15 And then you might see that in order to pick up your birth certificate at the department of vital records,
- #16 you need a photo ID and you’re living in a Kafkaesque dystopia. As much as we might want it to, technology can't always solve the problem of living in a Kafkaesque dystopia (or Washington DC, in this case). And it isn't just about process problems left unsolved. Sometimes it's about process problems that are created. So if you're creating an SMS reminder app for court appointments,
- #17 and those messages are coming from a public defender, they're probably privileged, and they're probably not going to be usable as evidence that someone willfully failed to appear in court. If they come from the *court*,
- #18 however, that protection vanishes, and an enterprising prosecutor could use message and phone metadata to prove they read the reminder, still didn't appear, and jail people who fail to appear in court. All of this isn't to say that technology is bad, but just that a technology tool is an opinion,
- #19 about how information should be structured, and about how processes should be structured. If you aren't forming those opinions in advance of building your technology project, you'll be at the mercy of whatever opinion the tool you picked happens to have. And the effects of the technology tool can impact more than just your processes around technology--it can fundamentally change how you do your work.
- #20 In military strategy, there's a concept called an OODA Loop - Observe, Orient, Decide, and Act. And the important part about this is the loop, which is that your actions, and the results of those actions, constantly affect how you observe the world.
- #21 So when you're relying on technology in order to achieve your mission.
- #22 It's important to understand that technology can distort how you view the world.
- #23 What this means is that if you're directing people to your web-based platforms, not only might you miss people who don't have access to the internet, you might not even know that you're missing people to begin with. Or, if you're thinking about search engine optimization, you might miss the larger question, which is "how do people find lawyers". Well, I'm a lawyer, and the people I know usually ask me something like this.
- #24 If someone doesn't know any lawyers, they might ask someone they trust, like a social worker, or a community center, or a pastor.
- #25 After all, a legal issue is often an emergency--and who do you turn to in an emergency? Is it Google? And technology makes following the contours of that community a lot easier,
- #26 but it does so in ways that are decidedly unsexy. And so if you think about technology in a narrow way, you're going to create narrow technology systems, that impose costs on people who don't have the same level of information fluency that you do.
- #27 And even as technology is distorting your world, the world is going to distort on its own. and laws will change, and funding and eligibility rules will change, and staff will change, and how well are your technology systems going to respond? Are you creating dependencies on developers? Are you creating processes that could calcify in a year or a month or tomorrow? And so a more ruthless way to look at your technology is to view it as a tax.
- #28 Taxes are sometimes good--they build roads, but they're costs that stand between you and the thing you want to do, and they should be evaluated as such.
- #29 And when you're evaluating technology projects, there's a temptation to do it in page views, or likes, or downloads, and it sort of blurs the view of what success actually is. We don't think any of those metrics really matter. As a fellow nonprofit, what matters is the mission,
- #30 and your evaluation of technology projects should focus exclusively on how this project does or does not support your mission. And as we start getting closer to technology assisted help, and blurring this line between information and advice,
- #31 we'll need to start taking a harder look at substantive legal outcomes, and what the real cost of achieving that outcome actually is, normalizing for the merits of someone's case. Because leaving old information floating around the internet, and telling people that this isn't legal advice, really isn't going to cut it anymore, because you, as legal providers, have a gravitational pull,
- #32 and the information you provide is the primary--sometimes the only--framing that a person has of the range of options available to them. You are literally defining the world they are stepping into, regardless of whether they ever contact you. So the bigger question then is not only how are you affecting your mission,
- #33 but how are you affecting the larger ecosystem of vulnerable people in poverty who need help? Technology can enable us to build networks that stitch together a real social safety net, and coordinate with other organizations, to an extent that wasn't possible even five years ago, but the problems that you need to solve are still, fundamentally, human.