Recently on Lessons from the Leap, our Founder Ghazenfer Mansoor sat down with Joe Hubert, a seasoned technical manager, systems analyst, and solutions architect with over three decades of experience in software development, database design, and system integration. Today, Joe is at the forefront of helping organizations navigate AI literacy and adoption.
The central message of this episode? Most software projects don’t fail because developers can’t code. They fail because of what happens, or doesn’t happen, before a single line of code is written. Below are five hard-won lessons from Joe’s career that every founder, product leader, and engineering manager should internalize.
Why Software Projects Fail: It’s the Coach, Not the Players
Joe opened with an analogy that reframes how most of us think about project failure. In his experience, developers rarely hit a hard technical wall. They are, as he puts it, capable of delivering virtually anything, if they are given the right support and direction.
During a conversation with a colleague, Joe shared this philosophy and was met with a well-known football saying:
“Players win games and coaches lose them.” — Joe Hubert
The idea isn’t that developers are blameless in every scenario. It’s that when projects go sideways, the root cause is more often a failure of leadership and guidance than a failure of execution. The people responsible for defining what needs to be built bear more responsibility for outcomes than is usually acknowledged.
This is one of the most consistent patterns we see at Technology Rivers. When founders bring us
broken or stalled software projects to fix, the underlying issue is rarely that the developers were incompetent. It’s that they were set up to fail. For startup founders and product leaders, this is a challenging but important shift in thinking. If your dev team keeps missing the mark, the first question shouldn’t be “what’s wrong with the developers?” It should be “are we giving them what they need to succeed?”
Why Software Projects Fail: The Communication Gap No One Sees Coming
One of the most nuanced observations in this episode is that the communication gap between business leaders and development teams usually isn’t intentional, on either side.
Joe explains it plainly: business stakeholders and developers speak different languages. They come from different backgrounds, carry different vocabularies, and operate with different assumptions about what “clear requirements” actually means. The gap isn’t something either party is deliberately creating. It’s something neither party can easily see.
What makes it worse is that there’s a specific blend of skills—someone who can speak development and business fluently—that is relatively rare. Without that bridge, both sides can feel confident they are aligned while actually living in entirely different versions of the project.
This communication gap shows up across industries, not just in startups. Whether you’re building a
custom web application,
a mobile app, or a complex enterprise integration, the translation problem is universal. It’s one of the core reasons we’ve documented the
top ways apps and websites break down and why so many teams end up in expensive rescue situations. Projects never reach launch, budgets blow out, and teams burn out. The problem was never a technical one. It was a translation problem.
Why Software Projects Fail: Agile Is Not a Substitute for Discipline
Agile methodology is widely embraced, and for good reason. Iteration, continuous feedback, and incremental delivery all make sense in a world where requirements evolve and markets shift. Joe is not against agile. He follows it himself.
But he draws a sharp line between healthy agility and an agile excuse culture:
“You don’t want to be doing the monkeys on typewriters waiting for the novel to come out.” — Joe Hubert
When teams iterate endlessly without ever locking down the fundamental definition of what they’re building, iteration stops being a strength and becomes a symptom. The fourth sprint in a row to “get it right” isn’t agile discipline. It’s a scope problem wearing agile clothing.
The solution isn’t to abandon agile. It’s to pair it with rigorous scope management. At Technology Rivers, we’ve developed what we call an Agile Startup-Friendly Methodology: each sprint is run agile-style, but each sprint begins with a fully defined, end-to-end scope, with clear deliverables, agreed-upon features, and fixed costs for that phase. Founders always know what they’re getting and what they’re spending.
This same discipline applies whether you’re building an
MVP for a startup
or scaling a product beyond its initial launch. Joe validated this approach clearly:
“Scope management is key. You need an agreement that we’re not going to shoot for the moon all at once.”
Why Software Projects Fail: No Blueprint, No Business
When asked whether he has a diagnostic playbook for struggling projects, Joe walked through his go-to methodology: the use case narrative approach.
Rather than jumping to technical specifications or UI designs, he starts with a structured set of questions:
- Who are the participating roles in this system? (Not job titles, functional roles)
- What are the most important actions each role takes?
- What rules and behaviors govern each use case?
- How does the system respond at each step?
This approach produces a document that is both understandable to business stakeholders and actionable for developers. Business leaders can sign off on it because it maps to how they actually think about the product. Developers can build from it because it captures the behaviors, rules, and logic they need.
It’s the software equivalent of an architectural blueprint, and just like a blueprint for a house, doing this work up front prevents enormously costly rework down the line. As Ghazenfer put it during the conversation:
“If you’re building a house, how many times would you just start and keep changing? It’s going to cost you a ton of money and you still won’t get the house you want.”
We’ve written about this extensively in our post on why every software project needs a blueprint before development begins. The use case narrative approach Joe describes maps directly to what we implement in our product strategy and discovery process. It is also a key reason why teams that skip this step end up dealing with the most common categories of software project failure.
Why Software Projects Fail in the Age of AI: Vibe Coding Isn’t the End of Engineering
No conversation in 2025 about software development is complete without talking about AI. Joe’s take is both grounded and forward-looking.
When AI-assisted “vibe coding” tools first emerged, the hot take was that software developers were obsolete. Joe pushes back firmly on that narrative, not out of nostalgia, but out of experience using these tools and understanding their real limitations.
He uses a sharp analogy: if the chainsaw had been invented today, some commentators would be declaring that anyone can now be a lumberjack. The tool is powerful. But that doesn’t mean the expertise around using it safely, strategically, and at scale becomes unnecessary.
We’ve looked at this pattern closely in our breakdown of
4 ways vibe coding transforms how developers build software, and the conclusion is the same: these tools accelerate the front end of development but don’t replace engineering judgment on architecture, compliance, or integration. For teams building in regulated spaces, a
HIPAA-compliant AI app built with vibe coding still requires a proper engineering foundation underneath.
The current generation of AI code generation tools is built on language pattern recognition, predicting what tokens should follow other tokens. That is fundamentally different from how experienced engineers think, which is conceptually and architecturally. Until AI models move toward genuine conceptual understanding and rule-based reasoning, engineering judgment will remain essential. Joe put it plainly:
“There’s still going to be a need for software development. The AI is an assistant to developers, not a replacement.” — Joe Hubert
For founders who have built a proof-of-concept in Lovable or Replit and are now wondering why it can’t scale into a real product, this is exactly why. If you want a deeper look at how AI tools compare for real development work, our
breakdown of Cursor vs Replit vs Claude Code is a useful reference. Vibe coding gets you a concept. Real engineers get you a product. And if you’re curious about where AI is genuinely changing the economics of software delivery, the research on
generative AI and software development productivity is worth reading alongside Joe’s perspective.
Final Thought: Build the Relationship Before You Build the Software
Throughout the conversation, one theme runs beneath all the others: trust. Whether it’s the trust between a product leader and a developer, the trust between a manager and their team, or the trust a founder extends to their dev partner, the quality of the human relationship determines the quality of the output.
Joe summarizes it this way: build an environment where developers feel secure, respected, and genuinely supported, and they will give you everything they’ve got, especially when the technical challenges get hard.
This is the servant leadership model in action, and it’s as relevant in the era of
AI and machine learning development as it has ever been.
Watch the Full Episode
🎙️ Lessons from the Leap — Joe Hubert Episode
Connect with Joe on LinkedIn: search “Joe Hubert” (no numbers) and mention Lessons from the Leap when you reach out.
Working on a Struggling Software Project?
If you’re a founder, product leader, or entrepreneur dealing with a project that’s stalled, over budget, or simply not delivering what you envisioned, you’re not alone, and it’s not always the developers’ fault.
At Technology Rivers, we specialize in:
- Rescuing and completing
broken or stalled software projects - Helping startups and product owners build innovative
SaaS, web, and mobile apps - Process automation powered by AI
- HIPAA-compliant healthcare software development
We start every engagement with a Blueprint Process, a structured requirements phase that ensures everyone is aligned before development begins. No surprises. No wasted sprints.
FAQs
Why do most software projects fail?
According to Joe Hubert, most software projects fail not because of technical limitations, but because developers aren’t given sufficient guidance, detail, and direction. The communication gap between business stakeholders and development teams, often invisible to both sides, is the most common root cause. Our post on the
top software project failures and how to fix them covers the patterns we see most often.
How does agile methodology contribute to software project failure?
Agile doesn’t inherently cause failure, but misapplied agile, where endless iteration substitutes for disciplined requirements, can. When teams accept perpetual “not quite right” sprints as normal, it’s a sign that scope and requirements haven’t been properly defined upfront.
What is a use case narrative approach in software development?
A use case narrative is a structured way of documenting what a system should do by identifying user roles, the key actions each role takes, and the rules and behaviors that govern the system’s responses. It creates a shared artifact that both business stakeholders and developers can understand, sign off on, and build from. It is the foundation of the Blueprint Process described in
why every software project needs a blueprint.
Will AI and vibe coding replace software developers?
Joe Hubert’s answer is a clear no. Current AI coding tools are built on language pattern recognition, not conceptual engineering reasoning. They are powerful assistants for developers but are not substitutes for engineering judgment, architecture, compliance requirements, or systems integration work. See our
comparison of AI coding tools in 2026 for more detail.
What is servant leadership in software development?
Servant leadership in software development means putting the needs of your development team first, providing clear direction, psychological safety, and trust so that developers can do their best work. Joe argues that this approach produces more resilient, motivated teams that show up when things get hard.
