Agitprop Àgogo

Mistake #1: Writing a Proposal

For the last year I’ve effectively been working as a funder of NGOs and CSOs. Some of this is direct, through the mySociety CEE project, and some of it is more indirect, by giving advice to OSI on other project applications they receive. One thing I’ve learned in doing this is how much I hate reading proposal documents. I’d say at least 95% of the ones I’ve seen have been woeful. And I don’t mean that in a small way. I mean that most of them want me to pry my eyes out with a spoon.

Part of the problem is that I don’t speak NGO lingo. There’s so much jargon, and taking two paragraphs to say one sentence that my eyes glaze over almost instantly. I like things that say in plain language what you’re going to do and what impact you hope that will have. Proposals never do that. They’re much more convoluted, telling you in depth all the things you don’t need to know, and glossing over all the things you do. I’ve lost count of the number of proposals that even after a third reading still make no sense to me whatsoever.

When we launched the CEE project we tried to bypass lots of this by asking instead that people simply filled out a web-based form. In hindsight even this was probably a bad move. Instinctively I knew even back then that getting people to write long proposal documents was bad, so I tried to shorten that. But now I think that the whole approach is completely wrong. Instead, we should have asked people to show us version 0.1 of what they wanted to build.

Some people have gotten very good at writing proposals that seem plausible without actually saying anything. The trap as a funder is to simply project onto that what you think they should be building, and assume that that’s what they were saying they would. Forcing people to show what they’re going to build bypasses that completely.

But I’m not simply talking about building a prototype here. I’m talking about building something that’s actually useful, and launching it to the world. This forces you to work out what the key element of your project really is, and focus intently on building that. You’ll discover really quickly then whether it’s a good idea or not.

The beauty of the modern internet landscape is that you can often do that extremely cheaply and extremely quickly. Most NGOs can’t grok that yet, however. I’ve been involved with four Social Innovation Camps now, and they highlight this well. The basic idea is to get about 40-50 geek activists with a variety of skills together for a weekend, divide them into five or six teams and have them compete against each other to see who can build the best project in 48 hours. When we did this in Bratislava last year, part of the outcome was slightly hilarious, but very revealing. The event was co-situated with the CEE Trust’s Civil Society Forum event. Whilst everyone downstairs was pontificating on the future of the third sector, a bunch of people upstairs were simply getting on with building useful things. Then, at the end of the conference, the SICampers proudly presented what they’d created.

Some of the CSF attendees, however, simply couldn’t accept that the projects being demoed had been built in two days. That was so far outside their worldview that they simply couldn’t hear that. Instead they decided that the teams must have spent the last two days creating the presentations, relating to projects that they’d clearly been working on for six months or a year or more.

But the reality is that these days it’s often quicker to build the initial version of what you want than it is to write a funding document describing it.

Obviously, you don’t stop there. You iterate rapidly off this first version, learning from user feedback and usage patterns etc. where you can add the most value next. We’ll come back to some of that later in the series. But for now the message is simple: don’t spend your time writing about what you want to build. Instead, spend that time building it. It’ll help funders decide better whether to give you money or not, it’ll teach you much more about what you’re trying to do, and you might even find out you don’t actually need the funding anyway.

Mistake #2: Working with government

Conversations you rarely overhear: “I had to contact the city council yesterday. It was such a delightful experience that it lit up my whole day. Everything ran so smoothly I was finished in under 5 minutes — it’s so impressive how they’ve rearranged everything to fit how I think, rather than their own structures.”

On the contrary, most people hate dealing with government. They fully expect it to be a painful experience. At a deep level politicians and civil servants simply see the world differently from normal people. They are the masters at constructing elaborately labyrinthine systems in which it’s easier to get lost than to make something happen. Worse, these systems have, at their core, an insidiously twisted and tantalising logic which makes them almost make sense. The longer you’re exposed to them, the more you feel that it’s simply you missing something, and things must just have to work this way. And, as there usually isn’t any alternative, you just grit your teeth and put up with it.

And so, when governments build websites, they reflect this crazy worldview. And worse, if you are building a website which lets people interact with their government in some way, it’s easy to fall into the trap of doing likewise. Avoiding that is one of the key things any civic engagement website has to overcome. It’s a difficult task at the best of times, and almost impossible to avoid if you end up working directly with government.

Many people who build these sorts of sites start with an assumption that their site will be better if it’s government supported. This is almost always wrong. They will force you go do things in all sorts of ways that will make your site resemble the official process. And worse, even thinking about getting official support usually steers people down a path that makes their sites more closely reflect how government already does things without even realising it.

The best sites smash this wide open, and make it possible to bypass all the bureaucracy. They reflect how we want to interact with government, not how government wants us to interact with them. And the best way to do that is to completely isolate yourself from the existing systems. Work out first of all the simplest possible way things should be. Then build that. Only then work out how to interface with how the official system actually works. Once you’re tainted with that knowledge it’s almost impossible to forget it and approach the problem with a normal person’s mentality.

This is a great opportunity for civic hackers. Coming up with ideas for great civic websites is fish’n’barrel territory. Simply find a government function that already exists, and which people would likely participate in more often if only it were easier. Then make it easier.

Of course, that’s not simple. A lot of effort goes into making things effortless. But every step you can remove from the existing process makes things significantly better. People expect pain when dealing with bureaucracy. The more you lessen that, the more people will love you.

Mistake #3: Dependency on regular funding

People in the NGO world spend a lot of time talking about sustainability strategies. In the commercial sector, the secret to business success is simple: make more money than you spend. If you build something that doesn’t actually have any income however (like most civic sites), this approach is problematic. There are therefore three main paths that organisations take: (1) find a way to make money from the site, (2) accept donations, or (3) get funding from a friendly benefactor. Unfortunately the first two are very difficult. Some big sites manage this1 but most don’t — leaving only the third option.

My favourite approach, however, is (4): have no running costs.

I’m not simply talking here about sites that are so simple they can be built in a few days and forgotten about (great though those can be). Rather I’m talking about a model where you receive funding to build a site, but you construct it in such a way as it can then run itself without ongoing funding.

This requires automating everything you possibly can (and I mean everything), and putting your users in charge of anything you can’t2. That doesn’t mean scrimping on costs — in fact the opposite is usually true. Usually this requires spending more money up front: automation takes much more work than just creating a database to populate, and much more effort is required to build tools suitable for use by the the public at large, or even volunteers, than internal staff who can more easily be trained how to work around the idiosyncrasies.

Nor does it mean you can’t spend money on marketing, PR, outreach, and the like. Again, on the contrary, if you’re going to be depending on users to maintain the site for you, you probably need to get a lot more of them to make that happen (following the 90/9/1 rule). I’m not saying these sites shouldn’t have any costs. Rather, I’m simply saying they shouldn’t require any maintenance costs. For such time as you have funding, then of course you should spend it making the site better, growing it, raising awareness of it, etc., but if the money runs out, then the site should be able to keep running at its current level. It should even be able to outlive your organisation.

Geeks are used to this kind of thinking (you can even buy the t-shirt). NGOs aren’t. In fact it positively scares most of them. I met an organisation recently who produce regular reports on what MEPs from their country are doing. They collect about 80 different pieces of data about each one, tally them all up using a complex formula, and then rank each MEP. This currently requires five full-time researchers (and sufficient funding every year to keep them all employed). When I suggested developing a series of tools to go fetch all this data automatically from various European Parliament websites, populate a database with it, and generate all the reports without any human involvement other than to double check that everything was working smoothly and the results looked OK, the organisation was horrified. That would put them out of business and destroy five jobs!

Ironically though, if you’re capable of doing this, then it actually makes it easier to get more funding. Most funders I’ve talked to are frustrated at supporting sites which start off well, but then run out of money and simply disappear. But they don’t want to have to keep bankrolling them every year simply to keep the site alive. People with the knack of building self-sustaining sites will have very little difficulty in getting more money to work their magic again and again. It’s not like there’s any shortage of problems to solve!

1. I’m always interested in more examples, so please leave comments of ones you know [↩]
2. We’ll talk more about this half later at “V”. [↩]

Mistake #4: Waiting for change

Occasionally I encounter proposals from groups whose plan requires first making government release some data, or pass some law. Then, once that happens, they can build something really cool and useful. There are lots of crazy ideas in this field, but this approach is amongst the craziest. As Micah Sifry explained to the attendees at PDF Europe this afternoon1, in a neat prelude to this post, one of the reasons the US (and by implication also the UK) is further ahead with these sorts of sites than most countries, is simply because they hacked Congress rather than waiting to be given what they wanted.

The approach here is straightforward: simply act the way you want the world to be, then wait for reality to catch up.

One of my favourite examples of this is WhatDoTheyKnow.com. The UK’s Freedom of Information laws have several gaping loopholes. One of these is that although companies which are wholly owned by a government body are subject to the law, companies which are jointly owned by two or more government bodies are not! This is almost certainly down to nothing more than bad lawmaking: there’s no reason why such companies shouldn’t be subject to FOI. So, at WhatDoTheyKnow, we include them on the site so that people can make requests to them as if they were.

It turns out that most of them are happy to comply voluntarily: they’re funded by public money, they likely believe they should be subject, and, as everything on WhatDoTheyKnow happens in public, an answer of “We don’t have to tell you that!”, whilst strictly true, may lead to negative publicity, further questions being asked, and increased pressure for the loophole to be closed off.

We’re hopeful that the next version of the FOI legislation will fix this problem, but unlike an official, government run site would have to, we don’t need to wait for that to happen: we can just pretend it’s already in place, and act accordingly.

It’s not always quite as easy to do this, and sometimes it may take some ingenuity, particularly if you need to get hold of data that isn’t officially available yet, but in areas where you believe things probably will change soon, if you act like how you wish things were, you’ll often be surprised how easily you can drag the world along with you. And being part of that change is a lot more beneficial (and exciting) than just waiting around for it to happen.

1. some of you may be able to deduce from this why these posts have been so late for the last two days! [↩]

Mistake #5: Educating instead of Fixing

Many NGOs have ‘education’ as one of their aims. And so, when they build websites they attempt to apply that — often by doing little more than converting a booklet to a website. This may be a noble goal, but it’s almost always a mistake. One key problem is that nobody will read it. The other is that often it subtly perpetuates the problem you’re trying to solve! People don’t need problems explained, they need them solved. Your goal shouldn’t be to teach them how to overcome hurdles — it should be remove the hurdles for them.

For example, if your country has recently passed a new Freedom of Information law, but very few people are using it yet because the process is so bureaucratically complex, you could create a site that provides lots of information on the what, why, when, etc of your law, and educates people on all the nuances of how to make valid requests. This is often the natural approach people take who have expended the energy on dealing with all the pain already and want to make it easier for others.

A better approach is to make lots of Freedom of Information requests yourself, and make the whole process public. Show people the actual letters you sent, and what you got back when, etc. Being able to see how things play out in practice is ten times better than just reading some dry explanatory text (no matter how lighthearted you think you can make it.)

But a hundred times better still is a creating a site to let everyone make Freedom of Information requests more easily. This way you can work towards eliminating the pain for people entirely. You can use your hard-won knowledge to act as a proxy, simplifying the processes down to the key elements, and hiding all the dirty work behind the scenes. All they should need to do is write their request for information, and choose the correct government agency — and even those can be made easier for people who don’t have a clue about how to phrase an official request, or don’t know enough about government is structured to know who to ask.

The problem with education in this sort of context is that most people don’t want, or need, to understand how everything works — they just want to get the information. In most cases they don’t even really need to know there’s such a thing as an access to information law, never mind how it works — all that matters is that they can get the information they want. Your job is to make that as simple as possible for them — not to educate them on how to do it.

Obviously people can still learn in the process. The key, however, is that you’re not simply educating them on abstract concepts — anything they learn is en passant within the very focussed context of making a real request. People shouldn’t be using your site simply to learn how to do something — they should be actually doing it.

(… if you compete with them)

Mistake #6: Building a Social Network

When you start a pitch with “We are building a social network for…” my brain will already have stopped listening before you get to the end of the sentence. Building a social network is a terrible, terrible, terrible idea for making things happen.

The biggest problem with launching any sort of social network is that it’s very difficult to bootstrap. Networks grow based on who’s already on them. If it’s mostly empty, then there’s very little value in signing up. But when everyone is already there, there’s huge value in joining too. Lots of people hate Facebook, but they have to be there because their friends are all there, and it’s the de facto way for organising events etc. You’re very very very unlikely to be able to replicate that (look how much trouble Google is having), but it’s almost certain that you don’t need to.

If you really need to harness a social network somehow, just build on top of Facebook, rather than trying to replicate it. But most of the time you don’t need to, because, rather ironically, the best way to achieve social change is usually by harnessing individual self-interest. I’ll write more about that in a couple of days at H, but for now simply consider why you think you need a social network. People can, do, and always have, been able to work together on things without needing that sort of structure. Just Don’t Do It.

Mistake #7: Undue reverence

Many of the sites built by organisations like mySociety could be built by the public sector. TheyWorkForYou could be created by Parliament itself. WhatDoTheyKnow could be run by the Information Commissioner. Local councils could have their own FixMyStreets.

I’m not entirely convinced that they necessarily should do this — I have a lot of sympathy for the idea1 that government should simply release their data, and leave the actual site-building to the private or third sectors, saving gazillions of dollars in the process. But either way, I think that a fun and useful thing to do when building such sites is to push the boundaries somewhat. As we’ve already discussed, governments are usually forced to reflect current reality, but even within those realms, they generally approach everything in a conservative2 manner, assume a high degree of deference to the state and/or politicians, and steer clear of anything that might be considered disrespectful, irreverent, or even humorous.

You, on the other hand, do not need to be so constrained. One of my favourite examples is on TheyWorkForYou, in the section which deals with written answers to Parliamentary Questions. As well as being able to leave annotations, users also get to vote on whether or not the minister has actually answered the question or, as is a key skill of most politicians, simply avoided it (see an example).

Even if Parliament were to produce a much more useful official site, it’s very unlikely that they’re ever going to ask visitors questions like “Is this avoiding the question?” or “Do you think we’re lying?”. So whilst we’re doing the job for them, we may as well poke the beast just that little bit more.

1. see “Government Data and the Invisible Hand” in the Yale Journal of Law & Technology for an extended discussion of this [↩]
2. i.e. conventional, not Conservative [↩]

Mistake #8: Requiring Supporters

In an ideal world, no doubt everyone would be a supporter of your cause. Unfortunately, as I suspect you’ve noticed already, we’re not. If you can manage to catch our attention for 30 seconds when we’re in the right mood, and you’re really lucky, then maybe we’ll give you a ‘Like’ on Facebook, but that doesn’t mean we’re going to do anything more than that. The vast majority of people simply have too many other things that they’re already far too busy with to spend any time on your website unless it does something for them.

Yes, I’m sure you think that if people just understood how important the issue is, they’d all be falling over themselves to do whatever it is you want, but achieving that is like winning the lottery. It’s not that it never happens, it’s just that if your future depends on it, you’re in trouble.

It’s much easier to catch people at their own point of pain, help them with that, and find a way to turn that into something much bigger. Someone who reports a pothole on FixMyStreet generally isn’t subscribing to some grandiose vision of How Things Should Be — they’re probably just fed up with having to swerve around it every morning on their way to work. Most people who make a request on WhatDoTheyKnow aren’t interested in Freedom of Information campaigning — they’re simply trying to find something out. But in each case, tapping into that self-interest and aggregating it all in public achieves something significant.

If your site revolves around people contributing something simply for the benefit of society at large, then you’ve a massively uphill struggle to overcome. There are many, many more people in the world who don’t support your cause, don’t believe in your philosophies, and have no real interest in making your world a better place. But if you can find a way to help them, and in so-doing, also help everyone else — then you’ve got something worth shouting about.

Mistake #9: Living in a bubble

As I’ve already said I’m a firm believer in idea that the best way to build something is to start small — ideally with one key feature — and then rapidly iterate from that, building out the a larger site based on feedback from real users of your site. However, there’s a key trap in that approach you should beware of: your very first users are often not your main target audience, and paying too much attention to what they want can take you down completely the wrong path.

This happens all the time with Silicon Valley startups. They murder their grandmother to get featured in TechCrunch only to find out that even if they do manage to build a customer base from it, it’s made up entirely of the sort of people who read TechCrunch — i.e. not the sort of customers they actually want anyway if they’re ever going to cross the chasm. But by paying attention to what their existing customers want, they never manage to build something that normal folks want to use.

Transparency and accountability sites have their own chasm to cross too: it’s not enough to cater to the Westminster Bubble or stay inside the Beltway, or whatever your country’s equivalent is. Your first users are probably going to be those sorts of geeks, wonks, activists, etc., and they’re certainly going to be important, but you don’t want to let them be too influential as to the direction in which you steer things — assuming, that is, that your goal is to build something that’s more broadly useful to normal people!

When you do manage to get any indication of real users, though — i.e. not your Facebook / blog / twitter friends and followers, but people you’ve never heard of before who seem to have simply stumbled across your site as a potential solution to a problem they have — then pay attention more intently than you’ve ever done before, hang on their every word, pore over their clickstream, and do everything in your power to make everything you can for them easier, easier, and easier still.

Mistake #10: Waiting

“Until one is committed, there is hesitancy, the chance to draw back. Concerning all acts of initiative (and creation), there is one elementary truth, the ignorance of which kills countless ideas and splendid plans: that the moment one definitely commits oneself, then Providence moves too. All sorts of things occur to help one that would never otherwise have occurred. A whole stream of events issues from the decision, raising in one’s favour all manner of unforeseen incidents and meetings and material assistance, which no man could have dreamed would have come his way. I learned a deep respect for one of Goethe’s couplets:

Whatever you can do, or dream you can do, begin it.
Boldness has genius, power, and magic in it!”

— William Hutchinson Murray

You don’t need money.

You don’t need permission.

JFDI.