A software-dependent company relies on software for its products and operations but retains budgets and power structures designed when technology was a support team. Banks and insurers usually fit the description; so do retailers and airlines. Public bodies can share the same contradiction, as can older companies that now call themselves technology companies.
People close to the running mechanism experience the mismatch between software dependence and support-era authority as a particular kind of exhaustion. They sit through priority discussions with no stable relationship to the systems producing value and see engineers blamed for outcomes decided elsewhere. Strategy documents grow as shared understanding shrinks. Precise descriptions create friction because they cross the reporting boundaries through which the company has learned to explain itself.
Most companies will acknowledge legacy software. The conversation becomes less enthusiastic when the budgeting model and governance structure are described as legacy too, especially the separation of engineering from operations. Software now mediates customer and internal work, including risk decisions as well as pricing and fulfilment; the people with decision rights still treat changing that mechanism as a request to a support team.
The phrase “IT project” performs the same separation at initiative scale. A renewal transformation may alter underwriting decisions, customer communications, operating work, controls, process economics and the software carrying all of them. Once it is called an IT project, those owners become stakeholders in a technical delivery. A flood-excess pricing rule changes, and the underwriter who owns it becomes a “stakeholder” in delivery of their own decision.
They can approve, advise, escalate and withhold consent; Technology owns the plan for an outcome it cannot decide alone.
The label “IT project” is politically useful even when nobody uses it cynically. If the work fails, delivery can be reviewed without disturbing the authority model. Supplier management, architecture, scope, testing and programme governance may all deserve scrutiny, but none answers why a business transformation was assigned to a function without the ordinary rights to transform the business. More alignment can make that assignment work harder; it cannot make the assignment coherent.
Do not police the label; test it against the work. If the work changes only a bounded technical component, a technical project may be exactly what it is. If it changes a customer promise, operating process, policy, control or economic mechanism, replace “IT project” with the outcome and the owners whose decisions must change. The sentence will either acquire an accountable business transformation or expose authority that cannot name itself.
Language supplies the quickest diagnostic. If “the business” means people who are not engineers, where do the engineers work? In Technology, apparently: somewhere outside the business that consumes a material share of its revenue yet builds and operates the systems through which that revenue arrives. The company pays for product roles and OKRs to carry context across the boundary it created. Quarterly planning and consulting reinforce the same bridge.
Calling every group outside Engineering a business stakeholder preserves the fiction that Engineering sits outside the business. Operations knows the edge cases, Marketing knows demand, Sales knows the customer and deal, Finance knows the economics, and Engineering knows the behaviour and changeability of the operating mechanism. Each holds expertise in the same process; none constitutes an imaginary remainder called the business.
Including engineers in the business changes the question asked of them. Instead of receiving a solution already translated into features, they can work directly with the people who run and finance the process, manage its risk and serve its customers. Architecture then follows process decisions and language, including failure modes and data. Excluding engineers from the context and asking them to create a loosely coupled design is an unusually expensive way to discover that company design has already chosen the coupling.
Author observation
At one company I helped, engineers called Product “the business” and Operations and Sales “the business business.”
The phrase “the business business” had mapped the operating model because Product translated between Engineering and the teams selling and operating the service. Engineering received requirements from Product; Product reconstructed them from Operations and Sales; Operations discovered what the system meant when a change returned. The process ran through all four groups, but no one maintained one description of its important states and decisions.
At the company I was helping, if you asked every employee, “Do you work in the business?”, no more than a third would answer yes. Yet its employee-engagement survey would report that the staff were engaged. The company also held a large party just before sending the survey, which is one way to improve the workplace without changing it.
Do not turn the substitution test into a league table. One honest use of “the business” may be harmless shorthand; ten named functions can still conceal a missing right. Take three sentences that failed substitution and trace each backwards. Who asked and who can decide? Who owns the outcome and which running system must change? Ask the engineer who would implement the request and the operator who would carry it whether those answers describe the same decision. If they do not, you have found the first seam worth examining, because language has exposed authority that cannot name itself. The point is to inspect the right, not police the words.
Companies place capable product people between Engineering and the operating teams to compensate for a boundary they preserve. Those people's customer knowledge and commercial judgement remain valuable; the design creates the permanent bridge work.
A product team cannot repair the separation of process authority from engineering by itself. Product people can make context travel more intelligently by clarifying the promise and improving the sequence of choices. They cannot give an engineering team authority over a process when its budget, control decisions, operating data, and consequences remain elsewhere. The translator becomes more capable; the load-bearing boundary still defeats the team in practice.
The people closest to operational reality are often judged not to be management material because they keep mentioning what actually happens. A claims handler knows that the official process omits a manual edge case, an analyst maintains the mapping that makes two reports agree, and an engineer knows that a release labelled complete is disabled live. Their evidence crosses functional and reporting boundaries and disrupts the management account, so the company treats the contradiction as a communication problem or a failure to take the broader view.
Once engineers are excluded from the business, maintaining one account of reality becomes optional. Operational knowledge, management reporting, and system behaviour can diverge without any owner responsible for reconciling them. Functional reporting lines then conceal that the running company is contradicting the representation leadership governs.
Structural repair begins with one unit owning a complete process. The people who operate and judge the process work directly with those who change and control it. Different experts remain different. Their context and consequence no longer travel through a role whose permanent purpose is to translate between them.
The process-owning unit still belongs to the company, working inside its capital envelope and the law. Its duties as an employer remain, as does company risk policy. Its difference lies in being able to operate and change the process, then measure and recover it, without borrowing ordinary decision rights from several teams. Ownership can become singular enough to act without forcing expertise into one voice.