When AI Fails, It’s Never the AI

If you’ve read any of the recent AI-adoption reports – the ones with ominous charts, jargon-heavy executive summaries, and the unmistakable whiff of “we swear we didn’t panic writing this,” you’ve probably noticed a theme: enterprise AI pilots are failing at an almost comedic rate. MIT claims something like 95% of generative AI pilots never translate into meaningful business outcomes, and McKinsey notes that while nearly everyone has launched a pilot or two (or ten), only a small fraction ever manage to scale beyond the “bright new object we showed at last month’s steering committee” phase.

None of this surprises me anymore, not because AI is flawed or overhyped or secretly plotting its inevitable victory over humankind, but because after more than a decade of consulting across dozens upon dozens of organizations, I’ve learned that most institutions are astonishingly consistent in one particular way: they struggle mightily to absorb the benefits of the very technologies they claim to want.

And I don’t mean the small benefits or the edge-case improvements; I mean the obvious, measurable, plain-as-day gains that practically beg to be captured.

I’ve seen organizations automate entire processes only to watch those same organizations slowly, almost lovingly, rebuild the manual steps they had just eliminated. It’s like watching someone clean out a garage, marvel at the newfound space, and then promptly fill it with the very same boxes they had pulled out, because “we might need these old light fixtures someday.”

The Gains Are Real; the Organization Is… Less Real About Them

Over the years, I’ve lost count of how many times a team has celebrated shaving hundreds of hours off a process, only to quietly reintroduce “just one more check” or “a backup spreadsheet, for safety,” or some legacy side-process that made sense in 2007 but somehow refuses to die, like an office plant no one remembers watering but that somehow thrives on fluorescent light and despair.

The funny thing is, everyone involved is usually earnest, well-intentioned, and genuinely trying to improve their institution. There’s no malice here, no plot to undermine progress; it’s simply that the structure of the organization is too rigid to metabolize the very efficiency it claims to pursue. So the efficiencies leak away. Slowly, invisibly, with no dramatic explosion, and over time, everything returns to a slightly more modern version of how it used to be.

This is the part of the reports that almost no one talks about:

AI isn’t failing. The organizations are failing to absorb what AI enables.

And I say that with no smugness whatsoever, because the pattern is so universal that it almost feels evolutionary, the sort of deeply embedded institutional instinct that resists change not because change is bad, but because change requires movement. And movement, it turns out, is surprisingly hard for systems designed to stay exactly where they are.


Not Built for Possibility

One of the quiet truths you discover when you work with enough institutions is that most modern organizations were never truly built for adaptability; they were built for stability, predictability, and, if we’re being brutally honest, the comforting illusion that the future will politely resemble the past if you schedule enough meetings about it.

You see it everywhere:

  • job descriptions that read like ancient tablets
  • approval chains that stretch into eternity
  • workflows fossilized under layers of “best practices” that were best around three administrations ago
  • committees that meet quarterly to decide whether a decision should be made by a different committee

And when AI arrives, the organization reacts the only way it knows how: it tries to domesticate it, shape it into the familiar, force it to behave like the old tools it replaced, and in general, treat it like a cute but slightly unruly intern rather than a fundamental shift in how work can be done.

The predictable result is that nothing truly changes.

AI produces possibility; the organization produces structure; and possibility loses, not through violence, but through paperwork.


The Pattern Under the Pattern

At some point in my consulting career, after watching yet another digital transformation wilt under a mountain of legacy process maps and nervous middle management, I realized there was a deeper dynamic at play. Something not quite about technology, and not even really about culture, but about what organizations find tolerable.

Here’s my working hypothesis, stated plainly:

Most institutions are far more comfortable living with chronic deficiency than enduring the temporary inefficiency required to become adaptive.

A person who is mediocre in a role they’ve held forever? The organization can navigate that with its eyes closed.

Moving that person into a new role because automation freed them up? Now we’re flirting with chaos.

Redefining responsibilities across departments? Chaos.

Letting go of legacy processes that once made sense but now actively sabotage progress? Pure, unfiltered chaos.

And faced with the choice between stability tinged with obvious deficiency or the messy middle of reconfiguration, institutions pick stability every single time. It’s the devil they know, the devil they’ve budgeted for, and the devil whose email signature matches the one in the HR system.

But the irony is painful: the inefficiency they fear is the thing that would make them adaptable.

It’s the slack required for learning, the oxygen needed for experimentation, the breathing space that allows a structure to shift. Without it, the organization becomes a beautiful, frictionless machine that cannot turn.


AI Isn’t Exposing Weakness; It’s Exposing Design

When AI pilots stall, it’s not because the model is bad or the data is messy or the vendor oversold their demo (though let’s admit, that last one does happen with the kind of frequency usually reserved for meteor showers).

It’s because AI reveals the tension between what an organization says it wants and what it is structurally capable of doing.

AI creates room, a space to imagine, space to reassign, space to reconfigure, and the organization, almost immediately, fills that room with the exact structures that made adaptation impossible in the first place. But it’s not sabotage – it’s muscle memory, inertia, comfort level. Whatever you want to call it.

Which brings me back to the reports.

When 95% of AI pilots fail to generate value, the story is not that AI is overhyped. The story is that organizations are still built for a world where technology creates efficiency, and they have no idea what to do in a world where technology creates possibility.


What’s Possible Will Always Be More Interesting Than What Exists

This is the part that has kept me fascinated for more than a decade: not the failures, not the regressions, not the slow slide back into familiar behavior, but the gap between what institutions do today and what they could do if they were designed for adaptability instead of preservation.

It’s in that gap, the quiet space between reality and possibility, that the real future of organizational life lives, and it’s the space where I plan to spend the next several years: researching, questioning, designing, and eventually helping build institutions that not only use AI but integrate it into the very architecture of how they think, decide, and evolve.

Because as frustrating as these patterns are, the possibilities sitting just beyond them are extraordinary, and as I’ve said many times in many contexts:

What’s possible is fascinating.

And right now, possibility is lapping at the edges of our institutions faster than they know how to absorb it.

Posted in Corporate Culture, Uncategorized | Tagged , , , , | Leave a comment

Funeral jokes and job interviews

Context is everything.

A funny story told at a funeral isn’t great. It’s a disaster.

The best storytellers know: it’s not about the story. It’s about the listener.

When hiring, let the applicant interview you first. Watch how they gather context. That’s the skill that matters. 

Then watch how they tell the story of them in your context.  Works wonders for sales interviews.

Because in sales, in marketing, in life: If you miss the context, you miss everything.

What context are you missing right now?

Posted in Random Thoughts | Tagged , , , , , | Leave a comment

The Vicious Circle of Commitment

I’ve observed that:

If there is no Commitment, there is no Availability

If there is no Availability, there is no Follow-Through

If there is no Follow-Through, there is no Ownership

If there is no Ownership, there is no Commitment

One can probably break this circle at any point, but we mostly like to dance around it.

In the end, it all starts and ends with commitment; personal or organizational Progress depends on it.

Posted in Corporate Culture | Leave a comment

Build vs. Buy is the Worst Possible Way to Frame That Decision

Why?  Because it represents a false dichotomy.

“Build” part of that equation implies that you are either starting from scratch, or at the very least, have a very long road ahead, wrought with long requirements sessions, prioritization arguments, and project delays and overruns.  It brings to mind images of 6 hour pizza-catered sessions, Gantt charts, and difficult conversations.  It comes with high support costs and staffing issues.  Ultimately, however, you will get something that meets your exact specifications.

On the other side, “buy” implies that you will get what you need out of the process.  Yes, there will probably be overpromising and underdelivering, and you will likely have to compromise on some things and sacrifice others, but at least you will get the very thing that will help you do your thing at the very end.   You can just pay for maintenance to some entity and they will deal with the headaches.

In what world are these two scenarios true?  Were they ever?

In my almost 25 years of IT, while I saw both “build” and “buy” efforts either phenomenally succeed or spectacularly fail, and eventually corner the company into some box, a way out of which was to do a costly and painful forklift.

Because change.

Taking into consideration the rapid pace of improvement in today’s technologies, and more importantly, the rapid pace of change in our customer’s needs and behavior, it is exceedingly speculative to guess what will be asked of our teams and technologies in a year or two.   And so when we develop our systems to meet our requirements, we are focusing on the needs of today and maybe, just maybe, give 5 minutes of thought to the future.  But historically, the future gets here sooner than we think, lagging ever so slightly behind now.

It’s all about platforms and accelerators.

No “buy” system will ever meet “now” needs fully or account for “future” needs completely.  No “build” project will deliver exactly what’s needed.  What it all comes down to, are two questions:

  1. How far towards achieving critical objectives and requirements can I go before I have to customize to meet remaining needs?
  2. Can the selected system support both getting up and running quickly, and customizing extensively?

“Buy” would likely get you pretty far towards achieving stated goals and objectives, but will likely limit how much customization you can make.  In fact, it seems that the closer you can get to meeting your immediate needs with a “buy” product, the greater the limiters on what you can eventually turn it into.

“Build” would most likely start out nowhere near stated goals and objectives, but will probably offer great customization opportunities.   It does come with increased support costs.

Picking the right platform and accelerator can give both – quick path towards launch plus ability to hold off the forklift for much longer.

So my argument is that it’s not “build vs. buy” decision, regardless of how snappy and easy saying it is. The whole thing should be framed as “how far towards my goals does this get me and can I drive myself afterwards?”

Posted in Information Technology | Leave a comment

Soviet Union, lapel pins, and gamification

Earlier today, a coworker of mine emailed me a picture asking if I knew what it was.  The picture was of a Swimmers Federation of the Soviet Union lapel pin.  It was fun to see such a trinket, and I responded to my coworker explaining what it was he just happened to find among things his Canadian mother had.  Along with that, I sent a picture of other Soviet lapel pins I had.  It’s a sorry collection, considering that I used to collect these pins when Iimage1 was a kid.  Considering the fact that I brought them all the way from the Soviet Union and they were preserved all this time, the collection is maybe not as sorry.

As I thought about how I’d explain the tremendous culture surrounding lapel pins in the Soviet Union, I had an epiphany.  The kind that maybe was not so startling to others, but in those 5 minutes, I had my mind completely blown.

Much is being said in the past 10 years about gamification.  Both the theory of gamification and the badging are now at the root of many product and service design concepts, especially those geared towards millennials.  It’s the latest motivator – complete three tasks and receive a badge – that should drive achievement.

Well, as I pondered explaining lapel pins to my co-worker it occurred to me that it was the very early iteration and application of the gamification concepts and badging.  Here we’re arguing about the value of gamification is a motivator, and we perhaps have the biggest experience already concluded, with certifiable results – ready to go.

Soviet Union was highly gamified society.  So many things we did were based on levels, and so many achievements awarded with lapel pins, medals, etc.

Sports – we all went to the same sports clubs, but those that were serious would follow a very structured rank system, akin perhaps to belts in martial arts: if you could demonstrate certain things in your particular sport, you’d be given a higher rank.  The awards for achievement of each rank were lapel pins.

Work – there were productivity goals, achievements of which would be rewarded with a particular lapel pin, and higher awards would be awarded with medals.  Schools are rank/grade based anyway, but military service – certain things you did, you’d get lapel pins, medals, and ranks.  Come to think of it, I find it hard to imagine what it was that wasn’t structured as a multi-tiered achievement ladder with badging as rewards for interim performance (hoping my friends can chime in here.)

I remember specific people that wore their 3rd rank in fencing lapel pins proudly, above their Young Pioneer lapel pins we were all required to wear (big no-no.)  I remember movies about calloused factory workers beaming with pride as plant manager affixed pins to their lapels signifying completion of 2000 widgets manufactured above the planned amount.

The thing I do not remember if it was ever as much of a motivating factor.  Hard to argue that for all of our gamification of an entire society, Soviet Union crashed and burned in the worst possible way, and we can argue that the issues that ultimately brought it down were beyond anything motivational lapel pins could overcome, but I simply have to question the wisdom of motivation with badging and gamification.

I don’t know if I have a larger point here.  Just thought I’d share my epiphany along with trying to revive this stalled blogging effort.

Posted in Random Thoughts | Leave a comment

Choices

“In life our first job is this, to divide and distinguish things into two categories: externals I cannot control, but the choices I make with regard to them I do control. Where will I find good and bad? In me, in my choices.” -Epictetus

Amazing how Hellenistic philosophy resonates in modern day business world.

We can’t control market conditions, vendor roadmaps, customer requirements, competitor actions, or executive whims.  What we can control is how much time we spend on thinking about what’s possible and how flexible and forward-looking our solutions are.  In that flexibility do we find the capacity to respond appropriately.

And the solution that was good at one point can become bad pretty quickly if it can’t adequately respond to an external factor.  The mark of a good solution is its ability to stand the test of changing, uncontrollable, external factors.

Posted in Information Technology, Quotes, Random Thoughts | Tagged | Leave a comment

Innovation vs. Improvement

Being on the Central time zone internally and Pacific time zone physically allows for waking up really early and pondering.  As I await the start of Salesforce Foundation’s Higher Ed Summit 2014 in Phoenix, I began reflecting on the few conversations I had with some of my colleagues regarding my last post, specifically the part about allowing customers to innovate being the only job of IT.

It became clear that what I consider to be innovation is not necessarily what others consider it to be as way too many people agreed with me, and in the meantime, I realized that I was too eager to publish my post and so was in error.

Ever since Apple began to dazzle us with their innovative prowess (and has since ceased to do so), innovation became this sexy term, much like leadership, that everyone began chasing after.  These two terms became the Holy Grail.  If a person or an organization was a leader, then it had to become innovative; if it were an innovator, then it had to become a leader; and if it were neither, then it had to become both, otherwise, it was doomed to fail (interesting to note here that I actually obtained a certificate in innovative leadership some years back.)

But as few people are truly innovative, the definition of innovation, IMHO, became deluded and first significant, then marginal, improvements became substitutes for true innovation.

To me, if your decision is supported by data, then you are not innovating.  The only data that can support true innovation, again IMHO, is that nobody else is doing it.  If you have data to support your decision, then you are making improvements.

Both of these, innovation and improvements, are hard.  Innovation requires tremendous comfort level with risk, and convincing of everyone, customers and team members, and potentially new ways of not only doing, but even thinking about things.  Improvement requires setting up the tools to  identify area of improvement, then convincing everyone that improvement is worthwhile making (had a discussion this week with a coworker who made the claim that everyone is convinced by facts and I actually laughed out loud), then actually making the improvement.  But they are worth doing, and they are not same things.  With that, I amend my IT mission statement to enabling our customers to improvement and innovate.

Posted in Information Technology | Tagged , , | Leave a comment

IT as an Impediment to Innovation

Over the past decade, much is being said about IT being the enabler of innovation within organizations.  I certainly am firmly in that camp.  In fact, I don’t view it as one of our jobs, to enable our customers to innovate, I view it as our only job.

But as I go around speaking to customers about our bright future with Force.com, a thought began to formulate in my mind.  It is something that I suppose I always knew, but only now does it begin to take shape into something I can actually state, and therefore, tackle.

If IT is supposed to be the enabler of innovation, then doesn’t that mean that the opposite is true as well?  That IT can be an impediment to innovation?  Lately, I find that it is exactly the case, and as I reflect back on my 19 year IT career, I find that to be the case universally.

Naturally, IT is not the only reason why companies do not innovate.  But sometimes, just sometimes, we have a much greater impact than we think.  And our obstructionism occurs in roughly two ways.

First way is by erecting a direct barrier – we just say no.  When our customers come to us and ask us to do something, we say we can’t do it, or we won’t do it, or we can’t do it now, but we say no.

Most certainly, the reasons for us saying no can be very valid, and they all boil down to us not having enough resources to satisfy every request.  On my awesome web team, we have departments lining up out the proverbial door but virtually every request that comes in now will have to go into a 6-9 months waiting list because we only have so many project managers/developers/content editors.  Years ago, I remember sitting in a meeting where one of the floor traders was trying to pitch an idea to allow the company’s customers to make their own trades through computers, and the IT director shut it down because the technology to implement such a capability was too new, too risky, and would “break a lot of existing things”.   In only 2 short years, online trading exploded.

We say no.  Sometimes we really want to say yes but can’t; and sometimes, we truly believe that no is the right answer, but we say no, and so put up a barrier to innovation.

The second way we impede innovation is more subtle, and far more evil.  Not meaning to compare our customers to elephants, but I’m reminded of the experiment where if you keep an elephant tied to a pole long enough, pretty soon you can remove the rope and the elephant will never leave the vicinity of the pole, to the point of dying of hunger.

After constantly being forced to say no to customer requests, what I find is that we actually condition our customers to temper their outside the box thinking.  They already know what our limitations are, because we keep talking about them as justifications for our nos.  And so when they think of how they can improve their business, they inevitably self-sensor.  I often hear that in meetings “that’s a great idea, but IT can’t do it” at which point we solemnly nod and inwardly pat ourselves on the back for doing a good job of marketing what we do and how we do things.

Two things are important to note here.

IT is not the only group that does this.  How many times have you said: “yes, I’d like to be able to do this, but legal/accounting/HR/Marketing won’t allow it or will make it difficult, so I won’t even try it?”

Also, the inevitable argument that customers still bring all sorts of requests to us means that we’re not as bad as I think we are.  My only response to that is customers are not bringing us innovative ideas.  They bring us pain points that came to the point of where they don’t want to deal with them, or they heard somewhere that someone else solved it.  In other words, they come to us out of necessity.  They bring their wacky problems and make outrageous requests just to help them get their job done, which to me is not at all the definition for innovation.

This creates a problem where whenever anyone is asked to think about creating a truly innovative idea, they self-sensor because they have been conditioned to do so by IT/HR/legal/accounting/Marketing/etc.

As I find that virtually all of the readers of my blog are people with whom I interact on regular basis, I look forward to hearing what you think about this.  There isn’t much we can do in the near term about other departments (except to show them how it’s done), but there is something we can do about us being the impediment to innovation. Because if we can have a discussion about IT’s role as enabler of innovation and if we should strive to be that, but it is undeniable to me that the role we do assume is one of a barrier to innovation.

As Eldridge Cleaver said: “There is no more neutrality in the world. You either have to be part of the solution, or you’re going to be part of the problem.”

Posted in Corporate Culture, Information Technology | Tagged , | Leave a comment

Preparing for different types of innovation

Yesterday, while attending a webinar, I heard something mentioned that struck a note with me. The speaker said that it is our job, as IT professionals, to support innovation. The statement of course makes sense and is inline with what I view our jobs to be, but hearing someone else say it made me ponder what exactly does it mean – to support innovation, in practical terms.

And while I can’t yet organize everything I thought of relating to this, what I did start to organize is the directions from which innovation can come. What I observed is that even if we do prepare for innovation, it is usually from only one or two of these directions, and ultimately end up blindsided.

So without any further ado, here is the list. Would love to know what my small band of forced followers think about it.

  • IT department innovation – innovation within our own department, new way of looking or doing things, that are largely confined to just us, the IT department within the organization.
  • IT industry innovation – innovation within our profession, although we haven’t seen true innovation in a long time.
  • Business innovation – innovative ideas and concepts initiated by the organization we support.
  • Industry innovation – innovation started by someone else within the same industry we’re in.
  • Customer innovation – innovation on the part of the customers our organization serves.
Posted in Information Technology | Tagged , , | Leave a comment

The Agile Triangle

I have recently been thinking about this whole concept of Agile, and how to best transition from the “old and tired” to the “new and exciting”.   In other words, how to take the best of what agile has to offer and implement it into our professional, and even personal, lives.

For one, there are clear advantages to embracing the agile mindset, even if all of its tools and approaches may not be applicable.  To be more nimble, personally and organizationally, and facing the inevitable change with an open and ready mind is a survival skill, again personally and professionally.

So I began to think about what’s needed for a person or an organization to become “agile”.  As my thoughts began to take shape, I also came upon the need to convey the concept to my project management students.  In preparation for the class, I finally came up with a model that I think works well.  And so, an Agile Triangle was born.

The Agile Triangle

Agile triangle

The way I see it, you need three things to be agile – Agile Team, Agile Customers, and Agile Situation.  The reason why the triangle works for me is that it’s reminiscent of the PM’s triple constraint triangle – I see it working in roughly the same way.

The Agile Team

What I am essentially saying here is that for an agile environment, the project team must have an agile mindset.  In broad strokes, it means they should be open to change.  Getting down to the team level, that may mean different things and different tools may be used to achieve that agility, but at its core, the team must display the qualities, and reflect the values, of agile manifesto.

This also works for personal agility – whatever qualities an agile team possesses, they can also be applicable to an individual.  In fact, if the individuals within the team are not agile, the team will likely suffer from low agility.

The Agile Customers

This one is easy to understand, but for most teams, I find, is the one considered most difficult to achieve.  It essentially means that the customer must also have an agile mindset, and most importantly be willing to work with the team in an agile way.

The Agile Situation

I have been going back and forth with this, not knowing if I wanted to call this situation, or solution base, but what I am essentially saying here is that the thing you are engaged in must be agile-friendly.  That means the project must be agile-friendly (how do you organize an event in an agile way?), the tools you have must be agile friendly (sculpting a statue from 100 ft piece of granite is probably not going to give you much agility), and so on.

Triple Constraint

Much like the PM’s triple constraint triangle, I believe this triangle works in exactly the same way – if one of the areas of the triangle is less agile, then at least one other area, and possibly two, will have to be more agile to make up for it.

While I continue to refine this model, what do you think about it?  Like, no like, hmm, meh, etc?

Creative Commons License
Agile Triangle by Vadim Gorelik is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.

 

Posted in Information Technology | Tagged , , | Leave a comment