Moving Fast Without Breaking Things: A Conversation with Traction's CTO

What does the CTO role actually look like right now, with everything moving as fast as it is?

There's a lot to keep up with, honestly. A good part of the job is learning fast enough to make sense of it all: every new acronym, every new platform, every new system, and how they all integrate. Then I translate that into something digestible for the rest of the team. I don't necessarily need to know how to do every implementation myself, but I need to know who does. That's why picking the right partners and the right platforms matters so much now.

How has the job actually changed with AI — versus just being more of what it's always been?

A lot of it is tooling, and tooling has expanded exponentially. I was talking with a colleague recently about how we used to build almost everything ourselves. You'd spin up a single server, and everything lived on that one box. A few apps installed, and you were up and running. Then, well before AI came along, the industry moved toward specialized SaaS platforms. Why reinvent the wheel, right? That made sense, because you get outside support on those pieces. So the job shifted from building things yourself to building the bridges that connect all those platforms. Today one end product can easily have twenty different solutions behind it, and you're the one responsible for holding it all together.

With AI, we could be shifting back toward building more ourselves, because we can build so fast now. Some of those twenty solutions might consolidate into tools we own. Not back to our own servers. The cloud isn't going anywhere. But we'd own more of what runs on it. As much as the speed of all this worries me sometimes, it's also what excites me most. We can work on several parts of a project at once, get a plain-language walkthrough of code we've inherited, and move through research, testing, dependency upgrades, and log analysis faster than ever. It's fun. There's a lot of room to get creative right now.

Where do security and risk fit into all of that?

So much of what I do comes down to weighing risk versus reward, and right now the biggest risk is all the connectors and platforms people want to plug in. Every one of them is another place data can end up, whether that's secrets, personal information, or client work under NDA. And not every platform's terms protect that data the way we need them to. There's also the chance someone connects a personal AI account to the company workspace, where none of the protections in our company agreements would apply. So the contract is part of the security now, not just the technology, and it's why the team has company AI accounts that our policies direct them to use. My approach is layered: policies that put the rules on paper, training and constant reminders so people actually understand them, and technical controls behind that. We block unapproved apps, limit access by role, require multi-factor authentication everywhere it's offered, and run automated monitoring and logging. I keep things as tight as I can without getting in the way of anyone's work.

When someone on the team wants to bring in a new tool, how do you decide whether it gets the green light?

When someone wants a new tool, I make sure we don't already have something that does the job, then dig into its security, encryption, and user controls. And I don't just take the vendor's word for it, I look at reviews and what others are saying about them. Wherever there's an option to keep our data out of AI training, I take it. Clients sometimes have their own requirements too; we've gone through security reviews with several of them, and I've set certain teams up on different platforms to meet those needs. Once something checks the boxes, I move as fast as I can to get people what they need.

Has AI changed how much you trust the output you're working with?

Yes, I have a little less trust in the raw output now, just because so much of it is generated rather than written or built by hand. The industry is all about instant gratification right now, and I understand why. But a result still has to be accurate and actually be what we wanted in the first place. So trust has to be earned through verification. On the dev side, we've always done that through test-driven development, and this is a new layer of the same idea: AI agents check the work at the planning and build stages, automated tests run on every project, and a person reviews every merge into our dev and production branches. The same goes for any process we automate for the rest of the company. We always put a human in the loop. Those checks catch things all the time, like an AI tool overthinking a problem, misreading the requirements, or heading in the wrong direction. Nothing dramatic, and that's the point: we catch it while it's small. None of it is infallible, though. The question I keep coming back to is: what are we going to miss if we push this out too fast?

How do you balance that caution against the pressure to just move?

Traction's got a long history, and part of that history is holding a high standard for the quality of what we put out. I don't think that should ever change. Yes, we need to move fast. Marketing has always run on speed, and AI has made a real difference in how quickly we can deliver. But quality can't be the thing that suffers so we can get there faster. That's why we build the checks into the work itself. They're what let us move fast without cutting corners. If the output isn't doing the right thing, it's wrong, no matter how quickly you got there.

Some people on the team have called you the QA of Traction. Is that fair?

I'll take it, but it's a bigger job than that. If I'm doing it well, nobody thinks about it. The real job is choosing the right systems, integrating them, maintaining them, and putting the processes around them that the whole team runs on. That's what keeps Traction running and performing properly. QA catches what went wrong. I'm trying to build things so less goes wrong to begin with.

With so many new tools and platforms, is there even a shared vocabulary yet for talking about this stuff?

Not really, no. A lot of terms mean something slightly different depending on who's using them; the language hasn't solidified yet. So we've had to get a little more careful about not assuming everyone means the same thing when a term comes up. You slow down, you ask what someone means by it. Which, funny enough, brings us right back to verification.

If you had one phrase for how you approach this whole moment, what would it be?

Trust but verify. It's an old line, and verifying has always been part of the job. What's changed with AI is how trust gets earned: in smaller pieces, checked more often, all the way through.