Blog

Posted on

Organizational Lag in AI Adoption Is Killing Faith-Tech Momentum—Here’s How to Fix It

Last spring, a faith-tech leader pulled me aside after a conference session and confessed something that stuck with me: “Half my team is using AI every single day. I found out from a Slack message two months ago. We still don’t have a policy.” She laughed, but her eyes didn’t.

Here’s a number that should stop you cold: 73% of workers in tech-driven industries have already adopted AI tools for personal productivity, according to a 2025 Gartner report. But only 22% of organizations in the same report have a formal AI strategy in place.

That gap isn’t just a statistic. It’s a momentum killer. Individual team members are racing ahead with AI, while leadership lags behind, leaving faith-tech orgs fractured and unable to harness the very tools their people are already using.

I’ve seen this firsthand in my work with global discipleship platforms and curriculum tools. The disconnect between ground-level adoption and organizational vision doesn’t just stall progress—it risks alienating your most innovative team members. If leadership doesn’t close this gap fast, we’re not just missing opportunities; we’re actively pushing talent and ideas out the door.

This is the foundational misread that causes product teams and ministry leaders to fumble AI integration. They assume adoption happens organically because individuals are already experimenting with tools like ChatGPT or Midjourney. But without a deliberate strategy, these efforts fragment, creating silos instead of synergy.

To frame this problem, I’m turning to John Kotter’s 8-step change management model. Kotter, a Harvard professor who’s shaped how organizations navigate transformation, argues that lasting change starts with creating urgency and ends with anchoring new practices into culture. His framework isn’t about tech—it’s about people and systems. And right now, faith-tech needs both to align around AI before the gap becomes a chasm.

The Data Gap Between Workers and Leaders

I’ve sat in planning meetings for digital ministry tools where team members are quietly using AI to draft content or analyze user data. They’re not waiting for permission. They’re solving problems in real time.

But leadership often doesn’t even know this is happening. In one project I worked on for a children’s ministry curriculum platform, volunteers were using AI to adapt lessons for their specific contexts. Meanwhile, the org’s executives were still debating whether AI was “safe” for their mission. The people closest to the problem had already moved on. The people with the authority to support them hadn’t.

This isn’t just a communication failure. It’s a structural one. Workers are moving at the speed of necessity, while leaders are stuck in analysis paralysis. The result? Duplicated efforts, wasted resources, and a creeping frustration among team members who feel unseen.

Kotter’s first step—creating urgency—cuts through this. If leaders don’t see the 73% adoption rate as a call to action, they’ll keep treating AI as a future problem instead of a present reality. Urgency isn’t about fear; it’s about recognizing that your people are already ahead of you and deciding to lead from the front rather than manage from behind.

Why Faith-Tech Struggles with Strategic Alignment

Faith-tech organizations face a unique hurdle in AI adoption. We’re not just building products; we’re stewarding missions. That sacred responsibility can make leaders hesitant, fearing that AI might dilute the human or spiritual elements of ministry.

I’ve felt this tension myself. When working on a global Bible engagement app, I wrestled with how AI-driven personalization might feel mechanical to users who crave authentic connection. It’s a valid concern—but it often morphs into a permanent barrier that stalls progress long after the concern has been addressed.

Here’s where Kotter’s second and third steps—building a guiding coalition and developing a vision—come in. Without a coalition of trusted voices across the org, AI initiatives get stuck in endless debates. Without a clear vision, every decision feels like a threat to the mission rather than an expression of it.

I’ve seen faith-tech teams break through this by tying AI directly to their core purpose. One team used AI to analyze user engagement patterns, revealing which devotionals led to deeper spiritual practices. That’s not tech for tech’s sake—it’s tech for mission’s sake. When the vision is clear, the resistance softens.

Building Urgency for AI Implementation

Creating urgency isn’t about hype. It’s about showing what’s at stake. In faith-tech, I’ve watched organizations lose ground to secular competitors because they couldn’t move fast enough on digital tools—AI included.

Take a sermon resource platform I contributed to. Volunteers needed quick, adaptable content for their 7-minute prep windows. AI could have streamlined that process, but leadership hesitated, citing budget and “fit” concerns. Meanwhile, users drifted to faster, less mission-aligned alternatives. The lag didn’t just slow them down—it redirected their people somewhere else entirely.

Kotter’s model pushes for short-term wins—his sixth step. Pilot an AI tool for a single pain point, like automating email responses for volunteer inquiries. Show the time saved and the feedback gained. These wins build momentum and prove the case to skeptics more convincingly than any strategy document ever will.

Urgency also means addressing the human cost of lag. When team members see their AI experiments ignored, they disengage. I’ve been in rooms where the most creative minds quietly checked out because their ideas never made it past the brainstorming phase. Leadership lag doesn’t just lose ground on AI—it loses people.

Anchoring change—Kotter’s final step—means making AI a cultural norm, not a one-off project. It’s not enough to launch a tool; you have to celebrate its impact, train your people, and bake it into how you operate. Only then does the gap between individual adoption and organizational strategy finally close—and stay closed.

Your Turn: Apply This Today

  • Survey your team this week to find out who’s already using AI tools—send a quick Google Form asking for specific examples and outcomes.
  • Schedule a 30-minute meeting with key stakeholders by Friday to share the 73% adoption stat and discuss what inaction costs your org in momentum.
  • Identify one pain point AI could solve—like content adaptation or user support—and commit to a 4-week pilot starting next month.
  • Form a small coalition of 3–5 team members from different levels to champion this pilot and report weekly wins to leadership.
  • Draft a one-page vision statement tying AI use to your mission—focus on outcomes like reaching more people or freeing up volunteer time—and share it at your next all-hands.
  • Celebrate early results publicly—email the team or highlight a success in a meeting—to build buy-in and show this isn’t a passing fad.

The 51-point gap between how many workers are using AI and how many organizations have a strategy for it is not a technology problem—it’s a leadership problem. And leadership problems, unlike server outages, don’t fix themselves. The faith-tech teams that close this gap won’t just move faster; they’ll move together, with their most creative people finally feeling seen, supported, and unleashed to build what the mission actually needs.

If you’re wrestling with AI adoption gaps, check out my posts on AI Code Generation Won’t Fix Your Ministry’s Tech Debt—Here’s What Will and Internal AI Tools Need a Product Mindset to Stick in Faith-Tech Teams for more on navigating these challenges with a mission-first approach.

I consult with faith-tech product leaders and ministry innovators on closing AI adoption gaps, aligning tech with mission, and building urgency for change. Let’s talk.

Posted on

AI Code Generation Won’t Fix Your Ministry’s Tech Debt—Here’s What Will

I got a message last month from a church tech director who was almost giddy: “Josh, we’re using AI code generation to clean up our entire legacy system. We’ll have our tech debt solved by Q3.” I’ve heard versions of this pitch a dozen times now, and every time, I feel the same mix of admiration for the ambition and dread for what comes next.

There’s a shiny new promise floating around tech circles, and it’s making its way into ministry and faith-tech spaces. I’m talking about the hype around AI code generation tools—think GitHub Copilot or ChatGPT spitting out code—like they’re the magic wand to erase your tech debt. Consultants and tech blogs are pushing this narrative hard, claiming these tools will let your small team “build faster” and “modernize legacy systems” overnight.

Here’s the hard truth: they won’t. For every line of code AI writes, it often introduces new bugs, dependencies, or complexity that your already-stretched team has to debug. In ministry contexts, where tech budgets are tight and volunteers often manage systems, this isn’t a solution—it’s a trap that piles on more accidental mess.

I’ve seen this firsthand. A church tech team I worked with got excited about using AI to rewrite an old registration system, only to end up with a half-finished codebase no one could maintain. The real issue wasn’t writing code faster; it was never defining what “done” looked like in the first place.

This is the foundational misread that causes product teams to chase tech debt solutions in all the wrong places. We think speed—more lines of code, quicker deploys—equals progress. But in faith-tech, where mission clarity and user trust are non-negotiable, speed without strategy just digs a deeper hole.

Let’s anchor this in a classic lens from software engineering: Fred Brooks’ seminal essay “No Silver Bullet.” Written in 1986, Brooks argued there’s no single tool or technology that can magically solve the inherent complexity of building software. He split complexity into two types—essential (the core problem you’re solving) and accidental (the mess we create through bad decisions or shortcuts). AI code tools, for all their promise, often amplify accidental complexity while ignoring the essential work of aligning tech with mission.

Why AI Code Tools Miss the Real Problem

AI code generation sounds like a dream for under-resourced ministry teams. You’ve got a legacy database for member management that’s clunky and outdated. Why not let an AI tool rewrite it in a modern framework?

The issue isn’t the code output; it’s the input. AI doesn’t know your mission priorities or the quirks of your user base—like the volunteer who only logs in once a month and needs a dead-simple interface. I’ve seen teams adopt AI-generated solutions that looked slick but broke under real-world use because they weren’t built with the end user in mind. The AI wrote great code. It just wrote great code for the wrong problem.

Brooks’ insight on essential complexity cuts deep here. The real problem isn’t that your code is old; it’s that your team hasn’t clarified what the system needs to do for your community. AI can’t solve that—it just papers over the cracks with new syntax.

I remember a project with a sermon resource platform where we had a sprawling backend that hadn’t been touched in years. The temptation was to throw AI at it for a quick refactor, but instead, we mapped out who actually used what features. Turns out, 80% of the code wasn’t even needed—AI would’ve just rebuilt the bloat faster. That audit alone saved months of wasted effort.

Accidental Complexity in Faith-Tech Stacks

Faith-tech and ministry products often inherit accidental complexity from years of patchwork solutions. You’ve got a donor management tool bolted onto a website CMS, with a mobile app that doesn’t sync properly. Each “quick fix” over the years adds friction that no AI tool can untangle—because the problem isn’t in the code; it’s in the decisions that produced the code.

Brooks warned that accidental complexity grows when we don’t address root causes. In my experience with a children’s ministry platform, we had a print-first UX that volunteers loved, but the backend was a nightmare of redundant scripts. AI could’ve generated cleaner code, but the mess wasn’t in the syntax—it was in undocumented workflows no one had revisited.

This is where faith-tech differs from Silicon Valley startups. Our users aren’t tech-savvy early adopters; they’re often volunteers with seven minutes to prep a lesson or update a giving record. Building more code, even with AI, doesn’t fix the friction—it just buries it under new layers.

I’ve walked through this with multiple teams. One church tried to use AI to modernize their event signup tool, only to realize post-launch that volunteers couldn’t navigate the “optimized” UI. The accidental complexity wasn’t in the old code; it was in ignoring the human element. They had traded one set of problems for a shinier but equally frustrating set of new ones.

Prioritization Over Automation

Brooks’ “No Silver Bullet” essay pushes us to focus on what’s essential, not what’s flashy. For ministry and faith-tech, that means ruthless prioritization over blind automation. Tech debt isn’t a coding problem; it’s a decision problem—and AI tools don’t make decisions, people do.

When I worked on a global discipleship app, we faced mountains of tech debt from years of feature creep. The team was tempted to automate refactoring with AI tools, but we stepped back and asked: What do users actually need right now? We cut features no one used and simplified the stack manually—hard work, but it stuck. A year later, the platform ran faster, cost less to maintain, and the team actually understood what they had.

Prioritization means saying no to shiny tools until you’ve defined your mission-critical outcomes. For a church tech stack, that might mean ensuring giving platforms are rock-solid before touching anything else. AI can’t make those calls for you; only your team can.

I’ve seen this play out with a small ministry team managing curriculum resources. They had a backlog of tech debt a mile long, but instead of automating fixes, they prioritized one thing: volunteer completion rates. By focusing on what mattered, they rebuilt trust with users—no AI required. The discipline to say “not yet” to automation was itself the most powerful tool they had.

This is the heart of Brooks’ argument. There’s no shortcut to tackling essential complexity. You have to do the hard work of aligning tech with mission, even when a tool promises to do it for you. And in ministry contexts, that alignment isn’t just good engineering—it’s an act of faithfulness to the people you serve.

Your Turn: Apply This Today

  • Map your tech debt this week by listing every system or tool your ministry or product uses—then mark which ones directly tie to your core mission outcomes.
  • Pick one high-impact area of tech debt (like a donor tool or event signup) and define what “success” looks like for users before touching any code.
  • Schedule a 30-minute team discussion to identify accidental complexity—look for features or workflows no one uses but everyone maintains.
  • Cut one unused feature or system this month; don’t refactor it with AI, just remove it and track if anyone notices.
  • Build a prioritization framework by ranking tech projects based on user impact, not ease of coding—use this to guide your next sprint or quarter.
  • Document one critical workflow (like volunteer onboarding) in plain language this week to expose hidden complexity no tool can fix.

Tech debt in ministry isn’t just a technical burden—it’s a weight that slows down the people doing the work. The path forward isn’t faster code generation; it’s clearer thinking about what your systems are actually for. Prioritize ruthlessly, design for your real users, and let that clarity guide every technical decision. That’s not a silver bullet, but it’s something better: a sustainable foundation that serves your mission for years to come.

If you’re wrestling with tech debt in your ministry or faith-tech product, check out my related posts on AI Is Breaking Faith-Tech Infrastructure — Here’s How to Build for Breakpoints and Mission-Aligned Governance: How Faith-Tech Products Stay True to Purpose Under Growth Pressure. Both dig into keeping mission at the center of tech decisions.

I consult with church tech leaders and faith-tech product managers on navigating tech debt, aligning AI strategies with mission, and prioritizing user impact. Let’s talk.

Posted on

Internal AI Tools Need a Product Mindset to Stick in Faith-Tech Teams

Picture this: a faith-tech product manager spends three months building an internal AI tool to streamline sermon prep for her team. The algorithm works beautifully in testing. On launch day, she sends an excited email to the whole staff. Two weeks later, exactly two people are using it—and one of them is her. Sound familiar?

A few weeks back, a faith-tech PM messaged me with this exact frustration: “Josh, we built an internal AI tool to streamline sermon prep for our team, but no one uses it. What did we miss?” My answer is straightforward—your tool isn’t failing because the AI doesn’t work; it’s failing because it wasn’t designed as a product with your team’s real needs and workflows in mind.

Internal tools, especially AI-driven ones, often get treated as side projects or tech experiments in faith-tech spaces. But if you want adoption, you’ve got to approach them with the same product mindset you’d bring to a customer-facing app. That means intuitive design, clear value, and alignment with your team’s mission—not just a shiny algorithm.

I’ve seen this play out in my own work on tools for ministry leaders. Build a functional AI widget without user-centric design, and it sits unused. Treat it like a product, and even non-tech staff start relying on it daily.

This is the foundational misread that causes faith-tech teams to fumble internal AI tools. They assume “if we build it, they will come,” ignoring the reality that even internal users need a compelling, frictionless experience. It’s not enough to solve a problem on paper; the solution has to feel indispensable in practice.

To unpack this, I keep coming back to Donald Norman’s design principles for usability. Norman, a pioneer in human-centered design, argued that good products don’t just function—they communicate their purpose and fit seamlessly into the user’s world. His framework, rooted in concepts like affordances and feedback, isn’t just for consumer gadgets; it’s a lens for why internal AI tools in faith-tech often fail to stick.

Why Internal Tools Fail Without Product Thinking

Most internal AI tools in faith-tech start with a noble goal—save time, reduce grunt work, or scale impact. Think of a tool to auto-generate discussion questions for small group leaders. Sounds great, right?

But here’s the rub: they’re often built by engineers or data folks who don’t live the day-to-day of ministry staff. The tool might spit out decent questions, but if the interface feels like a clunky spreadsheet or the output doesn’t match the tone of a pastor’s teaching style, it’s dead on arrival.

I’ve watched this happen with teams I’ve advised. One group built an AI to summarize sermon feedback from online forms. The tech worked, but the summaries felt robotic, and the staff had to spend more time editing than they saved. No product mindset—no empathy for the user’s real pain—meant no adoption. The tool wasn’t wrong; it was just never designed for the people who were supposed to use it.

Norman’s principle of “discoverability” applies here. If users can’t instantly see how to use a tool or why it helps, they won’t bother. Internal tools need to communicate their value from the first click, or they’re just expensive shelfware.

Designing AI for Non-Tech Ministry Staff

Faith-tech teams often serve users who aren’t tech-savvy—think volunteer coordinators or part-time pastors. I remember working on a curriculum platform where our core users were “7-minute volunteers”—folks with barely enough time to prep a kids’ lesson, let alone learn a new tool. That constraint shaped everything we designed, from button labels to the number of steps in any workflow.

AI tools for these folks can’t assume digital fluency. If your internal chatbot for scheduling requires a tutorial, you’ve already lost. Norman’s idea of “affordances”—design cues that hint at how something works—means buttons should look pressable, workflows should feel obvious, and jargon should be nonexistent.

I’ve seen a ministry team try an AI tool for event planning. The tech could predict attendance and suggest venues, but the dashboard was a maze of dropdowns and filters. Staff ignored it, sticking to their messy Google Sheets. Why? The design didn’t meet them where they were. The tool optimized for capability, not for the actual human sitting in front of it.

Contrast that with a project I supported where we built an AI assistant for sermon research. We made it as simple as texting a friend—type a topic, get bullet points. Non-tech staff loved it because it felt natural, not alien. Design for the user’s reality, not your ideal tech world.

Measuring Adoption Beyond Usage Stats

Faith-tech teams often gauge an internal tool’s success by raw numbers—logins, queries run, hours spent. But those metrics lie. A tool with high usage might still be hated if staff only use it under duress.

I’ve been in rooms where leaders celebrated “100% login rates” for an AI reporting tool, only to learn later that users resented every click. They complied because they had to, not because the tool helped. Norman’s feedback principle kicks in here—design must give users a sense of control and clarity, or it breeds frustration regardless of how often people open it.

On a project for a global discipleship app, we learned to track something deeper: completion rates. Did users finish the task the tool was built for? If our AI suggested devotionals but users dropped off before sharing them with their group, we knew the design failed somewhere. That single metric revealed more about adoption than any login dashboard ever had.

True adoption shows in qualitative signals too. Are staff mentioning the tool in meetings unprompted? Are they asking for new features? Numbers matter, but stories of real impact—how a tool saved a pastor an hour of prep—tell you if you’ve built something that sticks.

Norman’s lens reminds us that usability isn’t a checkbox; it’s the heartbeat of adoption. Internal AI tools in faith-tech need to be measured by how they empower mission, not just by how often they’re opened. Build for felt value, and the stats will follow—but more importantly, so will the people your ministry is trying to serve.

Your Turn: Apply This Today

  • Map your internal AI tool’s user journey this week by sketching out every step a non-tech staff member takes to use it—identify where they might get stuck or frustrated.
  • Interview three users of your tool by Friday, asking one question: “What’s the hardest part of using this?” Write down their exact words and brainstorm one design fix for each pain point.
  • Simplify one core feature of your tool by next Monday—cut out unnecessary clicks or fields so it feels as easy as sending an email.
  • Define a “completion” metric for your tool this month—track whether users finish the key task it’s built for, not just whether they log in.
  • Set up a 15-minute feedback session with your team in the next two weeks to hear unfiltered thoughts on what the tool does or doesn’t do for their mission.
  • Prototype a quick visual cue or tooltip by the end of the month to make the tool’s purpose obvious at first glance—test it with one user and iterate based on their reaction.

The internal tools that endure in faith-tech aren’t the ones with the most features or the most sophisticated AI—they’re the ones that feel like they were made for the people using them. When ministry staff reach for a tool without being asked, when they recommend it to a colleague, when they notice it’s missing on a day it’s down—that’s the goal. That’s product thinking applied to mission. And it starts with caring more about the person at the keyboard than the algorithm behind the screen.

If you’re wrestling with internal AI adoption or want to dive deeper into designing for faith-tech teams, check out my posts on AI Prototyping Without Mission DNA Builds the Wrong Product and The Complete Guide to AI Product Strategy for Faith-Tech and Ministry Leaders. They’ll give you more angles on aligning tech with mission.

I consult with faith-tech product leaders and ministry innovators on building internal tools with a product mindset, designing for non-tech users, and measuring true adoption. Let’s talk.

View all posts