Why 'It's Just a Small Change' Is One of the Most Expensive Phrases in a Tech Company

Why "It's Just a Small Change" Is One of the Most Expensive Phrases in a Tech Company

In hardware+software products, a small change rarely stays small.

If you run an HW+SW company, you probably recognize these situations:

A field technician calls: “Which version of the device is at the customer site? The manual doesn’t match.”
The Head of Product learns about a mechanical change when firmware stops working on the new board revision.
Production has two versions of a component, but no one knows which serial number started using the new variant.
Every change decision requires a five-person meeting because there’s no single source of truth.
During an audit, it turns out the physical product exists in a different version than what the documents describe.

This isn’t normal startup chaos. These are signals that the company doesn’t control product changes.

And it usually doesn’t start with big decisions. It starts with the phrase:

“It’s just a small change.”

The Domino Effect — Why HW+SW Is Not SaaS

In SaaS, a change has a shorter path: code change → review → tests → deploy → monitoring. If something goes wrong: rollback, hotfix, feature flag.

In hardware+software, different physics apply.

Changing one component triggers a cascade of dependencies that doesn’t end at the code repository. You’re touching a physical product, supply chain, production, documentation, certifications, and customers who have devices in the field.

A concrete example: changing a connector.

In the meeting, it sounds innocent — the old one is hard to source, the new one is cheaper and “practically the same.” The decision seems obvious.

A few weeks later, it turns out the change affected:

Hardware engineering — schema update, PCB, BOM, design revision
Firmware — pinout, detection, power, initialization procedures
Mechanics — enclosure, tolerances, service access
Production — assembly instructions, test fixtures, quality control
Purchasing — new supplier, MOQ, alternative qualification
Compliance — impact assessment for CE, EMC, FCC certifications
Service and support — spare parts compatibility, version identification in the field

Plus three suppliers and potentially two certifications requiring re-evaluation.

The cascade lasted 12 weeks. Not because the team was incompetent — people responded quickly and fought fires. The problem was that no one asked a simple question at the start:

What does this change entail?

In SaaS, a change lives in the repository and pipeline. In HW+SW, it lives in the warehouse, production, customer devices, documentation, and engineers’ heads.

The most expensive changes aren’t the biggest ones. They’re the ones someone deemed too small to formally evaluate.

Why “Small Change” Sounds Innocent — And How It Destroys Schedules

The problem with “it’s just a small change” is that it reassures too early. Then come:

“It’s just cosmetic.” “No need to document.” “It doesn’t change functionality.” “Service will manage.” “We’ll document later.”

A change without impact assessment is an uncontrolled change.

Two types of debt accumulate here, both invisible for months. Technical debt: firmware workarounds, hardware variants without logic, tests written in a hurry, differences between revisions no one remembers. Documentation debt: manuals inconsistent with the product, multiple BOM versions, changelog in one engineer’s head, no link between serial number and revision.

In practice: the mechanical team changes a small mounting element, cutting assembly time by 90 seconds. At 1,000 units, that’s 25 hours of savings. Sounds good.

Nobody updates the service manual.

Six months later, a technician drives to a customer site with parts for the old version. A 2-hour repair takes 2 days — figuring out the product variant, shipping the right parts, explaining to the customer why the procedure doesn’t match reality.

Savings: 25 hours in production. Cost: 2 days of service, express shipping, escalation, lost trust.

Schedules don’t fall apart on the day a bad decision is made. They fall apart when the company has to reconstruct change history it never recorded.

ECR/ECO — What It Is and Why Small Companies Don’t Do It

Mature organizations don’t rely on engineers’ memory. They have a mechanism that stops a change for 30–60 minutes before it generates 3 months of chaos. That mechanism is ECR/ECO: Engineering Change Request (a proposal describing the change and its impact) and Engineering Change Order (an approved implementation decision with dates, versions, and responsibilities).

Small companies don’t do this for three reasons: “We’re too small,” “Too much paperwork,” “We don’t have time.”

That last one is the most expensive. If the team doesn’t have 1.5 hours to assess a change’s impact, they’ll find 20 hours later to fight the fire. Or 200, if the problem surfaces at the customer or during certification.

Simple math: a lightweight process for 30 changes per quarter means 30–60 hours of work, internal cost of 6,000–12,000 PLN (~€1,400–€2,800).

No process: if just 5 of 30 changes generate post-hoc problems (analysis, rework, production delays, customer escalation), the real cost is 25,000–75,000 PLN (~€6,000–€18,000) per quarter. Not counting delayed certification, overtime, and lost trust.

ECR/ECO doesn’t mean SAP or Windchill. It’s about one question asked before every change: What does this change entail?

Minimum Viable Change Process — How to Implement Without Bureaucracy

A 20–80 person company doesn’t need a heavy system. It needs four elements.

1. Three questions before every product change:

What exactly is changing? — not “we’re fixing the connector,” but: which one, in which revision, from which lot, for what reason. If you can’t describe it in one paragraph, the change probably isn’t that small.
What does this change affect? — a short checklist: hardware, firmware, BOM, suppliers, documentation, certifications, production, service, sales. The most important answer is “I don’t know” — it doesn’t block the change, it just says: someone needs to check before we implement.
Who approves and takes responsibility? — not “everyone,” not “engineering.” One specific decision owner.

2. Lightweight ECR — one document (Notion, Jira, spreadsheet — tool is secondary): change number, description, reason, affected products and versions, impact assessment, owner, approval, effective date, document links. One entry in the change register.

3. One change register — all approved changes in one place, with the serial number or revision from which the change applies. Not in emails, not in Slack. One register — so that in three months someone can answer: what did we change, why, and where does it apply.

4. Definition of done — a change isn’t closed when the engineer “pushed the fix.” It’s closed when updated: design, BOM, firmware/software, tests, production instructions, customer documentation, service documentation, version markings. This is where companies most often deceive themselves: technically ready, operationally not absorbed by the organization.

The hardest part isn’t creating an ECR template. The hardest part is establishing where changes actually originate, who really approves them, and how they reach production, documentation, and service. It looks different at every company — and that’s exactly what’s worth checking before implementing any tool.

Signals That Your Company Has a Change Problem

Check which of these apply to your company:

Service technicians don’t know which product version is at the customer — they ask three people and search emails
Documentation doesn’t keep up with hardware — “almost current” is not the same as current
“Fixes” are discovered during customer deployment, not by the company
Every change requires a five-person meeting because there’s no decision register
No one knows which changes went into which production batch
Purchasing changes components for availability reasons, and engineering finds out after the fact
A new engineer spends their first weeks reconstructing product history from conversations, not documents
The team is afraid to touch the product because “no one knows what will break”

3+ points: the problem already exists — the next change will probably enter production without impact assessment.
5+ points: you’re risking series delays and incorrect field service.
7–8 points: product changes aren’t managed, just reactively firefought.

The best time to fix this was before the first major production run. The second best time is now — before the next “small fix” turns into a three-month delay.

If “small changes” keep coming back as delays, unclear product versions, mismatched documentation, or field service surprises — check this before it becomes a bigger cost.

Product Control Review is a 90-minute session where we map how you currently manage product changes in hardware+software:

where change decisions originate
who approves them and how they reach production, documentation, and service
where information gets lost
which “small changes” are already waiting to be managed

After the session you get: a change flow map for your company, a list of 3–5 biggest gaps, a minimum ECR/ECO process recommendation, and an action checklist to implement within two weeks.

We don’t implement heavy PLM. We don’t create corporate paperwork.

Book a Product Control Review →