I Pull Technology. Then I Push It.

A 50-Year Pattern That Predates the Word 'Innovation'

It Started with a Broken Television

I was 13 years old when I first got paid to fix something that most people would have thrown away. Not lawn equipment. Not bicycles. Vacuum tube televisions.

While other kids were mowing lawns and delivering papers — which I also did — I was opening up the back of television sets, understanding how the components worked, diagnosing failures, and making them work again. Nobody taught me a curriculum. The television taught me, because getting it wrong meant it still didn't work.

That was the first lesson in a very long education: technology is not something you consume. It is something you understand from the inside out.

Technology is not something you consume. It is something you understand from the inside out.

High School: Fabrication, Welding, and 135 Feet in the Air

Through high school I held two jobs simultaneously. One of them was at a grain elevator sales and service shop, where I worked as a general mechanic. I learned to fabricate and weld components and structures. I assembled countless auxiliary machines — bins, augers, distribution systems. I worked around cranes. I climbed as high as 135 feet to do the work.

What I was learning — though I wouldn't have used this language then — was physical consequence. In environments like that, being wrong is not an abstraction. The structure either holds or it doesn't. The machine either runs or it doesn't. You develop a calibration for reality that no classroom manufactures.

By the time I sat down at an engineering workstation years later, I already understood in my hands and in my body what the drawings were actually describing. Most engineers come to manufacturing from the drawing. I came to the drawing from manufacturing. That inversion matters.

AutoCAD: I Didn't Use the Tool. I Rebuilt It.

When I encountered AutoCAD, I didn't spend long using it the way it came out of the box. I could see what it was capable of, and I could see the gap between that ceiling and where the native interface left you.

So I rebuilt it. Custom LISP programming. Macro restructuring. A completely reconfigured GUI. A layer-based part management system that gave operators surgical control over complex assemblies — pick a part, send everything else to background, work on exactly what you need with precision and uniformity.

The result was a 4 to 10 times productivity multiplier, with enhanced quality and standardization built in as a structural feature rather than a discipline to enforce. And this wasn't for my own workflow. Almost 100 users were running on the system I architected. That's enterprise infrastructure design disguised as drafting.

I didn't spend long using it the way it came out of the box. I could see what it was capable of — and I could see the gap.

The Overnight Calculator: Apple IIe and the Sharp PC-1500

In the years that followed I discovered something important about computing: you could tax a machine to its limit overnight and come back to an answer in the morning.

On an Apple IIe — 5¼" floppy disk, the whole ritual — and on a Sharp PC-1500 pocket computer running Microsoft BASIC, I wrote programs to solve problems that would have taken weeks by hand. One of them ran overnight to find the critical ratio of hole diameter to center distance for a discharge control valve that became my first patent. The program ran until the variables reached zero. I came back to a thermal printer output with the answer.

The tool wasn't finished when I bought it. I finished it. That has been true of every tool I've ever used.

Building My Own Machines to Build Better Machines

In the early years of my business, I built my own workstations from components. ASUS motherboards. Corsair memory. Western Digital drives. Nvidia Quadro GPUs — because I knew what SOLIDWORKS actually needed from the hardware layer, and commodity boxes didn't deliver it.

Most engineers accepted the computing environment their employer provided. I specified mine from the ground up, because the right hardware is not overhead — it's infrastructure for the work.

I was also the first person at one organization to earn my own PC on my own desktop. Others got them by default afterward. That's how it tends to work when you pull technology: you become the proof of concept, and the institution follows.

I was the first person at that organization to earn my own PC on my own desktop. Others got them by default afterward.

SOLIDWORKS: 25 Years, and Giving Back to the Platform

I started on SOLIDWORKS in version 2001. I am on version 2026 today. Twenty-five years on a single platform is not loyalty — it is mastery accumulated in layers, each version adding capability that I incorporated into practice.

At one point I was the leading contributor of support cases to help evolve the stability of the system. I understood the software deeply enough, and experienced it across enough complex real-world applications, that my cases were materially contributing to what the platform became. I was, in effect, an unpaid member of their development feedback loop.

The through-line from my AutoCAD LISP work to my SOLIDWORKS case contributions is the same: I don't just use platforms. I participate in their evolution.

Python: When the Data Needed Surgery

More recently I wrote programs in Python to clear redundancies in an item master list. The culling and consolidation reduced the data set by almost 60%.

I did not set out to become a Python programmer. I set out to solve a specific problem, and Python was the appropriate instrument. A leaner, more accurate bill of materials foundation — achieved not by hiring consultants or running a six-month ERP cleanup project, but by writing a script.

LISP. BASIC. Python. The language is always in service of the problem. That has never changed.

AI: The Latest Chapter in a Very Old Story

People often describe AI as a revolution in how we work. For me it is a continuation.

I use Claude, Gemini, and Microsoft Copilot as verification engines for cross-domain insights. I don't ask the machine what to think. I tell the machine what I think — and ask it to tell me if I'm right. Instinct fires first, drawing simultaneously from grain elevators, medical devices, textiles, inkjet systems, foundry equipment, and automotive assembly. The AI verifies, challenges, or confirms.

That is the same cognitive pattern I applied with the Apple IIe in 1985. The tool is exponentially more powerful. The method is identical.

I don't ask the machine what to think. I tell the machine what I think — and ask it to tell me if I'm right.

There is certainly something far more refined beyond AI. When it arrives, I will be an early adopter exploiter — not collecting a new tool for novelty, but going deeper into it than almost anyone else, rebuilding what needs rebuilding, deploying it for communities of users who don't yet know they need it, and contributing back to the platform itself.

I pulled the PC onto my desktop before the organization knew it needed one. I rebuilt AutoCAD for 100 users. I filed support cases that helped shape SOLIDWORKS. I wrote Python to do in hours what would have taken months.

Whatever comes next, the pattern holds.

— Robert Tegel | Founder, Tebots Inc. | 30+ Patents | 37 Years of Executive Engineering

#Manufacturing #Innovation #AI #SOLIDWORKS #IndustrialDesign #Tebots #EarlyAdopter #DFM #EngineeringLeadership #ThoughtLeadership #NonLinearThinking #Patents