The tech geek’s burden

The tech geeks are coming to government. Whether they’re in our cities as Code for America volunteers or part of the federal U.S. Digital Service and 18F (hailed by Fast Company as “Obama’s Stealth Startup”), programmers, data scientists and UX designers are starting to find their place in the public sector.

This is a good thing. The more accomplished technology professionals devoting their talents to public service, the better. However, there’s a potential problem. Tech professionals in government are in for a serious culture clash. Government writ large has generally been labeled by tech professionals in the private sector as hopeless and its culture, frankly, backward. Any number of online comment threads going back to the launch of (or even long before that) make this pretty clear.

Some programmers publicly say government is so behind the times that they feel taking a job there would atrophy their own skills, almost like a contagion — that working there for more than a year would make it impossible for them to keep up their skill set to the level of the “civilized world” back in Silicon Valley. Even one government engineer otherwise happy with the public sector says that her skills have “atrophied to the point that (she) would probably have to take an entry level position in the private sector.”

So this leaves us with an interesting situation. One of technology’s great goals is to help society and the people in it. It turns out there’s another group of people who’ve devoted their entire careers toward that: They’re called public servants. So you’d expect technologists and government officials to have some of the same goals. But the attitude many tech geeks have to government can be patronizing at best — and open contempt at worst.

Here’s the surprising thing most people on both sides haven’t noticed yet. While you’d be forgiven for thinking this is an entirely new situation with no precedent thanks to, say, the Internet,  smartphones, machine learning or any number of other technological advances, you’d be flat-out wrong. We have seen something a lot like this situation before — and we know how it plays out. We’ve made some serious mistakes from which we have learned, and we can apply the same lessons today.

Where have we seen this situation before? In the world of international aid.

The parallel isn’t precise, but it exists. In older, less-enlightened international aid scenarios, the professionals who came from rich countries had a very clear preconceived idea of what needed to be solved. They engaged with the poor country’s government and people, spending a minimum of effort trying to understand local history and culture and assuming lots of stereotypes (inefficiency, laziness, a love of red tape, inability to “do” anything), which ended up offending the people they wanted to help and harming much of their efforts to do good. The pattern is so common that entire books have been published on the topic, with titles like “The Tyranny of Experts.

Take the time to work with the people you meet and understand where they’re coming from.

Substitute “tech professionals” for “aid workers” and “government bureaucrats” for “locals” and you have a common attitude many tech professionals take with government. The engineers wondering why their “obvious” solution isn’t being adopted really aren’t that different from the development economists wondering why the people in poor countries aren’t behaving “rationally.” Call it “The Tech Geek’s Burden” if you like. It’s a fast way to alienate many of the career civil servants those in tech want to assist.

There is, however, an important and very useful difference: Even if internet professionals have only just started coming to help government, foreign aid has been around at least since the Marshall Plan that helped rebuild Europe in the 1940s and 1950s.

While it’s far from perfect, international aid has learned a few things to which tech professionals joining government might want to pay attention.

Even if you think you have the answer to all the problems on arrival, you’re probably wrong. The problems you will be facing on the ground are inevitably more complex than you’ve realized. More importantly, if you drop in and tell people who have committed their lives to serving their community that “they’re doing it wrong” and they all need to stop being dumb and listen to you, you’re either going to get sent home in short order or wind up wishing you had been.

Ditch the preconceptions about culture. Most of what you know about the place you’re going, and its people, has been shaped by media that are in the business of telling exciting and controversial stories, not reporting the often-dull truth. Some of what you’ve heard about inefficiency, graft or laziness relative to your culture may seem like it’s true at first. But if you’re going to get anything done, you’re going to have to take the time to build relationships with the people with whom you’re working to learn about their reality and what they value, especially the things you hadn’t thought of before.

Pay attention not only to what’s “wrong” but how and why it came to be that way. You will spot inefficiencies as soon as you start your work. But even if you can change them by the flick of a switch, you will save time and trouble in the long run if you first find out who relies on the system to be the way it is currently and make sure their needs are met. You can find out a lot of this by getting curious about the history of what you’re seeing.

If you’re starting something new, think carefully about who is going to maintain it after you leave. Good programmers know this already, but writing a new application is a lot easier than fixing a broken application. Similarly, in aid projects built using foreign expertise and parts, once the engineers leave and the system breaks, the community can be left without not only the new system, but also the old one they abandoned in place of the new system. In other words, if you create something new to replace something old, if and when it breaks, you can leave people worse off than when you arrived — unless you’ve made sure that someone there can fix any problems that arise.

Make sure you’re not replicating something that has already quietly failed. Failure often goes unreported, especially in places that rely on success stories to get funded. Engineers Without Borders’ David Damberger gave a brilliant TED talk on this point about a water pump system he helped install in Malawi. When they came back a year later they found that not only had it broken, but they discovered something they hadn’t noticed the first time: a bunch of other broken water pump systems that other groups had installed years before. If you’re going to make something, ask around to make sure the broken remnants of someone else’s attempts aren’t lying around, and, if they are, try to see what you can learn from their mistakes.

In short, if you are coming from a tech background and using your talents in public service, you can improve the lives of huge numbers of citizens. But you’re going to be a lot better at it if you recognize that you’re coming into a place with its own culture and history that does not need to be replaced by the one you’re used to. Take the time to work with the people you meet and understand where they’re coming from and your work will be far more efficient, effective and durable in the long run.