Most of the time, it's both. AI is reshaping how teams build, but the constraint is usually somewhere else in the system — an architectural decision that hasn't been made, an unowned ownership boundary, a vendor relationship that won't carry the new pace, or a review process designed for slower work. The first conversation is about reading the system, not selling a transformation. If the right answer turns out to be "you don't need a fractional CTO, you need three months of focused engineering management," I'll say that. Diagnosis is the work.

A written-down map of where humans review, where agents act, and where the rules get re-examined when reality shifts. It names the high-judgment decisions a person still owns, the lower-judgment work the team is comfortable letting an agent do, and the gray-zone work that needs structured review before it ships. It is not a deck. It is a document the team uses, updates, and argues with. When the next model release changes what's possible, the operating model is what tells you whether to update the boundary or hold the line. Without one, every team member ends up writing their own version in their head, and the team can't move together.

By scaling judgment alongside throughput. AI lets a small team move like a bigger one — but only if the team's review discipline, ownership, and shared mental model can carry the new speed. The work usually involves three things: (1) clarifying which decisions need a human and which don't, with that clarity written down so it survives turnover, (2) building review surfaces that match the new throughput rather than choking on it, and (3) protecting the team's capacity to think, because the bottleneck shifts from typing speed to judgment quality. A team that can't think can't ship trustworthy work at any speed.

The ones AI speed makes louder, not quieter. Cost — because higher throughput compounds spend in places nobody was watching. Security — because more code paths and more agent actions widen the surface. Vendor lock-in — because the runtime dependency on a model provider is now a real architectural choice, not an abstraction. Code health — because AI-generated code reviewed casually accumulates a different kind of debt than human-written code. The job is naming these trade-offs early, with owners attached, so they don't surface as crises six months in.

It depends on what's stuck. The simplest version is a one-to-three-week assessment: I read the system, name the constraint, and write a roadmap with owners and sequencing. From there, engagements range from advisory (a recurring rhythm with the leadership team) to embedded (acting as the fractional CTO two or three days a week, leading the work directly). Most engagements include at least one reusable artifact — an operating model, an architecture decision record, a review process — that the team keeps using after I'm gone. Scope and pricing are agreed up front. No retainers that drift.

Yes. Most engagements involve working with an existing CTO, VP Engineering, or technical co-founder. The job is usually to bring outside range, surface what's hard to see from inside, and accelerate decisions that have stalled. I don't do staff augmentation — meaning, I won't be a second pair of engineering hands. I will absolutely partner with whoever is already accountable for the team, and the work usually ends with that person better-positioned, not displaced.

Burlington, Vermont. Most engagements are remote. I travel for kickoffs, key milestones, and workshops when it matters. Time zones from the US East Coast through Western Europe work cleanly; further east or west, we structure overlap windows up front.