Have you ever run, funded or been part of a development project?

Have you ever gotten to the end of it and felt that, during the process, everyone had learned and grown, and had stories to share?

Have you ever thought, “We should definitely share what we learned”?

And then someone wrote a report. And that was the end of that.

It continues to surprise me that we keep forgetting (or ignoring) the things that we all know: that building on history requires us to listen and learn from others’ experiences. Instead, we like to invent our own new things – and we repeat the same mistakes ad nauseam.

The web has changed our world in ways that we are still only beginning to learn, but development professionals haven’t yet leveraged it to full effect. As a tool we’ve applied it well in some cases, as more people have access to more knowledge than at any time in history. Yet we’ve also applied it poorly: While information retention within our institutions may be going up, our knowledge retention often lags behind. So we see discussions on secure chat channels lead to pivotal decisions, then vanish as if the conversations had never happened.

We still have much to do to adapt our behaviours and cultures to work with these new tools. We need to keep thinking through how we are going to make the most of both human and machine experiences, as they increasingly combine.

These might feel like hard questions, but if we shift the way we approach solving problems together, we might come up with new answers.

DESIGNING FOR SEARCH – AND OPEN ACCESS

Let’s start with a user need. Think of a project you worked on six years ago. You’re trying to solve a similar issue now, but you can’t remember how you did it before. You remember that there was a really good idea, a phrase, a table of data, a use-case or an interview that helped your team to find a solution. But how do you find the thing you remember?

You might, as many people do (whether allowed or not), carry a backup of all the project details around on an old hard drive. You might try and find the old project website, if there was one (which is likely). You might try a funder’s website to see if they have a copy. You might email a colleague who worked with you on the project – you might even call them.

However you frame this, your starting point is to conduct a “search.” But a search for what? The project title? The name of a person or a topic? What if you can’t find it? What if the information you’re looking for is in the notes from a phone call, which were never properly categorized in the first place?

This all leads us to our first design principle: Design for search.

What does this mean? First and foremost it means something very simple: Did you add enough words to your digital files (e.g. in the title) so that when you type words into a search box six years later, you might have a chance of finding it?

In the age of the web, this is harder than it might seem. The average website survives less than three years so we also need to make sure this information can be searched for at all. There’s a huge spectrum: Google isn’t going away anytime soon (probably); your project website will atrophy rapidly (unless funded); Wikipedia may or may not quite fit; Archive.org archives pages more than their context; national libraries have lasted centuries, but may not be as interested in hosting your project files as you might wish.

This drives us to a solution that is culturally different than what most of us are used to. Rather than publishing project details “in your house” (i.e. on your organization’s website, which is usually designed around the hierarchy of the organization, and still reflects its physical structure), you should focus on publishing in “everyone’s house” (i.e. on popular websites with a digital-native structure that reflect all users’ needs, not just those of your organization). You should, therefore, place your content in as many different places as possible to maximise the chance that you, your colleagues, funders, partners — and the rest of us in the development space — can find it.

Our second design principle is: Publish widely under an open license – or at least for open access. By providing context and publishing widely, under open licenses such as Creative Commons, development professionals can create a better return on our collective investment. We can help the machines help us find things. To give one example that’s likely to resonate: How many of you have used Google to get a copy of your own company’s logo?

WHY, WHAT AND WHERE ARE YOU PUBLISHING – AND FOR WHOM?

There’s an essential question that’s deeply linked to enabling others to find, use and build upon your work: Is what you are producing relevant to the people who could potentially use it?

How often have you encountered a summary report that is written for “people” rather than for “you”? On a regular basis, I find myself asking, “Who is this written for – what is their name, role and organization?” If you can’t answer that question, then let’s pause for thought.

Some questions you should answer to define your audience include:

1. Why are we publishing this — what’s the story?
   Start by writing down the essentials. This can involve writing the press release for every project. It’s not that everything should go through PR, but the process of thinking about the story and the specific audience is critical. Who will act upon it and why? In many instances we know that there are likely only 20 people who will read any report in-depth, and maybe 100 who might read an executive summary — so it can be helpful to write the summary first. How will you describe this work to someone verbally in two years? This is a powerful, behaviour-driving question.
2. What are we publishing?
   Is it a document? A PDF? Slides? Images? Data? Code? Algorithms? What’s useful to the user? Why? What format do they (not we) need most?
3. Where are we publishing?

Certainly, everyone wants to publish on their own websites, but where are your users obtaining their information? Go to where they might find you. The ambition here is, in most cases, not to drive traffic back to your website. You’re not a destination, the content is. If I’m going to find it, it should be in as many relevant places as possible (e.g. blogs, Instagram, LinkedIn, Slideshare, Pinterest, Wikipedia, Archive.org, Github, postcards, books and videos). This isn’t about having a social media strategy to flood people with your content (you do that already). It’s about making sure that when your site is dead and the team is scattered to the wind, you can all find your own work again.

Once you have a sense of your likely readers and their needs and information sources, ask how you can:

• Get diverse input when evaluating users’ needs
• Define a common language and use it: If you’re using words with various or ambiguous meanings, make sure your intended meaning is clear and consistent
• Make outputs available in machine- and human-usable formats
• Tell stories to help people learn, including recurring storytelling to prompt recall
• Use shared documentation systems and shared tools such as wiki’s, Google documents, Github and Trello – not isolationist “need to know” systems
• Work with institutions of accountability to enable longevity of access (e.g. libraries, universities, national archives)

The answers to these questions can help you deliver content that’s likely to reach the people who need it, not just now but for years to come.

CHANGING HOW WE WORK TO BE OPENLY COLLABORATIVE

In my time running the Open Data Institute (ODI), we took extensive measures to foster a culture of open sharing and long-term accessibility of information. I mandated the creation of shared Google documents. The sending of attachments (internally) was banned. The guiding principles of this approach were reflected in this checklist, to be followed with all documents:

1. Create a document.
2. Name the document with keywords relevant to a later search (e.g. date, topic, themes, place, hashtag equivalents).
3. Share it with everyone in the company (organization-wide).
4. Reduce sharing to a named list if required (e.g. for HR or legal reasons).
5. Start writing.

This applied to all meetings (internal and external), as well as all operational documents, research, proposals, HR, budget, financial reporting, sales planning and reports, project plans, performance metrics, board reports, compliance reporting, and legal and accounting documents. Instead of each person writing something, then emailing a document, we would schedule short group working sessions to simultaneously edit documents, often while in voice contact to discuss anything unclear. This produced better outcomes, and was also far faster — but only after induction and training, as it takes practice to work so differently.

Once learned, this process was also applied to co-create proposals with clients. The outcome was that the client could input directly to proposal documents, engage in internal Q&As about scope and budget, and shape outputs, timing and costs. This improved the team’s relationships with clients and their trust in the team.

Induction documents and guides were provided for all staff on the process, naming conventions (e.g. dates written in ISO format), how to add keywords to document titles to aid searchability, and security and privacy guidelines. Design for search was a guiding principle.

The power of an open approach to development has many benefits. Done well, it changes the way people collaborate during projects — they are producing a legacy, not a document.

As the ODI Labs team expressed,

“At the Open Data Institute, we build all our technology in the open. This may seem terrifying, but it’s probably one of the most powerful things we do. By using open tools and practices, we communicate better as a team, engage with our community, avoid cutting corners, and at the end of the day, produce better results.”

One cultural imperative is essential to this approach: bravery. It is not possible for any team to share widely, embrace openness – and be open to the potential criticism that this may cause – without total buy-in and support from leadership: from the board-down, and from the practitioners-up. Openness flattens hierarchies, and it can also lead to different emotional responses and power dynamics.

But this only serves to illustrate, again, that the way to stop ourselves from losing our minds is to embrace our humanity, and to acknowledge that we need to work together to join the collective intelligence of humans and machines. The process may seem scary, but it may be one of the most powerful things we can do.