The gap between good intentions and systematic delivery

A senior leader and I had a meeting at South Pole, the last thing they brought up was, 'We want you to build these solutions next,' they said, outlining an ambitious set of new software products.

This should have been exciting. We were the digital climate solutions team - hired specifically to build technology that could solve climate problems. We'd been set up separately from the main consulting business so we could have our own ways of working and do things the way tech teams are supposed to.

But I had questions. Why these solutions? What problems are we solving? Who would actually use this? What's the business case?

The person I was talking to seemed to understand these were reasonable questions, but they also seemed confused that I was asking them. They tried to answer quickly, and get us moving, but when I didn't budge, the confusion grew. It became obvious they'd already committed to someone, somewhere, that we'd build these things.

The problem was, they wanted to be a tech-forward company but were approaching software development like consulting projects - say yes first, figure out the details later.

This pattern is everywhere

Every impact organisation I've worked with has some version of this challenge. They know what change they want to create, but the gap between good intentions and systematic delivery trips them up.

It's not about intelligence or capability. These are brilliant people working on crucial problems that they're passionate about. But somewhere between 'we should build this' and building something that works, the wheels come off.

At South Pole, part of the issue was that leadership didn't grasp the real cost of software development. Building something that actually works - not a prototype, not a demo, but a system people can rely on - takes a serious team of engineers and a designer several months. The timelines and budgets for that reality never seemed to land.

But the deeper problem was process. We were hired to build software systematically, while the organisation wasn't set up to support systematic development. When I asked if we could talk to consulting clients who'd use our tools, the answer was no.

How do you build tools for users you can't talk to?

Same gap, different context

I saw this pattern again with a project called Climate Huddle. The vision was compelling - a community platform where SMEs could connect, share knowledge, and access simple climate tools. Think of it as combining community building with practical climate action.

I'd seen community building work at Canonical with Ubuntu. Open source communities succeed because you invest in them systematically. You create spaces for people to gather, you populate them with both company people and community members so they feel active, and you acknowledge it takes time and sustained effort to build something meaningful.

But at South Pole, the approach was different. They assigned an experienced practice lead to the project and allocated some marketing budget, but made no systematic investment. No roadmap capacity, no dedicated development budget, no process alteration. It was supposed to work on entrepreneurial spirit alone.

The moment I realised this wasn't going to work was during a "team" meeting where only three people were invited - including me. Both the marketing person and I were part-time contributors. At the end of the call, when we discussed what we'd accomplish before the next meeting in two weeks, it was obvious we'd have almost nothing to show because of our split focus.

You can't build community as a side project.

What systematic delivery looks like

Looking back, both situations needed the same thing: proper process definition and buy-in before any building began.

Instead of jumping straight into development, we should have started with a gated innovation review process. Any new idea would need to answer basic questions: What problem does this solve? Who are the users? Where does the funding come from? What does success look like?

We'd follow this process completely before writing any code. If leadership had problems with the approach, they could raise them upfront, not after teams were already committed.

For the community project, systematic delivery would have meant dedicated team members, clear success metrics, and a realistic timeline measured in years, not months.

The cost of not doing this systematically is that skilled teams become demotivated, resources get wasted, and good ideas die because they never had a proper chance to succeed.

You have to actually change the way people work, processes, workflow, schedules, you should be able to tell things have changed because people do different things. If everything is the same then, surprise, everything is the same.

The gap isn't going anywhere

I started StudioRhys partly because I keep seeing this pattern across impact organisations. Brilliant missions, unclear execution. Good intentions, poor systems.

The organisations doing the most important work in the world shouldn't have to struggle with the basics of delivery. But bridging that gap requires acknowledging it exists first.

What gaps do you see between vision and execution? Get in touch to talk about closing these gaps.