Where the Bottleneck Goes When Drafting Is Automated

Where the Bottleneck Goes When Drafting Is Automated

We've written before about why solar drafting doesn't scale: on a typical commercial project the engineering decisions take under an hour while the drafting takes three to five, so a growing pipeline forces linear hiring. This post is about the question that comes after a team fixes that — because automating the drafting does not end the constraint. It moves it.

Eliyahu Goldratt made this the core of his Theory of Constraints: a system always has exactly one binding constraint, and relieving it promotes the next one. Solar engineering teams that automate drafting experience this within weeks, and the teams that expected it do much better than the teams that didn't.

The constraint's first stop: review

When strings, homeruns, tags, and schedules appear in minutes instead of hours, the first thing that backs up is the engineer's own review. The drawing set that used to be limited by drawing speed is now limited by checking speed.

This is the correct place for the constraint to live. Review is the part of the work that is actually engineering — the judgment a stamp certifies. But it changes what matters in a tool: an automated output the engineer can't inspect efficiently just converts drafting hours into auditing hours, and the trade stops being worth it. This is why we're insistent that automation must show its arithmetic — the voltage window behind each string, the length behind each cable figure. A checkable number gets reviewed in seconds. An unexplained one gets re-derived by hand, and the bottleneck quietly returns.

The second stop: everything upstream

Once drafting and review are fast, teams discover how much of a project's calendar was never engineering at all. The design change that arrives three weeks after the proposal was accepted. The equipment substitution that invalidates the string plan. The redline cycle with a client whose estimating tool produced a layout the site can't actually hold.

Slow drafting used to hide these, because the drawing was always the long pole. Fast drafting exposes them. The teams that handle this well treat a redesign as cheap — re-run the stringing against the new equipment, regenerate the schedules, resubmit — instead of protecting the old drawing because it cost 25 hours. When a redesign costs minutes, "the client changed the modules again" stops being a crisis. That, more than the first-draft speedup, is where the operating leverage lives.

The stop after that: the pipeline itself

An engineering team that produces sets faster than sales wins projects has inverted the usual EPC problem. This sounds like a joke until it happens; then it's a pricing and positioning question, not an engineering one. It is also the moment a firm can take on the overflow work other firms subcontract out — a real revenue line for specialized solar engineering shops whose constraint was always drafting capacity.

What to do with this

Three practical consequences for a team considering drafting automation:

1. Budget review time explicitly. The hours don't vanish; they convert. Plan for the reviewer, and pick tools whose output is checkable line-by-line.
2. Re-price change orders. When a redesign costs minutes, aggressive change-order pricing stops being a defensive necessity and starts being a competitive weapon.
3. Watch for the next constraint on purpose. Ask "what backs up now?" before it backs up. The answer is usually review first, upstream churn second.

The goal was never zero constraints — Goldratt would say there's no such system. The goal is moving the constraint from the mechanical work nobody wanted to the judgment work someone stamps. That move is available to any commercial solar team, whichever tools they choose to make it with.

The earlier piece on the linear-hiring trap is here. What the drafting automation itself looks like: Branch, or the typed path in Leaf Automation Studio.