Your Technology Is Only as Simple as Your Business
Growth changes how a company works. New products appear. Regions develop their own processes. Functions add approvals. Acquisitions bring different systems, terminology, and reporting structures. What began as a relatively simple business gradually becomes harder to explain.
Some of that complexity is necessary. A global company cannot operate like a small local business. But leaders often confuse scale with complication. They assume that every process, exception, handoff, and local variation must remain simply because it exists today. That becomes a serious problem when the company introduces foundational software.
I noticed this most clearly while working at Microsoft and Critical Manufacturing, an MES software company. Both sell technology that sits inside the way a business operates. That experience was different from my earlier career at industrial automation companies, including Keyence, Rockwell Automation, Festo, and Omron. In those roles, customers were often buying a specific device for a specific task. A sensor detected a part. A controller ran a machine. A pneumatic component moved an actuator. A vision system inspected a product. The application could be technically difficult, but the purpose of the device was usually clear and contained. Foundational software is different because its boundaries are much wider.
Foundational Software Forces the Business to Make Decisions
Not all software creates this problem. A narrowly focused application may perform one task without forcing the company to rethink how it operates. But ERP, MES, PLM, SCM, CRM, data platforms, and workflow systems coordinate work across people, functions, and locations. To configure them, the company must answer basic questions. What is a customer? When is an opportunity qualified? Who can release a production order? Which product version is current? Which approvals are required? When leaders do not provide clear answers, implementation teams usually preserve every existing variation. Each plant, region, or function submits its own requirements, and the software is configured to support all of them.
MES: Preserving Every Plant’s Process
Imagine a manufacturer implementing an MES across six plants. One plant requires four approvals before a production order begins. Another requires two. A third allows a supervisor to release it verbally and update the system later.
One plant defines a batch by production date. Another uses the material lot. A third relies on a spreadsheet maintained by a planner who understands all the unwritten exceptions. The company can either decide how these processes should work across the business or configure the MES to preserve every local method. Preservation is often easier because no plant has to change and no leader has to choose.
The result is a system filled with conditional rules, alternate approval paths, overrides, and links to older databases. The MES may work exactly as specified, but the company has rebuilt several inconsistent operating models inside one platform.
Microsoft: Better Search for Poorly Managed Information
I saw a similar pattern at Microsoft around collaboration, document management, data, and business applications. A company might say employees cannot find information and ask for better enterprise search. But the real environment may contain seven document repositories, duplicate files, inconsistent security settings, and no clear owner for published information. The problem is presented as search, but the company has never decided where documents belong, which version is authoritative, who maintains them, or when obsolete content should be removed. A better search tool may make more information discoverable. It does not fix poor information management. The software is simply exposing the environment the company created.
CRM: Automating Disagreement About Sales
The CRM example is one I particularly appreciate because I have spent much of my career in sales. I understand that selling is not perfectly linear. A major strategic opportunity does not develop like a small transactional deal, and some opportunities emerge before a formal budget exists. But legitimate variation can become an excuse for avoiding basic agreement.
One business unit may define a qualified opportunity as any customer showing interest. Another may require budget, a decision-maker, and a timeline. A third may not create an opportunity until it receives a formal request for quotation. Leadership then asks why it cannot trust the pipeline. Instead of agreeing on one definition, the company adds more stages, custom fields, regional rules, and dashboards. Salespeople enter placeholder data, while managers return to spreadsheets because the official reports do not reflect how they view the business.
The CRM did not create the disagreement. It exposed that the company never decided what an opportunity is, when it becomes credible, or what information is needed to forecast revenue. This is how technology becomes overcomplicated. Every unresolved business question becomes a field, workflow, integration, approval, exception, or piece of custom code. The system becomes harder to use and maintain because it was built to preserve conflicting processes rather than replace them with clear decisions.
Why Simplification Is a Leadership Responsibility
When a business becomes difficult to manage, technology is often treated as the answer before leadership has clearly defined the problem. A new platform, automation program, data environment, control system, or AI initiative promises to connect the pieces, remove friction, and make the organization easier to run. Sometimes it can. But technology cannot decide which parts of the business should remain different, which should be standardized, or which should disappear entirely.
Without that discipline, the project begins absorbing everything it encounters. Every regional preference becomes a requirement. Every historical exception gets preserved. Every department insists that its process is unique. The organization says it wants transformation, but the project team is instructed to reproduce the existing business with as little disruption as possible. The result is often a highly customized technical solution that costs a great deal, changes surprisingly little, and becomes harder to maintain with every future update.
I think leaders underestimate how directly business ambiguity gets transferred into technology. It does not remain an abstract disagreement in a conference room. Confusion over ownership becomes permissions, interfaces, and duplicated responsibilities. A lack of agreement on process becomes alternate workflows, parallel automation paths, and different operating logic by site or region. An unresolved definition becomes another data field, status, calculation, report, or control rule. Before long, the technology is not complicated because the capability itself is unusually advanced. It is complicated because it has been asked to carry several versions of the business at the same time. Then everyone starts treating the complexity as though it originated in the technology.
That is the part I find most interesting. A company can spend years creating inconsistent processes, unclear ownership, and competing definitions, then become frustrated when a technical system reflects them. The technology is criticized for being too rigid when it requires a decision, then criticized for being too complicated when it is customized to avoid one. It is blamed for failing to change the business after being designed specifically to preserve it.
There is a narrow path between forcing false uniformity and preserving every inherited difference. Finding that path requires a deliberate strategy before the technical design begins. Leaders have to decide what the company is actually trying to improve, what must be common, where variation creates real value, and what has merely been allowed to remain different. Those are not the same thing. One may be required by the customer, the product, the market, the physical environment, or regulation. The other may survive because nobody has had the authority, patience, or political appetite to challenge it.
That work has to happen before requirements harden, before teams become attached to their preferred designs, and before customization begins to feel inevitable. Otherwise, the organization gradually encodes every unresolved decision into equipment, infrastructure, integrations, workflows, data structures, and custom logic. Each individual choice may appear reasonable. Together, they create technical debt: more maintenance, more testing, more specialized knowledge, more difficult upgrades, and less freedom to change later.
A leader who cannot simplify the business will always overcomplicate the technology because technology will be asked to compensate for the focus, decisions, and strategy that leadership did not provide. The lesson is not to avoid sophisticated technology. It is to become much more disciplined about what the technology is being asked to support. The quality of the final solution is often determined long before anything is purchased, configured, connected, or programmed. It is determined when leaders decide whether they are willing to simplify the business first, or whether they are about to spend a great deal of money preserving it.
