The CTO Podcast

“We’re not doing software development anymore. We’re engineering a factory.”That single line from Matt Ferguson captures a fundamental shift happening in technology leadership. As CTO of Roof Maxx—a nationwide roofing brand with 385 dealerships—Ferguson has spent the past year transforming how his team builds software. The methodology he’s championing isn’t new, but its implications in the age of AI are profound.It’s called Document-Driven Development. And if you’re still measuring your engineering team by lines of code, you may be optimizing for the wrong century.The Cost of Software Is CollapsingFerguson opens with a provocative claim: “The cost of software goes to zero.”He’s quick to acknowledge this is a euphemism—a deliberate exaggeration meant to spark conversation. But the directional truth is harder to dispute. When a team that once needed 100 engineers can now accomplish the same work with 10, or when the same team can produce 10x the output, the economics of software fundamentally change.“If they’re not taking into consideration the risk of their business when the cost of software goes to zero,” Ferguson says of potential vendor partners, “then they’re not gonna be a partner in two years because they’re gonna be out of business.”The data on AI-assisted coding tells a more nuanced story. A recent randomized controlled trial from METR found that experienced developers were actually 19% slower when using AI tools—despite believing they were 20% faster. Meanwhile, studies from GitHub and Microsoft show gains of 20-55%, with the strongest improvements among junior developers tackling well-defined tasks.The takeaway isn’t that AI doesn’t help. It’s that how you use it matters enormously. And that’s where Document-Driven Development enters the picture.What Is Document-Driven Development?At its core, Document-Driven Development flips the traditional software process. Instead of diving into code and documenting later (or never), teams invest heavily upfront in requirements, specifications, and architectural documentation—then use AI to generate code from those artifacts.“Our document-driven development is the concept of writing down what you want to do, what your problem is that you want to solve, in a descriptive enough way that the AI can interpret and plan the work, and through that plan can execute the code,” Ferguson explains.The approach has been championed by Ryan Vice, CEO of Vice Software, through his DocDD.ai methodology. GitHub recently validated the concept with their “Spec-Driven Development” toolkit, and AWS published their “AI-Driven Development Lifecycle” framework—both emphasizing documentation as the critical input to AI-assisted coding.Ferguson’s team has taken this further than most. His developers now spend roughly 90% of their time writing and refining requirements, and only 10% reviewing code.“Documents are your new code,” he says. “Treat them like code, put them in your GitHub repository as code, and iterate on them as your source code.”The Goal: One-Shot Code GenerationThe ambition behind Document-Driven Development is what Ferguson calls “one-shotting” the code—generating production-ready software on the first attempt.“We’re not here to pull the old slot machine and see what we get,” he explains. “Oh, all jacks. That’s wonderful. Oh, we didn’t win that one. Try again. Until AI gives us the right answer. That’s not what we’re after.”This stands in stark contrast to “vibe coding”—the practice of giving AI a rough prompt and iteratively debugging whatever emerges. Ferguson sees this as a recipe for unreproducible results and mounting technical debt.“If you’re not putting time into governance and you’re giving everybody free reign to do whatever they want,” he warns, “you’re gonna get different results. And when you try to build that piece of software six months from now, you might get a different result—which is not acceptable.”The key insight is that the “one shot” doesn’t mean one interaction with AI. It means extensive iteration on the documents—using AI to stress-test requirements, identify edge cases, and refine specifications—before any code is written.“We probably did a lot of interactions with AI, conversations with a highly intelligent, highly well-reasoning system,” Ferguson clarifies. “Just so that we’re getting to that point where we think a one shot is possible.”Systems Thinking: The Intellectual FoundationUnderneath Ferguson’s methodology lies a deeper framework: systems thinking, particularly as articulated by Donella Meadows in her seminal work “Thinking in Systems: A Primer.”Meadows identified 12 leverage points for intervening in complex systems, ranked from least to most powerful. At the bottom are parameters and numbers—the metrics most organizations obsess over. At the top are paradigm shifts—fundamental changes in how we think about a problem.“I tell people, the first thing you should do is read the last chapter about the 12 leverage points,” Ferguson says. “Understand that your leverage point needs to start around the middle—the six or the seven—where we’re changing paradigms, where we’re actually changing how these systems impact each other.”This systems lens explains why Ferguson believes SDLC transformation is more valuable than any individual technology choice.“When I come into a company, I’m constantly thinking about the systems I’m observing,” he says. “That’s where I find I can have the greatest impact. I want to operate to make sure we’re making the right operational decisions and process decisions.”The Factory MetaphorPerhaps Ferguson’s most useful reframe is viewing software development as factory engineering rather than craft production.“We’re creating a software factory. The engine in our factory is AI. You have inputs to the system. You have feedback loops to the inputs. You can either impact the feedback loops and get reoccurring results that are virtuous, or you can just fix the toys at the end of the line and never fix the feedback loop.”In this model, software engineers become process engineers. Their job isn’t primarily to write code—it’s to design, optimize, and govern the system that produces code.“Software engineers are the process engineers of a factory,” Ferguson says. “I understand how this factory works. I understand the inputs. I understand the outputs. I understand how I can impact the inputs. If you’re gonna build a factory, you better have a systems thinking approach.”This has significant implications for hiring and team development. Ferguson is actively retraining his developers to think more like product managers—to write excellent requirements, to understand stakeholder needs, to communicate abstractions clearly.“Writing software’s not the hard part anymore,” he observes. “The value is writing great requirements, great user stories, the use cases, and making sure you’re writing those initial documents correctly.”Implications for SaaS SelectionFerguson applies the same thinking to vendor relationships. His first question to potential partners: “How are you writing software?”“If they’re not using document-driven development and can’t describe that process, they go pretty far down the list,” he says.His reasoning is economic. As AI capabilities accelerate, vendors with undisciplined development processes will struggle to compete against AI-native startups with fraction-sized teams and radically lower cost structures.“A startup is gonna run circles around you,” Ferguson warns established players. “And all it is, is marketing at that point. And it’s a price point.”The implication for CTOs evaluating SaaS purchases: due diligence on a vendor’s development methodology may be as important as feature comparisons. Partners who can’t articulate how they’re adapting to AI-assisted development may face existential pressure in the coming years.Beyond Software: Enterprise-Wide AIFerguson is careful to note that Document-Driven Development is only part of a broader transformation. For CTOs, the mandate extends across the entire organization.“You can’t just be improving the software side of the shop,” he says. “What are you doing about ordering and marketing and all these other processes?”His framework for enterprise AI adoption centers on business process mapping—identifying where humans currently insert themselves to make processes work, then asking whether those decision points could be automated.“Where’s the human inserting themselves to make this process work? Why does that need grease from a human all the time? Do we have the right inputs that an AI could make the same decision?”The metric Ferguson uses to evaluate progress: how many agents is each team member managing?“The measurement of the people in your company needs to be, how many agents am I managing? I shouldn’t be doing work. I should be managing my agents that are doing my work for me.”Getting Started: A Practical PathFor CTOs looking to adopt these approaches, Ferguson offers a straightforward sequence:First, solve the product-requirements interface. Wherever product specifications are authored in your organization, that’s your entry point. Ensure requirements are structured for AI consumption, with clear acceptance criteria and well-defined boundaries.Second, prototype and enforce a process. Document-driven development only works if it’s actually used. Model the approach yourself, build governance around it, and resist the temptation to let individual developers freelance.“Everybody can’t be doing their own thing,” Ferguson emphasizes. “We’re not building ET’s software factory and Matt’s software factory and John’s software factory. We’re building a software factory. Everybody’s following the same process.”Third, extend the thinking beyond engineering. Look for high-value business processes where AI agents could replace human decision-making. Invest in frameworks that allow non-programmers to build and manage their own agents.The Energy QuestionWhen pushed to imagine the far future—a world where AI can generate any software on demand—Ferguson lands on an unexpected constraint: energy.“The answer to the question is the cost of energy,” he says. “If I wrote the same thing in assembly language, it would be far less energy intensive than writing in Java. The same thing is moving up the stack all the way to AI—worst case scenario, I’m burning more electricity to do the same thing.”In a world of abundant, cheap energy—fusion power, orbital data centers—Ferguson sees no reason to maintain software at all. Everything becomes real-time interpretation. But until that day: “The economics will answer that question for us.”The Bottom LineDocument-Driven Development isn’t magic. It won’t transform every team overnight, and the research suggests productivity gains are real but more modest than the hype implies—typically 20-30% improvement, not 10x.But Ferguson’s underlying insight is sound: in an age of AI-assisted coding, the bottleneck shifts from implementation to specification. The teams that invest in better inputs—clearer requirements, stronger governance, reproducible processes—will capture more value from AI than those who simply give developers access to Copilot and hope for the best.“If the cost of software goes to zero, you got no more excuses,” Ferguson says. “Domain-driven design, test-driven development, service-oriented architectures—these are the patterns we should be based on. Anything else has always been cutting corners.”The corners are getting harder to cut.Matt Ferguson is CTO of Roof Maxx, the nation’s leading provider of sustainable roof restoration solutions. Prior to Roof Maxx, he served as Director of Data Engineering, AI, and Machine Learning at Simple Technology Solutions and was CTO of Galley Solutions.For more on Document-Driven Development, visit DocDD.ai or explore Ryan Vice’s YouTube channel.Donella Meadows’ “Thinking in Systems: A Primer” is available wherever books are sold.Key Takeaways:* Document-Driven Development inverts traditional software processes—invest 90% of effort in requirements, 10% in code review* The “one-shot” goal means extensive AI-assisted iteration on documents, not a single prompt-to-production attempt* Systems thinking provides the intellectual framework—focus on leverage points 6-7 (paradigms and feedback loops), not just parameters* Software engineering is becoming process engineering—the factory metaphor reframes what CTOs should optimize* Vendor due diligence should include questions about AI-assisted development methodology* Enterprise-wide AI extends beyond engineering—map business processes to identify automation opportunities This is a public episode. If you would like to discuss this with other subscribers or get access to bonus episodes, visit www.ctopod.com

In this conversation, Nishant interviews Kathy Keating, Etienne de Bruin, and Scott Graves, co-authors of LIQUID: How CEOs and CTOs Unlock Flow and Momentum in Complex Systems. They discuss how the idea for the book was born, the challenges of co-authoring as three CTOs, and how they shaped the narrative through the fictional characters Alice (CEO) and Theo (CTO). The authors share how their distinct voices and strengths fused together: Scott’s deep knowledge of complex adaptive systems, Kathy’s operational lens, and Etienne’s ability to simplify and communicate concepts. Together, they created a framework that blends philosophy, practice, and story.The conversation highlights the importance of seeing organizations as complex adaptive systems and the risks of companies becoming either “boiling” (chaotic) or “frozen” (rigid). The authors emphasize that true leadership comes from navigating toward liquidity, the state where flow and adaptability are preserved. They reflect on the critical role of CEO-CTO partnership, the necessity of boundaries, and the difficulty of shifting culture once it stagnates. They also explore why the timing of LIQUID is especially relevant today. As technology accelerates, craft alone is not enough. Leaders must become sense-makers and problem-solvers at the systems level.About the BookLIQUID takes readers inside the hidden systems that drive every organization. Using the fictional journey of Alice, a founder-CEO, and Theo, her engineer-turned-CTO, the book shows how teams often slide into boiling chaos or frozen rigidity without realizing it. By illustrating the patterns of complexity through story, the authors make abstract concepts tangible and immediately useful.At its core, LIQUID argues that the most important role of the CTO is not simply delivering technology but stewarding the entire system so that people and processes remain in flow. The book introduces accessible frameworks, practical language, and vivid scenarios that help leaders spot when their organizations are shifting out of balance and how to guide them back to a liquid state.Whether you are a CEO, CTO, or executive navigating rapid change, LIQUID is a blueprint for unlocking resilience, adaptability, and momentum in your company. It bridges systems thinking with real-world leadership and equips you to see and influence the invisible dynamics that make or break technology organizations.Time Stamps00:00: Introduction: Why LIQUID matters now02:00: Behind the authors: creativity, systems, and personal lenses07:00: Discovering each other’s strengths during the writing process13:00: Pivoting the book: from frameworks to storytelling17:00: The origin story: from CTO failures to systemic insights23:00: Defining the role of the CTO in complex systems28:00: Why now: AI, accelerated change, and systems thinking33:00: The 7CTOs connection and levels of complexity40:00: Why Alice and Theo: storytelling as a teaching tool46:00: Subjective perspectives in complex systems52:00: The hidden world of complexity and CTO boundaries59:00: CEOs and CTOs as co-sensemakers1:04:00: Simple versus complex language in leadership communication1:12:00: Culture as the hardest complexity to shift1:20:00: Coaching example: boiling versus frozen organizations1:28:00: The CEO’s challenge: orchestrating boundaries1:31:00: Partnership, empathy, and trust at the executive level1:33:00: If LIQUID had a soundtrackLIQUID: LinkedIn / WebsiteContact Nishant: LinkedInContact Etienne: Website / YouTube / LinkedIn / X / Instagram / The CTO Podcast WebsiteContact Kathy: Website /LinkedInContact Scott: Website / LinkedIn This is a public episode. If you would like to discuss this with other subscribers or get access to bonus episodes, visit www.ctopod.com

RSVP to the 13th CTO Colloquium on 4/17/25In this episode, Steven Zgaljic, CTO of Jahnel Group, joins host Etienne de Bruin to share a personal story about his daughter’s health challenges. Faced with the need to meticulously track symptoms and daily activities, Steven leveraged his technical expertise to create a custom AI-powered solution using tools like N8N and Superbase. The conversation highlights how AI can transform complex problems into actionable insights, even in personal contexts.Steven discusses the challenges of using traditional methods like pen and paper for symptom tracking, leading him to build an automated workflow integrated with Slack. By applying AI for data validation and pattern recognition, he gains real-time insights into potential triggers and patterns in his daughter's symptoms. Beyond his personal use case, Steven reflects on the broader applications of AI in problem-solving and the necessity of human oversight in AI-driven systems.This conversation explores the intersection of personal challenges, technological innovation, and the potential of AI to improve lives.Timestamps00:00 Introduction and Overview 01:00 Steven Zgaljic's Background and Family Story 03:00 Challenges with Tracking Medical Symptoms for His Daughter 05:00 Using Slack for Family Communication 07:00 Applying AI to Track and Analyze Symptoms 09:00 Exploring N8N, Superbase, and AI for Automation 11:00 Creating Validation Models for AI Accuracy 13:00 Building a Custom AI System for Health Tracking 15:00 AI Insights and Pattern Recognition in Health Data 17:00 Future Plans for AI Health Analysis 18:00 Reflections on AI in Problem SolvingWe have 200+ CTOs in peer groups: Quick Testimonials VideoContact Etienne: Website / YouTube / LinkedIn / X / Instagram / The CTO Podcast WebsiteContact Steven: Website /LinkedInGreat news! The CTO Podcast has been featured on Feedspot's list of Top CTO Podcasts. Huge thanks to our amazing guests and listeners for being part of these conversations. Check out the full list here: Feedspot’s Top CTO Podcasts. This is a public episode. If you would like to discuss this with other subscribers or get access to bonus episodes, visit www.ctopod.com

In this episode of the CTO Podcast, host Etienne speaks with image strategist Zayna Rose about the importance of personal branding and leadership presence for technology leaders. They discuss how visual identity, color psychology, and intentional self-expression can enhance a leader's credibility and connection with others. Zayna emphasizes the need for tech leaders to be mindful of their appearance and how it impacts their professional image, while also encouraging them to embrace their authentic selves. The conversation highlights practical tips for improving one's image and the significance of digital presence in today's world.Time Stamps00:00 Introduction to the CTO Podcast and Guest Zaina Rose03:06 Understanding Leadership Presence05:29 The Importance of Visual Identity09:55 Casual Power Looks for Tech Leaders12:18 Strategic Wardrobe Levels16:30 Choosing Colors That Work for You21:17 Tailored vs. Standard Looks23:38 Experimenting with Self-Expression30:14 Leveraging Digital Assets for First Impressions34:33 Practical Steps for Improving Personal Branding38:42 Enhancing Stage Presence and Communication42:45 Closing Thoughts and Call to ActionWe have 200+ CTOs in peer groups: Quick Testimonials VideoContact Etienne: Website / YouTube / LinkedIn / X / Instagram / The CTO Podcast WebsiteContact Zayna: Website /LinkedIn This is a public episode. If you would like to discuss this with other subscribers or get access to bonus episodes, visit www.ctopod.com

In this episode of the CTO Podcast, host Etienne de Bruin speaks with Lena Skliarova-Mordvinova, CTO and Co-Founder of the Good Face Project. They discuss the origins of the Good Face Project, which aims to educate consumers about the ingredients in personal care products and promote safer alternatives. The conversation delves into the role of generative AI in analyzing ingredient safety, the challenges of navigating the venture capital landscape, and the importance of parenting in the digital age. Lena shares her insights on balancing technology and family life, as well as cultural perspectives on parenting from her experiences in Ukraine. In this conversation, Lena shares her experiences navigating the challenges of leading a tech team in Ukraine during the ongoing war, highlighting the resilience and determination of her team. She discusses the importance of maintaining a sense of normalcy and connection amidst chaos, the innovative tech stack they are using in AI, and the complexities of regulatory environments in the personal care industry. Additionally, she reflects on her passion for space research and the evolution of data mining technologies.Time Stamps00:00 Introduction to the CTO Podcast and Guest03:01 The Good Face Project: Origins and Mission06:01 Understanding Ingredients: The Science Behind Personal Care08:53 Generative AI in Personal Care: Innovations and Challenges12:12 Venture Capital Landscape: Navigating the Hype15:07 Parenting in the Digital Age: Balancing Technology and Family21:04 Reflections on Parenting: Learning and Growing Together26:56 Cultural Perspectives on Parenting: A Global View34:03 The Power of Connection in Uncertain Times39:14 Resilience Amidst Chaos: The Ukrainian Experience45:09 Innovations in AI: Tech Stack and Models53:39 Navigating Regulations in Personal Care and Supplements01:02:22 Passion for Space: A Journey Through ResearchWe have 200+ CTOs in peer groups: Quick Testimonials VideoContact Etienne: Website / YouTube / LinkedIn / X / Instagram / The CTO Podcast WebsiteContact Lena: Website /LinkedIn This is a public episode. If you would like to discuss this with other subscribers or get access to bonus episodes, visit www.ctopod.com