This piece is written by Paul Figueira, Head of Design at Open Cities Lab. Paul’s work spans architecture, product, and civic technology, and has led and contributed to the design of public-facing digital tools at OCL since 2017, including community reporting platforms, election tools, and municipal open data portals.
Even the most elegant system will fail without the right people.
We’ve learned this the hard way.
I’m a systems-obsessed person working at a systems-obsessed organisation. And over the years at Open Cities Lab I’ve seen firsthand that no matter how well you map processes or design data flows, a system only works if it resonates with the people inside it.
Choosing the right team, and creating the conditions for them to thrive, is far more important than the system itself.
So how did we build our system, and how did we choose our team?
By getting it wrong first.
Mostly, through years of making mistakes and not being afraid to start over when something clearly wasn’t working. There’s no shortcut here. Every iteration taught us something about what we valued, what we needed, and what kind of team we were actually trying to build.
Along the way, I leaned on people I trust. Joanne Parker (Chief Executive Officer), Matt Adendorff (Co-Founder and former Data Lead), Wasim Moosa (Chief Technology Officer), Richard Gevers (Co-Founder and former Chief Executive Officer), and Callum Oberholzer (Founder of Black Box). Not because they always agreed with me, but because they pushed me to confront my blind spots.
By way of example: an early learning for us was that building solutions that solve real problems can’t be done with a “if we build it they will come” attitude. In the beginning we got it wrong more than once because we did not engage with potential users and stakeholders enough or in meaningful ways. This learning triggered us to become user obsessed and we have embedded that ethos into every aspect of our systems and operations.
Deciding who we are before deciding who to hire.
Before choosing individuals, we had to answer hard questions:
- Who are we as a team?
- What are we trying to achieve?
- What is our posture and how do we show up in the world?
- What do we prioritise when things get hard?
For us, that meant valuing curiosity over certainty, delivery over perfection, and respect for people’s lived realities over abstract solutions. Those answers became a filter for every hiring and team decision that followed.
Choosing people for a reason (not just because they are good).
We build our team deliberately. People aren’t interchangeable units, you can’t just swap one out and expect the system to keep humming.
We also choose people who are better than us in areas we know we have gaps.
Lerato Mosehle (UI & UX Designer), for example, brings visual communication, graphics, and design excellence, and is deeply plugged into contemporary design trends, while still being UX-heavy and grounded in users’ needs.
Benjine Gerber (UX Researcher) is exceptional at prototyping: highly detail-oriented, endlessly creative, and a problem solver of a rare calibre.
This isn’t accidental. It’s intentional humility.
People are people.
No matter how good your system is, people will wobble. So will you.
That doesn’t mean something is broken. It means you’re working with humans, not machinery. Designing a team means designing for those moments too.
Increasing capacity beyond ‘the team’
One of the biggest shifts we made was realising that good systems shouldn’t centralise power or expertise unnecessarily.
For example:
- Needs assessments used to sit squarely within design. We trained the wider organisation to conduct them well. We still help… setting up scripts, guiding where needed… but we no longer need to be in the room for high-quality results.
- Reviews and quality assurance are now democratised. A wider range of people test things, and they see issues designers can sometimes miss.
- Product Managers now own the backlog, where design used to control it because feedback lived with us. That ownership shift matters.
The result? Less dependency, more resilience.
Actively listening to feedback, especially the uncomfortable kind.
Feedback isn’t just about the work. It’s also about how you do the work.
I received feedback, particularly from our former CEO, Richard Gevers, that I was too slow to deliver, stuck in perfection rather than getting things into people’s hands quickly. That was further reinforced by Richard Pope’s consistent advocacy for working in the open and getting feedback early.
Both Rich’s were right, so, we changed:
- We started using interactive prototypes so users could experience how something might work.
- We sped things up by building stronger prototyping capability – Lerato becoming highly competent in Webflow (a no code/low code webtool builder) was a turning point.
- Then we levelled up by hiring Benjine, who builds prototypes for fun.
Feedback has always been a driver of concrete system change, not a note taken and forgotten.
Supporting your people is the job.
When things go wrong, and they will, if you’ve chosen well, punishment isn’t the answer. Guidance is.
Supporting your team means:
- Helping them strengthen weak points or ensuring someone else covers that gap
- Keeping them informed about what’s happening around them (context is a form of respect)
- Taking ownership when things go wrong, taking the heat so they can focus on what they do best
If you lead a team, your job is to provide cover so your people can produce without fear.
What we’re still trying to get better at.
None of this is finished.
We’re still:
- Iterating and improving everything described above
- Working more openly, more visibly, and more honestly
If the systems stop serving the end goal, throw them out and start again.
That work never really ends. And that’s probably the point.
