Claudifying program operations at HIP

By Nina Friedrich🔸, High Impact Professionals @ 2026-08-20T08:57 (+22)

Summary

• We are currently automating the majority of our program operations, so that we can significantly scale our programs without the admin growing at the same speed.
• A task is worth automating for one of three reasons: 1) Speed, 2) Evening out the workload, or 3) Reliability and quality. A fourth reason is different in kind: some things were never possible without AI use.
• Our process: 1) Set a rough North Star, 2) Start with a small version, 3) Document, especially for tasks you want to repeat, 4) Build out from the example, and only then 5) Set your actual North Star. Step 5 often crystalises during steps 1-4.
• The prerequisite is knowing your tasks. Our ~350-task template for one program round of our Impact Accelerator Program is what made this tractable. Without that list, building it is the first thing to do, and it probably pays off even if you automate nothing.

At High Impact Professionals the most valuable things we do can't (yet) be automated: supporting individual people through high-impact career decisions, making the right introductions, the human conversations that actually change someone's path. The program operations around those take a lot of time and can mostly be automated. THerefore, we are teaching Claude Code to run the recurring operational scaffolding, so our time goes to the parts only we can do, and so we can support far more people.

This post covers how we think about what to automate, the five steps we follow, and what it looks like in practice. We use Claude (specifically Claude Code); other coding agents are available and most of this should transfer.

Part 1: How we think about automating

Three reasons to automate

Not everything is worth automating. We found three reasons why automating something can make sense, and luckily they are not mutually exclusive!

1. Speed. The obvious one: some tasks get much faster. If you do something every month and it takes you 10x as long to automate it, you are already gaining time by month 11. Giving an organisation recruiter access to our Talent Directory used to be really annoying. It never took more than ~10 minutes, but it involved task switching, several systems, and remembering various edge cases. Now it is done at the click of a button (two buttons in some cases). That means organisations get access faster, at the point where they most need it: when they are hiring.
2. Evening out the workload. If many things need doing at roughly the same time, spending time early (when the workload is somewhat lower) to automate some of them means your peaks are lower overall. Our program rounds are exactly like this: cohort matching (a lot of thought goes into this, so it used to take us two days to get right), Google Drive and calendar set-up, welcome emails, and a good deal more are all needed on the same two days. Every task automated in a quieter week makes the peak week more manageable.
3. Reliability and quality. Automation does the boring parts the same way every time. We have a very low drop-out rate in our Impact Accelerator Program (1.5% in 2025). But when someone does drop out, it involves updates to 15 internal systems. By hand, we never managed to remember all of them (there is a list, but with the program evolving it is often slightly out of date). Now we do ~95% of them with the click of a button.

Those three are all about automating tasks you already do. There is a fourth reason to use tools like Claude Code: enabling things that were never possible manually, but since this is not the focus of this post, here's just one example: 

• Talent Directory Automated Matching. A daily unattended run that surfaces relevant people from our Talent Directory for new roles at organisations with recruiter access, and drafts the shortlist for a human to review and send. I had assumed we would need to bring in a contractor to build something like this. It turns out Claude Code was enough. If you are hiring and want to make use of this, please request recruiter access to our Talent Directory.

Five steps to claudify a process

The process we follow, learned by doing. We have started calling it "claudifying": automating a task by teaching Claude to do it.

1. Set a rough North Star. Roughly where do you want to go? It does not need to be precise, and (see step 5) it might change as you learn more about the process. This is also a good moment to ask whether your goal falls under any of the three reasons above.
2. Start with a small version. Automate one concrete instance of the task, one step of the process, one example you understand well. Do not start with the whole system and every exception at once, mainly because you learn about many of the exceptions as you go.
3. Document, especially for tasks you want to repeat. Make sure Claude knows what to do next time, otherwise it has a tendency to rewrite things from scratch. We store the instructions where the task lives: tickets in our task tracker carry the how-to, tagged so Claude knows to execute them directly next round.
4. Build out from the example. Generalise once the small version works. It turns out there are far more paths for handling organisation applications to the Talent Directory than I would have expected: a new organisation name could be a genuinely new organisation, or a typo, or a different spelling, or a rename of an existing one. We add these as we find them (I hope we have them all now!).
5. Set your actual North Star. Only now do you know enough to see where this is really going.

An example of the North Star shifting

When we started claudifying the program operations of our Impact Accelerator Program, the initial North Star was simply "automate any relevant tasks". As we worked through them, we realised we could turn it into a system. Along the way we got an overview artifact, a colour-coded map showing how automated each step of a program round is. For the record, we are at 11% of the ~350 tasks being mostly automated and climbing, working through them as and when they naturally become due.

More importantly, the actual North Star became clearer: a system that at the start of each week goes through that week's tasks and lists

• tasks due that week that are fully automated,
• tasks due that week that need input before the automation can run (for example, which speakers we would like to invite to our panel discussions),
• tasks that are still manual.

We confirm, and Claude does its share on the relevant days. We did not have this in mind when we started, and that is exactly the point of steps 1 and 5.

Working principles we converged on

• Claude drafts, humans send. Nothing goes out without review. There is no email-sending capability in the automation code; the last step is always a human clicking send. This might change in future. For now it is sometimes a bit annoying but has saved us on multiple occasions.
• Put the instructions where the task lives. Documentation inside the task tracker (or a per-repo CLAUDE.md) survives. Documentation in someone's head or a chat log does not. Since nobody loves writing documentation, this is itself automated: before pushing to GitHub, it checks for any documentation updates and test additions required.
• Claudify as you execute. When someone on the team does a recurring task manually, they spend a little extra time capturing it so the next round is automated. This also gets faster over time, as Claude learns more about our systems and programs.
• Make it portable. Automations live in shared repositories with unit tests, so any team member can run any of them, not just the person who built them. Claude wrote all 4,000+ of our tests, which removes the usual excuse for not having any.
• Share the learnings. We call it "Claude Corner" and it is a regular item on our team meeting agenda. Every month or so, someone shares a new use case to inspire the others and keep pushing what is possible. I also really like AI Wow for inspiration!

A word of warning: know your tasks

Saying "Claude, please automate our program ops" with no further context would have been a very limited success, to say the least. Instead, we have a template of ~350 tasks involved in running one round of the Impact Accelerator Program (which might be linked to participants and facilitators finding the experience rather well organised 😉). Marketing and outreach, vetting, building the material for every participant, coordinating facilitators, participant comms, M&E and much more, each with its due date. Automating these one by one, and ideally several at once, is far more achievable than trying to remember what is involved in the first place.

If you do not have that list, building it is the first automation-adjacent thing worth doing, and it probably pays off even if you never automate anything.

Part 2: What this looks like in practice

A selection, grouped by the three reasons above.

Speed

• The weekly referral run. A 13-step routine: ingest new referral requests from the inbox, surface every decision on a review dashboard, draft each tailored referral email on the correct thread, log everything. The main step, knowing who to refer to which role, is still manual, so we spend our time on the most important part of the referral process, rather than on tracking and email drafting. This let us roughly 3-4x our referral output for about the same amount of time spent. (Are you hiring and looking for curated referrals from our Impact Accelerator Program? Email us at info@highimpactprofessionals.org.)
• Monthly finances. Receipts swept from Gmail into Drive, expense dashboard generated, salary invoice created, budget actuals written, submissions prepared; leaving only the final confirmation step to a human.
• Recruiter access to the Talent Directory. See example in Part 1.

Evening out the workload

• Facilitator coordination ahead of a round. We need to line up facilitators during the busy participant vetting period. Automating the comms and the tracking of responses makes that much easier, especially having grown from 30 participants in a round in 2024 to over 100 now.
• Lowering the peak of the program operations phase. See example in Part 1.
• LinkedIn quarterly planning. Learning from past posts, updating our tone of voice over time, and pulling from ideas saved whenever they came up. We can now start ~50% of the way to the finish line rather than from scratch.

Reliability and quality

• One-command participant changes. A drop-out is removed from all 15 systems at once (See example in Part 1.); the same tooling onboards people or moves them between cohorts. It saves a lot of time, too.
• Participant introduction slides. Giving edit access on a slide deck to ~130 people means something will go wrong. We now check automatically: do slides exist for all participants, did someone fill in the wrong slide, did someone move a slide by accident. All are fixed automatically.
• Blind vetting. Anonymised candidate handles, without manually copy-pasting files into new folders, so nobody on the team sees the names before the test task vetting is done.

Caveats

• Everything above runs with a human in the loop. Claude produces drafts and dashboards; people make the calls and press send.
• Building this took (and takes) real time. The three-reasons framing is partly about deciding where that time pays back.
• And occasionally the honest conclusion is that five minutes of doing something by hand once a year beats an afternoon of automating it.
• I was a software engineer in my first job. I have forgotten most of it, and I have written exactly zero lines of code by hand since we started this (which is for the better, believe me!). It does help with the conceptual side of producing software, even without writing any code. If you have not been a software engineer, get Claude to explain things to you as you go.
• Not everything we built is still in use. One of the first things I built with Claude Code was an interactive morning-routine dashboard, which has since been retired. I would not call it a failure or waste of time though. The integrations built for it (calendar, inbox, task tracker) now power other automations, and building it is how I learned what Claude Code can do. Getting started somewhere, ideally on something that touches some of your systems and that you find fun (a pretty dashboard can make things a lot more fun!), is most of the value of a first project, even if the thing itself does not survive.
• On cost: we are on the Claude Team plan with the non-profit discount, with most of the team on Premium seats at $40 per person per month. For what is effectively an additional team member's worth of output, we consider that very cheap.

Our time now goes to the work that creates the impact: supporting people, making connections, changing paths. The automation is also a good foundation to scale from: onboarding a new team member is far simpler, and it is a solid baseline for building new programs on.

We would love comments, both from organisations doing similar things and from anyone considering starting.