3 Common Leadership Mistakes That Slow Technology Adoption

Your team isn’t slow because the technology is hard. It’s slow because of the decisions being made above them, decisions that feel careful, responsible, even wise in the moment, and that quietly work as a brake.

That’s the uncomfortable part. When a new technology stalls inside a company, the instinct is to look at the tooling, the budget, the talent gap. But look at enough of these stalls and a pattern shows up, and it’s rarely about any of those things. It’s about how leaders react to a shift they can’t fully see yet, and three of those reactions show up again and again. Once you know what they look like, you can’t unsee them.

The ground moves fast now. ChatGPT reached 100 million users in about two months, the fastest a consumer product had ever grown at the time.¹ Enterprise use of generative AI roughly doubled in a single year, from about a third of organizations to two-thirds, and kept climbing.² The window between “interesting” and “everyone’s already doing this” used to be measured in years. Now it’s measured in quarters, which means the cost of a slow reaction isn’t what it used to be. Being careful is no longer free.

Three brakes, and three things to do instead.

Mistake 1: Waiting for certainty

You know the meeting. Someone brings a new technology to the table. The room nods, the potential is obvious, and then comes the question that kills the momentum: “Can we see the proof first? Let’s wait until it’s more mature. Let’s see how it shakes out.”

It sounds responsible. Nobody gets fired for waiting. But waiting for certainty in fast-moving technology comes with a hidden price tag: certainty and opportunity almost never show up at the same time. By the time a technology is proven beyond doubt, the advantage has already been captured by the people who moved while it was still ambiguous. You’re not avoiding the risk. You’re just trading the risk of moving early for the risk of moving late, and pretending only one of them counts.

The data on this gap is getting hard to ignore. A 2025 Boston Consulting Group survey of more than a thousand senior executives found that the companies pulling ahead on AI expected roughly double the revenue growth and forty percent greater cost reductions than the laggards. Only about five percent qualified as built for what’s coming.³ And though most organizations now use AI in some form, only a small fraction capture real bottom-line value from it.⁴ Put those two facts side by side and the picture is clear: the proof you’re waiting for arrives late, and it arrives for someone else.

This isn’t new behavior, just more expensive than it used to be. Everett Rogers, the scholar who essentially wrote the book on how new ideas spread, mapped the pattern more than sixty years ago.⁵ Every population of adopters splits the same way: a few innovators, then early adopters, then the early and late majorities, and finally the laggards. What leaders miss is that these aren’t personality types you’re born into. They’re positions you choose, meeting by meeting, through exactly the kind of “let’s wait and see” decision that feels so reasonable. Wait long enough for certainty and you’ve chosen the back of the line. You just didn’t feel yourself choosing it.

The fix isn’t recklessness. It’s changing what you’re waiting for. Amazon founder Jeff Bezos put it well in one of his shareholder letters: most decisions should be made with around seventy percent of the information you wish you had.⁶ Wait for ninety and you’re slow. And as he pointed out, being wrong is often cheaper than you think, while being slow is expensive for sure.

The move is to stop asking “are we certain?” and start asking “how cheaply can we find out?”

Run a small, reversible experiment. Give a real problem to a small team for two weeks. You don’t need proof the technology works everywhere. You need one honest test of whether it works here, and most of what you’re agonizing over is reversible anyway. That changes the whole calculation.

Mistake 2: Rewarding heroics instead of building systems

Every organization has its heroes. The engineer who pulled the all-nighter and saved the launch. The team that scrambled through the weekend and got the release out the door. And when they do it, you celebrate them, publicly and gratefully, because they earned it.

Then next quarter, the same fire. And the quarter after that. Why wouldn’t it happen again? You just showed everyone what gets rewarded around here.

This is one of the most expensive patterns in technology work, and it’s expensive precisely because it feels like the opposite. Heroics look like strength. What they actually signal is that the system underneath is broken, and that the organization has learned to paper over the crack with human effort instead of fixing it. Two MIT researchers named this the “capability trap” in a paper whose title says everything: “Nobody Ever Gets Credit for Fixing Problems That Never Happened.”⁷ Organizations reward the last-minute save over the quiet, unglamorous work that would have prevented the crisis in the first place. And because firefighting eats the very time you’d need to build the systems that stop the fires, the whole thing feeds on itself. Low capability creates fires. Fires consume the time you’d use to build capability. Around and around.

When it comes to adopting new technology, this is poison. New tools demand that people learn, experiment, and occasionally break things safely, and none of that happens in an organization where everyone is already underwater bailing. The heroes don’t have time to absorb anything new, because they’re too busy saving the thing they saved last month.

The engineering world actually solved a version of this, and the language is worth borrowing. Google’s site reliability engineers talk about “toil,” the manual, repetitive work that scales linearly as you grow and creates no lasting value. Their rule is blunt: keep toil under fifty percent of anyone’s time, so that at least half goes to building systems that make the toil disappear.⁸ As they put it, if a human has to touch the system during normal operation, that’s a bug. The broader research backs the instinct. The teams that ship fast and stay stable aren’t the ones with the most heroes. They’re the ones with the best systems: the automation, the documentation, the platforms that let ordinary effort produce excellent results.⁹ And the heroic-throughput cultures? They post the highest burnout and the most unplanned work. In LeadDev’s 2025 survey of engineering leaders and developers, more than a fifth reported burnout at critical levels.¹⁰ That’s not a durable way to run anything, let alone a team you’re asking to keep learning.

The fix is to change what you celebrate. By all means thank the people who saved the launch, then say, out loud and in front of everyone, “and now we’re going to fix the thing that required saving.” Reward the boring release that shipped on time because the system worked. Ask the better question after every fire: not “who saved us?” but “what keeps starting these fires?” Heroes are thrilling. Systems are what let you adopt the next thing without setting the last thing ablaze.

Mistake 3: Treating adoption as a project instead of a capability

This is the deepest one, and it’s the one almost nobody catches, because it’s disguised as good management.

When a new technology arrives, you tend to do the responsible thing. You charter a project, maybe even a transformation program. Budget, timeline, steering committee, a go-live date. The rollout happens, the box gets checked, and the team moves on to the next initiative. Clean, contained, done.

Except technology adoption doesn’t work like a project, and treating it like one is why so many of them quietly fail. A 2025 study from MIT looked at hundreds of enterprise AI efforts and found that roughly ninety-five percent were delivering no measurable impact on the bottom line.¹¹ Ninety-five percent. And the reason wasn’t the infrastructure, or regulation, or a talent shortage. The reason was a “learning gap”: the tools and the organizations around them didn’t retain what they learned, didn’t adapt, didn’t improve over time. They were built to be deployed, not to keep getting better. Elsewhere, the share of companies abandoning most of their AI initiatives jumped from seventeen to forty-two percent in a single year.¹² That’s what pilot purgatory looks like at scale.

Everything turns on one reframe.

Adoption is not something you complete. It’s a capability you build, a muscle for continuously absorbing whatever comes next.

And this isn’t a soft opinion. Management researchers have circled the same idea for decades under a pile of different labels: dynamic capabilities, absorptive capacity, organizational ambidexterity, the learning organization.¹³ Strip away the jargon and they’re all describing one muscle: the ability to sense what’s changing, take it in, and reconfigure around it, again and again. This capacity compounds. The more you’ve taken in before, the faster you can take in what’s next.¹⁴ That’s the real reason waiting hurts so much: every cycle you sit out is a cycle of capacity you never bank.

This is the difference between a project mindset and a product mindset. A project has an end. You finish it, close it out, celebrate, and walk away. A product is never finished. You keep making it better, or you watch it rot. Technology adoption is a product, not a project. Treat it like a project and it fails at exactly the moment it looks like it succeeded, because you can finish a project but you cannot finish a capability. You can only keep building it or let it atrophy. When the next shift arrives, and it will, the company that treated the last one as a one-time initiative starts from zero all over again. The company that built the muscle just flexes it.

The fix is to change the question you ask. Stop asking “when will this be done?” and start asking “when will we be better?” It’s a question you can ask over and over, precisely because it’s about improvement, not completion. Build the feedback loops that let the organization learn from each adoption and carry it into the next. Make absorbing new technology a standing capability with an owner, not a temporary project with an end date. It’s slower to feel like progress, and far faster to actually get there.

What this looks like on Monday

Three brakes, three releases. You don’t need a transformation program to start letting off the pressure. You need to change three habits.

Stop asking your teams for certainty and start asking them for the cheapest possible experiment. Trade the three-year forecast for a two-week test. Stop celebrating only the saves, and start celebrating, loudly, the systems that make saves unnecessary. The next time you thank a hero, commit in the same breath to fixing what made the heroics necessary. And stop treating each new technology as a project to finish. Treat your ability to absorb new technology as a product you keep improving. Trade “when will it be done?” for “when will we be better?”, name an owner for it, and give it a budget that doesn’t expire.

None of these are technology problems. They’re leadership habits, which is good news, because habits are yours to change. The ground is going to keep moving faster, not slower. The question isn’t whether your organization can keep up with the technology. It’s whether you’re the one holding it back, and whether you’re willing to take your foot off the brake.

Notes

1. ChatGPT reached an estimated 100 million monthly active users about two months after its November 2022 launch, making it the fastest-growing consumer application at the time (UBS analysis reported by Reuters, February 2023). It was later surpassed by Meta’s Threads. ↩

2. McKinsey, The State of AI (2024 and 2025 global surveys), which found regular use of generative AI roughly doubling year over year. ↩

3. Boston Consulting Group, The Widening AI Value Gap (2025), a survey of roughly 1,250 senior executives across nine industries. “Future-built” leaders expected about twice the revenue growth and 40% greater cost reductions than laggards; only about 5% qualified as future-built. ↩

4. McKinsey, The State of AI (2025). A large majority of organizations report using AI, but only a small share attribute meaningful earnings impact to it. ↩

5. Everett M. Rogers, Diffusion of Innovations (1962; 5th ed. 2003). The origin of the innovator, early adopter, early majority, late majority, and laggard curve. ↩

6. Jeff Bezos, 2016 Letter to Amazon Shareholders: “Most decisions should probably be made with somewhere around 70% of the information you wish you had… being slow is going to be expensive for sure.” ↩

7. Nelson P. Repenning and John D. Sterman, “Nobody Ever Gets Credit for Fixing Problems That Never Happened: Creating and Sustaining Process Improvement,” California Management Review 43, no. 4 (2001). The paper that named the “capability trap.” ↩

8. Google, Site Reliability Engineering (O’Reilly, 2016), Ch. 5, “Eliminating Toil”: the definition of toil and the 50% rule. ↩

9. DORA and Google Cloud, Accelerate State of DevOps reports. Delivery performance is driven by systemic capabilities (automation, documentation, internal platforms), and high-throughput-via-heroics patterns correlate with the highest burnout and unplanned work. ↩

10. LeadDev, Engineering Leadership Report 2025, in which 22% of 617 surveyed engineering leaders and developers reported burnout at critical levels. ↩

11. MIT Project NANDA, The State of AI in Business 2025. Roughly 95% of enterprise generative-AI pilots showed no measurable P&L impact; the report attributes the gap to a “learning gap” rather than infrastructure, regulation, or talent. (The figure measures bottom-line acceleration specifically and has drawn some methodological debate.) ↩

12. S&P Global Market Intelligence (2025): the share of enterprises abandoning most of their AI initiatives rose from 17% in 2024 to 42% in 2025. ↩

13. The four labels, in order: dynamic capabilities (David Teece; Teece, Pisano & Shuen, 1997, and Teece, 2007: sense, seize, transform); absorptive capacity (Wesley Cohen and Daniel Levinthal, 1990); organizational ambidexterity (Michael Tushman and Charles O’Reilly, 1996; O’Reilly and Tushman, Harvard Business Review, 2004); and the learning organization (Peter Senge, The Fifth Discipline, 1990). ↩

14. Cohen and Levinthal, “Absorptive Capacity: A New Perspective on Learning and Innovation,” Administrative Science Quarterly 35, no. 1 (1990). Absorptive capacity is path-dependent: a firm’s ability to absorb new knowledge depends on the related knowledge it has already accumulated. ↩