Engineering optimization is often flattened into a math problem. Improve performance. reduce waste. tighten the model. repeat.

Jacob Freking offers a more mature version of the idea. In his telling, optimization is never only about maximizing a curve in simulation. It is about deciding what matters, preserving enough margin for reality, and moving quickly enough to learn from actual hardware before a team disappears into theoretical perfection. His perspective comes from a career spent in RF wireless systems work across antenna design, testing, performance analysis, integration, and startup execution. Rather than treating optimization as a narrow technical exercise, he treats it as a broader discipline of judgment.

That shift is what makes Freking more than a capable practitioner. He emerges here as a thought leader on engineering optimization precisely because he understands it across layers: the design layer, the workflow layer, the organizational layer, and the educational layer. Plenty of engineers can talk about tuning a model. Fewer can explain why teams stall, why curiosity needs limits, and why “good enough” is sometimes the most responsible technical decision in the room.

A systems engineer by temperament, not just by title

Freking’s background helps explain that stance. He did not enter college with a rigid specialization in mind. Electrical engineering appealed to him because it offered breadth, complexity, and room to avoid boredom. Over time, he drifted toward RF and electromagnetics, then further into the antenna and wireless domain. What he found there was not confinement, but a center point.

“I get the best of all the different kinds of problems.” … “I kind of get to be a center point… in a lot of these system design discussions.”

Those lines are revealing. Freking does not describe engineering as a solitary depth exercise. Instead, he values the position of the engineer who has to speak across embedded systems, software algorithms, signal processing, circuits, and RF specialties. What emerges is a profile of someone whose authority comes not only from technical depth, but from the ability to interpret tradeoffs across a whole system. That kind of perspective is exactly what makes a useful public thinker inside engineering culture, especially in a moment when cross-functional work is increasingly the norm rather than the exception.

The turning point was not abstract. It was physical.

Early in his career at Raytheon, Freking knew one thing clearly: he wanted to be hands-on. Hardware had to be seen, touched, assembled, tested. Then came the moment that seems to have shaped much of his working philosophy. A senior engineer and mentor, Ryan Cutshaw, asked whether he wanted to help build a new antenna chamber.

“It sounded like the perfect mix of everything that I’d been wanting to do, very hands-on. And that was kind of a turning point for me.”

That project became more than an assignment. It became an apprenticeship in the real conditions of technical work. Freking learned the chamber’s theory, its failure modes, and the practical errors to watch while assembling it. Later, the lab became a kind of incubator: different programs came through, testing happened under real constraints, and that exposure pulled him into broader integration work. Expertise, in other words, was not delivered as a credential. It was built through responsibility.

A useful profile of Freking starts there because the story explains his larger philosophy. Engineers who live close to hardware tend to develop a sharper feel for what optimization is actually for. Numbers matter. Simulation matters. Geometry matters. Still, hardware eventually asks a blunt question: does it work, and does it work under the conditions that matter? Freking’s answer to engineering optimization is grounded in that physical reality.

Engineering optimization starts before the final design

One of Freking’s strongest ideas is that optimization begins in the workflow itself. Antenna work, as he describes it, often follows a structured path: system requirements come first, known designs are adapted or recreated, frequency scaling happens, and the array is sized to hit the needed performance. Because parts of that process are repetitive, he looks for ways to automate them.

“What I find interesting is ways to make that easier.”

Scripts, code, and repeatable analysis patterns are not secondary conveniences in this framework. They are part of the optimization effort. A team that wastes hours on avoidable repetition is not being rigorous. It is leaking attention. Freking’s viewpoint is valuable because it broadens the keyword itself: engineering optimization is not only about the artifact at the end. It is also about improving the path that leads there.

That makes his argument especially relevant for startup hardware teams. Speed is not just a business preference. Speed is how technical organizations learn before cash, time, or internal alignment run out. Freking’s process mindset gives that speed a disciplined shape rather than a reckless one.

“Good enough” is a technical standard, not an excuse

Many engineers can describe perfection. Freking is more interesting because he can describe stopping points.

“You have to know when to call it good enough and move on to the next step.”

At first glance, that line sounds modest. In practice, it is the heart of the piece. Freking is not arguing for sloppiness. He is arguing against false precision. He explains that best practice is to analyze designs across manufacturing tolerances and verify that specs still hold. Even so, he also notes that sufficient margin often tells you something crucial: the design is likely robust enough to proceed without endless extra sweeps.

“Typically if you just get enough margin in there, it’ll work well enough hardware.”

To reframe optimization as judgment under uncertainty is, in my opinion, true thought leadership. Plenty of technically literate people know that more analysis is always possible. Freking pushes the conversation toward a harder question: when does more analysis stop producing proportionate value? His answer is rooted in manufacturability, tolerance awareness, and the practical realities of hardware development. Especially in phased arrays, where scan angle introduces still more data and reflected-power variation, the engineer’s task is not to eliminate complexity. The task is to decide which complexity deserves time now.

Why engineering teams mis-optimize

Freking’s most broadly useful insight may be organizational rather than purely technical. When projects struggle, he does not default to blaming individual weakness. He points instead to conflicting definitions of success.

“It seems like it’s a misalignment between whatever leadership on that program is and their end stakeholders.”

That observation deserves to be taken seriously beyond RF. Stakeholders may want something fast, functional, and good enough to learn from. Leadership shaped by legacy programs may still optimize for thorough documentation, maximum certainty, and first-pass completeness. Each stance has logic behind it. Problems begin when both goals remain active at once, unspoken and unreconciled.

Freking’s diagnosis is sharper than a generic complaint about communication. He is really describing competing optimization functions inside a single organization. One group is optimizing for learning velocity. Another is optimizing for risk minimization. A third may be optimizing for process hygiene. Once those definitions split, teams inherit confusion.

“You’re always going to learn something the first time around. And the faster that you learn it, the faster you can iterate on that and get it right.”

That line is one of the strongest in the interview because it scales. It applies to antenna work, simulation work, and product development at large. Just as important, it positions Freking as someone thinking beyond his subdiscipline. He is not only describing how to optimize hardware. He is describing how to optimize the organization that has to build hardware.

Startups cannot afford unlimited curiosity

Popular startup mythology treats curiosity as an unquestioned virtue. Freking introduces a more sober view. Early-stage work certainly requires “what if” thinking, and he acknowledges that exploratory thinking likely helped get the company founded and funded. Daily execution, though, operates under a different logic.

“I try to minimize how much of the what-ifs I’m actually doing.”

“To be fast, it has to be something that’s been done before and scalable too.”

That is not anti-curiosity. It is pro-throughput. Mature engineering optimization means budgeting curiosity instead of worshipping it. Exploratory thought creates possibility. Reusable methods, trusted models, and disciplined follow-through create viable products. Freking’s distinction is a strong corrective to the idea that the smartest technical culture is simply the most open-ended one. Sometimes the smartest culture is the one that knows when a rabbit hole will cost a sprint.

Tools tell the truth about the model you actually built

Freking’s remarks on simulation tools sharpen the same theme. He speaks favorably about Ansys HFSS, but his trust is conditional and instructive.

“As long as you set the model up right, it’ll give you the right answer.”

This is not really a software quote. It is a philosophy-of-engineering quote. Solvers solve the problem they are given. Teams optimize for the incentives they are handed. Metrics reward the behavior they encode. Error often begins upstream, in the formulation of the question itself. That makes Freking’s point broader than tool preference. It is a claim about technical honesty. Engineers should trust models, but only in proportion to how well they understand the assumptions and setup underneath them.

His education argument adds credibility, not controversy

Freking turns to engineering education. He argues that universities still offer useful discipline and habit formation, but he also suggests the industry should be more open to self-taught engineers, given the sheer amount of high-quality technical instruction now available online.

“You can find all the lectures that you would have had through a college course on YouTube for free.”

“It kind of makes sense to have more self-taught people where they come in just with the basic understanding… and then learn the rest on the job.”

His point lands because it is balanced. Formal education still builds discipline. Universities still matter. Yet real engineering competence continues to deepen after graduation, often through work itself, and increasingly through distributed learning environments. Freking’s comments fit broader conversations in engineering education. ABET’s current accreditation criteria say engineering programs should foster the “systematic pursuit of improvement” in a “dynamic and competitive environment,” while the National Academy of Engineering’s Engineer of 2020 work argues that engineering education must adapt to changing practice and prepare engineers for broader leadership roles.

Seen that way, Freking’s position is not fringe. It aligns with a long-running institutional recognition that engineering capability depends on continuous learning, adaptation, and the ability to grow beyond the textbook baseline. His contribution is to say that clearly from inside practice rather than from inside policy.

Why Jacob Freking reads as a thought leader

Thought leadership is often confused with charisma, volume, or futurist spectacle. Freking offers something rarer and more durable: a usable philosophy of work. He explains why optimization belongs to the workflow as much as the design, why margin matters more than fantasy perfection, why teams fail when they optimize for competing outcomes, and why engineers need both rigor and stopping rules. His comments never read like slogans detached from practice. They read like ideas earned through contact with hardware.

That makes him an especially strong Hardware Rich Development subject. Freking does not merely represent one technical niche. He represents a style of engineering intelligence: interdisciplinary, physically grounded, skeptical of over-optimization, respectful of education but realistic about its limits, and deeply aware that the first version of a product teaches what the cleanest model cannot. For an audience trying to think seriously about engineering optimization, that is a perspective worth foregrounding.

Recommended Quilter.ai internal links and where to place them

I’d add these as in-line internal links rather than a “related reading” dump at the bottom.

1. Anchor phrase: “systems work across disciplines”
   Place it in: the section “A systems engineer by temperament, not just by title”
   Link target: Carol Erikson on Systems Thinking, Technical Leadership, and Building Teams That Actually Work
2. Anchor phrase: “the generalist path in hardware”
   Place it in: the paragraph about Freking operating between embedded, software, signal processing, and RF
   Link target: On T-Shaped Engineers and Hardware Development: Transparency and the Generalist Path
3. Anchor phrase: “trust through technical transparency”
   Place it in: the tools/model-setup section, right after the HFSS discussion
   Link target: Transparency, T-Shaped Engineers, and FPGAs: Interview with Jami Friedman
4. Anchor phrase: “design for manufacturability and robustness”
   Place it in: the “Good enough is a technical standard, not an excuse” section
   Link target: Design for Reliability, Design for Manufacturability: Building Smarter Test Systems
5. Anchor phrase: “what technical leadership actually looks like”
   Place it in: the “Why engineering teams mis-optimize” section
   Link target: What is a Technical Leader? Derrek Cooper’s Answer
6. Anchor phrase: “curiosity under real engineering constraints”
   Place it in: the “Startups cannot afford unlimited curiosity” section
   Link target: Curiosity in Power Electronics: Reflections with Jovana Plavšić

‍