The CTO Podcast · Insights & Strategies for Chief Technology Officers Navigating the C-Suite while Balancing Technical Strategy, Team Management, & Innovation

The Software Factory: Why Document-Driven Development Is Reshaping How CTOs Build

·1 hr 3 min·3 clips

“We’re creating a software factory. This is not software development.”

The discussion opens with AI-assisted coding and its impact on the SDLC, including what it means for CTO roles, software design, incremental improvement, technical debt, and refactoring. It also broadens into how teams negotiate with partners and set expectations with software vendors. In that context, the speakers describe auditioning large partners by asking a simple question: how are you writing software? If they cannot clearly describe a document-driven process, they quickly fall down the list. A central thread is document-driven development. The conversation frames it as a practical way to organize work by domain, context, and use case. Major domains get broken into documents, and each document is tied to questions like what problem is being solved, what the narrative is, and what the exit criteria are. That structure then becomes the basis for the product requirements. From there, the workflow is presented in a strict order. A requirements document comes first, typically hand-authored. The PRD is generated next. Then the team works through the technical design in iterative cloud code sessions, with questions, answers, and approvals from senior team members. Only after those steps does the team move into code. The point is to push uncertainty upstream so the coding stage is the last and smallest step. The goal, as the speakers put it, is to get as close to one-shotting the code as possible. If the code does not land on the first pass, the team can ask whether the model is struggling with the problem or whether something upstream, in the requirements or patterns, needs to be improved. That framing keeps the conversation focused on diagnosis instead of endless retries. There is also a broader leadership angle underneath the process talk. The episode treats AI as something that affects not only coding speed but also how senior teams think about planning, approvals, and expectations. In that sense, the work of a CTO is not just architecture, but also organizing the documents and decisions that make the code path cleaner. The conversation briefly links this to mob programming and conversational coding, where the typing itself is downstream of the discussion. It closes by crediting Ryan Weiss and his work, which the speakers describe as influential and worth following for people thinking along these lines.

As heard by us

A practical look at how AI is pushing CTOs to move planning upstream.

It argues that AI-assisted coding is changing how SDLCs are judged, especially for CTOs thinking about software design, steady improvement, technical debt, and refactoring.

Read the full review in PlayNext →

Why you'd press play

For CTOs rethinking how code starts before anyone types.

Read the full recommendation in PlayNext →

Listen to the show on

Apple Podcasts Spotify

Play clips from this episode More from The CTO Podcast