At The Engine Room, we’ve valued diversity for a long time. Having a team whose life experiences and perspectives vary greatly makes us better able to respond to complex situations and complement each other’s approach (and it makes our conversations much more interesting!).
But developing ways of working that make the most of a diverse team–let alone a diverse team who works remotely–is hard. There’s no ‘one way of doing things’ that works for everyone. There are rarely shared cultural understandings of, well, anything. And messages that could seem clear to one person might mean something completely different to someone else.
One of my biggest aims upon becoming Deputy Director this year was to figure out how we could navigate this complexity better. We’ve worked hard to establish and refine internal processes so that the varied strengths of our team can be reflected in the work we do internally and externally. In this post, I’ll share a few processes we’ve developed this year – most of which are still under improvement. If you have suggestions, I’m all ears.
At The Engine Room, we have four programmatic teams: Research and Learning, Technology, Engagement, and Regional Support. But projects rarely fit neatly within one team – more often than not, a project is made stronger using the skills from a combination of teams. For example, our digital ID project ‘sits’ within the Research and Learning team, but involved working with communities in research sites with the Engagement team and called upon our Regional Support team to coordinate researchers in Sub-Saharan Africa.
In order to make the most of the team structure–and make sure projects flow smoothly when they involve multiple programmatic teams–we decided that each project should have its own ‘project team’, which would have people from different programmatic teams on it, while being managed by one person. A tech-heavy project, for example, would be managed by someone from the Technology team but might have someone from the Research + Learning team conducting the ‘research’ component. If the project were to involve organisations based in Latin America, someone based in the region would also join the team.
In addition to strengthening the project with diverse skillsets and experiences, this kind of collaboration also means that internal teams learn from one another and that no project depends solely upon one person. Distributed knowledge and responsibilities across the team makes sure we have more shared knowledge in the long run, and in the short term it makes it easier for people to completely disconnect when they go on vacation!
Brainstorming business development
The Engine Room has two main ways of bringing in projects. One is through large grants that allow us to support civil society organisations pro-bono (for example, through our light touch support program or through Matchbox partnerships). The second is through fee-for-service consultancies, which typically involve larger organisations paying us to work with them on a problem or question. For these consultancies, we’re often asked to put together a proposal which outlines the way in which we would approach those questions.
Bringing in these projects is not everyone’s responsibility, but we realised that everyone has good ideas, perspectives and problem-solving tactics that can strengthen the way in which we shape proposals. So, instead of just one or two people writing those proposals, we’ve set up a ‘brainstorm’ process to incorporate more perspectives early on in the process.
Now when we get a new business development opportunity, we call upon the collective brainpower of the team to contribute. We write out a one-page document with the constraints, the problem and any other background that people need to know, share the email with the whole team, and ask people to join a brainstorming session if the topic interests them.
Then, we set up a one hour brainstorming call and use an online whiteboarding tool to discuss prompts like:
- What are our initial questions?
- What would success for this project look like?
- How would we approach the project?
- What potential challenges can we see from here?
- Are there any key milestones we want to outline?
By the end of the call, we’ll have ideas that make writing the actual proposal far easier. This process has brought an extra level of creativity to the proposals we’ve written, and it also means that if those projects do come through, more team members see their ideas reflected in the shape of the projects. Personally speaking, it’s pushed my own approaches and strengthened how I think about what we as an organisation can and should offer.
Structure in processes to leave space for serendipity
Different people have different preferences for how they manage projects. As an organisation, there are some project processes that are entirely necessary (eg. having a contract before you start work on a new consultancy) and others that have been established more informally. Additionally, certain aspects, like what we do, our mission and strategy, are pretty fixed. But the ‘how’ of doing many of these things is not set in stone.
Generally speaking, we used to leave project management processes to individual project managers to decide. That meant that everyone had a great deal of freedom–but it also meant there were sometimes repeated tasks, redundant efforts and, sometimes, confusion in how things would happen. This year, I drafted a ‘Programmes Handbook’ which brought together a lot of separate project guidance into one document and is complemented by a ‘Programmes Toolkit.’
The goal of the Programmes Handbook isn’t to prescriptively set out how to do projects. Instead, it makes what was previously implicit (and thus, hard to grasp) explicit. It clarifies when processes are optional and when they are non-negotiable steps we need for operational integrity. Establishing these guidelines removed the pressure of designing every single process (all the way down to budget templates) from project managers, enabling them to focus on the parts of projects they care about most.
Having it all written down in one place also makes it much easier for people to offer suggestions that can inspire new approaches, too. It’s made onboarding for new staff smoother, as they can learn about approaches we’ve already tested and easily see where their suggestions can be woven in.
Comfort in order to contribute
In order for these processes to actually work, people also need to feel like they’re in a safe space where their ideas and contributions are valued. The work that our People Lead, Anneke, has done towards creating that safe space goes a long way on the care and well-being side of things.
In addition to that, this year (for the first time!) we did ‘small group coworking’ in addition to our annual all-team retreat. We put people in small groups (5-6 people) based on who might not work together often, instead of by formal team structures. We hoped this would spur new ideas and strengthen relationships across teams. Now that we’re back in our remote ‘office’, the opportunity of spending a week together seems to have gone a long way towards building trust and connection, and making people feel more comfortable with one another.
We’re also about to kick off a participatory strategy refresh process, through which everyone in the team will have multiple opportunities to contribute their thoughts to the overall organisational strategy. (More on that in another post!)
This is definitely worth another blog post, but I would be remiss not to mention the great knowledge management work that’s gone on at The Engine Room this year. Our colleague Paola Verhaert became our new ‘Knowledge Coordinator’ earlier this year (or, as we affectionately call her, our internal librarian). She’s instituted a lot of thoughtful processes for how we internally document, manage and engage with information in a way that has enabled smooth flows of knowledge across teams, and allows for people to contribute in meaningful ways. She’ll share more on this in the future – for now, suffice it to say that being a remote organisation requires good documentation and eagerness across the team to engage with said documentation.
As I said at the beginning of the post, these are just a few ideas and almost all of them could still be improved. If there are other ideas or approaches that you’ve done or seen that you’d like to share, don’t hesitate to reach out to me on zara[@]theengineroom.org.