Tech is the easy part

Tech is the easy part

My CTO always said “tech is the easy part” when we talked about AI adoption across the org. As a software developer, I couldn’t buy it. I fought tech every day- deployment fires, debating architecture with colleagues, re-working systems that used to work and now had to stretch. Tech is hard.

And even now- with Claude feeding me perfect context, laying out every alternative for a technical call, asking the follow-up questions I’d have missed- it’s still hard. Which is when it hit me: he meant something deeper than the literal line.

Our role is changing, and not just in software. Implementation is getting easier. We’re all becoming guides to our favorite LLM (no judgment on your pick). AI is already a big part of my day- I keep scheduled tasks running in the background, work in parallel, lean on it to move faster.

Our R&D org is very AI-driven, so when I was asked to automate and integrate AI into our marketing department, it felt natural. But it became the project that changed how I see this whole AI era- and taught me lessons that stuck to my personal life, not just my work.

the brief was one line

There were four of us, developers originally, each paired with a different department. “Optimize” is a direction, not a plan. “Be more AI-first” stays a feeling until you decide what to do Monday morning. So I designed the whole thing from scratch, brainstorming with the others, who faced similar challenges in their own mini-projects.

The most basic question came first: what do I build this on? Claude on its own, Claude Code, Cowork? a dedicated hosted platform? Which platform fits a team that doesn’t write code? Getting that right mattered most- everything downstream would stand on it, and it was pure judgment, before a single line of code.

the department

Then the real work began, and it was about people.

To automate anything, I had to understand what the team actually does all day. So I sat with each person, one by one- what they spend real time on, what they dread, what eats their morning that a machine could just handle.

That’s where the work lived: finding the common threads. You don’t boil the ocean. You find the one thing three different people are all doing by hand, start there, and build out.

And here’s the part that still feels strange to say: the agent built it. I orchestrated. My job was to hold the vision of how the pieces fit into one system instead of disconnected toys.

learn about AI using AI

Half the time I was still discovering what was even possible. So instead of marching a rigid spec into a wall, I’d ask Claude “can we do this?“ “what about this pattern?“ and let it show me. I learned what the tools could do while I built with them.

A fully-baked plan would’ve let me build the wrong thing perfectly. My best ideas arrived mid-conversation. The well-defined task is the output of exploring, not the input.

shipping was the start, not the finish

The demo always works. Then real people use it every day, and you learn what “works” actually means.

So I stayed responsive, tending the unglamorous stuff that decides whether a tool lives or dies:

• It separates “I found nothing” from “I couldn’t check.” They look identical until you force them apart.

• The boring error noise goes to my DMs, so the team’s channel stays clean.

The goal was to save people time, not hand them more overhead- so I kept reaching for the version that fit into someone’s day. A tool can be impressive and still fail that test. UX matters, even for an internal tool.

the easy part

The hard parts were never the tech.

Choosing what to build on, sitting with people until you understand their day, finding the thread worth starting with, holding a vision clear enough that the pieces fit, and caring enough after launch to keep shaping it around how people react- THAT IS THE HARD PART. And in fact, it is still on-going.

That stays stubbornly human. It’s judgment, taste, and patience- the thing you spent years getting.

So my CTO was right.

5 tips if you want to make your org more AI-first

1. Believe in your top adopters. I got to walk into a new department, learn it, and run this project end to end. Find the people most eager to adopt, back them, and get them working together- I learned something every day from colleagues in both R&D and marketing.

2. Start with the people- they’re the spec. I didn’t start with the platform. I started with the people who’d actually use this, watched their real day, and let the spec come from them. They’re the experts; the tools only matter in service of them.

3. Learn AI with AI. Half the time I didn’t know what was possible- so instead of marching a rigid spec into a wall, I just asked. “Can we do this?” “What about this pattern?” The clear plan is the output of exploring, not the input- so explore, and let the work reveal itself.

4. The ground keeps moving- make peace with it. The tools change weekly. Something I wrote from scratch one week shipped as a native integration the next. So I stopped gold-plating and reached for the lowest-effort thing that worked today, because the platform was usually about to catch up.

5. The work doesn’t end when you ship. Launch is the start, not the finish. It’s a living system: you watch how people react, keep shaping it around their day, and earn trust in the small, unglamorous details. A tool only keeps saving time if you keep tending it. Part 2 if anyone's curious?