A recent story in BusinessWeek caught my eye. It dealt with allegations that Apple, Intel, Adobe, and Google had colluded to control the compensation of software engineers and programmers by agreeing not to raid one another’s staffs, even going to the extent of having written agreements to this effect. A class-action suit brought by 64,000 engineers and programmers resulted in a settlement of $324 million for the plaintiffs — hardly damaging to these giant firms (it represents 0.4% of their valuations), but certainly a sign that technologists are a rare commodity worth fighting for.

This has some bearing on our own experiences with technology, which continue to be underwhelming, especially as platform providers attempt to be “one-stop shops” for our technology needs, and we continue to have the expectation that they can be. I can’t visit another publisher or talk with a colleague without the topic arising — we don’t have enough platform providers to choose from; those we have are too limited or difficult to work with; option A is good at this, but not good at that, while option B is good at that but not at this; and we want everything at prices our mostly non-profit firms can afford.

Of course, these complaints are rife with contradictions. We want unlimited horsepower at low prices; we want more platform provider options but a “one-stop shop”; and we want them to be both unlimited in their scope and simple to work with.

Our customers provide fuel for these contradictions. They want journals to be cheaper, believe technology is inexpensive to build, operate, and maintain, and compare us to multi-billion-dollar firms and their technological capabilities (“Can’t you just do it like Amazon does?”). Even with resources essentially semi-pooled at the platform providers, we don’t have anything approaching the kind of financial heft needed to meet these expectations. As noted above, even the multi-billion-dollar firms have been caught capping and trapping expensive engineering and programming talent.

One response to the situation has been for publishers to hire staff to deal with technology, but these publishers seem to have one of two experiences:

• They have a hard time hiring qualified technology people, underscoring the experience their platform providers must be having
• They hire people who are good at dreaming up and/or describing requirements, but don’t prioritize or winnow their demands to a few key initiatives, which only exacerbates the problems associated with limited bandwidth while also clogging deployment channels

This latter problem bears some examination.

There is a good deal of workplace credibility to be gained by establishing yourself as extremely persnickety about interfaces, user flows, online design, online functionality, and so forth. Yet, often these same people are not asked to justify their demands in economic or financial terms — i.e., is there a practical difference in getting it “just right” by their standards? More importantly, they are not asked to justify their demands in terms of actual user needs or desires.

Search engines provide a good example of this kind of behavior. They are a special magnet for unique demands and idiosyncratic expectations, for many reasons.

First, search engines are at the nexus of the problem of input/output (or GIGO–Garbage In Garbage Out, otherwise known at help desks call “the PICNIC problem” — Problem In Chair, Not In Computer [also known as the “I.D. 10T” problem]). This refers to those users who put in search queries that nobody with any facility with searching would ever enter. In most search engines, less is more. But some users will enter what they think was the full title of the article, something that often sends a search engine into tailspin, especially if conjunctions and articles are included, and if the internal logic is “or” instead of “and.” Or they will enter punctuation, extra spaces, or typographical errors. Even after doing so, any substandard result is the search engine’s fault. Maybe so. But worse, any frustrating experience becomes an excuse for that person’s inner dramatist to emerge, and for a number of vague requirements to stream forth. Woe to the online development crew who has a person of influence who has these habits and takes a shine to the task of “getting it right.”

Second, there is the vanity problem, which invariably leads to authors searching for themselves and being disappointed when the results are either incomplete or overly inclusive (many search the references as well as the author fields). Glaring problems can occur for a few reasons. In some papers, authors were listed by initials, but by full name or some combination in others. In some cases, authors were acknowledged outside the actual authorship line, so they were not included as authors per se, but still feel they were authors. In other cases, search engines crawl references to return papers that include mention of the name being searched, believing this to be a service. In one memorable case, the author in question realized that, whoops, he hadn’t published in the journal he was searching, but in one with a very similar name. No matter what, it’s a problem with the search engine.

But is it worth fixing, in an era where most article searching comes from outside your own site?

A third situation that can arise with search engines is that editors have editorial ideas about how search engines should parse responses into certain conceptual bins or linked zones they can imagine. These ideas can be compelling for the editors involved, but a quick dose of user testing or a guided session of prototyping often breaks the spell.

Pick your technological mire — video players, audio players, article displays, home page designs, tablet versions, mobile designs — it doesn’t matter. In any situation, we mostly encounter a two-sided problem — publishing staff members who gain rewards and recognition by pushing technology into a more perfected state, and technologists who are spread too thin, are hard to find, and who are expensive.

Clearly, this can cause discord, just as any situation where the expectations are far greater than the other party’s ability to deliver. And when it comes to centralized services like platform providers, it can lead to finger-pointing or hard feelings, which often makes the relationship all about the relationship, and less about the customer and the business.

Our technology partners and providers can and often do find ways to improve offerings and increase our capabilities, and many provide great custom offerings. I think this is because they, like many of us, find the rewards of mission-related work in the sciences elicit dedication and strong contributions. In short, we give more because we care, and we get more because they care.

But when multi-billion-dollar companies are so protective of their software engineers and programmers that they basically agreed to a four-company “no touch” policy, it’s no surprise that our little online publishing industry has a difficult time finding the talent to do complex engineering and software development work at reasonable prices. Remember, we’re an industry in which 81% of the companies have less than US$25 million in annual revenues. There are very few companies in our industry that can afford champagne solutions. Heck, even Apple and Google were trying to keep things affordable by colluding to keep their technologists captive.

There are three solutions I’ve found that work — first, focus on the revenue-generating aspects of your online properties, not on the aesthetic or technical aspects; second, supplement platform providers with other providers to compensate for the inevitable gaps these providers will have; and, finally, test ideas with users beforehand, because often the idea you find so appealing will fall flat with actual users, making blind pursuit of it an exercise in futility.

Technology is one of the most difficult things to manage in the modern publishing organization, a moving target with an evolving ecosystem of standards, expectations, and possibilities. It is also something not many customers are willing to pay for. Managing all three of these within budgets that are nowhere close to limitless is, to me, part of managing technology relationships — when resources are stretched thin and the stakes can easily be made to seem higher than they are.