It’s Wednesday, and you’ve opened the same CAD file for the fifth time this week. A hole count goes up. A staircase needs seventeen steps instead of nineteen. A radius moves from forty-two millimetres to forty. None of it is new design. It’s confirmation that the new combination can actually be built, and then the drawing that says so.
You recognize the request before you’ve even opened the file. The type is familiar. There’s no confusion about what to do, but there’s real pressure, a salesperson or a customer is waiting on the other end. What’s left once the confusion is gone isn’t calm. It’s tedium. Monotonous, fiddly, small changes made by hand, one file at a time.
The confirmation problem.
That confirmation is the whole problem. The rules for what’s buildable are rarely written down. They exist as judgement, held by you. You know which combinations work in this particular workshop, with the tooling that’s actually in the machine and the tolerance chains that tend to give way at assembly. There’s documentation, somewhere across spreadsheets, CAD folders and email threads, but it assumes the reader already knows which version applies.
01. Why training a colleague doesn’t fix it.
That judgement could be transferred. A colleague could be trained, the rules could in principle be written down. In most companies, neither has happened. While the knowledge exists only in your head, it has to be applied again for every request, however trivial the change.
Training a second person raises the ceiling but keeps the structure. Two people can answer requests instead of one, and the ceiling moves accordingly. Every request still has to pass through someone who holds the rules in their head. Getting a colleague there is measured in months, not weeks. Your own speed follows the same pattern, experience cuts the minutes per request, but it doesn’t cut the number of requests that need your judgement call.
Hire or train a second engineer
Raises the ceiling — two people can now answer requests instead of one — but keeps the exact same structure. Every request still has to pass through someone who’s internalized the buildability rules, and getting a person to that point is measured in months, not weeks.
Write the rules down
A genuinely good instinct, worth doing regardless. But documentation scattered across spreadsheets, CAD folders, and old email threads still assumes the reader already knows which version applies — it gets someone closer to the judgment call. It doesn’t make the call for them.
Capture the rules in a system that applies them automatically
Instead of a person re-deriving “is this buildable?” from memory every time, the rules — valid dimensions, compatible options, tolerance limits — live in a system that checks any new combination against them instantly. Whoever’s asking gets the answer directly, without waiting on you.
02. Why growth makes it worse, not better.
It’s also why growth makes this worse instead of better. Every new salesperson generates more requests without adding capacity to answer them. Every new market does the same. The bottleneck isn’t the number of hours in engineering. It’s that one route exists from customer request to production file, and it runs through you.
That’s also why growth makes it worse instead of better: every new salesperson and every new market adds more traffic to the one route, without adding a second one.
Over time, noticing the tedium stops feeling like a complaint and starts feeling like a condition of the role. It’s what comes with being the person who knows the product best.
03. The cost that never shows up in a report.
The cost is real but doesn’t show up in any report. Time for product development, the part of the job that actually builds your expertise, shrinks. Frequent interruption makes sustained work hard regardless of the hours you technically have. Colleagues and sales aren’t a separate social friction, they’re part of the same mechanism. They wait because the knowledge isn’t stored anywhere else, not because you’re slow. That distinction is invisible to the person waiting, which is why the follow-up lands on you and not on the process.
We build this with DynaMaker, a platform for building the kind of visual, web-based configurator that does this — you define your product’s parametric rules once, and every valid configuration that comes through is one the system has already confirmed can be built, without you personally checking it.
You can also poke at a live example configurator here on our website.
04. Where the knowledge should live.
As long as this looks like a workload problem, no fix holds. It comes back next quarter, in the same shape, on the same desk.
Where the knowledge lives today isn’t the interesting part. Where it should, is.
Try It on Your Own Product Line
You don’t need to buy anything to see if this holds up — build a configurator for free and see whether it actually validates a real request the way you would.
