In the early days of business computing, stupid computer tricks appeared frequently in the popular press … stories like the company that sent out dunning notices for customers who owed $0 on their accounts. (Resolution: customers mailed them checks for $0 to cover what they owed.)

Somewhere in most of these stories was an obligatory explanation, that computers weren’t really the culprits. Behind any mistake a computer made was a programmer who did something wrong to make the computer do it.

Years of bug fixes, better testing regimes, and cultural acclimatization pretty much dried up the supply of stories like these. But we’re about to experience a resurgence, the result of the increasing popularity of artificial intelligence.

This week’s missive covers two artificial-intelligence-themed tales of woe.

The first happened as I was driving to a regular destination from an unfamiliar direction. My GPS brought me close. Then it announced, “Your destination is on your right.”

Which it was, only to take advantage of that intelligence I’d have had to make a 90 degree turn that would have had me driving off the shoulder of the highway and up a steep grassy slope, at which point I could hope I’d have enough momentum to knock down the chain-link fence at the top.

Dumb GPS. Uh … oops. Dumb user, as it turned out, because I’d been too lazy to look up my client’s street address. Instead I’d entered a nearby intersection and forgotten that’s what I’d done. So AI lesson #1 is that even the smartest AI will have a hard time overcoming dumb human beings.

The more infuriating tale of AI woe leads to my making an exception to a long-standing KJR practice. Usually, I avoid naming companies guilty of whatever business infraction I’m critiquing, on the grounds that naming the perpetrator lets lots of other just-as-guilty perpetrators off the hook.

But I’m making an exception because really, how many global on-line booksellers that have authors pages as part of their web presence are there?

I was about to point a new client to my Amazon author’s page, as he’d expressed interest, when I noticed an unfamiliar title on my list of books published: The Feminist Lie by Bob Lewis.

If you’ve read much of anything I’ve written over the past 21 years you’d know, this isn’t a book I would have written. Among the many reasons, I figure men shouldn’t write books criticizing feminism, any more than feminists should write books that explain male motivations, Jews should write books critiquing Catholicism and vice versa, or Latvians should publish patronizing nastiness about Albanians.

Minnesotans about Iowans? Maybe.

But I distrust pretty much any critique of any tribe that’s written by someone who isn’t a member of that tribe and who feels aggrieved by that tribe.

But some other Bob Lewis proudly wrote a book with this title, and somehow I was being given credit for it. Well, “credit” isn’t the right word, but saying I was being given debit for it might be puzzling.

In any event, I don’t think all of us named “Bob Lewis” constitute a tribe, and I want no responsibility for the actions of all the other Bob Lewises who are making their way through the world.

And yet, somehow I was listed as the author of this little screed.

Oh, well. No problem. Amazon’s Author Central lets me add books I’ve written to my author page. Surely there’s a button to delete any I don’t want on the list.

Nope. Authors can add and they can edit, but they can’t delete.

Turns out, an author’s only recourse is to send a form-based email to the folks who run Author Central to request a deletion. A couple of tries and a week-and-a-half later, the offending title was finally removed from my list.

And, I got an answer to the question of how this happened in the first place. To quote Amazon’s explanation: “Books are added by the Artificial Intelligence system Amazon has in our catalog when the system determines it matches with the author name for the first time.”

Artificial what? Oh, right.

Which leads to one more prediction. Whereas as of this writing “artificial intelligence” has some actual, useful definitions, within two years the phrase will be about as meaningful as “cloud,” because any and all business applications will be described as AI, no matter how limited the logic.

And, as in this case, no matter how lacking in intelligence.

Let’s see if we can pull this all together.

In recent weeks we’ve talked about teams and team dynamics. We’ve talked about the too-often perverse relationship between knowledge and certainty. We’ve talked about culture and how its self-reinforcing nature can result in appalling behavior just as it can help bring out the best in people.

Teams, as described here from time to time, are groups of people who trust each other, and are aligned to a common purpose.

Toss in some additional reflection and discussions with various correspondents over the past few weeks and it’s clear that while trust and alignment are important team-ness ingredients, they aren’t the whole recipe.

Another is interdependence. In the world of sports, members of baseball, football, and basketball teams depend on each other move-by-move to get the job done. Golfers competing in the Ryder Cup, in contrast, do root for each other, but don’t nudge the ball when nobody’s looking. Likewise tennis players in the Davis Cup who presumably don’t use mirrors to try to blind members of opposing teams from the stands.

The world of business can be even more extreme: Many companies pit members of the so-called “sales team” against each other in the quest to receive the sales incentives that only go to the top 10% of producers.

And some business leaders still buy into the old MBO (management by objectives) method of setting management goals, assuring that each manager will do whatever it takes to achieve his or her objectives whether or not it’s at the expense of other members of the “management team” trying to achieve their goals.

Does this mean the “sales team” and “management team” are only teams in scare quotes?

Not entirely, because of another ingredient of team-ness. That’s affinity – a shared sense of identity that’s independent of both trust and purpose. Independent, that is, except for a desire to beat other, competing groups.

Which gets us to culture. Shared identity can be and often is independent of trust and purpose. It’s never independent of culture.

Here in KJR-land our working definition of culture is how we do things around here. It’s the informal, unwritten rules the affinity group … the tribe … enforces far more strictly and ruthlessly than HR enforces any of what’s spelled out in the company’s policies and procedures.

Identity politics … tribalism, that is … isn’t limited to politics.

Because if it were, how would you explain soccer riots?

It’s time to connect all this theory to your work-a-day responsibilities as an IT manager.

As the golden rule of engineering is form follows function, start with what you want. I imagine that in most situations, most of the time, you want the men and women who work in your organization to accomplish important results.

Most of the time, they’ll accomplish important results more effectively as a result of teamwork than of working in isolation. So you need to encourage team-building in the trust-and-alignment sense.

But like it or not, achieving trust and alignment is hard work that requires constant, steady leadership. That’s in contrast to achieving an us vs them tribal sense of identity, complete with unwritten rules governing how we do things around here. You’ll get that in spite of your best efforts to prevent it.

What you can do, sometimes, if you’re lucky and the wind is blowing in the right direction, is to channel your employees’ natural tendency to form up into rival tribes, so tribal and team identities coincide, or at least overlap heavily.

It isn’t a perfect solution by any means. Yes, project teams that have a strong sense of tribal identity will work harder and collaborate better internally than employees assigned to a project whose sense of team identity is limited to trust and alignment to a common purpose.

But that same sense of tribal identity will make the team less likely to collaborate with other teams they think of as the them to their own us.

Is there anything you can do to limit the extent to which the tribes take over?

There is. You can keep projects short, so project-based tribes disband before their tribalism starts to dominate the cultural landscape. And, you can populate new project teams cross-functionally, redefining us and them frequently enough to break down tribal animosities faster than new ones can form.

Or, you can do what most managers seem to do: Hope for the best, complementing hope with an occasional lecture about how we’re all on the same team.

That’ll work well.