The Doors We Walk Past

Have you ever looked at something someone else does at work and thought, “I could never do that”?

That’s how I always felt about engineering. I’m an Executive Assistant, and my days revolve around calendars, inboxes, weekly team huddles, conferences, onboarding, board logistics, and all the small details that keep an executive’s week running smoothly. For most of my career, I relied on software built by other people. I never imagined I’d be the one building it.

Like most people, I started using artificial intelligence for everyday tasks. I’d research an institution before a meeting, summarize documents, draft emails in my own tone, turn meeting notes into action items, or organize a travel itinerary. It was useful, and it genuinely saved me hours each week. But looking back, I was only scratching the surface of what AI could do.

I Did Not Know the Words

When CampusIQ first introduced the idea that everyone, not just engineers, could build, I’ll admit I was nervous. I watched from a distance as the engineering teams started using these tools and assumed they were meant for them, not me.

Then the company opened it up to everyone.

I didn’t know what a pull request (PR) was. I didn’t understand what it meant to ship or merge code, or even what a skill was. I worried everyone else knew what they were doing while I struggled with the basics.

I’ve always appreciated something Nelson Mandela wrote in Long Walk to Freedom: courage is not the absence of fear, but the triumph over it. I thought about that when I decided to try this. I wasn’t suddenly confident or comfortable with building software, but I also didn’t want fear of something unfamiliar to stop me from learning.

What surprised me was that the confidence didn’t come when I decided to start. It came after I finished something and saw that it actually worked.

The First Thing I Shipped

On April 23, 2026, my first pull request was merged. It was a design document and implementation plan for how our conference operations should work, and I remember refreshing the page to make sure the word “Merged” was really there. Three weeks later, on May 12, we pushed the first working version.

It solves a problem every operations person will recognize.

CampusIQ doesn’t organize conferences. We attend them, and our roadmap includes more than thirty higher education events throughout the year. We typically commit to about half of those. These events are important because they’re where we meet facilities directors, campus planners, and business officers who often become customers.

But managing all those events comes with a lot of moving parts. Every conference has deadlines that need attention long before we even know whether we’re attending. A registration cutoff might arrive by email in February, a speaking proposal closes in March, and sponsorship commitments and membership renewals are scattered across different inboxes.

Missing one deadline can mean losing a booth, missing a speaking opportunity, or paying unnecessary fees. And when you’re managing dozens of events, keeping track of everything manually becomes a job of its own.

So I built a skill that reads our conference roadmap and tells us what’s due in the next seven, thirty, or ninety days. It automatically posts reminders in our team channel, so everyone knows what’s coming without having to constantly check different calendars, spreadsheets, and inboxes.

It was a relatively simple solution to a problem I knew very well. And it was the first time I’d built something that other people at the company could actually use.

Start With What Is Painful

Our CEO, Aaron Benz, gave me advice that helped me decide what to work on next. Start by solving the problems that directly affect you, especially the ones that are genuinely frustrating. Once you’ve built something that works for you, figure out how to make it useful for everyone else.

That’s why I didn’t start with something particularly impressive. I started with the problems that made my own work harder than it needed to be.

Grace Hopper once said that the most dangerous phrase a manager can use is “we have always done it that way.” I think about that when I see how many everyday processes we keep following simply because they’re familiar. Onboarding was a perfect example.

Most companies use a checklist for onboarding, but an enormous amount of coordination still happens behind the scenes. A new hire might be confirmed just five days before their start date, and suddenly someone needs to organize their accounts, equipment, first-week calendar, welcome messages, and role-specific setup.

A lot of that information lives in one person’s memory. If something gets overlooked, the new employee usually feels it.

On June 18, I merged my onboarding skill. It now handles intake, generates the necessary tasks, drafts messages for human approval, and updates our team roster. Instead of scrambling to get everything ready, we have a process that helps ensure each new colleague arrives to an organized first day.

And the best part is that it isn’t something only I can use. Any department lead can run it under their own name, and nothing gets sent without a person approving it first.

I won’t pretend it’s perfect. Every new hire since June has revealed something the skill could handle better, and we’ve continued improving it along the way. I’ve had to get comfortable with that, too. You don’t need to have every detail figured out before you start building. Sometimes you learn the most by putting something into use and seeing what needs to change.

What a Company Chooses to Count

As I write this in September 2026, I’ve merged eighteen PRs into production across three of our repositories.

CampusIQ tracks what each person ships and makes that progress visible across the company. Your first merged PR earns you a badge, and there are more milestones at 10, 25, 50, 75, and 100. Each comes with a higher rank and custom artwork featuring your face.

We unveil the badges during our Friday all-hands meeting, so everyone can celebrate the progress together.

I was excited past the point of dignity about the first one. I hold the 10 now, the 25 is close enough to see, and here’s the part I still find funny: the slide that displays everybody’s badges each week is itself one of the things I built.

It’s a small thing, but it’s incredibly satisfying to see your work used by the people around you. Especially when, just a few months earlier, you didn’t even know what a pull request was.

An Assistant Named Mufasa

Not everything I’ve built is in production, and I’ve learned that doesn’t make it any less valuable.

I built an assistant of my own and named it Mufasa, after the lion who tells his son to remember who he is. I liked the name because I needed help remembering things on my behalf.

Every morning, Mufasa goes through my email, calendar, and Slack messages and helps me prioritize what needs attention. It captures commitments as they’re made, so something I promised in passing doesn’t disappear between a conversation and my desk. At the end of the day, it helps me review what actually got done and what still needs attention.

It’s built around my specific responsibilities and how I work. Mufasa knows how I write, which conversations I’m waiting to respond to, and which commitments are especially important. No vendor would ever build something quite like it because nobody else has my exact job or schedule.

That’s been one of the biggest surprises of this experience. For years, I adapted my workflow to whatever software was available. Now I can build tools around the way I actually work.

And once you realize that’s possible, you start noticing all the little things throughout your day that could be easier.

Access Without Condescension

I want to be precise about CampusIQ’s role here because it would be easy to turn my experience into a story about determination and learning something new.

Of course, those things matter. But I’d wanted to learn new skills for years. What changed was that I finally had the opportunity to do it.

CampusIQ gave everyone access to the same tools the engineers use, and then did something I think is equally important: it held us to the same standards.

My PRs go through the same review process as an engineer’s. I’ve had work sent back for correctness, for clarity, and once for a mistake I was convinced wasn’t actually a mistake. I’ve learned to take that feedback, make the changes, and try again.

Nobody lowered the bar because I’m the Executive Assistant, and nobody would let me quietly fail either. They gave me the tools, the support, and the expectation that I could figure things out.

That combination, access without condescension, is the whole engine.

Who Is Allowed to Build?

One of the biggest things I’ve learned through this experience is that the people who understand a problem best aren’t always the people who know how to write code.

Assistants, coordinators, analysts, and managers spend their days working with systems and processes. We know where things break down, what takes too long, and what could be better. Until recently, most of us had to rely on someone else to make those improvements.

That’s what CampusIQ changed for me.

In April, I didn’t have a computer science degree, and I don’t have one now. But I’ve built tools that my colleagues use, improved processes that used to take up hours of my week, and learned skills I never imagined would be part of my job.

I’m still learning, and I still have plenty I don’t know. My work still gets reviewed, my tools still need improving, and I still run into things I don’t understand. But I no longer assume building something is someone else’s job.