The operating condition: deciding where technology belongs

The condition around the work matters as much as the task.

I have spent 25 years working with technology in businesses that sell complex products, operate physical systems and carry consequences when information arrives late. The industries have ranged from oil and gas to pharmaceuticals, telecommunications and manufacturing. Each field uses its own language. The operating pattern underneath the work is easier to recognize.

A task never sits alone. A person owns it, other people depend on it and information moves through a collection of formal and informal steps. The team works within customer commitments, budgets, equipment limits and deadlines. Technology enters that condition. It does not replace it.

I use the term operating condition for that complete setting. It includes the people, process, information, tools and consequences around a piece of work at a given time. A solution fits when it improves the condition without creating a larger burden somewhere else.

Owners can use that question before they discuss software categories. It keeps the conversation attached to the business. It also creates room for an answer that costs less than the product under consideration.

Read the job at its edges.

Process diagrams tend to show the clean centre of the work. The cost often sits at the edges: the email that arrives without a job number, the spreadsheet someone keeps because the system lacks one field, or the customer promise that changes after the formal approval.

I start by following one real example from the moment it enters the business until someone considers it complete. The person doing the work can show where they wait, search, copy, interpret and check. Their workarounds deserve attention. A workaround may protect the business from a limitation that the official process ignores.

A useful baseline comes out of that observation. Count preparation time, corrections, waiting and missed work. Record enough examples to see the normal path and the awkward one. You do not need months of analysis. You need a picture accurate enough to stop the project from solving an imaginary version of the job.

The right intervention may be smaller than the proposed system.

Technology projects often begin with a category: CRM, workflow platform, AI assistant or custom application. I prefer to earn the category after we understand the operating condition. Five moves cover most of the first decisions I encounter.

Remove the step

Some work exists because an old system once needed it. A team may copy information into a report that nobody uses, collect approval twice or maintain a spreadsheet beside a platform that has since changed. Removing the step costs less than automating it and leaves less to maintain.

Clarify the process

A clear trigger, owner and definition of complete can solve a surprising amount of delay. This work feels basic, yet it gives any later system a stable process to support. Teams should know who acts when information is missing and which decisions need escalation.

Connect the information

Many businesses already own the right systems. The gap sits between them. A focused connection can move an approved record, create the next task or assemble a review packet without replacing either product.

Automate the rule

Conventional automation works well when the input is structured and the decision follows a stable rule. It runs fast, behaves the same way each time and remains easy to test. AI adds little when a deterministic rule can do the job.

Give an agent a bounded job

An AI agent earns a role when the work requires interpretation across emails, documents or conversation. The agent can gather evidence, compare it with approved criteria and prepare a next step. A person should still own commitments, material exceptions and decisions with serious consequences.

A single process may use more than one move. The team might remove a duplicate approval, connect two records and ask an agent to prepare the exception summary. The architecture follows the work instead of forcing the work into one product.

The exception path reveals the quality of the design.

A demonstration shows the clean example. Monday morning supplies the customer who changed the order, the missing attachment and the employee who knows that one plant uses a different code. The system has to preserve enough context for someone to handle those cases without starting over.

I ask teams to bring the examples they warn new employees about. Those stories show where judgment lives and where a system must pause. They also show which information deserves structure. If three experienced people resolve the same exception in three different ways, the business may need a policy decision before it needs software.

AI makes this discipline more important. A fluent answer can hide missing evidence. A useful agent names the gap, shows the source and routes the decision to the right person. Confidence should come from the design of the workflow, not from the tone of the generated sentence.

Teams need a recovery path as well. If a connection fails, a source conflicts or the agent cannot classify the request, the person doing the work should know what happened and what to do next. A blank screen or silent failure transfers the system’s problem to the employee.

A stable first release completes one useful job.

Small businesses cannot carry a technology program that takes a year to produce its first result. A better first release handles a defined piece of work from trigger to review. It serves a small group, uses limited access and runs beside the current method long enough to compare the two.

The word small describes scope, not ambition. A narrow release can still prepare a complete sales opportunity, route a service request or assemble a supply-chain decision packet. The business should receive something it can use even if it chooses not to expand the project.

• Name the person who owns the result.
• Choose real examples that include awkward cases.
• Limit the data and actions to what the first job requires.
• Record preparation time, corrections and missed items before the change.
• Agree on the condition that would cause the team to stop.

That final point protects the budget. A pilot deserves a stop condition as much as a success measure. If the work changes too often, the data proves unreliable or the users spend more time correcting the output, the business should reconsider the intervention.

A first release that proves its value creates a stronger second decision. The team can expand from evidence, improve the controls and add access in proportion to trust.

Ask operating questions before technology questions.

An owner does not need to design the system. The owner does need enough clarity to judge whether the project fits the business. I would start with these questions in the first conversation:

1. Which piece of work creates the most repeated delay or rework?
2. Who owns the result today, and who handles the exception?
3. Which information does the team trust?
4. What would improve for the customer or the employee?
5. How will the business compare the new condition with the old one?

Those questions support a software purchase, a custom build or a process change. They also make it easier to decline technology that solves a cleaner problem than the one your team faces.

Main Sequence exists to do that work with you. We can follow the job, identify the intervention and build a first release when technology belongs in the answer.