Your Software Team Isn't the Problem. Your Org Chart Is.

#softwareinsidenontechindu

Non-tech companies keep hiring engineers and then systematically preventing them from doing engineering — and the cost of that confusion is finally becoming impossible to ignore.

Picture this: an oil services company with 30,000 employees and $4 billion in annual revenue installs a Jira board. Leadership hires a Scrum Master. Sprint planning runs on schedule every two weeks. The backlog is groomed. The velocity chart goes up. And the lone software team — eight developers buried three layers beneath the VP of Operations — continues to wait six weeks for a Change Advisory Board to approve a three-line patch to a field-management application running on a server nobody can physically locate.

The Jira board is not the problem. The org chart is.

This is the defining tension in enterprise software delivery right now: the gap between companies that exist to build software and companies that build software in order to do something else. Retailers, oil and gas operators, manufacturers, heavy-equipment firms — these organizations have been told, with increasing urgency, to "become tech companies." Most have responded by adopting tech company rituals without changing anything about how they actually make decisions, reward employees, or manage risk. The result is a kind of organizational cosplay: the ceremonies of Agile without the authority structures that make Agile functional.

The Cost Center Trap

In accounting, every department is classified as either a cost center or a profit center. At a software company, developers build the product that generates revenue — they're a profit center. But what if you don't work in software?

That question has a very concrete answer in most industrial organizations. When a drilling company's IT team ships a better scheduling tool, they have not drilled more oil. When a retailer's in-house engineering team automates a supply-chain workflow, they have not sold more goods. The software is real and the value is real, but it is indirect — and indirect value, in organizations measured by barrels, SKUs, or tonnage, is perpetually at risk of being classified as overhead.

This is the root of why so many older companies struggle to transform, and why the struggle doesn't seem to be easing. The Pragmatic Engineer has documented the pattern thoroughly: engineering teams at non-tech firms tend to be understaffed, undercompensated relative to their skills, and perpetually underinvested compared to peers at software-native companies. They are expected to deliver modern software while being resourced like a maintenance department.

The practical downstream effect is talent bleed. Industries that have been slow to adopt technology — manufacturing, agriculture, transportation and logistics — now face pressure to integrate AI. They have decades of technical debt and greenfield AI opportunities sitting side by side. They need developers who are AI-literate but also understand domain-specific requirements, regulatory constraints, and existing systems. Finding people who satisfy all three criteria and will accept a non-tech salary is not straightforward. So these organizations cycle through contractors, system integrators, and offshore teams — and then wonder why institutional knowledge disappears every 18 months.

Legacy Systems: The Real Constraint That Agile Ignores

Throughout the life of a software system, its architecture decays, its underlying technologies become obsolete, and user requirements shift — until the software becomes what the industry politely calls a legacy system. Most software currently running in production fits that description: long-lived systems representing years of accumulated business logic, kept alive through extensive maintenance, at increasing cost and increasing exposure to security risk.

This is the technical reality that Agile transformation decks tend to skip over. The Scrum framework was designed for greenfield product development. It assumes a team can iterate freely, deploy frequently, and learn from user feedback. In a company running a 25-year-old ERP written in COBOL, interfacing with a proprietary MES that the original vendor no longer supports, none of those assumptions hold. The backlog refinement session becomes an exercise in estimating how long it will take to find a workaround for infrastructure that shouldn't exist in 2025.

In many traditional IT organizations, a Change Advisory Board is tasked with assessing risks and approving changes. The CAB holds regularly scheduled meetings to review all proposed upcoming changes, pulling in experts to explain, defend, or assess them. And while change management exists for real reasons — risk, compliance, auditability, cross-team coordination — the process has a well-documented tendency to become complex, bureaucratic, slow, and painful. Atlassian calls this "bureaucratic." In heavy-industry contexts, it's often non-negotiable. A software change to an oil platform's sensor management system touches IEC 61511 functional safety requirements. A retail pharmacy's order management update carries FDA audit obligations. These aren't excuses for slow delivery — they're load-bearing constraints. Agile doesn't remove them. It just makes the sprint retrospective more awkward.

Transformation Theater

From 2022 to 2024, digital transformation spending in Western markets was projected to reach $6.3 trillion. Failure rates hover around 84%, with no signs of improvement. Organizations are pouring money in and not getting the value out.

Some of that failure comes from technical complexity. Most of it, if you talk to practitioners who have actually sat inside these transformations, comes from a simpler problem: organizations adopt the vocabulary of modern software delivery without restructuring the authority that software delivery requires.

The failure patterns are consistent. Middle managers stay in waterfall mode, keeping old bureaucracy intact while internal silos are preserved. Other functions refuse to change their pace. Product launch activities resist incremental delivery. Reward models stay focused on individual output rather than team outcomes.

This is what "Agile transformation" actually looks like inside a manufacturing firm: two-week sprints scheduled inside a six-month project plan, approved by a steering committee that meets quarterly. Developers write user stories. The acceptance criteria are written by a business analyst who reports to a VP who has never merged a pull request. The Definition of Done is whatever makes the next milestone gate turn green. Velocity is tracked religiously. Deployment frequency is never measured at all.

In practice, assigning responsibility to a Product Owner creates friction with existing processes when transitioning from a waterfall or ITIL way of working. And in non-tech companies, "existing processes" includes procurement rules, union agreements, safety certification cycles, and board-level risk frameworks. These don't flex for a two-week sprint.

The Counterargument Deserves a Fair Hearing

It would be easy — and wrong — to conclude that Agile and DevOps are simply incompatible with industrial settings. That's not the claim here.

The CrowdStrike outage of July 2024 is a useful counter-case. When a problematic CrowdStrike update clashed with Microsoft's widely-used software, the resulting global IT outage cost Fortune 500 companies north of $5 billion. The disruption hit companies with outdated legacy systems hardest — airlines in particular took longest to recover. Delta canceled around 5,000 flights in the first three days, then another 1,000 on day four.

Delta's prolonged recovery compared to peers was not bad luck. Their crew scheduling system was so deeply dependent on Windows machines that manual recovery — physically touching each one — was the only remediation path. A company in that position has not invested adequately in its software operations layer. That is a cost-center mentality applied to infrastructure that cannot afford it.

There are genuine wins on the other side. One automotive manufacturer trying to shift its complex architecture to the cloud struggled to translate legacy code into requirements that could be moved or rebuilt. Using AI-assisted tooling, teams removed eight person-weeks of effort previously spent documenting each portion of legacy code, producing reports then available for forward engineering. That's a meaningful compression of the most brutal phase of modernization work — not because Agile ceremonies unlocked it, but because actual engineering investment did.

The Organizational Capability That Actually Matters

The honest thesis isn't that non-tech companies are bad at software, or that the engineers inside them are underqualified. Most are doing something genuinely hard — delivering software inside organizations whose decision-making architecture was built around a completely different model of production. The sprint board doesn't threaten anyone who runs a blast furnace. The retro doesn't rearrange a procurement committee.

What actually differentiates the non-tech companies that deliver good software from those that don't is not the methodology on the wall. It's whether technical leaders have organizational authority to match their accountability. Whether a CTO or VP of Engineering can say "this system is a liability" and be heard, rather than just noted. Whether the change control process exists because the risk is real or because nobody ever had the clout to simplify it.

Software management is playing a larger and more strategic role across large traditional organizations — and those organizations are finding themselves increasingly limited in their ability to respond to market and customer needs. "Limited in their ability to respond" is polite phrasing for what actually happens: a three-line fix that should ship Tuesday takes six weeks, costs a developer their enthusiasm, and eventually costs the company a person who leaves for somewhere that ships.

The oil rig doesn't care about your sprint velocity. Fair enough. But the rig's operator should care that the software running its sensor telemetry was written before smartphones existed, is maintained by one contractor who knows the codebase, and would take four weeks to update even in an emergency. That's not a technology problem. That's a governance problem wearing a technology problem's clothes.

And no amount of Scrum certification fixes an org chart.