You know that thing where you spend a weekend building a Zap that saves you 4 hours a week, and then on Monday you just...sit with it? Nobody asked you to do it. Nobody's going to promote you for it. Your manager might not even understand what you did.
But you know what you did. You got frustrated enough to fix something, and you taught yourself the tools to make it happen.
I did this for years in healthcare ops. I was the person on the team who made Excel do things it had no business doing — ROI calculators, invoicing tools for contracts that had fifteen different rate structures, entire mini-operating systems held together by formulas and stubbornness. Eventually the work wasn't hard, it was just tedious, and no spreadsheet was going to solve that. So I started automating.
I automated almost my entire role. And then I turned around and started teaching the people around me how to do it too.
That pivot had a much bigger impact than anything I'd built on my own. The automation I created saved hours. The program I built — training non-technical people to identify their own bottlenecks and build their own solutions — saved thousands. 3,000 hours of work automated across the organization in 6 months. And when I left, the program kept running. Four more training cohorts completed without me.
I think a lot of you are in the first half of that story right now. You're the person on your team who figured it out. You built the thing. You saved the time. And you're wondering what comes next.
I've seen this across a dozen organizations since I started CitizenWorks. The pattern is consistent: the most valuable thing you bring to the table is that you understand the work well enough to know what should be automated in the first place. IT teams have the technical skills but they don't sit in the workflows every day. Consultants can build systems but they leave, and 6 months later nobody knows how to update anything. You're the person who actually understands how the work gets done.
The organizations getting AI adoption right have figured this out. They're finding the people who already taught themselves the tools and building structured programs around their knowledge. Giving them support, permission, and a way to teach the rest of the team.
There's a name for this: citizen developer programs. The ones that actually work tend to start with someone on the team who cared enough to automate their own job and was generous enough to show someone else how.
If you've been the unofficial "tech person" on your team, there's something bigger you could do with what you've learned. I'll be writing a lot more about what that looks like over the coming weeks.
— Jamie
P.S. If you're a leader reading this and thinking about someone specific on your team, pay attention to that instinct. Most organizations are completely overlooking those people.