Advertise on podcast: Develpreneur: Become a Better Developer and Entrepreneur

AI is an essential tool for many developers, but using it well takes more than picking the most powerful model. As adoption grows, developers and businesses face new questions about cost, performance, infrastructure, and matching the right technology to each task. Knowing when and how to use each option is becoming a core engineering skill. In this episode of Develpreneur, Rob Broadhead and Michael Meloche continue their conversation with Kevin Riedl, founder of Wavect, an AI-native software agency in Austria. Building on our last discussion about AI-native development and software quality, we dig into the technical and business decisions behind efficient AI-powered systems. Kevin shares his views on local AI models, cloud services, model routing, orchestration, token optimization, and shifting expectations for software development. We also talk about how smaller companies can compete with larger ones by using AI strategically, without piling on cost or complexity. This episode fits Season 29, Build a Career Beyond the Code. Generating code is getting easier for everyone. Designing efficient systems, controlling costs, and delivering real business outcomes is where the value is. About Kevin Riedl Kevin Riedl is the founder of Wavect, an AI-native software agency based in Austria that works with clients internationally. His work covers software engineering, artificial intelligence, product development, and helping organizations build effective technology solutions. Through Wavect, Kevin helps businesses with AI-assisted development, software modernization, and improving their engineering processes. His approach emphasizes practical results, thoughtful technology decisions, and using AI to create measurable business value. He also shares insights on emerging AI tools, software engineering practices, and technology trends through his professional content and Wavect's online resources. Connect with Kevin Riedl: LinkedIn: https://www.linkedin.com/in/wsdt/ Wavect: https://wavect.io/ Local AI vs. Cloud AI: Which Makes More Sense? As developers get comfortable with AI, many start thinking about running models locally. Instead of relying on ChatGPT or Claude, they consider buying hardware and hosting their own AI infrastructure. Michael brought this up while talking about his experiments with Apple Silicon, including Mac minis and a Mac Studio. Powerful consumer hardware gives developers more room to experiment with local models and build private AI systems. Kevin says the decision often comes down to economics. Local AI keeps improving, but cloud-based frontier models are still cheap compared with buying and maintaining the hardware needed to approach their capabilities. For many individuals and small businesses, running advanced models locally would cost more than a commercial AI service. That doesn't mean local AI has no value. Running models locally gives you more control over your data, less dependence on outside providers, and a good fit for workloads that run continuously. It also lets developers see how models behave outside the interfaces the major AI companies provide. The real question is whether the investment supports an actual business or technical need. A company sending occasional requests will likely do better with a cloud subscription. An organization running AI workloads around the clock may find dedicated hardware increasingly attractive. Kevin recommends understanding both approaches instead of assuming one always wins. Why Developers Should Experiment With Local Models Even if cloud AI makes financial sense today, developers should know the alternatives. AI providers keep changing their models, capabilities, pricing, and services. A business that depends on one provider may eventually hit limits that affect its costs or operations. Understanding local AI gives you another option. Kevin suggests Hugging Face as a starting point for exploring available models. The platform hosts a large collection that developers can evaluate for different workloads. Tools like Ollama make it easier to run supported models on local hardware, compare capabilities, and learn the limits of smaller models. Experiments should have a purpose. A developer might test whether a local model can summarize documents, classify information, process internal records, or handle repetitive tasks without sending data to an outside service. Those jobs don't necessarily need the most advanced model available. Once you know which tasks a local model can handle, you can design systems that balance performance, cost, and privacy. AI Model Routing: Choosing the Right Model for Each Task One of the most interesting topics in our conversation was AI model routing. Many developers pick a single AI platform and use it for nearly everything. The same advanced model summarizes emails, writes documentation, analyzes complicated architecture, and produces production code. It's convenient, but it isn't always efficient. Kevin believes model routing will become an important part of AI development. Instead of sending every request to the same model, a routing system evaluates the task and picks a model that fits its requirements. It works like assigning work on a development team. You wouldn't put your most experienced architect on every small documentation update or routine data-processing job. You don't need the most powerful AI model for every request either. A model-routing strategy might look like this: Simple classification: Use a smaller model to categorize emails, documents, or support requests. Document summarization: Use a model that can handle the required context without extra reasoning overhead. Code generation: Pick a model suited to the complexity and requirements of the task. Architecture analysis: Use a more capable model when the work needs deeper reasoning and broader context. Sensitive internal processing: Consider local models when privacy requirements rule out external services. Complex problem-solving: Escalate difficult tasks to a more advanced model when simpler approaches fall short. The goal isn't to pick the cheapest model. It's to find the least expensive model that can reliably do the job. A model that's too limited can cost more in the end if it produces wrong results or needs repeated attempts. Kevin stresses that routing has to balance capability and efficiency, not just price. For developers building AI-powered applications, this is another place to apply traditional engineering principles. AI Orchestration: Letting Models Work Together Model routing gets even more powerful when combined with orchestration. Instead of relying on one model to complete an entire workflow, developers can build systems where a more capable model coordinates several specialized agents or smaller models. Kevin described an approach where a higher-level AI system decides what needs to be done and delegates tasks to other models. That mirrors how software teams divide work. A senior engineer defines the overall architecture while other team members build specific components. An AI orchestrator can take a larger objective, break it into manageable tasks, and assign each one based on the capabilities it needs. A development workflow might use separate agents to analyze requirements, generate code, review changes, run tests, and summarize results, with the orchestration layer coordinating the work and deciding when more is needed. This can reduce how much expensive model processing goes to routine tasks. Orchestration also adds complexity. Developers have to consider how agents communicate, how results get validated, and how the system handles failures. The goal isn't to build as many agents as possible. It's a workflow that produces reliable results with reasonable resource use. Kevin also noted that existing AI development tools already include some orchestration features. Try those before building a complicated custom solution. Sometimes the Best AI Solution Doesn't Use AI Rob raised another point: what happens when an AI workflow becomes predictable enough that it no longer needs AI? Software development has always meant finding repeatable processes and automating them. Once the rules are clear, developers can often build deterministic solutions that give consistent results. AI doesn't change that. Kevin says that if a task requires deterministic behavior, use deterministic technology instead of adding a language model. If a system needs to validate a known data format, calculate a specific value, or apply established business rules, conventional software is usually more consistent and cheaper. AI earns its place when a task requires interpretation, reasoning, or handling information that doesn't follow a predictable structure. Developers can get so focused on integrating AI that they overlook simpler options. A well-designed application may use AI for some tasks and conventional code for others. The best architecture isn't the one that uses the most AI. It's the one that solves the problem efficiently and reliably. AI Is Raising Customer Expectations for Software AI adoption is also changing what customers expect. Developers can build prototypes and minimum viable products faster than ever. Applications that once took weeks can become working demos in days. Kevin points out that customers know this. When software gets easier to produce, they expect more. That adds competition. A functional application no longer gives the advantage it once did. More businesses can build software, more entrepreneurs can test ideas, and more developers can bring products to market. As the number of solutions grows, standing out takes more than the ability to generate an app. Businesses need

Introducing He Lost it All, Then Did the Impossible from The Oprah Podcast. Follow the show: The Oprah Podcast In this episode we’re joined by Jim Morrison, the first person ever to summit and ski down the North face of Mt. Everest, a seemingly impossible feat. Oprah and Jim talk about his process of preparing for his historic ski run after previously attempting the climb twice before. Jim also reflects on the unbelievable tragedies in his life and how he managed his grief. Jim lost his wife and children in a plane crash in 2011, then his partner and fellow famed mountain skier, Hilaree Nelson, died in 2022 in an avalanche right in front of Jim. Academy Award winning filmmaker Jimmy Chin joins the conversation to give his perspective on how he and their film crew prepared to record this extraordinary accomplishment for a new documentary, “Everest, The Other Side.”  WATCH THE MOVIE “Everest: the Other Side” will play in theaters and IMAX worldwide starting October 30th.  00:00:00 - Welcome Jim Morrison 00:04:30 - What goes through Jim’s mind on top of Everest  00:07:12 - What drove Jim to ski down Everest  00:09:25 - Jim lost his partner Hilaree  00:12:12 - Jim’s loss of his wife and two kids  00:17:00 - Jim’s definition of grief  00:30:00 - He failed to summit Mt. Everest 3 times 00:32:56 - Director Jimmy Chin joins  00:49:50 - A well-lived life  Follow Oprah Winfrey on Social: https://www.instagram.com/oprahpodcast/ https://www.facebook.com/oprahwinfrey/ Listen to the full podcast:  https://open.spotify.com/show/0tEVrfNp92a7lbjDe6GMLI https://podcasts.apple.com/us/podcast/the-oprah-podcast/id1782960381 DISCLAIMER: Please note, this is an independent podcast episode not affiliated with, endorsed by, or produced in conjunction with the host podcast feed or any of its media entities. The views and opinions expressed in this episode are solely those of the creators and guests. For any concerns, please reach out to [email protected].

Companies are racing to adopt AI. Developers are experimenting with increasingly powerful coding agents. Businesses want projects delivered faster. But faster development doesn't automatically produce better software. In this episode of Develpreneur, Rob Broadhead and Michael Meloche talk with Kevin Riedl, founder of Wavect, an AI-native software agency in Austria. Kevin shares what he has learned building software with AI, helping organizations adopt it, and balancing automation with proven engineering practices. We cover what AI-native means, why quality assurance still matters, and how developers can use AI without sacrificing security, reliability, or maintainability. This episode fits Season 29, Build a Career Beyond the Code. Writing code keeps getting easier. Knowing what to build, how to validate it, and whether it solves the right problem matters more every month. About Kevin Riedl Kevin Riedl is the founder of Wavect, an AI-native software agency based in Austria that works with clients internationally. His work covers software engineering, artificial intelligence, product development, and helping organizations build effective technology solutions. Through Wavect, Kevin helps businesses with AI-assisted development, software modernization, and improving their engineering processes. He emphasizes practical results, established engineering principles, and reliable software over adopting technology because it's popular. He also shares insights on AI development, emerging tools, software engineering, and technology trends through his professional content and Wavect's online resources. Connect with Kevin Riedl: LinkedIn: https://www.linkedin.com/in/wsdt/ Wavect: https://wavect.io/ What Does It Really Mean to Be AI-Native? Startups use the term "AI-native" to describe their business models. Established companies are restructuring around it. Software teams are working it into their development processes. Kevin thinks organizations should be careful about what the term means. Being AI-native doesn't mean putting AI in every application or discarding decades of engineering experience. It means knowing where AI adds value and pairing it with proven development practices. Kevin calls AI one of the most significant tools developers have received in decades, but it's still a tool. Developers still need to understand architecture, security, testing, requirements, and the business problem in front of them. Some organizations treat AI as a replacement for their existing processes. They assume that because AI can generate code, it can also make every architectural decision, understand every requirement, and catch every problem. It can't. Good AI-native development combines what AI does well with human engineering expertise. The goal isn't to use AI everywhere. The goal is better software, with AI used where it makes sense. Just Because AI Can Do Something Doesn't Mean It Should AI capabilities have expanded quickly. Modern tools can write applications, deploy infrastructure, drive browsers, analyze repositories, run tests, and help gather customer requirements. Work that once took specialized knowledge or significant time can now be partly automated. That doesn't make automation the right call every time. Experienced developers know the pattern. AI produces an answer that looks reasonable but misses key context. The code works, but it ignores performance concerns, security requirements, or existing architectural decisions. The model repeats approaches that already failed, or its changes break something elsewhere in the application. The risk grows with the responsibility. Asking a model to explain a function carries little risk. Letting it modify an entire application or deploy infrastructure carries a lot more. Kevin keeps human expertise and quality assurance at the center. Developers need to understand what the AI is doing, spot its mistakes, and set up controls that keep those mistakes out of production. AI speeds up development. Developers still own the results. AI Adoption Is Not the Biggest Challenge. Governance Is. Michael asked about companies that introduce AI without preparing their people. Some buy tools, hand out licenses, and expect productivity to jump. Others build controlled environments, train employees, and phase AI into existing workflows. Kevin says that at many companies, getting employees to use AI is no longer the hard part. They're already experimenting, sometimes without their employer knowing. The hard part is setting rules and making sure people understand them. Kevin described a large enterprise that had invested in its IT department, written internal policies, and provided approved AI tools. Employees still had personal smartphones. If they wanted help with a problem, they could photograph their screen and send it to a public AI service. Locking down company computers doesn't fix that. Organizations need to teach employees what information they can share, which tools are approved, and how to use AI responsibly. Kevin compares it to cybersecurity awareness training. Employees learned to spot phishing and suspicious emails. Now they need to learn the risks of sharing information through AI platforms. AI governance has to be part of daily operations, not a policy people read once and forget. Start With Simple AI Guardrails When Michael asked what organizations should do to protect themselves, Kevin said it depends on the business. A small software agency has different needs than a large financial institution or a multinational enterprise. His advice is to start with the basics instead of trying to solve every problem at once. Simple policies and employee education cover many of the most common risks. Start with the mistakes most likely to happen in normal AI use. Practical guardrails to start with: Protect confidential information. Never put sensitive business data, customer records, credentials, or proprietary information into unapproved AI services. Establish approved tools. Tell employees which AI platforms they can use and what restrictions apply. Provide ongoing training. Cover AI policies in onboarding and reinforce them as tools change. Maintain human oversight. Require review before AI-generated changes reach production systems or customers. Define quality standards. Set testing requirements, acceptance criteria, and review processes for AI-assisted work. Adapt policies to the business. Account for industry regulations, company size, customer expectations, and how sensitive the information is. None of this is new. These practices build on existing software development and security principles. Organizations don't need a new management philosophy to introduce AI responsibly. They need to apply established principles to a new technology. Kevin's advice: get the fundamentals right first. Organizations that follow simple policies consistently prevent many avoidable problems and can build more sophisticated governance over time. Managing Context in AI-Assisted Development Rob raised another challenge: managing context. AI tools can now work across entire repositories instead of single functions. Larger tasks need more information about the application's architecture, dependencies, requirements, and existing implementation. The question is how much the model actually needs. Too little context leads to wrong assumptions. Too much drives up token usage, slows responses, and buries what matters. Kevin says developers are experimenting with tools that trim unnecessary context and make information easier for AI to process. Some compress command-line output. Others organize repository information into structured knowledge representations. These techniques can cut token consumption and help AI focus on the relevant parts of a project. Kevin mentioned significant savings reported with combinations of context-management tools, though results depend on the tools and workloads. The takeaway isn't that every developer should adopt a particular optimization framework. The technology changes too fast for any single tool to stay the obvious answer. Developers should understand how context affects AI performance and try approaches that improve efficiency. Good Documentation Makes AI More Effective Rob tied context management to something developers have talked about for decades: documentation. Well-run software projects already have clear requirements, API definitions, architectural diagrams, and technical documentation. These let developers understand a system without reading every line of code. The same applies to AI. When developers give AI accurate, structured information about an application, the AI spends less time figuring out how the system works and more time on the actual problem. Clear documentation cuts unnecessary context and makes responses more relevant. Take an AI agent working on an API integration. It works better when the endpoints, request formats, authentication requirements, and error-handling rules sit in one place. Without that, it has to search multiple files or guess at the implementation. That changes what documentation is for. It no longer serves only to onboard developers or maintain legacy systems. It's now part of the information infrastructure that supports AI-assisted development. It still has to be accurate. Outdated or conflicting documentation misleads AI as easily as it confuses a human developer. The better the information we provide, the better the results. Vibe Coding vs. AI-Assisted Software Engineering One of the best parts of the interview covers the difference between vibe coding and professional AI-assisted development. As AI coding tools improve, developers write less code by

Smarter AI development is not about using the most advanced tool or building the most complicated solution. As AI makes software development faster and more accessible, developers and business owners face a different challenge: deciding what is actually worth building. The ability to create something quickly does not eliminate the need to validate the idea, maintain the finished product, or determine where human judgment still matters. In part two of our conversation with Alane Boyd, Co-CEO of Biggest Goal, Develpreneur: Building Better Developers explores what happens after a company moves beyond basic AI experimentation. Rob Broadhead and Michael Meloche talk with Alane about AI agents, vibe coding, custom software, minimum viable products, human oversight, and the growing temptation to build simply because AI makes building easier. For developers building a career beyond the code, the lesson is especially relevant. AI has dramatically reduced the effort required to turn an idea into working software, but the business questions surrounding that software have not disappeared. In many cases, those questions have become even more important. About Alane Boyd Alane Boyd is Co-CEO of Biggest Goal and a serial entrepreneur whose background spans technology, operations, sales, marketing, automation, and business growth. She has built SaaS businesses and describes herself as a two-time SaaS founder with successful exits. Biggest Goal's current work focuses on hands-on AI training and implementation for leaders and teams, including helping organizations move from basic AI experimentation toward repeatable systems and practical business workflows. Alane is also a published author, mentor, speaker, and podcast host. Her work increasingly focuses on practical AI fluency: helping businesses understand where AI belongs in their operations, how teams can use it consistently, and where human expertise should remain part of the process. Learn more about Alane and her work through Biggest Goal and connect with her on LinkedIn. Smarter AI Development Goes Beyond Chat Many people still use AI primarily through a chat interface. They enter a prompt, receive an answer, copy the output somewhere else, and repeat the process. Alane sees organizations beginning to move beyond that model toward AI workflows, connectors, scheduled tasks, skills, and agents. That progression can eliminate much of the manual movement between systems. Instead of repeatedly copying prompts and outputs, businesses can build processes that automatically trigger AI and move information where it needs to go. At the same time, tools such as Claude Code have made development accessible to people who would not traditionally consider themselves developers. Alane sees value in that shift because people outside software development can finally see some of what happens behind the scenes when software is created. However, creating an application is only one part of software development. The excitement of building something can hide the long-term responsibility that follows. Someone still has to maintain the application, troubleshoot failures, adapt to changing requirements, manage dependencies, and determine what happens when the original creator no longer wants to spend time supporting it. Michael sees the same issue when talking with people who have created applications using AI. They are excited because the application works, but they have not necessarily considered what comes next. AI Makes Building Easier, Not Maintenance Optional This creates one of the biggest challenges surrounding AI-assisted development. A founder can now describe an idea and begin creating software without fully understanding the lifecycle of the product being built. The first version can feel almost magical. AI writes code, creates interfaces, troubleshoots problems, and helps someone move from an idea to something tangible much faster than traditional development allowed. That speed can create the impression that software has become a one-time project. It has not. Alane points out that maintaining what you build can become a significant burden. A founder who creates a custom platform may eventually discover that the software requires constant attention. What started as an exciting experiment can become another system the founder is personally responsible for keeping alive. This is where smarter AI development requires thinking beyond the initial build. The important question is not simply, "Can AI build this?" It is also, "Do we want to own and maintain this after AI builds it?" Build Versus Buy Still Matters AI has made the traditional build-versus-buy decision even more interesting. If AI can create custom software faster and cheaper than before, building something yourself can look like the obvious choice. Alane's experience suggests otherwise. Before selling one of her previous companies, she merged with a competitor. Both companies had developed software, but one had built a SaaS product that customers could purchase while the other had proprietary software designed primarily for internal use. When the combined company eventually evaluated those systems, the proprietary software was the first to be shut down. The reason was business value. Internal proprietary software had limited marketability compared with a product customers were willing to purchase. The company had invested resources into creating and maintaining something that ultimately had little independent value during the sale process. That experience shaped an important principle in Alane's approach: build what people want to buy. For developers, that does not mean custom software is always the wrong decision. It means the ability to build something is not enough justification for building it. An existing platform may already solve the problem while another company absorbs the cost of maintenance, upgrades, security, and continued development. AI changes the economics of building software, but it does not eliminate those considerations. Validate the MVP Before You Keep Building Developers like to build. That is one of the reasons many people become developers in the first place. Give a developer an interesting problem and enough time, and there will always be another feature worth adding. AI can amplify that instinct. Alane recommends returning to a familiar startup principle: the minimum viable product. Before investing heavily in development, determine the smallest version of the idea that can test whether somebody actually wants it. That means asking practical questions early: Will someone pay for this? What is the smallest version we can put in front of a customer? Which features are actually required? Can we validate demand before investing more development time? Are we solving a real customer problem or simply enjoying the build? Alane acknowledges that she has fallen into the same trap herself. It is easy to believe a product needs every feature before customers can see it. The problem is that developers can spend months or even years creating something without discovering whether there is a viable market. Time is a resource. A product that consumes a year of development without generating revenue may eventually become difficult to justify, regardless of how technically impressive it is. Talk to Customers Before Building in a Vacuum Alane references the early Dropbox story as an example of validating demand before completing a product. Rather than waiting until every part of the platform existed, Dropbox demonstrated the concept and gathered interest from people who wanted the solution. The broader lesson is more important than the specific example. Developers and founders need feedback from potential customers before disappearing into build mode. Friends and family are not necessarily enough. The useful feedback comes from people who might realistically use or purchase the product. Those conversations can expose incorrect assumptions long before they become expensive features. AI makes this even more important because the barrier to building has dropped dramatically. When a new feature can be generated quickly, it becomes easy to keep adding functionality without stopping to ask whether anyone needs it. Smarter AI development requires resisting that momentum. Build enough to learn, talk to users, and then decide what deserves to be built next. Do Not Make the Solution Harder Than the Problem Developers and founders also have a tendency to make solutions more complicated than necessary. AI gives us even more ways to do that. A developer can open an AI coding tool, create custom logic, and continue refining an increasingly sophisticated solution. However, the same problem might be solved with a scheduled task, an AI skill, a simple automation, or an existing product. Alane encourages teams to focus on the job that needs to get done rather than the technology they want to use. The question becomes: What is the quickest, cheapest, and easiest reliable way to accomplish the goal? Sometimes that answer will be custom software. Sometimes it will be an AI agent. Other times, the answer may be a much simpler workflow. That distinction matters because every custom solution creates ownership. Someone has to maintain it. Someone has to understand it when it breaks. Someone has to modify it when the business changes. Smarter AI development includes knowing when not to develop something. Keep Human Judgment in the Loop One of the clearest guardrails Alane provides is that judgment should not be handed entirely to AI. AI can process information, identify patterns, generate options, and perform repetitive tasks, but Alane draws a distinction between havin

Building an AI-ready organization requires more than giving employees access to ChatGPT, Claude, Copilot, or another AI platform. Without training, standards, and a clear understanding of where AI belongs, organizations can create more confusion and expense instead of improving productivity. The technology may be new, but many of the problems it exposes have been hiding inside businesses for years. In this episode of Develpreneur: Building Better Developers, Rob Broadhead and Michael Meloche talk with Alane Boyd, Co-CEO of Biggest Goal, about what businesses are learning as they move beyond experimenting with AI. Alane has built and scaled technology companies, including two SaaS platforms and a social media agency. Today, much of her work focuses on helping organizations implement AI, train their teams, and create scalable systems that make work easier rather than simply adding another technology to the stack. The conversation quickly reveals an important distinction. AI adoption is not really about purchasing AI tools. Building an AI-ready organization starts with understanding how work gets done and deciding where AI can genuinely improve that work. About Alane Boyd Alane Boyd is Co-CEO of Biggest Goal and a serial entrepreneur whose background spans technology, operations, sales, marketing, automation, and business growth. She has built SaaS businesses and describes herself as a two-time SaaS founder with successful exits. Biggest Goal's current work focuses on hands-on AI training and implementation for leaders and teams, including helping organizations move from basic AI experimentation toward repeatable systems and practical business workflows. Alane is also a published author, mentor, speaker, and podcast host. Her work increasingly focuses on practical AI fluency: helping businesses understand where AI belongs in their operations, how teams can use it consistently, and where human expertise should remain part of the process. Learn more about Alane and her work through Biggest Goal and connect with her on LinkedIn. Moving Beyond AI Experimentation For many people, the first experience with generative AI was simple experimentation. They opened a chat window, entered prompts, generated content, summarized documents, or tried whatever interesting use case appeared online. That experimentation helped people become comfortable with the technology, but organizations are now asking a more difficult question: How do we turn that experimentation into a repeatable business process? Alane sees this transition with both individuals and organizations. Solopreneurs may want to move beyond basic prompting and learn how tools such as Claude Cowork can become part of their workflow. Larger organizations face another challenge because they need multiple employees to use AI consistently. They also need policies that prevent AI adoption from becoming what Alane describes as the "wild, wild west." Many organizations already have employees using several different AI platforms. Those employees may be paying for separate subscriptions, developing their own prompting techniques, and solving similar problems without sharing what they have learned. Management eventually sees those subscriptions and begins asking what everyone is actually doing with them. That is when AI stops being an individual productivity experiment and becomes an organizational challenge. It is also where the work of becoming an AI-ready organization really begins. An AI-Ready Organization Needs Training Michael shared an example that will probably sound familiar to many developers. One organization provided employees with AI development tools and effectively told them to use the technology to meet an aggressive deadline. There was no meaningful training, shared handbook, or established standard for how the tools should be used. The AI helped the development team meet a deadline that likely would have been impossible otherwise. However, the lack of planning created another problem: consumption. Developers burned through available AI tokens quickly, forcing the organization to rethink how accounts and shared resources were allocated. Alane has seen similar situations. One organization decided to skip training and purchase Claude subscriptions for its employees instead. Within days, employees exhausted their available usage and the company had to address the consequences. The problem was not that the employees had access to AI. The problem was that nobody had taught them how to use it effectively. Alane compares the situation to introducing any other workplace technology without establishing expectations. Give an organization Slack or Microsoft Teams without communication standards, and employees can quickly become overwhelmed with messages. AI follows the same pattern because employees naturally develop their own habits unless the organization provides guidance. When Alane asks employees to share their screens and demonstrate how they use AI, she often discovers inefficient workflows that generate poor results while consuming unnecessary resources. Better tools do not automatically create better processes. Teams still need training. Start with AI Champions Organizations do not necessarily have to create an AI strategy from scratch. Alane recommends looking first at the people who are already experimenting with the technology. Those employees can become AI champions. Instead of limiting AI adoption to the technology department, companies can create a cross-functional group of employees who already understand some of the possibilities. Representatives from sales, marketing, operations, development, and other departments can identify useful applications within their own areas while sharing what works across the organization. This approach also helps companies address different comfort levels. Some employees naturally experiment with new technology and learn by trial and error. Others prefer structured instruction before changing how they work. Neither group represents an entire organization, so an implementation strategy needs to account for both. Cross-department AI champions can help bridge that gap. They can demonstrate practical use cases, answer questions, and provide examples that are relevant to the work people actually perform. More importantly, they help an AI-ready organization develop shared practices instead of allowing every department to create its own isolated approach. Not Every Task Needs AI Another mistake is assuming that once an organization has AI, every task should involve it. Alane encourages companies to think carefully about where AI creates meaningful value. Different teams also have different needs. Software developers may legitimately consume far more AI resources than employees performing other tasks because AI can dramatically accelerate certain areas of development. A content team, however, may not need the same allocation. In some cases, writing an email manually may actually be faster than prompting AI, reviewing its response, correcting it, and rewriting the result. The goal is not maximum AI usage. The goal is better work. Organizations should ask where AI can handle repetitive processing, organize information, analyze transcripts, move data, or perform other behind-the-scenes tasks. They should also identify where human expertise still produces a better result. That distinction matters because poorly implemented AI can actually increase costs. A company may purchase more subscriptions and consume more computing resources without gaining meaningful productivity. Training helps employees recognize which jobs are appropriate for AI and which jobs are better handled directly by a person. AI Often Exposes Problems That Already Existed One of Alane's most important observations during the conversation is that many problems blamed on AI existed long before AI arrived. Companies frequently struggle with inconsistent processes, missing documentation, scattered files, and employees completing the same task in completely different ways. AI does not create those problems. It makes them much harder to ignore. Alane sometimes begins working with an organization only to discover that the company does not even have a consistent shared folder structure. Before building sophisticated AI agents or automations, the organization may need to solve much more basic operational problems. This creates an important lesson for developers and business leaders. Automation works best when the underlying process is understood. If nobody can explain how a process is supposed to work, automating it may simply make the confusion happen faster. In that sense, AI can act as a diagnostic tool. Attempting to implement it forces organizations to ask questions they should have asked already. Where does information live? Who owns a process? What is the standard procedure? Which version of a document is authoritative? Where should a human review occur? Those are not AI questions. They are business process questions, and answering them is an important part of creating an AI-ready organization. AI-Ready Organization Foundations Come First Some organizations simply are not ready for advanced AI implementation. Alane has encountered companies whose technology and processes were so outdated that Biggest Goal ultimately determined it was not the right partner for them yet. That does not mean those companies can never use AI. It means they have foundational work to complete first. An organization may need to establish shared storage, document its standard operating procedures, modernize parts of its technology stack, or determine how information moves between departments. Once those foundations exist, AI becomes much easier to introduce because there is a stable process to imp

Success stories often sound much cleaner after the fact. Someone starts a company, grows it, sells it, and moves on to the next opportunity. What usually gets left out are the mistakes, difficult decisions, and moments when the business almost did not survive. In Part 2 of our conversation with Glenn Poulos, we get into that side of entrepreneurship. Glenn has started companies, sold companies, worked through an acquisition, nearly lost a business, rebuilt, sold again, and eventually became a buyer himself. That experience has given him a perspective you do not get from simply reading about entrepreneurship. Some of his most valuable lessons came from the deals and decisions that did not work as expected. About Glenn Poulos Glenn Poulos has spent more than four decades working in technical sales, entrepreneurship, and business leadership. After beginning his career in electronics, he entered technical sales in 1985 and founded his first technology distribution company in 1991. He later co-founded Gap Wireless, which grew into a major Canadian distributor serving the mobile broadband and wireless industries before being acquired in 2022. Today, Glenn is President of ProgUSA, a U.S.-based company serving power utilities and service organizations with electrical test and measurement equipment, technical support, service, and calibration. He is also the author of Never Sit in the Lobby, which shares practical lessons from his career in sales and business. Connect with Glenn on LinkedIn or learn more about his work through his website. A Successful Exit That Wasn't So Successful Glenn's first company was eventually approached by a well-known public company interested in acquiring the business. The offer looked impressive. Glenn and his partners would receive some cash, but most of the value came through millions of shares in the acquiring company. On paper, Glenn became a multimillionaire and one of the company's largest shareholders. There was one major problem. He could not immediately sell those shares. Within roughly 18 months, the acquiring company went bankrupt, and the shares became worthless. Glenn had sold a valuable business but received nowhere near the value he expected from the transaction. That experience taught him a lesson that would influence future deals: the number written at the top of an acquisition agreement does not necessarily equal the money you will eventually receive. It also taught him something about due diligence. The buyer had thoroughly investigated Glenn's company, but Glenn and his partners had not done the same investigation of the buyer. Because it was a public company and a recognizable name, they assumed that was enough. It wasn't. Due Diligence Goes Both Ways This is an important lesson for developers, consultants, and founders because we often focus on proving ourselves. A potential employer interviews us. A client evaluates our proposal. An investor examines the company. An acquiring company reviews the books. But evaluation should work in both directions. Glenn later realized that more investigation might have uncovered warning signs within the company acquiring his first business. That experience changed how he approached future transactions. The same principle applies outside acquisitions. Before accepting a major client, investor, partner, or even a new job, ask what you need to know about the other side of the relationship. A recognizable name does not eliminate risk. Growth Can Take You Away From What You Do Best Glenn's next company eventually became highly successful, but getting there was not a straight line. By 2019, the business was in serious trouble. Part of the problem was expansion. The company knew how to buy technology from manufacturers and sell it to customers. Because they were successful at that, it became easy to assume they could move into adjacent businesses. Why not install the technology too? Why not expand into another product category? Those ideas sound reasonable until the new business requires completely different expertise, employees, equipment, inventory, and risk management. Glenn calls what happened the "reverse Midas touch." Instead of everything turning to gold, new ventures began creating problems. The company eventually found itself about $1.3 million in the hole. The solution required difficult decisions. Glenn and his partner dramatically reduced the size of the organization, transferred a problematic service division, exited another difficult product area, and refocused on the company's core strengths. Those decisions helped turn the business around and ultimately positioned it for a successful sale. There is a valuable lesson here for technical professionals. Being good at one thing does not automatically mean you will be good at the thing next to it. Expansion needs more than opportunity. It needs the right expertise and someone capable of owning it. Be Careful With the Money Attached to Growth Another theme in our conversation was financing. Glenn is careful to point out that his experience comes primarily from running traditional operating businesses rather than venture-backed startups. Within that context, he prefers avoiding outside money for as long as practical. Debt has a cost. Equity has a cost. Partners have a cost. Those costs are not always measured only in interest rates or percentages. Taking an investor may mean giving someone influence over how the company operates. Bringing in a partner means sharing the value you eventually create. An earn-out may make an acquisition price look larger, but some of that money depends on hitting future targets after control of the company has changed. Glenn's experience has made him particularly cautious about large earn-outs and long post-acquisition commitments. Choose Partners for More Than Proximity Glenn also offered a warning about business partnerships through something he jokingly calls "vice president in the room syndrome." A few friends start talking about creating a company. Someone becomes CEO. Someone else becomes VP of Technology. Another person gets sales. Someone else happens to be there, so they get a title too. The company has barely started, but ownership and leadership positions have already been distributed based on who was in the room rather than what the business actually needs. That can become extremely expensive later. Glenn has successfully worked with partners, so his point is not that partnerships cannot work. It is that ownership decisions made casually at the beginning become very difficult to undo once the company has real value. Experience Is Often Learning What Not to Do One thing I appreciated about Glenn's story is that the lessons do not come from pretending every decision was correct. Some worked. Some didn't. His first company taught him how dangerous an acquisition can become when you fail to investigate the buyer. His second taught him how quickly expansion outside your core strengths can consume a profitable business. Selling to private equity taught him about earn-outs and what happens when you are no longer the person controlling a company you built. Those lessons eventually influenced how he approached buying and running his current business. For developers building a career beyond the code, that may be the most useful takeaway. Entrepreneurship is not simply about having a good idea or building a product. It requires understanding money, people, partnerships, risk, operations, and sometimes knowing when to stop doing something that is not working. The technical problem may actually be the easy part. Stay Connected: Join the Developreneur Community 👉 Subscribe to Building Better Developers for more conversations on momentum, leadership, and growth. Whether you're a seasoned developer or just starting, there's always room to learn and grow together. Contact us at [email protected] with your questions, feedback, or suggestions for future episodes. Together, let's continue exploring the exciting world of software development. Additional Resources Business Agreements – Lessons Learned Learning From Your First Business Strategies for a Successful Business Launch Building Better Developers Podcast Videos – With Bonus Content

Building a career beyond the code does not necessarily mean leaving technology behind. Sometimes it means learning how to take technical knowledge and apply it differently. That might involve sales, leadership, consulting, or eventually building a company of your own. In this episode of Develpreneur, we talk with Glenn Poulos, an entrepreneur who started his career as an electronic technician before moving into technical sales. That transition eventually led him to start, grow, and sell multiple technology distribution companies. More recently, Glenn took a different approach: instead of starting another company from scratch, he bought an existing business. His experience provides an interesting lesson for developers and technical professionals considering entrepreneurship. The biggest opportunity may not always be building something new. Sometimes it is finding something that already works and figuring out how to make it better. About Glenn Poulos Glenn Poulos has spent more than four decades working in technical sales, entrepreneurship, and business leadership. After beginning his career in electronics, he entered technical sales in 1985 and founded his first technology distribution company in 1991. He later co-founded Gap Wireless, which grew into a major Canadian distributor serving the mobile broadband and wireless industries before being acquired in 2022. Today, Glenn is President of ProgUSA, a U.S.-based company serving power utilities and service organizations with electrical test and measurement equipment, technical support, service, and calibration. He is also the author of Never Sit in the Lobby, which shares practical lessons from his career in sales and business. Connect with Glenn on LinkedIn or learn more about his work through his website. From Technical Skills to Sales and Entrepreneurship Glenn began his career working with electronics, including repairing equipment used at Canadian weather stations. He soon discovered that the role was not what he wanted long-term, and his boss suggested that he consider sales. That advice changed the direction of his career. Glenn moved into technical sales in 1985, selling test and measurement equipment used by engineers. Because he understood the technology, he could speak the customer's language while learning the business side of the industry. He eventually realized something important: sales could dramatically expand his earning potential without requiring him to abandon his technical background. A few years later, he saw another opportunity. Instead of simply selling products for someone else's company, he could build the company employing the salespeople. In 1991, Glenn left his job and launched his first business focused on technology for the growing mobile wireless market. He would spend the next several decades building businesses around a similar model: find useful technology, understand the market, and connect those products with customers who need them. For developers, there is an important lesson here. Your technical skills can be the foundation of your career without defining its boundaries. Starting a Business Versus Buying One After starting companies from scratch more than once, Glenn eventually decided he would take a different approach. He bought an existing business. The experience showed him how much infrastructure entrepreneurs have to recreate every time they start from zero. A new company needs banking relationships, insurance, employees, vendors, customers, processes, credit, and a reputation. An established company may already have many of those pieces. That does not mean buying a company eliminates the work. Glenn changed much of the business he acquired, including its branding, systems, vendors, staffing, and processes. He also had to manage something founders do not encounter in quite the same way: an existing culture and employees dealing with significant change. Still, he started with an engine that was already running. Glenn believes there is an overlooked opportunity in smaller established businesses whose owners are ready to retire but do not have someone prepared to take over. In some cases, a new entrepreneur may be able to structure a transition in which the existing business helps finance the owner's eventual exit. Instead of spending years creating everything from scratch, the entrepreneur can focus on improving what already exists. AI Changes What a Small Business Can Do The other major change Glenn has experienced is AI. When he acquired his current company in 2024, AI was already becoming useful. In only a few years, however, it has changed how he operates the business. Glenn described using AI across financial reporting, accounts receivable, marketing, planning, sales training, and internal tools. Rather than hiring full-time employees for every specialized role, he can combine fractional experts with AI-supported processes. The important distinction is that AI is not running the company. People still make decisions, review information, manage relationships, and provide judgment. AI increases what those people can accomplish. Glenn gave a simple example with trade shows. Coordinating a trade show means tracking booth reservations, travel, hotels, equipment, marketing materials, deadlines, and dozens of other details. Instead of buying another software package, Glenn had AI help him build a tool specifically around his company's process. He has created enough internal tools that he eventually needed another tool simply to keep track of them. That is both funny and revealing. AI removes many of the old barriers to creating software, automating processes, and increasing productivity. The new challenge is deciding which problems are worth solving and making sure we finish what we start. The Opportunity Beyond the Technical Work One thing that stood out in our conversation with Glenn is that none of these transitions required abandoning technology. His technical background remained useful throughout his career. What changed was how he applied it. He learned sales. He learned how businesses operate. He learned how to build companies, manage people, work with vendors, and eventually evaluate an existing company as an acquisition. Now he is adding AI to that toolkit. That is exactly what building a career beyond the code can look like. The technical skills get you started, but the opportunities become much larger when you combine them with communication, business knowledge, sales, leadership, and the ability to recognize a problem worth solving. You do not necessarily need to build the next startup from nothing. There may already be a good business, product, or process waiting for someone with the right technical experience to see what it could become. Stay Connected: Join the Developreneur Community 👉 Subscribe to Building Better Developers for more conversations on momentum, leadership, and growth. Whether you're a seasoned developer or just starting, there's always room to learn and grow together. Contact us at [email protected] with your questions, feedback, or suggestions for future episodes. Together, let's continue exploring the exciting world of software development. Additional Resources Building Trust in the AI Era | Amit Zandberg Can AI Help You Trust Online Course Reviews? | Amit Zandberg The Entrepreneurial Mindset: Moving From Side Hustle to Company Building Better Developers Podcast Videos – With Bonus Content

Developer work-life balance is often treated as a productivity problem. We look for better schedules, better tools, fewer meetings, or another technique for getting more done. However, our second conversation with Gaylen A. Wilson raises a different question: what happens when the problem is not how much work you have, but your inability to stop working the problem? Developers spend their careers learning how to stay with difficult problems. We debug issues that make no sense, work through production failures, deal with changing requirements, and keep digging until we find an answer. That persistence can make us successful. It can also make it difficult to recognize when we have crossed from productive problem-solving into stress, frustration, and burnout. The challenge becomes even greater when we carry that state away from the computer. Work may have ended, but mentally, we are still debugging. Learning to recognize that transition is an important part of developer work-life balance. About Gaylen A. Wilson Gaylen A. Wilson is an author, relationship coach, technology veteran, entrepreneur, farmer, former stockbroker, and heart-transplant recipient whose career has required him to reinvent himself repeatedly. Together with his wife, Heather, Gaylen developed the Monument Method, an approach they use to help couples interrupt destructive conflict patterns and strengthen their connection. Learn more about Gaylen A. Wilson through his website http://www.monumentmethodinstitute.com/. Developer Work-Life Balance Starts with Recognizing Your State Michael brought the conversation back to developers by pointing out something familiar to many people in technology. We can become so accustomed to constantly working the problem that we stop recognizing what it is doing to us. There is always another release, bug, customer issue, deadline, or technology to learn. We keep pushing because that is what has worked throughout our careers. Eventually, though, we can reach a point where we are no longer solving the problem effectively. We are simply reacting to it. Gaylen connected that experience to what he describes as fight-or-flight thinking. He had experienced an extreme version during his health problems. As a self-described Type A personality, one of the hardest things for him was accepting that he still wanted to keep going while his body was telling him that he could not. He credited his relationship with his wife, Heather, as an important source of support during that period. You do not need to reach that extreme before recognizing the same pattern in your career. Sometimes the warning sign is much simpler. You close the laptop, but you are still thinking about the defect. You sit down for dinner and mentally replay a conversation from work. You are supposed to be relaxing, but you feel guilty because you are not doing something productive. The workday ended. Your brain never got the message. The Car That Would Not Start Gaylen shared a story that provides a surprisingly good example of what this looks like. He had spent two months working on one of his cars and finally got it running. After driving it around the block, he and Heather prepared to leave and visit friends. He pushed the button to start the car, and nothing happened. For someone who likes solving problems, that was frustrating enough. Gaylen also felt that he was disappointing Heather because they were supposed to leave. He grabbed a multimeter, found the battery was low, and started looking for jumper cables. He could not find them. They were actually nearby, underneath a blanket, but Gaylen had become so frustrated that he could not slow down enough to move the blanket and see them. By his description, he had entered full fight-or-flight mode. He found another old set of jumper cables, discovered they were badly corroded, and became even more frustrated. Developers have our own versions of that blanket. You have probably stared at a defect for an hour only to discover the problem was obvious once you stepped away. Maybe you rewrote code that did not need rewriting. Maybe you blamed a dependency, the network, the database, or someone else's code before discovering a simple configuration problem. The longer we fight the problem, the narrower our thinking can become. At some point, persistence stops being an advantage. Developer Work-Life Balance Requires an Interrupt The most interesting part of Gaylen's story came next. Heather was sitting in the car and did not realize how frustrated he had become. Gaylen finally walked over to her and said, "I need a monument." That phrase comes from the relationship framework Gaylen and Heather developed, which they call the Monument Method. They use "monument" as an agreed-upon signal to interrupt an escalating conflict or emotional reaction and reconnect before continuing. Gaylen said that when Heather turned toward him, his anger quickly disappeared. He then gave her permission to use the same technique whenever she saw him beginning to spiral in the future. Whether or not you use Gaylen's specific method, there is a useful concept here for developers: we need an interrupt. In programming, an infinite loop does not usually fix itself because we let it run longer. Sometimes something external has to break the cycle. Our work habits can operate the same way. Build an Interrupt into Your System Developers love systems, so it can help to think about disconnecting from work as something we deliberately design rather than something we hope happens automatically. Your interrupt does not have to be Gaylen's "monument." It can be something simple that signals the transition from work mode to the rest of your life. Take a walk after shutting down your computer. Write down the next step before leaving a difficult problem. Create a short end-of-day routine that closes out unfinished work. Exercise before transitioning into your evening. Set a fixed point when you stop checking Slack, Teams, or email. Talk with someone rather than continuing to replay the problem internally. Step away from a frustrating problem before making another major change. The specific ritual matters less than recognizing why you need it. If you regularly leave work in a frustrated state, simply closing the laptop does not necessarily reset that state. You may physically leave the work while mentally carrying it into everything you do afterward. That affects more than your evening. It can affect how you communicate with the people around you and how prepared you are to return to work the next day. You Cannot Debug Everything by Working Harder Michael asked Gaylen an important follow-up question: what if you do not have someone there to help you reset? Gaylen described an experience while Heather was away visiting family. He had become frustrated while working with ChatGPT and realized that Heather would normally recognize when he was becoming agitated. Without her there, he experimented with mentally recreating the calming experience they had practiced together. He said that simply closing his eyes and imagining the familiar interaction helped him calm down. Gaylen attributed that response to repeatedly practicing their method until it had become a familiar signal for him to reset. The larger lesson is not that developers need to reproduce Gaylen's exact technique. It is that we can become better at recognizing when our current state is no longer helping us solve the problem. When you have been staring at the same code for three hours, are you still debugging effectively? When you are angry at a tool because it is not behaving the way you expect, are you still evaluating the problem objectively? When you are rewriting something for the third time late at night, are you improving it, or are you just unwilling to stop? Developers spend enormous amounts of time learning how to diagnose systems. We should learn to diagnose ourselves, too. Find Your North Star Rob connected Gaylen's Monument Method to something we regularly discuss in software projects and businesses: having a "why." Projects need a reason for existing. Without that reason, teams can spend enormous amounts of energy building things that do not actually move them toward their goal. A clear purpose becomes a North Star. When the project begins drifting, the team can return to the original question: what are we actually trying to accomplish? Developers can apply that idea to our careers. Why are you working so hard? Why are you pursuing the promotion? Why are you building the business? Why are you learning another technology? Why are you putting in the extra hours? There may be excellent answers to all of those questions. The danger comes when the work becomes its own answer. Developer Work-Life Balance Requires Boundaries There is a strange contradiction in successful technology careers. We work hard because we want to build a better life, but the habits that help us succeed can gradually consume the life we were trying to build. Gaylen argued that professional success, money, and recognition lose much of their meaning if they come at the expense of the important relationships around us. Rob connected that back to the larger theme of Career Beyond the Code: career success needs a reason behind it. Simply pursuing more work, more money, or more achievement does not provide a natural stopping point. That is why developer work-life balance cannot be solved entirely with productivity hacks. Sometimes you need to recognize that enough is enough. The defect can wait until tomorrow. The email does not need an answer tonight. You do not have to understand every new AI tool this weekend. The side project does not have to become

Career reinvention for developers is usually discussed in terms of learning a new language, moving into leadership, adapting to AI, or finding a new job. Our conversation with Gaylen A. Wilson takes that idea much further. His story shows what happens when careers, businesses, health, and even our assumptions about the future stop following the plan. Season 29 of Building Better Developers is about building a career beyond the code. Usually, that leads us into conversations about leadership, communication, business value, quality, or the skills developers need as they move beyond completing technical tasks. This episode is different. We did not spend much of the first half talking about software development or QA. Instead, Gaylen told us his story, and the longer he talked, the clearer the connection to developers became. Gaylen's career repeatedly forced him to confront something most developers eventually discover for themselves: you can master the tools, solve complicated problems, and work incredibly hard, but none of that guarantees life will follow the architecture you designed. His story is ultimately about rebuilding when the plan fails, which makes it an unexpected but valuable example of career reinvention for developers. About Gaylen A. Wilson Gaylen A. Wilson is an author, relationship coach, technology veteran, entrepreneur, farmer, former stockbroker, and heart-transplant recipient whose career has required him to reinvent himself repeatedly. Together with his wife, Heather, Gaylen developed the Monument Method, an approach they use to help couples interrupt destructive conflict patterns and strengthen their connection. Learn more about Gaylen A. Wilson through his website http://www.monumentmethodinstitute.com/. Your Career Is Not a Straight Line Gaylen started his professional life far away from software. He became a farmer in his twenties and built a life around agriculture. Then drought and crop failures destroyed the business, eventually forcing him into farm bankruptcy. He had to reinvent himself. His next chapter took him into finance as a stockbroker. He succeeded there until a company whose investment he had recommended collapsed after, according to Gaylen, misrepresenting its financial condition. He described that experience as another devastating setback. Without healthy ways to process what had happened, his personal life also began to unravel. Eventually, Gaylen rebuilt again. In 2001, he found work as a traveling PeopleSoft computer consultant. He was earning more than he ever had before and thought he had finally reached a stable point in his career. Then September 11 changed the economy and consulting industry around him. By December, he had lost that job. After months of searching and hundreds of mailed résumés, he eventually took a job as a Walmart cashier because he needed to work. For developers, there is an important lesson in that progression. We often build our identity around what we do. We become the Java developer, QA engineer, architect, DevOps specialist, technical lead, or whatever role currently defines our career. Then the technology changes, the company restructures, a project ends, AI changes part of the workflow, or the market simply decides that yesterday's valuable skill is commonplace today. The ability to rebuild can matter more than the title you are trying to protect. Career Reinvention for Developers Starts with Transferable Skills One interesting part of Gaylen's story is how often skills from one chapter became useful in the next. Farming did not look anything like stockbroking, and stockbroking did not look much like technology consulting. Yet farming had already taught him far more about running a business than people might assume. When the consulting market disappeared, Gaylen eventually returned to his hometown and put a small advertisement in the newspaper offering computer repair. He had never worked professionally as a computer repair technician. He had simply been interested in computers for years. Within six months, that small side business was outperforming his Walmart job. Then the market changed again. As Windows became more reliable and malware-related repair work declined, the computer repair business that had supported Gaylen and his wife, Heather, began drying up. Instead of assuming the old business would somehow return, he adapted. He found platforms connecting technicians with companies needing field work and began traveling throughout rural America installing and servicing technology. Eventually, that work took Gaylen and Heather through all 48 contiguous states. That is where this story starts to sound much more familiar to a developer. Technologies disappear. Frameworks fall out of favor. Companies reorganize. Entire categories of work become automated. A skill that was valuable five years ago can become commonplace today. Career reinvention for developers becomes easier when we stop defining ourselves by a particular technology and start recognizing the skills that survive those changes. Those transferable skills include: Problem-solving and troubleshooting Learning unfamiliar systems quickly Breaking complicated problems into manageable pieces Communicating with customers and stakeholders Testing assumptions instead of blindly following them Adapting when the original solution no longer works Understanding the business problem behind the technology Those are skills that remain valuable even when the code changes. Developers Are Professional Problem Solvers There is another reason Gaylen's story belongs in a developer-focused season. Developers tend to be fixers. Give us a broken system, and we immediately start looking for the defect. We gather information, isolate variables, test assumptions, and keep working until we understand the problem. That mindset is incredibly valuable. It can also become dangerous when we start treating every problem as something we can overcome simply by working harder. Michael touched on this at the beginning of the episode while discussing the difficulty of slowing down after a period of long releases and extreme work hours. Even after the immediate pressure disappeared, there was still that feeling that he should be doing something. Rob connected that experience to the larger conversation about how quickly technology is moving and how easily careers can consume the rest of our lives. Many developers know that feeling. There is always another ticket, certification, framework, side project, production issue, release, or AI tool to learn. We tell ourselves things will calm down after the current deadline. Then another deadline appears. Gaylen eventually encountered a problem he could not outwork. When Working Harder Stops Being the Solution In 2014, after years of traveling for technical work, Gaylen became seriously ill. He initially believed he had pneumonia and continued working. During another extended trip, his condition worsened until a clinic in Corpus Christi sent him for a chest X-ray. He was told he had congestive heart failure and needed to return to Colorado. His first reaction is revealing. The jobs were paying well. They already had weeks of work scheduled. Gaylen initially thought they should finish the trip before dealing with his heart. It took two more jobs before the seriousness of the situation finally broke through his drive to keep working. That moment is an extreme example of a pattern many developers experience in smaller ways. We know we need sleep, but the release needs to go out. We know we need a weekend away from the computer, but production has a problem. We know we have not spent enough time with the people around us, but there is one more thing we need to finish. The problem-solving mindset becomes a trap when the answer to every problem is simply more effort. There are times when the correct solution is to stop. What Are You Actually Building? Gaylen eventually received a heart transplant in 2018. He described being near the point where he and Heather were preparing for the possibility that he would die when they received the call that a donor heart was available. By the next morning, Gaylen had received a new heart. He viewed the transplant as an opportunity to have more years with the person who had stayed beside him throughout his illness. That experience changed what success meant to him. It also gives developers a useful question to ask about our own careers: What are we actually building? We spend our days building systems for other people. We think about architecture, scalability, reliability, technical debt, requirements, and defects. Yet we do not always apply the same intentional thinking to the systems surrounding our careers. A successful career should support a life rather than consume it. That does not mean ambition is wrong. It does not mean developers should stop working hard or stop pursuing difficult goals. It means the career itself should serve something larger. Otherwise, we can become incredibly efficient at building a future we eventually discover we did not want. Quality Applies Beyond Software At EnvisionQA, we spend a lot of time thinking about quality and finding problems before customers encounter them. One lesson from this conversation is that the same mindset can extend beyond software. In software, we do not wait for catastrophic failure if we can avoid it. We monitor systems. We test assumptions. We look for warning signs. We examine recurring defects because they often point toward deeper problems. Our careers deserve similar attention. If every release requires heroics, something may be wrong with the process. If every week requires sixty or eighty hours, the workload may not

AI communication skills are becoming increasingly important as developers and leaders rely on artificial intelligence to summarize meetings, draft emails, organize ideas, and prepare for conversations. These tools can save time, but Salvatore Manzi warns that using AI to improve your communication is different from letting AI do your communicating for you. In Part 2 of our Develpreneur conversation with leadership communication coach Salvatore Manzi, Rob Broadhead and Michael Meloche explore how communication changes as developers move into leadership roles and AI becomes part of everyday work. The discussion covers better meetings, keeping remote teams engaged, using AI without weakening your skills, and communicating technical ideas to people outside your technical world. About Salvatore Manzi Salvatore Manzi is a leadership communication coach whose work sits at the intersection of leadership, communication, and collaboration. He works with teams and analytical professionals to improve how they communicate so they can collaborate more effectively and move their ideas forward. Salvatore is also the author of Clear and Compelling: Communication Strategies for Big Thinkers. During the Develpreneur interview, he explained that the book draws on twenty years of communication strategies and is aimed particularly at analytical, technology, and data-driven professionals with bold ideas. His work fits closely with the theme of this season of Develpreneur: building a career beyond the code. Technical knowledge can help you develop the idea, but leadership communication helps you explain it, build support for it, and bring other people along with you. Social: Facebook / YouTube / Instagram / LinkedIn Website: Salvatore Manzi's Website AI Communication Skills Need Structure Without Becoming Rigid Developers tend to appreciate systems, but nobody wants every conversation governed by a complicated set of rules. That creates an interesting challenge for leaders: How much structure does a team actually need? Salvatore describes communication as an art rather than something with a perfect formula. However, he also points out that people need parameters. We need to understand the limits before we know how much freedom we have within them. In a meeting, those limits might involve time, the topic being discussed, or how long each person should speak. The key is keeping those parameters flexible. Telling someone they can speak exactly seven words creates a new problem because everyone becomes focused on satisfying the rule. Asking people to keep their responses to one or two sentences establishes a useful boundary without turning the meeting into an exercise in compliance. This same principle applies throughout leadership. Structure should help people communicate rather than becoming another obstacle they have to navigate. Better Communication Starts With the Purpose of the Meeting Many developers have experienced days where one meeting runs into another until there is almost no time left to do the work discussed in those meetings. The problem is not necessarily whether a meeting lasts fifteen minutes, thirty minutes, or an hour. Salvatore recommends starting with a more fundamental question: What is this meeting supposed to accomplish? Without a clear objective, a meeting can continue indefinitely without producing a useful result. When people understand the goal and receive the information they need beforehand, however, some discussions can be resolved in five or fifteen minutes. That changes the way we think about meeting efficiency. Instead of automatically scheduling an hour and trying to fill it, define the outcome first. Then determine how much time the team actually needs to achieve it. AI Communication Skills Require Human Engagement AI has added another dimension to the meeting problem. We can now record conversations, generate transcripts, create summaries, identify action items, and return to the information later. Those capabilities are useful, but they can also create an excuse to disengage. Michael raised a scenario that is becoming increasingly familiar: people attend a meeting with their cameras off, barely participate, and depend on an AI-generated transcript or summary to tell them what happened afterward. Salvatore argues that leaders have a responsibility to create engagement. His recommendation is the 3-5 rule: every three to five minutes, introduce some type of pattern disruption that brings people's attention back into the conversation. That disruption does not need to be dramatic. A leader can: Ask a question. Poll the group. Ask someone for their perspective. Introduce an interactive visual. Connect the discussion directly to someone's current work. Change the way information is being presented. One of the most effective approaches is relevance. If you connect a discussion directly to a project someone is working on, that person's attention naturally increases. Instead of simply delivering information to a group, you are showing people why that information matters to them. That may become even more important as AI makes passive participation easier. Communication Skills Matter Even Without a Leadership Title What happens when you recognize that a meeting is failing but you are not the person running it? That is a common situation for developers. You may be sitting in a retrospective, refinement, stand-up, or project meeting where two or three people dominate the conversation while everyone else remains silent. Salvatore suggests that participants can help create engagement without taking over the meeting. One approach is to respond directly to something another person shared. You might briefly explain what you appreciated about their contribution and how it connects to the work. If the meeting consistently prevents important voices from being heard, that can also become a conversation with the facilitator before the next meeting. Explain what you need from the discussion and why hearing from more of the team matters to your ability to move forward. This approach changes the interaction from criticism to a request. You are not simply saying that the meeting is bad. You are explaining what would make it more useful and why that change matters. Better Team Communication Permits People to Challenge Ideas Another problem appears when people have concerns but do not want to become known as the person who is always negative. Salvatore described working with a startup that deliberately assigned roles such as the critic, negator, or contrarian during meetings. The roles rotated between people, which gave someone explicit permission to challenge an idea without being personally labeled as difficult. Over time, something interesting happened. Team members reported feeling safer raising uncomfortable issues even when they were not officially assigned one of those roles. For software teams, this concept has obvious applications. Projects need people willing to ask what happens when something fails. Testers need to challenge assumptions. Developers need to question architecture. Business analysts need to identify missing requirements. Security teams need to think about how a system could be abused. The goal is not negativity. The goal is making constructive disagreement part of the process instead of treating disagreement as a personality problem. Communication Skills Help Make Complex Ideas Easier to Process Technical experts often struggle with another communication problem: we know too much. When someone asks about a system we have spent months or years building, it is tempting to provide all the history, context, data, dependencies, and edge cases necessary to prove that we understand the problem. The listener probably does not need all of it. Salvatore recommends narrowing information into a small number of meaningful chunks. The underlying data still matters, but effective communication requires deciding which pieces another person needs to understand before moving forward. That skill becomes increasingly important as developers move into leadership. Executives, customers, operations, marketing, legal, and other departments usually do not need the same technical depth that another developer needs. The challenge is not knowing the information. It is knowing which information matters to the person in front of you. Do Not Let AI Communication Replace Your Own Voice This is where AI communication skills become particularly important. AI can summarize a long email chain, draft a response, prepare meeting notes, and transform rough ideas into polished language. Salvatore sees value in those capabilities, but he also sees a risk when AI begins communicating back and forth while the people involved stop thinking for themselves. Eventually, an email conversation becomes a real conversation. At that point, you have to explain the ideas that supposedly came from you. You have to answer questions in real time, adapt to new information, defend decisions, and respond to a dynamic situation. If AI has been doing all of the thinking and communicating for you, you may discover that you are not prepared for that conversation. Salvatore's recommendation is straightforward: use AI, train it toward your voice, and take advantage of what it can do, but always read before you send. Edit the output. Make sure it sounds like you. More importantly, make sure you understand and can stand behind what is being communicated. AI should reduce unnecessary work. It should not remove you from your own communication. Build AI Communication Skills One Problem at a Time Avoiding AI entirely is not the answer either. The challenge is maintaining yo

Leadership communication becomes increasingly important as developers move beyond writing code and begin leading people, projects, and technical decisions. Being the smartest person in the room does not automatically make you the most effective leader. In fact, technical expertise can sometimes work against a team when the people with the strongest opinions dominate the conversation while everyone else quietly checks out. In this episode of Develpreneur, Rob Broadhead and Michael Meloche talk with leadership communication coach Salvatore Manzi about what happens when developers and technical experts move beyond writing code and begin leading people. The conversation focuses on learning how to make sure people understand one another, contribute their ideas, and work together instead of simply talking past each other. About Salvatore Manzi Salvatore Manzi is a leadership communication coach whose work sits at the intersection of leadership, communication, and collaboration. He works with teams and analytical professionals to improve how they communicate so they can collaborate more effectively and move their ideas forward. Salvatore is also the author of Clear and Compelling: Communication Strategies for Big Thinkers. During the Develpreneur interview, he explained that the book draws on twenty years of communication strategies and is aimed particularly at analytical, technology, and data-driven professionals with bold ideas. His work fits closely with the theme of this season of Develpreneur: building a career beyond the code. Technical knowledge can help you develop the idea, but leadership communication helps you explain it, build support for it, and bring other people along with you. Social: Facebook / YouTube / Instagram / LinkedIn Website: Salvatore Manzi's Website Leadership Communication Starts With Understanding Technical professionals are trained to process information quickly. Someone explains a problem; our brains immediately start analyzing it. This happens even before the other person has finished speaking; we may already be constructing a solution. That speed can be useful when solving technical problems. It can also create problems when working with people. Salvatore recommends starting disagreements with shared understanding. Before offering your own response, rephrase what you believe the other person said and confirm that you understood it correctly. The purpose is not to repeat their words back to them. It is to demonstrate that you understood the idea behind those words before adding your own perspective. For developers, this can initially feel inefficient. If everyone in the room understands the technology, why repeat something that was just said? Salvatore argues that this small investment in leadership communication can prevent much larger problems later. Rephrasing establishes a common starting point, particularly when people are working together for the first time or discussing an important decision. A simple way to develop the habit is to practice it once each day. Find one conversation where, instead of immediately responding, you rephrase what you heard and ask whether you understood correctly. Over time, that intentional pause becomes part of how you communicate. Get Your Voice Into the Meeting Early The opposite communication problem happens when someone has something useful to contribute but waits too long to speak. This is common on technical teams. When one or two people are viewed as the experts, everyone else may wait for them to speak first. Once those people begin driving the conversation, it becomes increasingly difficult for quieter team members to enter it. Salvatore recommends getting your voice into the meeting within the first five minutes. You do not need to make a profound statement or immediately solve the problem. Ask a question, acknowledge someone else's contribution, or invite another person into the discussion. The goal is simply to become an active participant instead of a passive observer. That advice applies especially well to developers who prefer to process information before speaking. Waiting until you have the perfect answer can mean never entering the conversation at all. Leadership can make that problem easier or harder. Leadership Communication Means Creating Space for Everyone A leader's responsibility is not simply to provide the best answer. Effective leadership communication also means creating an environment where the team can produce better answers together. Salvatore suggests several practical techniques for getting more people involved. One is a quick round-the-room check-in where everyone provides something that is going well and something that could be going better. The important part is establishing limits, such as one sentence for each answer, so the exercise does not turn into a series of monologues. Another technique is the 10-second rule. Ask the team a question, but tell everyone that nobody should answer for ten seconds. That short silence gives analytical team members time to process the question. Instead of rewarding whoever can speak fastest, the meeting gives everyone a chance to formulate a useful response. These techniques are simple, but that is part of their value. Improving team communication does not necessarily require a new platform, complicated process, or another meeting. Sometimes it requires changing the way an existing conversation is structured. Stop Putting People on the Spot There is also a significant difference between inviting someone into a conversation and suddenly calling on them. Anyone who remembers being unexpectedly called on in school knows the feeling. Instead of thinking about the question, your brain suddenly starts thinking about the fact that everyone is looking at you. Salvatore demonstrated a better approach during the conversation: give the person advance notice that you are coming to them, tell them the subject you want them to address, briefly move the group's attention elsewhere, and then return to them. That small handoff gives the person time to prepare mentally. Instead of creating a performance test, the leader creates an opportunity for the person to contribute. This is particularly useful for technical teams where some members may need a few moments to organize a complex answer. The goal is not to eliminate spontaneity. It is to stop confusing fast responses with valuable responses. Breaking Down Technical Silos Through Better Communication Technical organizations naturally create specialists. One person understands the database. Another understands infrastructure. Someone else knows the business rules, testing process, user interface, or deployment pipeline. Specialization helps teams solve difficult problems, but it can also create silos. Salvatore described working with a team whose individual groups functioned effectively but struggled when they came together. They were essentially speaking different languages. During a half-day session, the team worked through what they needed from one another and what they believed they were hearing from each other. They also formed smaller cross-functional groups. One surprisingly effective part of the exercise was asking people to begin by identifying something they appreciated about another person's work. That forced team members to think about what their colleagues actually contributed rather than seeing only their own piece of the system. That lesson matters in software development because it is easy to judge another role by how it affects your own work. Developers can become frustrated with QA. QA can become frustrated with developers. Technical teams can become frustrated with business stakeholders, while business stakeholders wonder why seemingly simple requests take so long. Good leadership communication helps people understand those different perspectives. Understanding what another person contributes does not eliminate disagreement, but it gives that disagreement context. What About the Person Who Never Stops Talking? Creating space for quieter voices introduces another challenge: the person who takes too much of that space. Most teams have experienced the meeting where someone gets the microphone and never seems to give it back. Salvatore recommends addressing this before it becomes a problem by establishing communication agreements for the team. Those agreements might include: Make sure every voice has an opportunity to contribute. Keep individual contributions short. Lead with the bottom line. Provide additional detail when the group needs it. Once those expectations are established, a phrase such as "bottom line" can become a shared reminder rather than a personal criticism. Everyone already understands what it means and why the team uses it. That distinction is important. Good meeting facilitation is not about silencing people. It is about managing the limited amount of attention and time available so the entire team can participate. Leadership Communication and the Move From Expert to Leader One of the biggest career transitions for developers is moving from being responsible for your own technical output to helping other people produce results. The skills that made you a strong developer do not disappear when you become a technical lead, architect, manager, or executive. However, they are no longer enough by themselves. You have to listen differently. You have to recognize when someone has stopped participating. You have to create room for people who need time to think while keeping stronger personalities from consuming the entire conversation. Most importantly, you have to stop measuring leadership communication by whether you successfully said something and start as

AI can produce code faster, automate repetitive work, analyze enormous amounts of information, and move development tickets at a pace that would have seemed impossible only a few years ago. Yet faster execution does not automatically create better software delivery systems. In fact, speed can expose weaknesses that organizations previously managed to hide. That distinction becomes central in the second part of Dana Hetté's conversation with Rob Broadhead and Michael Meloche on Building Better Developers. The first part explored the organizational cracks that form between roles and how developers can use systems thinking to recognize them. Part two moves from recognition to action: What happens when delivery is already struggling? Where should an organization start? And what role should AI play when the underlying system is not healthy? Hetté's answer challenges a common technology reflex: tools do not define the solution. They enable a solution that has already been defined. About Dana Hetté Dana Hetté, also known as Blondie Geek, is a fractional operator who works with founders and leadership teams at startups and small product organizations. After earning a degree in computer science, Dana spent roughly seven to eight years as a software engineer before moving toward roles centered on product, operations, and the connection between business strategy and execution. Dana describes her work as occupying the operator seat: the connective role between what leadership intends and what teams ultimately deliver. Her approach combines the systems-thinking foundation of software engineering with product discovery, organizational operations, and cross-functional communication. Rather than focusing only on what individual teams are doing, she looks for the cracks between roles where context, ownership, and business intent can disappear. You can learn more about Dana at BlondieGeek.com, connect with Dana Hetté on LinkedIn, or subscribe to her newsletter, Closing the Loop. Software Delivery Systems Need Diagnosis Before Automation Consider an organization where code is still shipping, deadlines are still being met occasionally, and every department appears busy. Underneath that activity, however, pipelines are breaking, quality is deteriorating, bugs are increasing, and teams are getting closer to the red line. Leadership sees the symptoms and understandably wants a solution. Maybe another project-management platform will help. Perhaps a new AI development tool can increase productivity. Maybe another automation will remove the bottleneck. Hetté argues that this is precisely where organizations need to resist the urge to start with technology. "Tools are not the solution, they enable a solution that you've already defined." — Dana Hetté When an organization does not understand why its delivery system is breaking, automating that system can simply make the dysfunction operate faster. Instead, Hetté returns to something far less glamorous: discovery. She describes getting into the organization, talking to people, observing stand-ups, examining project-management tools, reviewing tickets, and investigating what is actually happening. AI can assist with that process by analyzing meeting transcripts, tickets, sprint information, and other organizational data, but human judgment remains necessary to understand what those signals mean. The objective is not immediately to fix everything. It is first to define what is actually broken. Software Delivery Systems Improve When You Find the Real Problem Hetté points to the classic Five Whys technique as an example of how straightforward the diagnostic process can be. Something is broken. Why? Then ask why again. Continue until the team moves past symptoms and reaches the underlying cause. This sounds elementary, particularly to developers accustomed to sophisticated debugging tools, observability platforms, AI assistants, and complex architectures. Yet the underlying principle is remarkably similar to debugging software. A developer encountering an exception does not permanently solve the problem by hiding the error message. The exception is evidence. You trace the execution path until you understand the condition producing it. Organizational problems deserve the same discipline. Hetté describes the balance as spending much of the effort defining the problem. Once the actual problem is understood, the solution often becomes surprisingly straightforward. Complicated symptoms do not necessarily require complicated solutions. The complexity may come from not knowing which problem you are actually solving. This is also why firefighting becomes dangerous when it turns into a permanent operating model. There are legitimate emergencies where a team has to use what Hetté calls "duct tape and chewing gum" to cross the finish line. Production needs to be restored. A deadline cannot move. A customer needs an immediate resolution. The distinction is whether the organization recognizes that temporary stabilization is not the same as solving the underlying problem. Align Software Delivery Systems Around Trade-Offs Even after identifying a problem, teams can struggle because leadership and engineering are optimizing for different outcomes. Engineering may want time to improve quality. Leadership may be focused on speed to market. Finance may be focused on cost. Product may be trying to protect scope. None of those priorities automatically makes one group wrong. The organization needs to decide what matters most. Hetté uses what she calls project sliders during discovery. The idea involves familiar project constraints such as speed, quality, and cost. Leadership needs to determine where those sliders sit rather than pretending every priority can simultaneously be maximized. A company may say it needs to reach the market tomorrow while spending as little as possible. The next question becomes unavoidable: What is the organization willing to compromise—quality, scope, consistency, or time? Many disagreements that appear technical are actually disagreements about priorities that were never explicitly decided. Those decisions provide developers with something extremely valuable: guardrails. Hetté shares an example involving an engineer who wanted an increasingly agentic workflow. Instead of manually associating work, the engineer wanted one agent to determine what another agent was doing. Hetté suggested a dramatically simpler solution: put the ticket number in the pull request. The engineer could even have an agent perform that step. The exchange highlights an important distinction between technological possibility and operational value. An organization does not need to automate something merely because it can. Once leadership has established its priorities, those principles can become the North Star for deciding which practices are worthwhile. AI Needs Human Inspection Points The role of human judgment becomes particularly important when AI enters development workflows. In Part One, Hetté described developers using AI agents to move rapidly through tickets only to discover during user acceptance testing that the output did not match what was actually needed. Part Two reinforces why those failures matter. AI dramatically increases the amount of work a developer can produce. However, increasing output also increases the consequences of an incorrect assumption. A misunderstanding that once produced one incorrect implementation might now propagate across specifications, tickets, code, tests, and documentation before anyone notices. The answer is not necessarily a large new governance process. Sometimes it is simply a sanity check. An AI agent turns raw requirements into a specification. Before the next agent begins producing code, someone reads the specification and asks: Is this actually what we need? That lightweight inspection can prevent an incorrect assumption from accelerating through the entire delivery pipeline. Find one AI-assisted handoff in your development process and introduce a deliberate verification point. Do not merely ask whether the AI completed the task. Ask whether its output still matches the original intent. Human-in-the-loop development should not mean manually redoing everything AI produces. That would eliminate much of AI's value. Instead, human judgment should be strategically positioned where errors become increasingly expensive if they continue downstream. Software Delivery Systems Need Ownership There is another problem that neither AI nor better tooling automatically resolves: ownership. As organizations grow, a single operator cannot personally inspect every handoff. If that person attempts to do so, the individual who was supposed to eliminate bottlenecks becomes one. Hetté discusses solving this through mentorship and delegation. In one engagement, she entered knowing from the beginning that part of her responsibility would be finding and developing her eventual replacement. Rather than building an organization permanently dependent upon her, she worked with a more junior person and transferred the systems-thinking and operational mindset needed to continue the work. That approach provides an important lesson for technical leaders: good systems should reduce dependency on specific individuals. This is familiar territory for developers. We know the danger of a critical application understood by only one engineer. We recognize the bus-factor problem in software. Yet organizations can accidentally create exactly the same dependency in operations. The answer is to transfer judgment, context, and ownership. Hetté argues that systems thinking, product-oriented thinking, and operational

Software development careers have traditionally been measured by technical ability: the languages you know, the systems you can architect, the bugs you can solve, and the quality of the code you produce. But developer systems thinking expands that definition. As developers advance in their careers, their value increasingly comes from understanding not only how software works, but how people, processes, business goals, and technical decisions work together. That distinction sits at the center of Dana Hetté's conversation with Rob Broadhead and Michael Meloche on Building Better Developers. Hetté, also known as Blondie Geek, began her career in software engineering before moving into what she describes as the "operator seat." Her work now focuses on a problem that many startups and product organizations encounter: teams may be busy building, leadership may have a clear vision, and every individual may appear to be doing their job, yet what ultimately ships does not match what the business actually needs. The problem is often not inside any one role. It exists in the space between those roles. About Dana Hetté Dana Hetté, also known as Blondie Geek, is a fractional operator who works with founders and leadership teams at startups and small product organizations. After earning a degree in computer science, Dana spent roughly seven to eight years as a software engineer before moving toward roles centered on product, operations, and the connection between business strategy and execution. Dana describes her work as occupying the operator seat: the connective role between what leadership intends and what teams ultimately deliver. Her approach combines the systems-thinking foundation of software engineering with product discovery, organizational operations, and cross-functional communication. Rather than focusing only on what individual teams are doing, she looks for the cracks between roles where context, ownership, and business intent can disappear. You can learn more about Dana at BlondieGeek.com, connect with Dana Hetté on LinkedIn, or subscribe to her newsletter, Closing the Loop. Developer Systems Thinking Starts With the Gaps Hetté describes herself as the cohesive layer between strategy and execution. In smaller organizations, founders often carry an enormous amount of context in their heads. They understand the company strategy, board expectations, customer demands, product direction, and countless decisions that have accumulated over time. Engineering, meanwhile, is responsible for turning some version of that vision into working software. The trouble begins during the transfer. A founder may tell a technical lead what needs to be built. The technical lead interprets that request through an engineering lens and passes work to developers. The developers execute against the information they have. Everyone can perform their individual job correctly while the organization still produces the wrong outcome. Hetté calls attention to the "cracks" between roles. Those cracks are where assumptions go unchallenged, context disappears, ownership becomes unclear, and seemingly small communication problems become delivery problems. A team can execute every assigned task successfully and still fail to accomplish the business objective. Local success does not guarantee system-wide success. One example from Hetté's work involved a feature-intake process at a larger organization. The company already had automations built into its project-management platform. On paper, the system appeared complete. Requests entered the system, automations processed them, and work moved through the expected steps. Then Hetté started asking questions. What business rule determined a particular assignment? Why did an item move from one place to another? Who owned the decision at a particular handoff? The answers were missing. The automation existed, but the underlying operational logic had gaps. As Hetté explains, people tend to operate within the boundaries of their defined roles. Consequently, "the gaps form between the roles." That observation is important for developers because those gaps are fundamentally systems problems. Why Developer Systems Thinking Goes Beyond Architecture Developers already learn to think in systems. We reason about dependencies, inputs and outputs, interfaces, failure states, data flows, and interactions among components. When one component behaves incorrectly, experienced developers do not automatically assume that component itself is the root cause. They trace what entered it, what left it, and how it interacts with everything around it. Hetté argues that this same ability can be applied to an organization. Instead of looking only at software architecture, look at the architecture of the business producing the software. Where does a requirement originate? Who translates it? What information is lost before it reaches engineering? What happens when engineering finishes? Who determines whether the result actually fulfills the original business objective? This represents an important shift for developers interested in careers beyond coding. Hetté spent roughly seven or eight years as a software engineer after earning her computer science degree. Over time, she realized she was becoming more interested in what the team was building and why than in every technical detail of how it was built. That did not make her engineering background irrelevant. It gave her a different place to apply it. She specifically identifies systems thinking as one of the strengths engineers can carry into product, program management, and operator roles. The mental model remains useful; the boundaries of the system simply become larger. Developer Systems Thinking Connects Code to the Customer One danger of remaining exclusively focused on implementation is that developers can unknowingly optimize for the wrong definition of success. Engineering naturally views a product through an engineering lens. Users do not. Hetté references Alan Cooper's The Inmates Are Running the Asylum when discussing this distinction. One of the ideas she draws from the book is that engineers and the people using their software frequently operate with very different mental models. What seems intuitive to someone who understands the internal mechanics of a system may be confusing or ineffective for the person the product was actually designed to serve. That principle extends beyond user interfaces. A technically elegant implementation can still solve the wrong problem. A completed ticket can still fail to deliver the expected business outcome. A feature can satisfy its technical acceptance criteria and still disappoint the customer. Moving beyond code does not mean abandoning technical thinking. It means expanding the system you are thinking about until the user, business objective, and organization become part of it. Hetté encourages developers to ask larger questions while they work. What is the company trying to accomplish? What is the product supposed to achieve? Does the current work support that strategy? What does the end user actually care about? Holding that context changes technical decisions because developers are no longer treating a ticket as an isolated unit of work. They are seeing where that ticket fits into the larger machine. The Operator Vacuum Between Founders and Engineering This becomes particularly important in startups. A founder or CEO in a six-person organization cannot spend the entire day translating product ideas for engineering. The founder may also need to work with investors, communicate with the board, develop partnerships, pursue business development, and determine company strategy. Yet that same founder may be the person carrying the clearest picture of the product. The result is what Hetté calls an "operator vacuum." The founder needs to leave the weeds, but the organization still needs someone capable of translating strategy into execution. Hiring a project manager or product manager may address portions of the problem, but Hetté notes that those people also have defined roles. The missing function may be broader: someone who can extract the founder's context, understand stakeholder demands and strategy, and work across project managers, technical leads, and the execution team. Hetté compares the position to being a first officer to the captain. The operator is not there to replace engineering, product management, or leadership. The operator connects them. For developers considering how to broaden their careers, this presents an interesting opportunity. You do not necessarily need the word "operator" in your title to begin thinking this way. Look for Symptoms Instead of Assuming the Problem An important part of systems thinking is resisting the temptation to diagnose a problem from its most visible symptom. A founder may say, "My team isn't shipping on time." Another may say that the team is shipping, but what arrives is not what was envisioned. A leader may feel trapped in day-to-day decisions because leaving the team alone seems likely to send development in the wrong direction. Those are symptoms. Hetté approaches them similarly to product discovery. She begins with probing questions for leadership and then talks with the people performing the work. Comparing those perspectives exposes where expectations, processes, and reality diverge. One useful signal appears when all the formal indicators say a project is healthy while downstream results say otherwise. A project board can be green. Stand-ups can report that everything is on track. Developers can close their tickets. Then the product reaches user acceptance testing and gets rejected. Somethin

Software development is changing quickly. AI can generate code, build prototypes, test ideas, and turn concepts into working software faster than most of us would have imagined just a few years ago. That raises an important question for developers: If writing the code is becoming easier, what makes you valuable? Welcome to Season 29 of the Develpreneur Podcast. This season, we're returning to an idea that has been at the heart of the show from the beginning. Becoming a better developer means developing more than your ability to write code. Our theme for Season 29 is Build a Career Beyond the Code, and throughout the season, we'll explore what that means for developers navigating an industry being reshaped by AI. More Than a Coder We've always made a distinction between being a coder and being a developer. A coder can take a requirement and turn it into code, while a developer needs to understand the problem behind that requirement. Developers have to determine whether the proposed solution makes sense, identify potential risks, and ultimately help deliver something useful. That distinction matters more now than ever. AI is becoming remarkably good at generating code. Give today's tools enough context, and they can produce in hours what might previously have taken a developer days or weeks. That doesn't eliminate the need for developers, but it does change where developers provide value. The valuable skills increasingly involve asking better questions, understanding the business problem, evaluating possible solutions, communicating with stakeholders, testing assumptions, and recognizing risks. We also have to determine whether what we're building actually solves the original problem. In other words, the future developer isn't simply someone who knows how to code. The future developer knows how to solve problems. AI Changes the Speed, Not the Responsibility One of the most exciting things about AI is how quickly we can experiment. An idea that might once have sat in a notebook for years can now become a prototype over a weekend. We can pressure-test concepts, generate alternatives, experiment with architectures, and throw away approaches that don't work without investing months of development effort. Instead of having one opportunity to build something correctly, we may be able to test dozens of approaches before committing to one. That's an incredible advantage, but it also creates a new problem: just because AI can build something doesn't mean we should build it. We can generate a prototype overnight and then immediately add another feature. That leads to another feature, another integration, and another idea that suddenly seems easy to implement. Before long, the simple application we originally wanted to build starts looking like we're trying to recreate Salesforce. Knowing when to stop is becoming an important development skill. So is knowing which features actually matter and whether the application still solves the problem we started with. AI can dramatically increase our development speed, but speed without direction simply allows us to make mistakes faster. The MVP Is Changing For years, building a minimum viable product required meaningful investment. Even a relatively simple prototype could require developers, designers, infrastructure, and weeks or months of work. AI has changed that equation. Today, creating something that looks impressive is relatively easy. You can quickly build an application with polished screens, dashboards, workflows, integrations, and features that would have required a significant development team not long ago. That means the existence of a prototype doesn't tell us nearly as much as it once did. We have to ask deeper questions about what we've created. Does it actually work? Is the architecture sustainable? Can it handle real users and real data? Is it secure and maintainable? Does anyone actually need it, and does it create real value? Those are not primarily coding questions. They're development questions, and answering them requires experience, critical thinking, testing, and an understanding of the people and businesses using the software. Developers Still Need to Think AI tools are powerful, but they still require direction, context, validation, and oversight. Working with AI agents can sometimes feel a lot like leading a development team. You assign work, review the results, discover something wasn't done the way you expected, refine the requirements, and try again. The difference is that AI lets you repeat that cycle incredibly quickly. That makes critical thinking even more important. Developers need to learn how to communicate what they want, provide the right context, establish boundaries, review results, test assumptions, and recognize when an answer that looks convincing is actually wrong. This also changes the questions developers should be asking. Instead of focusing entirely on whether AI can generate a particular application or feature, we need to ask whether we should build it in the first place. Then we need to determine how we'll know whether we built the right thing. That's where experience becomes leverage. Your Career Isn't Disappearing. It's Evolving. There's understandable concern about what AI means for software development careers, particularly for developers entering the industry. Some traditional career paths are already changing. Work that once gave junior developers opportunities to learn may increasingly be handled by AI, teams may become smaller, and individual developers may become capable of producing dramatically more than before. However, that doesn't mean there is nowhere left to go. The career ladder hasn't disappeared. The angle has changed. Developers who combine technical knowledge with problem-solving, communication, business understanding, critical thinking, leadership, and testing have an opportunity to become far more capable. AI can amplify those skills by helping developers move from an idea to something they can evaluate much faster. The goal isn't to compete with AI over who can type code faster. The opportunity is to become the person who understands what needs to be built, why it needs to be built, how to validate it, and how technology can solve the underlying problem. Building the Skills Beyond the Code Season 29 brings Develpreneur back to its roots while building on everything we've explored during the last several seasons. We're going to continue talking about AI because it is now part of the development landscape, but AI itself isn't the destination. We're interested in what developers can accomplish with it and which skills become more valuable as these tools improve. That means exploring technical skills alongside communication, critical thinking, problem-solving, requirements, testing, leadership, business value, decision-making, and project ownership. We'll look at how developers can pressure-test ideas before investing too much time in them, manage AI-generated solutions, and recognize the difference between a flashy prototype and production-ready software. Quality becomes particularly important when software can be generated so quickly. Producing code faster doesn't automatically mean we're producing better software. Every additional feature introduces complexity, potential failure points, testing requirements, and long-term maintenance. If the foundation isn't solid, AI can help us create a complicated mess much faster than we could have created one ourselves. That's why testing, validation, and asking the right questions become even more important. Generating more code isn't necessarily progress. Generating the right solution is. A New Career Path for Developers The changes we're seeing aren't limited to the tools developers use. They affect how people build careers. Developers need to become comfortable moving between technology, business problems, communication, testing, and decision-making rather than defining themselves by a programming language or framework. AI may even accelerate that career progression. Developers can experiment with ideas that previously required an entire team. They can work with AI agents in ways that resemble managing junior developers, explore unfamiliar technologies, and rapidly test different approaches to a problem. However, getting the most from those capabilities still requires knowing enough to recognize when something is wrong. Experience matters because AI doesn't remove responsibility from the developer. If anything, it increases the number of decisions we can make in a shorter period. The better we become at making those decisions, the more valuable the technology becomes. Welcome to Season 29 We're now well beyond 1,000 episodes of the Develpreneur Podcast, but the mission remains remarkably similar to where we started: helping developers become better developers. The tools have changed, the industry has changed, and AI has accelerated what individuals and teams can accomplish. The path developers take through their careers is changing along with it. That's exactly why this is the right time to return to the fundamentals. We need to learn how to think through problems, communicate effectively, evaluate what we're building, test our assumptions, and understand the value behind the technology. We also need to learn how to use AI without allowing the speed of AI to replace good judgment. Season 29 is about taking everything we've learned about software development, careers, business, quality, and AI and asking where developers go from here. The answer isn't to abandon technical skills or stop writing code. It's to recognize that code is only one part of what makes someone a valuable developer. The developers who thrive in this next stage of our industry will be the ones who c

AI is changing software development faster than most organizations can adjust their processes around it. Developers can generate code, tests, documentation, and prototypes in a fraction of the time those tasks once required. Business owners who have never written software can now describe an idea to an AI tool and have something working surprisingly quickly. That creates tremendous opportunity, but it also changes where the real value in software development lives. In the second half of our conversation with Laura Chattington, CEO of Rebalance Network Limited, we explored what happens when producing code is no longer the hardest part of building software. Laura argues that developers still have an important role, but the value they provide is shifting toward understanding the problem, managing risk, assuring quality, and connecting technology to business outcomes. About Laura Chattington Laura Chattington is the CEO of Rebalance Network Limited and works with established entrepreneurs and corporate leadership teams to turn AI capabilities into measurable business value. Laura began her career as a software engineer and has more than 20 years of experience spanning technology, business, communications, and leadership. Her work includes AI strategy and transformation programs, executive AI workshops, AI CEO programs, the AI Evolution Multiplier, and the Four Levels of AI Value framework. Learn more through Rebalance Network, connect with Laura Chattington on LinkedIn, or follow Laura Chattington on YouTube. AI Has Lowered the Barrier to Building Software One of the most significant changes AI has introduced is access. Entrepreneurs and other non-technical users can now experiment with software without immediately hiring a development team. They can create prototypes, automate workflows, connect systems, and build surprisingly capable applications by working directly with AI. Laura sees this happening regularly with the businesses she works with. The challenge is determining where experimentation should stop and professional software engineering needs to begin. An AI assistant will enthusiastically keep building when you ask it to. It may make an assumption, misunderstand a requirement, or introduce a problem that isn't immediately obvious. Someone without a technical background may see a working application and reasonably assume everything underneath it is working correctly as well. A software engineer sees a different set of questions. How is the data protected? What happens when an integration fails? How does the application handle unexpected input? Can it scale? How is it tested? What assumptions did AI make while generating the solution? That knowledge hasn't suddenly become irrelevant because AI can write code. In many ways, it has become more important. Bad Scope on Rocket Fuel Laura offered one of my favorite descriptions of this problem during our conversation: AI can become "bad scope on rocket fuel." Software teams have always struggled with poorly defined requirements. If the customer and development team don't clearly understand the problem, developers can spend months building something before everyone realizes they were solving the wrong problem. AI changes the speed of that mistake. A poorly scoped project can now generate a tremendous amount of code and functionality very quickly. That can create the illusion of progress because there is always something new to demonstrate. However, producing more software doesn't necessarily mean you are getting closer to the correct solution. This is something I've seen repeatedly from the testing and quality side of software development. Speed is valuable only when you maintain confidence in what you're producing. Accelerating implementation while removing validation simply moves problems downstream, where they usually become more expensive to fix. The goal shouldn't be to slow AI down. It should be to build the right quality gates around that speed. Quality Assurance Becomes More Important, Not Less This led to one of the more interesting parts of our conversation. Laura believes AI may change the relationship between software development and quality assurance. Traditionally, developers have often received most of the attention. Development creates the product, while QA can sometimes be treated as the group that appears later and tells everyone what is wrong with it. AI disrupts that equation. If AI can generate large amounts of code quickly, simply producing code becomes less of a differentiator. The more important question becomes whether the generated software is correct, reliable, secure, maintainable, and actually solving the intended problem. As Laura explained, the challenge becomes how we use the intelligence and speed AI provides while retaining high-quality assurance throughout the process. That doesn't mean developers disappear and testers take over. It means development and quality need to become much more tightly connected. Developers need to understand validation, testers need to become involved earlier, and teams need automated checks and human review positioned throughout the development process. AI gives us speed. Quality gives us confidence that we're moving quickly in the right direction. Developers Need to Rethink the Value They Provide This also raises an uncomfortable question for developers: if AI can write much of the code, what exactly are we being paid to do? The answer can't simply be typing faster. Laura argued that software engineers need to think more creatively about the value they bring to the table. Knowing how software works remains important, but understanding what should be built and why becomes increasingly valuable as implementation gets easier. A developer who understands the business can identify assumptions before they become expensive mistakes. They can recognize when a proposed AI solution creates unnecessary risk, determine where automation makes sense, and help leadership distinguish an impressive demo from something that can safely support the business. That combination of technical understanding and business communication creates a significant opportunity. Laura saw a similar pattern early in her own career as a Java developer. Her ability to communicate with the business pulled her toward management and leadership roles. She sees that opportunity emerging again for technical professionals who can bridge the gap between AI capabilities and business outcomes. What Do You Do With the Time AI Gives Back? The conversation then returned to a question from the first half of the interview: what happens when AI dramatically reduces the time required to perform work? Suppose a task that once took a week now takes two hours. Saving that time sounds impressive, but the time savings alone aren't necessarily business value. The real question is what happens to the rest of the week. Laura believes relatively few businesses have figured this out. Organizations may purchase AI licenses and encourage adoption, but simply giving employees tools doesn't create a strategy. Leadership needs to decide how the capacity created by AI will be used. If a 100-person organization gives each employee several hours back every week, the combined capacity can be enormous. That time could improve customer service, accelerate product development, generate new revenue, reduce delays, or allow teams to solve problems they previously didn't have time to address. Without that next step, the company has optimized a task without necessarily transforming the business. Look for the Biggest Pressure Points Laura shared an example from working with a leadership team in the urgent healthcare sector. Before spending time with the organization, she could have arrived with a long list of sophisticated ways the company might use AI. Once she understood how the organization actually worked, however, she discovered something much simpler: people were spending huge amounts of time in meetings. Some meetings existed because people had missed previous meetings. Others were necessary to communicate information that had already been discussed elsewhere. Executives needed to catch up before attending another meeting, creating another cycle of lost time. The valuable AI opportunity wasn't necessarily an elaborate new application. It was using AI to capture meetings, summarize information, create executive reports, and prepare people before they entered the next conversation. That kind of workflow could return a substantial amount of time to the organization. You don't discover opportunities like that by starting with a list of AI tools. You discover them by understanding how people work. Start With Pain, Then Apply AI That example reinforces a principle we continue returning to throughout this season of Develpreneur: start with the problem. Look at where the organization is spending its time. Find the repeated manual work, communication gaps, customer frustrations, delays, and bottlenecks. Determine which problems are actually expensive enough to solve, and then ask where AI can provide leverage. Laura described two questions she looks at when working with organizations. First, where is the business spending large amounts of time that AI could reduce? Second, how could AI help customers reach their desired outcomes faster? The second question is particularly important because it moves AI beyond internal productivity. Saving employees five hours is useful. Helping customers achieve an outcome twice as fast may fundamentally change the value of your product or service. That's where AI starts becoming a business strategy rather than another productivity tool. Faster Iteration Changes How We Build AI may also c