Lessons learned from working together

Data for Action worked with ClientEarth for around 18 months. The original brief was to “support the Monitoring, Evaluation and Learning (MEL) team with developing data architecture and data collection tools for MEL”.  By the end of our involvement Client Earth had launched and are actively using a new impact tool and had shifted to placing more emphasis on Learning.

We recently held a retrospective to explore what we all learned about the work. This post looks to summarise the lessons we can learn from. 

---

Principles or key points

Show the thing(s)

Talking about something is good, showing it is better. It doesn’t need to be perfect, it doesn’t need to be the final thing, but just show it, rather than just talk about it. And along any project there will probably be many things, so show them as you go. 

Organisational memory is both long and very short

We often remember the emotions related to a change or transformation for a long time. But we very quickly forget the details of what actually happened along the way. This is why one of the key things we do is devote time to cataloging all the things we did along the way. It was great for the team to look back on everything, and pick through what worked, and what didn't, and really tease out why. So find the simplest way to create a catalogue of all the things you do along the way, not just the end result. Don’t overproduce documentation that becomes counter productive. We often do this via Notion, allowing tagging and a timeline

Vibes are important

We sometimes joke that Data For Action is a vibes based consultancy. But there's a lot of truth to just getting the vibes right. And no, I don't mean ping pong tables and afternoon beers. I mean creating enough trust and safety to be playful and experiment, and be liberated from stifling expectations of being a 'professional'. Humans are inherently playful and natural experimenters. In workplaces, due to hierarchy and power we often lose that due to real or perceived expectations. We reward certainty, value answers over questions and keep people in defined roles. It can often feel hard to put a professional reputation on the line by saying 'I don't know' or 'we tried this, it didn't work' which limits the ability for an organisation to learn

There may be fatigue in the organisation

Organisations are often changing so it’s important to be aware of what has come before. There may be fatigue from change programmes or ‘consultant fatigue’ where change hasn’t always gone well. People may be tired; tired of reports, of being asked for opinions that are never acted upon, of surveys that never see the light of day. So finding ways to shift the energy is important. Sharing things in different ways, showing things as they happen, consistently drip updates, create spaces for the non traditional, focus on vibe. 

Examples need to be contextual and specific

Every organisation is different; structures, type of work, ways of working. As a consultant you can’t know everything, but you should take enough time to understand, so that you can be specific in your examples. Generalised examples are not enough. One thing outside consultants can help with is bringing examples and insight from other organisations, but it’s important to really ground enough examples within the organisational context. Invest time (both as consultants, and as the organisation) at the beginning of any project to really understand an organisation, not just the work. 

Don’t be prescriptive with the outcome, lean into uncertainty

In our experience the best results come from being open to possibilities. Going in with a preconceived idea may be easier to deliver, but it likely won’t be the best outcome. Intentionally being uncertain about what might happen in workshops and experiments can be hard, but it’s that tension which tells you you are pushing at the boundaries of what is possible. 

Create supportive structures 

If you are going to lean into uncertainty, the structure of workshops and information should be clear and well defined. Not knowing what insights, ideas, concepts are going to come, or what the end point or result of a workshop is good, but you should have ways of both getting there and being able to reflect that back after. Make the process as clear and simple as possible, so people can devote their mental energy into the ideas, content and decisions. Create structures that liberate. 

Clear and simple language is good

Too often we can get caught up in over-complicating the language we are using, especially when it comes to things like evaluation, data and technology. It can feel uncomfortable to use simple language as we are often conditioned to demonstrate our expertise by using more technical or academic jargon. However, the simpler you can make things, the more likely you are to ensure everyone knows what you mean, and this is important. It feels especially important in a multilingual environment like Client Earth. 

Timing can be important (Change isn’t linear)

Change doesn’t happen on a Gannt chart. Sometimes the thing you are doing can be right, but the timing can be wrong. Sometimes you make progress and then something else happens and you feel like you’ve moved backwards. Change often happens in waves. There isn’t an exact science, that’s why being open, and being reflective in your approach is important. Don’t make everything over reliant on one activity or one final output. 

Approach over outputs

Ok, so this is one of Data For Action’s principles, so we might be a bit biased. However this comes through clearly time and again. If you don’t bring people along with you, the final output or ‘tool’ won’t really matter. Get to the right place together, and focus on ensuring that when change happens, and it will, you have the ways of working to help you adapt.

It’s the internal team that will make this a success (or not)

No matter how good a consultant you think you are, you are not the one who will ultimately make this work a success. From our point of view it was helpful to have a mix of skills and roles in the internal team. Some brought a strategic view and could see how this work might fit with other things going in the organisation. They were also able to provide cover for our approach which was very nontraditional for the organisation. Some were able to identify key people to bring into the work, while others were more technical and could really get into very practical details. Overall it needed the team, and it required them to trust us and the process, to make it a success. 

If you’re making any kind of product, bring the IT team with you

This isn’t always easy, especially if they didn’t commission the work. Even if you can build the thing yourselves, longer term someone has to maintain it. And it’s much harder for something to be killed off if the IT has been involved.

If there isn’t a big celebratory end point that’s probably a good thing

If people in your organisation just get on with doing a thing or using a thing when it comes along, you’ve probably landed it right. When we are in the middle of a project, when we’ve put time, effort, energy into it, WE might want a big moment where people react. However what we really want is people to just use the thing, and when things work, and people are ready for them, and the conditions are right, people will just get on with using the thing, and that’s the win.