Here’s a question worth asking at your next project closeout: did drafting come in under budget because the work went well, or because the hard part got pushed downstream to engineering?
Justin Mason has been asking that question for years. He’s the engineering manager at WB Powell in California, with 27 years in the industry and a Microvellum user since 2011. In our recent webinar on May 27 with Clay Swayze, Director of Product for CAD/CAM at INNERGY, he put it plainly: shops often come in under on submittal drawings and over on production engineering, then call it a wash. It usually isn’t. When engineering has to reinterpret drawings that were created in a separate system, the extra hours show up in one column or the other. The mistakes show up on the shop floor.
The four-application problem
Most shops that aren’t running connected engineering data are running something like this: one CAD application for drafting, maybe a modeling tool for custom products, a separate cabinet software where engineering recreates what was already drawn, another application generating CNC machine code, and a spreadsheet for hand cut listing. Clay described working with a Canadian company that was running eight applications to get product out the door.
None of those tools is the problem on its own. The problem is that each one holds a different piece of the project data, and none of them talk to each other. Every handoff between systems is a place where information gets reinterpreted, and every reinterpretation is a chance for a mistake.
The cost shows up when something changes midstream. A dimension moves. A material swaps. A customer revision lands after release to production. The drafter updates the drawing, but downstream, nothing happens automatically. Someone has to chase the change through every system, confirm the old data is gone, and hope nothing got missed. When it does get missed, you’re paying for rework, wasted material, and production delays on a job you already quoted.
One drawing, one database
Microvellum takes a different approach. It’s a CAD-based engineering platform built on BricsCAD and compatible with full-version AutoCAD, where the drawing itself becomes the manufacturing data. Every route, drill operation, sawing operation, piece of hardware, and material lives in a single database tied to the parametric model.
When a change request comes in, you update the drawing. The 3D model, 2D elevations, sections, annotations, cut lists, reports, and machine code all regenerate from the same data.
Justin’s example: a finished break room, installed and done, until the architect decided he wanted a taller coffee maker on the counter. Change order. In Microvellum, that meant pulling the prompts on two products, shortening one, adding a finished end to the other, and generating a new work order from the same data that built the original. No re-listing, no re-programming, no running between departments.
Drafters become engineers
One of the more interesting consequences of connected data is what it does to roles. At W.B. Powell, drafters and engineers work in the same environment with the same tools, so any drafter can pick up behind any engineer and vice versa. A drafter who knows CAD can learn to place parametric products and generate work orders. A seasoned builder from the shop floor who knows exactly how a die wall should go together can come into the office and produce drawings without years of drafting experience.
That matters for hiring, too. Drafters are easier to find than engineers who know how to build. Connected data lets you grow one into the other.
What it looks like on the floor
Before going fully to Microvellum, Justin’s shop floor got three different packets of reports for the same room, generated by three different systems. Now it’s one stack of paperwork, one set of reports, one package to the CNC.
When the edgebander eats the end of a part, the operator scans the barcode on the label and the G-code for that exact part comes up at the machine. No walking back to the office, no figuring out which cabinet, which side. Scan, re-cut, move on.
The more you put in, the more you get out
Justin’s advice for existing Microvellum users: put everything in. Grommets, in-wall brackets for nurses stations, even the elaborate metal-and-glass features you don’t manufacture yourself. Once they’re products in the system, they’re machined, reported, ordered, received, and tracked instead of living on a sticky note.
For shops evaluating Microvellum, his recommendation is to start with one or two people as keepers of the specification groups, the settings that dictate how your shop builds. Flip the switches once, and everyone works from the same standards.
Disconnected workflows don’t fail loudly. They leak: a little extra labor on every job, a little rework on every change, margin you never see leave. If you want to see what connected engineering data looks like in the context of your own operation, request a demo and we’ll walk through it with your products and your process.
Engineering frequently appears to be a mysterious field to millwork owners. Fundamentally, engineering is just the process of transforming input data which can range from napkin sketches to complete architect plans into information that can be produced on the shop floor.
Why should you care about engineering at all? Because it touches and affects nearly everything in your business. In sales and estimating, if engineering standards are weak and estimators must guess on projects, jobs get sold with holes in scope. It can also impact lead times. Want to avoid apologizing for missed delivery deadlines? Make sure engineering is forecasting what it can realistically release.
It also, not surprisingly, impacts production planning, scheduling, assembly, finishing, and installation. And if you thought it doesn’t touch marketing, you’d be wrong. What engineering does for building trust and the overall customer experience is vital to how you market your business. Engineering isn’t a department. It’s the handoff that controls every single handoff.
Light valances are a perfect example of how one small engineering decision can ripple through the whole shop.
If you want a real shop floor example of why engineering matters and how much it impacts, take the example of light valances, that narrow strip that hides the LED so you don’t see the light source when you open a cabinet.
This simple light you wouldn’t think would cause problems, but the narrow piece is often too small or awkward to edge band normally. The workaround becomes: cut it oversized, edge band it, rip it down later. That sounds easy until you look at where the ripping lands. If it lands on the wrong person at the wrong time, you’ve just created extra handling, extra queue time, and extra chances for a mistake. A tiny part can quietly steal hours across the job.
The real lesson isn’t “light valances are hard.” The lesson is that engineering is not only about drawings. It’s also about choosing a build approach that fits how your shop actually runs. Sometimes the better solution looks a little clunky at first glance. Tape two parts together and run them through the edge bander. Use a sled. Change the part strategy so the banding is easier. It might feel less clean for the edge bander operator, but it keeps the job moving and reduces touch time downstream. That’s engineering doing its job.
You didn’t start a millwork company to have the world’s best drawings.
This is one of the most important mindset shifts for owners. The goal isn’t perfect drawings, perfect G code, or perfect yield. The goal is making money.
That doesn’t mean your team can be sloppy. It means you have to be honest about what you’re optimizing for.
If your engineering team is spending time polishing drawings that don’t change outcomes in the shop, you’re paying for work that doesn’t ship product. If your engineering team is spending time clarifying scope, locking critical details, and preventing rework, that work pays you back.
You can usually feel the difference. When drawings are overbuilt, you get long lead times and a lot of internal approval loops. When drawings are underbuilt, you get questions, workarounds, and rework. The target is clear and buildable, not museum quality.
Don’t assume engineering is the bottleneck. Verify it.
Engineering is easy to blame because it’s upstream of so many issues. But overloading any department creates delay. That alone doesn’t prove it’s the bottleneck.
A common example is upstream batching. A PM holds an entire release for weeks because one detail is unresolved. Then everything gets released at once. Engineering gets hit with a surge. Production gets hit with a surge. Schedules slip. Everyone says engineering is slow, but the real issue was the release behavior.
If you want a quick diagnostic, look at where work is sitting and why. How much work is waiting on engineering time? How much is waiting on approvals? How much is waiting on selections? How much is being held because someone is waiting until the whole job is perfect on paper before releasing anything?
When you separate those buckets, the fix becomes obvious. Sometimes it’s staffing. Sometimes it’s standards. Sometimes it’s release discipline. The point is to measure it, not guess at it.
Kill Stupid Rules.
Every shop has rules that were created because something went wrong once. The problem is the rule stays forever, even when the original problem was rare and the cost of the rule is paid every single day.
Engineering carries a lot of these. Extra steps, extra signoffs, extra documentation, extra checks for edge cases that show up once a year.
You don’t want to remove quality control. You want to remove drag.
List the rules that slow engineering down the most. Then ask two questions: what problem was this created to prevent, and how often does that problem actually happen now? If it’s rare, is there a cheaper way to catch it than slowing down every job? Sometimes the answer is a simpler checkpoint. Sometimes it’s updated training. Sometimes you delete the rule and nothing breaks.
Smaller batch sizes create faster flow.
Big releases feel organized. One package, one handoff, one approval. But big batches create long waits, bigger rework, and unpredictable lead times.
Releasing in smaller units, whether that’s by room, by area, or by some other natural break in the job, gives production something to run with sooner. Revisions stay contained. Scheduling becomes more predictable. Install planning gets clearer. Even billing gets cleaner because progress is visible in real units.
This is one of the fastest ways to make engineering feel less like a black box to the rest of the shop. Owners can see work moving. The shop can see what’s coming. PMs can see what’s stuck. And everyone stops running the same end-of-job fire drill on every project.
A simple Engineering 101 checklist for owners.
- If you want a practical way to manage engineering without hovering over your engineers, come back to these questions regularly:
- Are you making small engineering decisions that create extra handling later, like the light valance problem?
- Are you aiming for clear and buildable drawings, or are you polishing things that don’t move the job forward?
- Does your engineering effort match how you compete, or are you copying someone else’s process?
- Are you blaming engineering for delays without verifying where work is actually sitting?
- What rules are slowing engineering down every day, and what problem are they really preventing?
- Are you releasing in smaller chunks so work can flow, or batching everything and wondering why nothing feels on time?
Engineering shouldn’t be a mystery. When owners treat it as the handoff that controls every other handoff, they start seeing where time is actually being lost, and what changes will make work move better through the whole shop.