CTO Nick Kraft on Leading at Scale in the Age of AI

Modern CTO leadership is no longer defined by technical brilliance alone. Today’s CTO operates at the intersection of architecture, culture, risk management, product velocity, and AI reliability – all while scaling teams without becoming the bottleneck. The role demands a shift from writing most of the code to designing systems of execution, trust, and accountability. In high-growth AI environments, the challenge isn’t just building innovative features, but ensuring they are resilient, secure, and meaningful at scale.

In this interview, Nick Kraft, CTO of Fathom, offers a grounded blueprint for navigating that transition. He explains how technical leadership evolves as companies move from early product development to operational maturity – and how leading at scale requires prioritizing trust, pragmatism, and risk clarity over control.

Cutting through AI hype, Kraft focuses on what it truly takes to build AI-powered systems that customers can rely on, while preserving culture, autonomy, and engineering standards as the organization grows.

The evolution from builder to CTO

You joined Fathom as a founding engineer and recently stepped into the CTO role. What fundamentally changed in how you spend your time – and how you think about impact?

Kraft: It’s been much more of a progression than a sudden shift. Day one as a founding engineer was all about shipping code and doing all of the technical work. As the organization started to grow, and our CEO Rich could no longer manage every single team, there was a path for me to step into the role of the primary point of contact for the engineers.

While I still ship code and do code reviews as CTO, the role is really about making work happen by eliminating barriers for my team. I absorb as much of the administrative and non-technical work as possible so they can focus. That includes everything from the fun stuff, like getting colleagues to interact across departments, to security compliance and SOC 2 audits. My goal is to give engineers the same kind of experience I had early on, where they can zero in on their craft without worrying about the overhead that comes with a growing organization. This requires strong relationships across the org and high trust within ENG, so I can serve as the first line of defense while everyone else stays focused on their own roles. Trust and focus are crucial components of the company’s success.

As a CTO stepping into ownership of systems you originally built, how do you avoid becoming the bottleneck – or the default ‘chief firefighter’?

Kraft: A big part of my role is maintaining the global view of what we’re doing. I don’t have perfect detail in every area, but I have both the luxury and the burden of seeing where things are set up to succeed – or where they might fail.

We’re managing a large risk portfolio; running a lean organization means making decisions about what to prioritize in terms of focus. So every decision involves taking on some sort of risk, like a feature not being compelling enough to drive adoption, or a feature being delivered in a form that won’t scale to future usage levels. I could have my engineers working on nothing but mitigating risks that may never be realized. It’s about being judicious, taking that global context, and focusing on what matters today rather than becoming scared of our own shadow. We don’t want to take productivity away from pushing the product forward because we anticipate something might “break.”

Our engineers work closely with the product team to realize their vision. We make sure we have a mutual understanding of what’s possible and on what timescales. If something is non-negotiable on timing, we need to be positioned to make it happen.

What was the most difficult technical decision to let go of, as you transitioned from hands-on system builder to an organizational leader?

Kraft: Nothing is sacred just because I did it or because a particular person did it. The nice thing about growth is you hope to bring in people who can do the job even better than you can. My goal is to provide them with the context behind past decisions so the team can make their own assessments, given what we know from historical knowledge. I want them to understand the decision, the risks we saw at the time, and whether those risks have changed -and then let them make their own technical judgments.

You hire people because you trust them, and once they’re on the team, it’s important to put that trust to work. That trust goes both ways. You need people who are not only willing to say “Hey, I have an idea that I think may work better” but also, “You’re right, maybe that’s not the direction we want to go today.”

Looking back, what prepared you least for the CTO role – and what ended up mattering most?

Kraft: The CTO role draws heavily on my earlier experience as a program manager and lab director, but I wouldn’t be effective in this role without having been an individual contributor. Being close to the work and hands-on in building these systems provided important context that shapes my day-to-day.

Also, being a professor definitely helped prepare me for this role. During that time, I had to recruit and fund graduate students. You become responsible for their livelihood in a lot of ways -covering tuition, salary, and allowing them to go down this path. That environment forces you to build deep mutual trust. I see the same dynamic when I coach my youngest son’s soccer team. If I can look a player in the eye and tell him I believe in him and that he can do this, he trusts what I’m saying and will go for it. Now soccer is very different from engineering, but at the core, communicating that trust is everything. It allows me and my engineers to achieve really cool outcomes together.

Preserving culture, rigor, and velocity while leading at scale

How do you preserve engineering taste and technical rigour when you’re no longer writing the majority of the code?

Kraft: When you’re building something, you establish patterns. Some are adopted because they’re the best at the time, and some because you just need to pick one and move forward. Over time, all the patterns we’ve established have become the backbone of how we do things here. It’s not unchangeable, but it is the default and the de facto. We exclusively hire senior engineers who can come in, see how we’re doing things, and use their experience to adapt and understand why we’ve chosen to do it that way. Then we decide together whether to continue in that direction.

It also comes down to buy-in during the hiring process and looking at whether someone can be happy working the way that we work here as a team. We are process-light and meeting-light, but we have core principles we believe in. Once there’s trust, as the team grows, nothing is sacred, and we adapt together.

What changes in leadership approach when your teams are scaling faster than your ability to personally mentor every engineer?

Kraft: When I first started hiring, I was able to pay a lot of personal attention to the team. I had more time to help drive patterns and processes and organizational beliefs, and really interact with them and build close relationships. I still have great working relationships with everyone on the team, but I’m not able to get as in the weeds as I used to with every new hire.

We don’t have a middle management layer yet in the company, but there are cultural touchstones and team members who help set the tone and pass along how we work to new hires. Not everything ends up being exactly what I may have described or prescribed back when we were just starting, and that’s fine. This organization is a living thing, and as people make their own adjustments and adaptations, the organization gets better because of it. That said, my approach to leadership hasn’t changed. While I’m not able to spend as much time one-on-one with everyone in the org, I try to remain as pragmatic and approachable as I was when we were just getting started. I’ve heard myself described as “salty” -in a fun way, not a grumpy one! The goal is to just be myself and to make everyone feel seen and heard.

How do you identify when an engineering process is helping versus quietly slowing innovation?

Kraft: Rather than coming in with a set way of doing things, our processes have always developed organically. Obviously, in high-risk situations, we work to quickly mitigate issues (security and compliance, for example). But in lower-risk areas, we solve real problems as they present themselves. You put forth your best effort based on industry standards and what you’ve seen work well in the past, then you iterate. The goal isn’t perfection. It’s to be more efficient and effective at your job each day.

How do we know a process isn’t working? Engineers are not bashful, and they’ll certainly let us know. One nice thing about shifting toward this oversight role isthat I have the luxury of looking for these signals versus having it always be the responsibility of an engineer to speak up about an issue.

Building reliable AI systems at scale

In AI products, user trust often matters more than raw accuracy. How do you design systems that feel reliable even when the AI is probabilistic?

Kraft: We have an AI engineering team that sits within the product side of the organization. They can have upwards of a 50% failure rate. And we celebrate that, because that means we’re pushing the boundaries. When things get to my team, our role is to realize their vision at scale and make sure it functions for customers. Trust and reliability decisions fall to that AI organization, but that doesn’t mean we don’t have a front-row seat. We build things that go through an internal release process, and the tech never goes straight from AI to customers. We’re able to see where the rough edges and potential pitfalls are before they use the technology. If any unexpected behaviors come up in the wild, we know how to monitor and react.

What’s the biggest mistake teams make when they treat AI as ‘just another feature’ rather than a core system?

Kraft: In the early days of AI use, AI features were more experimental -you give it an input, get an output, and then you move on. These days, there are a ton of complex pipelines involving different models and providers within the same feature. Just as with any product feature, scaling AI and keeping it reliable requires significant engineering effort.

In my mind, the worst case for an AI feature isn’t bad output, it’s no output. To expect something magical and nothing comes up. With so many companies leaning into AI, getting the models you need and having them behave reliably isn’t something you can assume will just happen. Our number one concern beyond whether this is meaningful for customers is how we keep it reliable as scale increases every single day.

How do you think about human-in-the-loop design in a product that’s supposed to save time, not create more oversight work?

Kraft: I trust the AI team and the product team to own human-in-the-loop design. From the engineering side, where I tend to get more involved is once things are actually running at real production scale because that’s where many of the issues show up.

If I’m a user interacting with something within our tech like our “Ask Fathom” feature, it’s always harder to simulate those conditions ahead of time. You can do a lot of testing and validation in development, but latency and reliability concerns often only surface once actual customers are using the product at scale, in real ways. An underwhelming answer isn’t great, but a great answer doesn’t matter much if the user gets frustrated and leaves before we show it to them. Engineering helps identify where things fall down under load. We make sure product and AI teams have visibility, then decide whether it’s a system design issue or a scaling concern.

As AI platforms mature, where do you think real differentiation will come from over the next two to three years?

Kraft: I think the differentiation will come from actually solving real problems with AI versus using AI just because you can. What we’re doing with meeting summarization and action item detection here at Fathom is solving real business problems. You couldn’t turn meetings into data without AI.

We’re moving beyond AI for AI’s sake to real problems where AI is truly the best option and provides meaningful value. Not just because it’s deemed cool, but because it actually helps people reduce burdens and makes lives easier.

Security, Risk & Compliance as First-Class Engineering Priorities

You’ve overseen security and compliance alongside rapid growth. At what stage should startups treat security as a first-class engineering problem, not a checklist?

Kraft: We knew from day one that we were dealing with sensitive data, so we went straight to a security program and a SOC 2 audit very early on. In the B2B technology world, security and trust are table stakes. Without them, there’s no adoption. As a startup, you really can’t come back from a major security and compliance breach.

At what stage a company should take this seriously depends on the product domain and the data they’re dealing with but for us, it was obvious to start at the beginning. If you’re trusted with sensitive company data, you have to take security seriously.

What’s one security or compliance lesson you learned the hard way that you wish more CTOs understood earlier?

Kraft: It’s always hard to retrofit security and compliance after the fact. Building those core principles and systems upfront can slow things down early, but the tradeoff is worth it because the risk is too massive without them.

The other thing is being clear about what’s non-negotiable. There may be times you want to bend a rule for a specific scenario if it’s the easier route. If the company knows upfront what’s off-limits, you can move straight to finding a solution that works within those boundaries.

Innovation across environments

Having seen academia, corporate research, and startups, what does each environment get wrong about how innovation actually happens?

Kraft: At a startup, you’re less bound by institutional overhead and inertia. In academia, especially a field like computer science, work is largely driven by government funding, which moves slowly and can make it difficult to get too far ahead of established priorities. Corporate research has similar constraints that are shaped by existing products and longstanding realities.

Startups aren’t free from those constraints, but the structure tends to be more flexible, and we’ve embraced it. In fast-moving markets, being nimble isn’t optional at a startup; it’s a requirement. You have to deliberately build for it.

Future outlook

What advice would you give future tech leaders?

Kraft: I don’t give much advice because I’m just in Raleigh quietly working with my team…but as I’ve mentioned a few times, I do believe strongly in staying authentic and genuine no matter what your role. And trust: building it, maintaining it, communicating it. Everything falls from there, especially in a startup where it’s intense and you’re in close quarters every day. Having interesting work to do isn’t enough.

We have a strong cultural identity in our engineering team. Staying true to it makes recruiting harder because we’re not just looking for great engineers, but great engineers who match our values – something we’re not willing to sacrifice on. It makes the hunt for talent harder, but when we find people who fit, the returns are far greater. It makes our jobs far more successful if everyone’s bought in and looking in the same direction.

Key takeaway

Successful CTOs don’t scale by tightening their grip – they scale by deliberately distributing ownership. Lasting impact comes from empowering strong teams, leading with authenticity, and delivering products – customers can trust every day.

As organizations grow more complex, clarity becomes more valuable than control, and context becomes more powerful than command. The CTO’s role, ultimately, is to create an environment where innovation can flourish without compromising on discipline. When trust, accountability, and technical rigor move in the same direction, scale stops being chaotic and starts becoming sustainable.