Standardize systems, not people

In January 1994, I attended a NEXTSTEP conference in Washington. One of the speakers was Paul Strassmann, a former Director of Defense Information for the United States government. The archived programme places his address on January 26, at the Sheraton Washington.¹

I remember his argument clearly. He described the battlefield as an exceptionally complex setting: decisions of life and death, an adversary potentially as capable as oneself, and a stream of information from satellites, cameras, communications and sensors. In that environment, gathering more data was not enough. The challenge was to identify, at the right moment, what mattered to the person who needed to act.

The example he chose stayed with me: HyperCard. At a conference devoted to NeXT, he cited this Apple tool to explain how a user could quickly define conditions and receive an alert when a relevant situation arose. This is my recollection of an address I attended, rather than a transcript of his words.

I had been enthusiastic about HyperCard myself when it appeared in 1987.² It opened up a possibility that seemed essential to me: people who were not programmers could build small applications. There were things to learn and limitations to accept, but users could already shape a tool around their own needs.

That memory came back to me as I considered what AI makes possible today. As custom software becomes easier to create, why shouldn’t an organization allow employees to design applications suited to the way they work, provided those applications respect its rules and information exchange requirements?

In “Software before the decision”, I explored how a lower cost of experimentation changes software development. The same shift could transform how organizations accommodate their employees’ methods. The question goes beyond usability: it concerns the value we place on individual contributions.

What needs to be shared

We first need to distinguish two ambitions that are often conflated. An organization can standardize the data, rules, controls and exchanges required for its collective work without requiring everyone to use the same interface or method. That common foundation supports consistency, security, traceability and fairness. Tools and methods can leave room for each person’s experience, abilities and circumstances.

In many organizations, software determines much of the working process: which screens to consult, the order of operations and the information brought to the foreground. This uniformity has real advantages. It makes training, technical support and continuity easier when a case passes from one person to another. Some actions also need to follow a particular sequence to ensure that cases are handled properly and fairly.

But a shared interface also makes choices for everyone. It favours one way of understanding a case and organizing attention. What suits one person can slow down another, even when both do excellent work.

One starts by reconstructing the chronology. Another compares a few indicators. A third looks for exceptions first, then works back to their causes. These differences can reflect experience, aptitude or a method worth preserving.

We have often accepted limits on that diversity for practical reasons. Developing and maintaining many versions of an application was expensive. A common interface was a reasonable compromise. Over time, however, that compromise can become an implicit view of work itself: if everyone uses the same system, everyone should work the same way.

Tools shaped around the work

AI creates an opportunity to reconsider that choice. Tools already allow someone to describe an application in ordinary language, obtain an initial version and refine it through successive exchanges.³ This does not automatically make the result reliable, but it lowers the barrier between a specific need and something that can be tried.

Imagine an employee who wants to see, whenever she opens a case, the four pieces of information she always checks and the three most recent interactions. She would also like an alert when something changes after an important step. Her colleague prefers a chronological view that highlights inconsistencies. A third needs a simpler presentation to meet her accessibility needs.

They could work on the same cases, with the same permissions, reference data and obligations, through different environments. The organization would retain a common definition of a complete case and a valid process. Each employee would have a more natural way of getting there.

To make this freedom possible, essential rules and controls must be enforced by the organization’s services, regardless of the screen being used. Application programming interfaces — APIs — provide access to those services under defined conditions. Personal applications can then arrange views, filters, alerts and certain sequences of work within that framework.

A person could choose how information is presented while retaining its common definition. They could add personal alerts and define their conditions while keeping mandatory alerts in place. They could organize their workflow while respecting the steps and controls required to handle the case.

Following an API’s format is therefore not enough. An application can exchange data correctly and still present misleading information, hide an exception or trigger an operation at the wrong time. Each application would need to be checked against what it displays and the actions it allows.

Modernizing without rebuilding everything

This architecture also offers an interesting path for existing systems. A mainframe can continue processing transactions while new interfaces provide access to its functions. Solutions such as IBM z/OS Connect already allow mainframe applications and data to be exposed through APIs.⁴

That does not mean every older system can remain untouched. Some require substantial work to make their functions accessible, separate business rules from screens or strengthen controls. But improving the working experience does not necessarily require rewriting the entire transaction system. We can preserve what works and invest in the ability to use it differently.

The cost of creating a screen is only part of the problem. Tools still need testing, maintenance, user support and adaptation when shared services change. An organization would benefit from providing approved components, a testing environment and common validation mechanisms. A personal view with read-only access does not require the same oversight as an application that authorizes payments.

IT teams would have a decisive role: building a framework that makes this autonomy workable. They could devote more effort to the quality of shared services and help employees create reliable tools. A reference interface would remain available for training, support and people who prefer it. Personalizing one’s environment should be an option, never an additional obligation.

Sharing ways of working

What interests me most is what this freedom might bring to light.

An experienced employee can sometimes recognize an unusual situation from a few clues that are difficult to express as a general procedure. By building a tool that brings those clues together, she could make part of her method visible and open to discussion. Colleagues could try it, discover its limits and adapt it to their own work. The organization would gain another way to share experience.

Organizations would need to resist the temptation to turn every good idea immediately into a new mandatory standard. A method can be excellent for certain tasks or people without being right for everyone. Its value would be judged through the quality of the work, mistakes avoided, cooperation and the service provided, beyond the number of cases processed.

The ability to shape one’s own tools has never entirely disappeared. Spreadsheets, macros and small databases are evidence of that. But these initiatives often remain fragile, dependent on a single person or difficult to integrate with official systems. AI could extend this capacity to create and help bring it within a shared framework.

A possibility we can choose

Revisiting Strassmann’s work, I found an echo of this idea. A 1993 research paper by Charles D. Miller describes his Shadow Warrior concept: personal software that would recognize a user’s habits and help them cope with their information-processing limitations. The same document also discusses a standard display intended to make training easier. Both goals — collective continuity and individual adaptation — were already present in the thinking of that period.⁵

Thirty-two years after that Washington conference, I recognize the enthusiasm HyperCard once sparked in me. AI could give new scope to the ability to build the tool one needs. Its value lies as much in the diversity of uses it makes possible as in the speed at which it produces code.

There is no guarantee that organizations will choose this direction. They could use the same technologies to prescribe every action more precisely. They could also recognize that part of their intelligence lies in the different ways their employees understand their work.

Standardize systems, not people: that would give this diversity a legitimate place in our computing environments, alongside the consistency that collective work requires. And it would make AI a means of strengthening each person’s distinctive contribution.

References