Last week we ran the first CRAFT roundtable. No slides. No presentations. Just a small group of people working in charity data roles, given the space to talk honestly about what the job actually looks like.
That was the intention from the start. Not to teach, not to pitch, just to create a room where people could compare notes without needing to have all the answers. We wanted to see what would emerge if we simply asked people to describe their work as it actually is, not as it appears in job descriptions or organisation charts.
What emerged was both reassuring and revealing. Reassuring because the patterns were so consistent. Revealing because those patterns point to something structural about how these roles have developed across the sector.
The shape of the role
Different organisations. Different systems. Different causes. But the fundamental shape of the role felt remarkably similar across the group.
Most people have not stepped into a clearly defined “data career path”. They have grown into the role over time. They became the person who understands the database. The person people go to for reports. The person expected to fix things when they break. And gradually, through a process that no one quite planned, the role expanded.
Not always intentionally. Not always with clear boundaries. Just through accumulation.
This is not unusual in the charity sector, where roles often evolve through demonstrated capability rather than formal progression. But it creates a particular dynamic.
You can find yourself carrying significant responsibility for an organisation’s data infrastructure without ever having been formally trained for it. Often without the organisation fully understanding what that responsibility entails.
The role becomes defined by what you can do, not what you were hired to do. And because there is often no one else in the organisation with comparable technical understanding, there is little external calibration of what is reasonable to expect.
That was the first pattern. But it was not the most interesting one.
Where the real friction sits
One of the more surprising threads in the conversation was this: very few people were struggling with how to do something technically.
They can learn a system. They can write queries. They can build reports. The sector attracts people who are good at working things out. If there is a technical problem with a clear solution, most people in the room had the capability to solve it, or at least knew where to look.
The harder part sits around that.
How do you prioritise when everything feels urgent? How do you explain that something will take longer than expected without sounding obstructive? How do you push back on a request without becoming the blocker? How do you make time for improvement when most of your time is spent responding to immediate needs?
One comment summed it up well: “I know what needs to change. I just don’t have the time to do it.”
That came up more than once, in different forms. It points to something central about these roles. The challenge is not capability. It is capacity, context, and the constant negotiation between what is urgent and what is important.
This is compounded by the fact that many of these roles are isolated. You might be the only person in your organisation doing this type of work, or part of a very small team with a broad remit.
So the decisions about prioritisation, scope, and what constitutes good practice are often being made without much external reference.
That isolation makes it harder to calibrate. Whether your experience is typical. Whether your workload is reasonable. Whether the friction you feel is a system problem or a personal one.
The default state is reactive
There is always another request. Another extract. Another campaign. Another report. Another deadline.
On top of that, there are seasonal pressures that are largely predictable but still difficult to absorb. End of financial year. Quarterly reporting. Funders asking for data within tight timeframes. Major campaigns that need segmentation yesterday.
So the work that would make things better — documentation, data quality improvements, automation, better structure — tends to get deferred. Not because people do not recognise its value. Everyone knows these things matter. They just sit slightly out of reach, always one crisis away from being deprioritised again.
This creates a cycle. Without the foundational work, everything takes longer than it should. Reports that could be automated require manual intervention. Data quality issues that could have been prevented now need urgent fixing. Systems that could be integrated remain separate, requiring duplicate entry or complex workarounds.
And because that foundational work never quite gets done, the reactive pressure never quite eases.
This is not a failure of individuals. It is a structural characteristic of how these roles function within many organisations. The urgent is visible. The important is not. And without someone senior enough to protect time for strategic work, the urgent will always win.
Data culture quietly shapes everything
A lot of the friction described in the session was not about systems at all. It was about how data is understood and used across the organisation.
Duplicate records that do not get merged because someone is unsure whether they are the same person. Requests based on assumptions about “what we did last time” that may or may not be accurate. Processes that exist in practice but are not documented anywhere, making handovers difficult when people leave.
None of these are unusual. But they have a cumulative effect. They make reporting harder. They increase manual work. They create uncertainty in decision-making. And they tend to land on the same person to resolve, because they are the only one with enough context to untangle them.
Data culture is one of those terms that can sound abstract, but in practice it shows up in very concrete ways. It is whether people check before creating a new contact record. It is whether campaign teams tell you what they need before they brief the agency. It is whether managers understand that “quick” and “accurate” are often in tension.
And critically, it is shaped by how much the organisation understands what good data practice requires. If senior leadership does not have a clear mental model of the work involved, it becomes harder to make the case for doing it properly.
There is more ingenuity than people realise
One of the more positive things to come out of the session was recognising how much people are already building for themselves.
Spreadsheets to check for duplicates. Macros to speed up repetitive tasks. Dashboards built in spare time. Workarounds to fill gaps in expensive systems. Small automations that save twenty minutes every week.
This is happening across the sector. Quietly. Individually. Often without much visibility beyond the organisation.
It points to something important. There is significant capability distributed across these roles. People are solving problems creatively with the tools they have access to. But because that work is often invisible to the rest of the sector, there is little opportunity to build on it collectively.
This is one of the things CRAFT is trying to address. Not by creating another repository of resources that no one looks at, but by creating space for people to describe what they have built and why. Because the context matters just as much as the solution. Understanding why someone built a particular workaround often tells you more than the workaround itself.
What the space made possible
The most useful moments in the session were not when someone had an answer. They were when someone said something and others recognised it immediately.
“Oh, it’s not just me.”
That is easy to overlook, but it matters. Because when you are the only person in your organisation doing this work, it is hard to calibrate whether what you are experiencing is normal. Whether the pressure is reasonable. Whether other people find this difficult too.
Having a space to compare experiences, even briefly, changes how those challenges feel. It does not solve them, but it shifts them from individual problems to shared patterns. And that makes it easier to think about them clearly.
This is not therapy. It is professional context. And in roles that are often isolated, that context is valuable.
What we will change
One piece of feedback was clear. People value open discussion, but they also want some structure to anchor the conversation.
So the next roundtable will be split more deliberately. A first section for open discussion and current challenges. A second section focused on a specific topic, so we can go deeper on something concrete rather than staying at surface level across everything.
That should give enough flexibility for real conversations while creating some continuity between sessions. We will see how it works and adjust from there.
Why this matters
There is a lot of conversation in the sector about systems, platforms, and tools. Those things matter. But what came through in this session is that the day-to-day reality of these roles is shaped just as much by time, expectations, culture, and the ability to make good decisions under pressure.
That is harder to solve with a system. It is easier to explore in conversation.
The roundtables are one part of what CRAFT is trying to do. Not the only part, but an important one. Because capability building is not just about learning new techniques. It is also about understanding that your experience is not unique, that the patterns you see are structural, and that other people are navigating the same tensions.
We will keep running these sessions and refining them as we go. If nothing else, the first one confirmed something quite simple: there are a lot of capable people doing this work. They just do not always have a place to talk about it.