For a long time, engineering has been told that the worst thing to be is late. Yes, do good work. Certainly, inject more function. Absolutely, meet the cost target. But, above all, meet the schedule.

There’s truth to the importance of hitting the market window, and there’s value in launching on time. But the schedule-at-all-cost message has been made too strongly, and it has a hidden dark side.

When you ask engineers to do something new, the knee-jerk “no” is evidence of that hit-the-schedule dark side. When you ask engineers to change a drawing to help production, the roll of the eyes is a tell-tale sign they’ve been programmed by can’t-be-late thinking.

But the knee jerk and eye roll are misunderstood and misattributed to the engineer stereotype of being stodgy for stodginess’ sake. They are better attributed to the don’t-miss-the-schedule imperative. When asked to do something new, engineers say “no” because we’re afraid to be late. But, we’re really thinking: “That’s a great idea, and I’d love to take a swing at it. But, you pay me to guarantee things will work, and there are a whole lot of things to check out before we could implement. And since I’m triple-booked on product development projects, I don’t have time to guarantee success.”

It’s a big problem now, and it will get worse. The problem will be amplified by the sea of new innovation programs. Innovation is all about newness—at an unprecedented scale. Today, schedule pressure and workloads don’t allow engineers to work on simple changes. Imagine the conflict when our innovation programs pile on newness.

That’s cruelly painful for engineers. We’re the biggest advocates for innovation, yet when we can’t do it right, we have an obligation to hold it back. For years we’ve advocated for innovation. We know it’s the right thing to do. We know it’s an imperative. Yet, we also know it’s incremental newness without incremental resources.

There is hope. First, engineers must decide to embrace newness. (There’s some truth to engineering stodginess.) Sure there’s a downside to newness, but we must learn to value the upside, which is far bigger. Our attitudinal pendulum must swing toward positivity. Second, we must learn to quickly and efficiently reduce the technical risk of newness.

“Build to learn” (BTL) is the answer. BTL starts with problem distillation—a translation of newness into a one-page picture of the potential problem and a single-sentence learning objective. These can then be used to exercise the most powerful engineering tool ever invented—Google.

A highly informed, tightly focused Google search can quickly provide examples of how others solved our potential problems. That, in turn, will inform the approach to satisfy our learning objective. It defines what to build—a learning prototype.

To speed learning, BTL changes the definition of “prototype.” Build-to-learn prototypes are elegantly simple. They can be built in less than a day (sometimes less than 15 minutes), and they do only one thing—help satisfy your learning objective. BTL prototyping requires new thinking by engineering, but the return is learning measured in nanoseconds.

BTL answers questions with experiments. Suddenly, newness is no longer new. Armed with test results for sticky questions, engineers can stand behind their inertia-breaking declaration: This will work.

“Build to test” makes things real. It shows that it can be done and how to do it. And armed with “cans” and “hows,” engineering can secure the required resources, and do it right.