The Slack thread where you approved that component swap last Tuesday? That was an ECO. It had a description of the change, a reason, and someone who said "looks good." It was just invisible, unsearchable, and gone the next time someone scrolled past it.
The question isn't whether your team does change control. You already do. The question is whether you do it in a way that you can actually use six months from now.
Your Current Process Is Already an ECO
Most hardware startups under 20 people are running informal change control without calling it that. An engineer notices a component is going end-of-life. They message the founder in Slack. The founder says swap it. The engineer updates the BOM, or maybe sends the new part number to the CM directly. Done.
That sequence has everything an ECO needs: a trigger, a proposed change, an approval, and an implementation. The problem isn't that you're skipping the process; it's that you're doing it somewhere that doesn't record it.
When your CM asks "which revision are we building to?" six months later, the answer is buried in a Slack thread, or in someone's memory, or nowhere at all.
What a Large Company's ECO Actually Looks Like
Enterprise change control exists for a reason. At a 500-person manufacturer, a single BOM change can ripple into purchasing commitments, supplier contracts, regulatory filings, quality records, and active production runs. The formal ECO process, with its Change Control Board, sequential sign-offs, and multi-department reviews, is sized to absorb that blast radius.
It is also genuinely slow. A non-urgent ECO at a large company can take weeks to close. The paperwork isn't bureaucracy for its own sake; it's the overhead cost of making sure a change doesn't break something downstream that nobody thought to check.
You don't have that problem. You also don't have that infrastructure. A 10-person robotics startup applying enterprise change control would spend more time managing the process than building the product.
What Actually Matters at Your Scale
Strip the ECO down to its purpose: create a record of what changed, why it changed, and who approved it.
That's it. Everything else is scaffolding that exists to serve larger organizations.
For a team under 25 people, the minimum viable ECO has five things:
- What is changing. The specific BOM line item, assembly, or process. Not "updated some parts" — the actual part number, rev level, or field.
- Why it's changing. One sentence. "EOL on U7, substituting with equivalent from same family." "CM flagged fitment issue on Rev B housing." "Cost reduction: same spec, 40% cheaper from alternate supplier."
- What the BOM looks like before and after. A diff. Not a description of the diff; the actual before and after state, so there's no ambiguity about what was in effect at any point.
- Who is making the change. The assignee. Accountability, not blame; if a question comes up at production, you need to know who to ask.
- Who approved it. One person is enough for most changes. The approval doesn't need to be ceremonial; it needs to exist.
That's the floor. A team at pre-production can run their entire change history on those five fields and be in better shape than most teams that are using spreadsheets to simulate a process they never fully built.
The EVT Exception
During EVT, you are trying to get the thing to work for the first time. The BOM is a hypothesis. Components get swapped mid-build. Entire subsystems get redesigned between Monday and Thursday. Formal change control at this stage adds process overhead to a product that doesn't have a stable baseline yet; there's nothing worth protecting.
Skip the ECO during EVT. Move fast. Break things intentionally.
The calculus changes the moment the product works. Once you have a functioning unit and you're entering DVT, you have something worth preserving: a known-good state. From that point forward, every change you make is a variable. If the product goes from working to not working, you need to know exactly what changed between those two states. That's what the ECO is for.
DVT is when change control earns its place. You're validating that the design holds up, not just that it turns on. Changes during DVT are meaningful; a component substitution that passes at room temperature but fails at 60°C is the kind of thing you need a paper trail for. By PVT, you're locking the design down for production, and every change has potential cost and schedule implications. The process weight should match that reality.
The short version: no ECO during EVT, lightweight ECO from DVT onward, tighter process at PVT and beyond.
When to Add More Process
The minimum viable ECO breaks down in specific, predictable ways. You'll know it's time to add structure when one of these happens:
You have more than one person touching the BOM. Two engineers making concurrent changes to the same BOM without coordination is a conflict waiting to happen. You need a mechanism that says "this BOM is in-flight right now, hold your changes."
You're in a regulated space. Medtech and defense have change control requirements baked into compliance frameworks. The question shifts from "should we do this?" to "what does our process need to look like to satisfy an auditor?" That's a different conversation, and the minimum viable ECO is just the starting point.
Something goes wrong. A bad part swap reaches production. A supplier change introduces a fit issue nobody caught. When that happens, the first thing you'll want is a full history of every change made in the last 90 days. If that history doesn't exist, you're doing forensics instead of engineering.
The Enforcement Question
There's a difference between having an ECO process and requiring everyone to use it.
Early on, requiring enforcement is usually the wrong call. Your team is moving fast, the product is still changing shape, and adding a mandatory approval gate to every BOM edit slows the iteration cycle without much payoff. Use the process for significant changes; skip it for fixing a typo in a reference designator.
The right time to enforce is when the cost of an untracked change exceeds the friction of the process. For most teams, that's somewhere between "first CM relationship" and "first production run." At that point, locking BOM edits to active change orders isn't bureaucracy; it's just how you make sure nothing gets built from a revision nobody approved.
Start permissive. Tighten when the chaos starts costing you.
The One Thing Worth Tracking Above Everything Else
If you implement nothing else from this post, track the BOM diff.
Not a note that says "updated component." The actual line-item record of what was in the BOM before the change and what was in it after. Added rows, removed rows, modified quantities, substituted part numbers. The diff is the whole point of change control; everything else in the ECO is metadata that helps you understand it.
The diff is what your CM reads to understand what changed between Rev A and Rev B. It's what your quality engineer looks at when a field failure comes in. It's what you look at in six months when someone asks why you switched suppliers on a specific component.
The form matters less than the record. A lightweight process that actually captures the diff is worth more than a formal ECO process that describes changes in prose and loses the specifics.
oroForge has ECOs built in, with BOM diffs computed automatically and a review workflow that works for teams of 3 or 30. See how it works at oroforge.com.