Work Worth Doing
On sustaining technical programmes when the funding landscape isn't built for it
Most research organisations build around projects. A project gets funded, a team assembles, work gets done, the project ends. If you’re lucky, some of the people stay and some of the knowledge carries over into the next proposal. If you’re not, you start again — new team, new scope, new infrastructure.
I’ve spent fifteen years building technical systems in places where continuity wasn’t guaranteed — a startup in Berkeley, a university in Bahrain, a research centre in the Azores. The pattern I keep seeing is the same: when projects define the work, capability accumulates slowly and dissipates fast. The alternative I’ve been testing is to treat the programme — the problem you’re committed to, the people you work with, the infrastructure you build — as the thing that persists. Projects fund it. They don’t define it.
This sounds like common sense. It’s hard to execute, for reasons that are partly institutional and partly structural. This is what I’ve learned trying.
---
In 2011, I co-founded a software company in Berkeley. Strategic Spatial Solutions — S3 — was a SaaS platform for streamlining Space Syntax methods, built on research from my PhD at UCL. We had a clear market gap and the technical ability to build what we envisioned.
We chose not to take investment. We wanted full control over the product, so we did consultancy on the side to fund development. That meant building slowly, but on our own terms. When we finally showed it to a client who wanted to use it, the reaction was clarifying: too many features, most of them unreliable, and no simple way to do the basic thing they needed. We had spent two years building toward a vision of the product rather than toward what users actually required.
The co-development failure was real — we built alone for too long. But the deeper problem was that there was nothing underneath. No institutional stakeholders, no pathway to adoption, no community invested in the work’s survival. S3 was a product without a programme. When it didn’t land, there was nothing to fall back on, no reason for anyone other than us to care whether it continued. It didn’t.
---
In Bahrain, I started a project that nobody had asked for. Rather than building a full platform, I made something deliberately minimal — a map with a few dots on it, barely more than a concept — and used it to start conversations. I showed it to senior decision-makers outside the university and watched which ones engaged. The ones who valued the topic and wanted to shape it became collaborators.
BahrainParks was co-developed from that first conversation through to deployment, and the Ministry of Works later adopted it as official infrastructure. What made it last wasn’t the technology — it was that the people who shaped it had institutional reasons to sustain it. They weren’t an audience for a finished product. They’d contributed requirements, challenged assumptions, and made it theirs before it was done.
This was the first time I saw work survive beyond my direct involvement. The difference from S3 was structural: I’d found the right people first, built with them, and the result landed in an institution that could carry it forward. The work had a home — not because I’d pitched it there, but because the collaborators I’d chosen were already in a position to adopt it.
---
There’s a well-documented problem in research funding sometimes called the “valley of death” — the gap between scientific discovery and commercial application. Emerging models like Focused Research Organisations are designed to bridge it, building scientific infrastructure with startup-like teams on finite timelines. The EU’s recent strategy on Research and Technology Infrastructures acknowledges the problem at a larger scale: research infrastructures across Europe rely on fragmented financing and often lack long-term sustainability.
These are real problems, and they’re getting attention. But they don’t quite describe the position I work in.
Discovery grants fund science. Innovation grants fund companies building services. If you’re a non-profit building operational scientific infrastructure — services that need to run continuously, that require scientific validation, but that aren’t commercial products — there’s no clean funding category for what you do. You’re not discovering, and you’re not commercialising. You’re operating and sustaining, which the funding landscape treats as somebody else’s problem.
This isn’t a complaint about the system. It’s a constraint that shapes every proposal I write. The grant mechanisms available to an organisation like mine fund discovery, so I frame operational needs as research questions. Sometimes the fit is genuine — there’s real science in what we do. Sometimes it’s a negotiation between what the programme needs and what the mechanism rewards.
The most recent example: our Internal Waves Service is a global ocean monitoring system built on Sentinel-1 SAR imagery. What it needs right now is validation — to be tested and confirmed as a reliable scientific platform. But the available grants fund discovery, not validation. So you write a proposal that serves both, knowing the fit is imperfect, balancing what’s true about the science with what’s necessary for the service. This is the recurring tension for anyone building sustained technical capability outside the commercial sector.
---
I arrived at the AIR Centre in the Azores in 2020 with a thesis shaped by the previous two experiences. The challenge was familiar in outline: build technical capability that would last beyond any single project or funding cycle — in a place where hiring is difficult, equipment arrives by ship, and the institution itself was still finding its shape.
The first investment was infrastructure. I told the story of our data centre build in Building What We Couldn’t Buy — how we designed and constructed it when buying a turnkey solution wasn’t viable, and the trade-offs that shaped the key decisions. What matters here is why we built it: nobody builds a data centre for a single project. It’s a physical commitment to continuity, an investment in shared capability that only makes sense if you’re thinking beyond the current funding cycle. Everything that followed — the services, the team, the partnerships — runs on what that decision made possible.
From there, the progression has been deliberate but constrained. Early on, we took small technical roles inside large consortia — contributing science, data infrastructure or processing capability to projects led by others. This was about learning the landscape: understanding how European research partnerships work, proving capability, building credibility with institutions that might later become collaborators on different terms.
Then we started leading small projects — scoped tightly enough to manage with a small team, but chosen because they advanced the programme, not just because the funding was available. Each one builds ownership over a specific domain: in-situ sensing, fusion of ground and satellite data, SAR-based ocean monitoring. The work accumulates.
The next step is leading larger funded programmes. I’ve pushed toward this — I led a six-million-euro grant application, the largest technical bid we’ve attempted. We didn’t win. The logic is sound, I think, but the transition from contributing partner to consortium lead is a real threshold, and we haven’t crossed it yet. It requires a track record of leading, which you can only build by leading — a circularity that smaller organisations know well.
Alongside this, we run targeted small projects with reference institutions — working with specific people at places like MIT and UT Austin — to build capacity in areas where we need depth. These aren’t filler between large grants. They’re how you develop capability in specific domains without waiting for a major programme to fund it. The flow goes the other way too: our Brazilian partners at LAMCE are adopting our storage architecture for their own infrastructure. When your programme produces things others want to use, that’s evidence it’s working.
Building a team follows the same logic — programme-level investment, not project-level hiring. At the AIR Centre, we’ve hired people at the start of their careers and invested in their development, because experienced hires to a mid-Atlantic island are rare and because growing someone within the programme builds knowledge that doesn’t walk out the door when a contract ends. João Gonçalves is now central to data centre operations. JuliaEO — the Earth observation workshop series I coordinate — started partly as a way to create learning opportunities that a small team on a remote island wouldn’t otherwise have access to. This is slow work, especially when funding is sparse and every position has to be justified against a project deliverable. But the alternative is faster hiring tied to project timelines, which means losing people and rebuilding capability every cycle. That’s exactly the pattern programme thinking is meant to break.
None of this follows a tidy arc. The progression is real but unfinished, shaped as much by what’s available as by what’s planned. What holds it together is the commitment to a programme of work — ocean monitoring, data infrastructure, Earth observation services — that predates any individual project and will, if I’ve judged this right, outlast them.
---
Our early warning system for Pythomices chartarum — SAP-c — started the way most of our work starts: with a specific problem and the stakeholders who actually cared about solving it. The working prototype we built in 2021 performed well enough to help us secure project funding, and that project was central to developing both the application and the underlying science. When the data it collected proved critical enough, the stakeholder company wanted to keep it running beyond the project. They now fund the service directly. That trajectory — prototype to project to sustained operation, each stage earned by the previous one — is programme logic working as intended.
Over four years, the data SAP-c collected proved that the existing scientific models for the fungus were incomplete — the observations didn’t match the predictions. Last summer, we developed a machine learning model that outperforms what we started with, trained on the data our own infrastructure generated. The project advanced the science. But the insight that the models were wrong came from what the project couldn’t have delivered on its own: four years of continuous operation.
This is what I mean when I say that infrastructure, sustained over time, becomes a way of knowing. A project-scoped version of SAP-c would have been built, delivered, and archived. The models would have gone unquestioned because there wouldn’t have been four years of continuous data to challenge them. The knowledge that made the new model possible wasn’t designed — it was generated by the commitment to keep something running.
The new model is ready. Deploying it into production is next — integrating it into the operational pipeline, validating it against live data, transitioning from the current system. The infrastructure that generated the insight is the same infrastructure that will serve the improvement. That continuity is the point.
---
The most recent example is still unfolding. In late 2024, we developed a prototype of the Internal Waves Service — a global ocean monitoring system built on Sentinel-1 SAR imagery. Before committing to a full build, we used it to gauge interest. Over twenty research institutions are now involved, and the second in-person workshop is scheduled for April.
The pattern by now is familiar: start with something that works, show it to the right people, let their engagement determine what it becomes. But the IWS is also where the structural tensions I described earlier are most visible. The service needs validation — to be tested and confirmed as a reliable scientific platform. The available grants fund discovery. The proposal we’re writing has to serve both, and that negotiation is ongoing.
We’re deploying a new system architecture ahead of the April workshop — faster, more robust, designed to process the full Sentinel-1 archive back to 2014 alongside the live feed. That’s a programme-level investment: we’re building infrastructure for what the IWS needs to become, not just what the next project requires.
And the community that formed around the prototype is now generating its own momentum. The group works well enough together that joint funding applications are following naturally — two submitted, one in progress. Twenty institutions didn’t come to the table because of a grant. They came because the work was worth doing and the prototype proved it was possible. The funding is assembling around the work, not the other way around. Whether it assembles fast enough is an open question
.
---
I’ve tested this approach across three contexts over fifteen years. Some of it has worked. BahrainParks is government infrastructure, adopted by the Ministry of Works. SAP-c started as a prototype, attracted project funding, and is now sustained by the stakeholder that uses it — four years of continuous data that proved the existing science incomplete and generated a better model. The data centre exists, built when we couldn’t buy what we needed, and it runs everything else.
Some of it hasn’t worked yet. I haven’t led a major funded programme. The structural gap between discovery grants and operational sustainability is real, and I navigate it on every proposal rather than having solved it. The IWS has twenty institutions engaged but the funding architecture to match that momentum is still being built.
This isn’t a formula. It’s a thesis, developed through failure and tested in practice: that the unit of continuity is the programme of work, not the project that funds it. The evidence is accumulating. The work continues.