Say a field team comes to you with a clear ask: an app that nudges coaches to complete their school visits and logs whether each visit took place. It's a reasonable request; visits do slip through the cracks, and the team already has a working rhythm they want to protect. Losing this data would affect our ability to provide relevant support to the teachers.

It would be easy to just build that. Instead, you spend a little time understanding the work the technology is meant to support. Not because the request is wrong, or because the team hasn't thought it through, but because so much of good work lives in people's experience rather than in “written process”. 

So you ask a few slightly annoying questions, not to poke holes, but to understand the parts of the work that everyone already understands intuitively, and whether the technology needs to understand them too 

• What counts as a "completed" visit: the coach arriving, or something specific happening once they're there? 

  
  

• Who confirms it's done: the coach, the teacher, or the data? 

  
  

• What's the unique identifier for a visit, the coach, the school, the date, or some combination, and what happens when the same coach visits the same school twice in a week? 

  
  

• Do we even own the coach-to-school mapping, or does it live in someone's head and a spreadsheet? 

And once a visit is marked done, what is supposed to happen next, does anyone act on it, or are we just collecting a record?

The team usually has a shared sense of all this informally; they'd know a good visit if they saw one, but it's never been pinned down, and different coaches interpret it slightly differently. None of that is necessarily a problem while the work stays human-centred. People can rely on judgment, context, and conversation. 

But the moment you ask technology to support that work, those assumptions have to become explicit. 

Software can't operate on "everyone more or less knows what we mean."

So the app doesn't get scrapped. It changes the conversation. 

Before anyone writes a line of code, the team is forced to ask questions it had managed to avoid until now: What exactly is a visit? Who decides it happened? What should happen next?

The technology hasn't solved the ambiguity; it has exposed it. And in resolving that ambiguity, the team builds something more valuable than the app itself: a clearer understanding of how the things actually work.

The app simply becomes one expression of that thinking.

I've been sitting with moments like this for a while, and they've managed to change how I think about what technology is actually for in an organisation like ours at Simple Education Foundation. 

And I used the word “managed” here quite deliberately.

Tech isn't the artifact. It's the leverage.

When people hear "technology in a nonprofit," they usually picture an artefact, a platform, an app, a dashboard. Something you can point to and show a funder or the outside world. But we do more than just build.

Unlike a non-profit working exclusively in technology and software, in implementation-facing organisations, technology is not the end product that the world sees. It’s the enabler. A force multiplier. 

 At its simplest, it takes a good process and lets it run at scale. 

At its best, it does something subtle and more valuable: it helps teams think in systems, to break work down logically enough that they can see exactly where the gaps exist, and where it could be better.

So, my understanding has evolved from “tech as a thing we build” to “tech as a way of thinking we build into the organisation”.

In doing so, technology verticals in implementation organisations may end up feeling like the actual technology building process may be the least interesting part of the job. But, we’re not complaining - because we get to build thinking systems for our team.

The most valuable output is often a better question

The most useful thing an in-house tech function does is not write code. It's push back, gently, and in good faith. An external vendor takes the brief and builds it. The thing ships, the novelty fades, and often it sits unused, because the brief captured what was asked for, not what was needed. An in-house team, sitting inside the work, can ask the questions that surface assumptions early.

Let me expand on the article from above. When we set out to build a dashboard showing coaching coverage. It seemed straightforward until we asked a simple question: What exactly counts as a coaching visit? Different people carried different answers, and none of them had ever needed to be written down. The dashboard wasn't difficult to build. Agreeing on what it was measuring. 

Was it reaching the school gate? Sitting with the teacher? Observing a class? Giving feedback? 

Questions don't just produce better software and solutions. They send the team back to look at their own processes, critically and with fresh eyes.

Very often, the most valuable thing to come out of a tech conversation isn't a tool at all. 

It's a sharper question the team hadn't known to ask itself. I'll admit, this is a slow, humbling realisation when your instinct, and your job title, is to build things.

You can't multiply zero: Internal clarity comes before the technology

A good process that ten people can follow by hand can become one that ten thousand can follow, once you add tech. That's the real magic of it. This is why I've come to think of technology as a force multiplier, and never a solution on its own.

But you cannot multiply zero by anything. Multiply a strong, clear process, and it scales beautifully; multiply a vague one, and you simply get a faster mess.

If a process leaves a small team confused, and they are always upskilling, always catching up, never quite settled. Can the process really be scaled? No, technology cannot be the solution here.

The clarity has to come first. Tech makes a good answer travel further. It cannot invent the answer for you.

Three kinds of decision, one person's hat: Building role clarity

There's a distinction I've found important, and I don't think it's talked about enough in our sector: an engineering decision is not the same as a product decision, which is not the same as a program decision.

An engineering decision is about how something is built. 

A product decision is about what should be built, and for whom. 

A program decision is about what the work is trying to achieve for teachers and classrooms in the first place. 

These are genuinely different kinds of thinking, and they're easy to conflate, especially in a nonprofit, where one person frequently ends up wearing all three hats without realising the hats are different.

This isn't a criticism of anyone. It’s the reality of our resource-deficient sector. 

But, knowing what it means to run a technology function, or how to work with one, is simply a different muscle, and one most of the sector is only beginning to build. 

 An in-house tech capability can do is make these roles visible, help place the right people in the right seats, and help the organisation understand that a tech vertical works best as a thinking partner, not a vendor you hand a spec to and later blame when it doesn't fit. 

That relationship takes time to grow, and it grows fastest where the pushback is welcomed rather than waved off.

Where we're trying to go

I spend my days building technology solutions, and I believe in it completely, because when it works, it lets a small team deliver and learn faster, and support more people without a quality slip.

That belief is also a direction we're deliberately moving in. 

We're working to build technology into the organisation, not as a collection of tools bolted on at the edges, but as a mindset and capability woven through how we operate, one that helps our teams standardise what works, reflect on what doesn't, and carry consistent quality to far more stakeholders than any of us could reach by hand. 

The ambition is not a shinier dashboard. It's an organisation that can grow, whose programs can scale, and serve more teachers and coaches with the same care it manages today. We're early in that journey, and honest about it. The systems are maturing, the thinking is maturing alongside them, and the two have to move together, because the moment tech gets ahead of clarity, you're back to multiplying zero.

 But the direction is set, and it's one I hope resonates with others who see the same possibility: that the real leverage in this work was never the artifact. It was always everything the artifact is allowed to sit on.

Start one step before the build

So if you're an implementation organisation thinking about technology, my honest suggestion is to start one step before the build. Before what should we make?, sit with a less exciting question: what are we actually trying to multiply?

Get that right, and, more often than you'd expect, the tech almost builds itself.