There’s a lot of conversation right now about “context engineering” for dev work; structuring what you feed an LLM so it can do useful things. It’s fantastic, we use this approach for DRI Your Career – to the point where we moved our course development out of Google Docs and into GitHub.
But – Jean and I are engineers. I can’t ask my non-engineering colleagues at Twill to do that. Hiring, sales outreach, project tracking; these processes live in spreadsheets and email and Notion.
Having seen the power of this framing for engineering, and being slightly horrified learning about some workflows to transfer context, I’ve been building operational pipelines that apply the same idea to non-engineering work, using Notion, Claude, Gmail and Slack. The system pattern is the same whether I’m looking at intern hiring or sales outreach. It’s not complicated, but it is a shift in thinking.
The last time I ran hiring myself with no recruiter, it was a nightmare. Took forever, things fell through cracks, I hated every minute. This time it’s bearable. Sometimes it feels like Claude is my admin; it pulls the database, checks what’s due, drafts the emails. Sometimes it feels like I’m Claude’s admin; downloading a resume attachment because it can’t handle that yet, hitting send on an email that I’ve already rewritten twice.
The system pattern
The core idea is: Notion is the source of truth, not the conversation.
Normally people update the task management after the task. This needs to shift. Every update goes to Notion first. Reviewing the candidate against the rubric I specified gets written to Notion before I see it. When my email is pulled in, there’s a round of updates written – before I get a summary of what actually matters to me.
Some key things:
- Every record has a Next Action. This turns a database into a task list. When Claude scans the database at the start of a session, it can tell you what the next steps are and when they are due.
- A startup prompt transfers context between conversations. The same every time, that recognizes the data as the source of truth and works to the system you’ve designed.
- Use handoff docs to make it multiplayer. Similar to how we use “claude.md” in a repo, the way of working has to be encoded in the same way. This is a killer feature for me – it’s annoying to get humans to change process, it’s easy to get Claude to.
- Claude drafts, humans decide. Claude can search email, read threads, create drafts, write to Notion, and score things against criteria. It can’t send emails or make decisions. The human reviews and sends. Over all, I like the clarity: the repetitive work is automated but the judgment stays with me.
- Iteration is cheap. The Notion-as-source-of-truth pattern was foundational; once that’s in place, changing things is easy. Forgot a column? Need to reformat a field? Need to add comms logging? These are rote, repetitive tasks, that Claude excels at and I plan to never do again. Adjust as you learn. This is particularly important when building workflows for other people – encourage them to adapt it to suit their needs.
- Interop is critical. I’ve used Trello personally for years and never once thought about its integrations. Now the fact that it doesn’t connect to Claude is its biggest missing feature. That’s a personal tool and a minor irritation. For an organization, interop is so foundational I wouldn’t consider adding a tool that lacks it.
I can see why people are saying the enterprise software market is in for trouble. Not because any one AI tool replaces Greenhouse or Salesforce, but because for a lot of workflows, “Claude plus the tools you already have” is pretty good. Add in no procurement process and no extra cost – that’s very compelling.
There’s an idea that agents will replace the humans that use these systems – certainly AI will shift jobs around, but I’m also not convinced that is the right framing. Many startup hires fail because their role isn’t understood, and the same issue is true of an agent – you need to know what you actually want them to do. The danger of AI is that being over-confident and wrong in those kind of roles is a brand and credibility risk.
I’m not anti-agent, I use them for coding. But a lot of the agent conversation feels deliberately incomprehensible to normal people, and like some kind of panacea – which makes sense, I guess, when you’re selling something to do a job. But to get an agent to do something well you need to define what it’s doing well enough; which means understanding it well enough yourself first. For a lot of operational work Claude as glue between the tools you already use seems like a better start. Over time it may turn into an agent definition and run without intervention. Or it may not.
Any conversation about how AI changes work makes me think about scaling. I came from an environment with a lot of specialisation; dedicated recruiters, dedicated EMs, dedicated ops people. Now I’m using AI to compensate for roles I don’t have. Whether that’s recruiter or engineering manager or something else, the pattern is the same. I think this will fundamentally change when and what you hire for – it’s certainly reshaped what I think I need. The challenge for existing organizations will be retrofitting this onto an existing org – which is much harder than building with it from scratch. When you have nothing, the reasonable working thing is a great addition. When you have an existing process, the reasonable working thing is a compromise you may not be willing to make.
Leave a Reply