How did an engineer become a systems thinker?

• Curiosity
• Broken electronics
• Circuit boards
• How things work

I grew up in a small village on Korea’s east coast, between the mountains and the sea. When I was six, I watched a black-and-white television and decided I wanted to become the engineer who built it. In the “future aspirations” column of my elementary school record, I wrote one word: Engineer.

What held me was never what the television showed. It was how it showed it. Near the village was a dumping ground for discarded electronics, and I went there for broken televisions and radios. I carried home the green circuit boards, spread them on the floor, and traced the copper lines with my finger, trying to work out which leg went where and how a signal might travel from one part to another. I did not know the names of the components. I only knew that separate parts, joined by lines, became something that worked.

Later, a computer and a modem on a telephone line connected my small room to the rest of the world. I learned to program on my own, and I spent more time writing programs than using them.

I read biographies of Thomas Edison in those years, and I took one sentence from them that I still believe: genius is one percent inspiration and ninety-nine percent perspiration. When I came to the United States in 2008, I took his name.

• Control engineering
• Robotics
• Speech recognition
• Embedded systems

I studied control and instrumentation engineering, which is the discipline of making systems behave: measuring, deciding, acting, and correcting. It gave formal language to what I had been doing with circuit boards on the floor.

Robotics made it physical. I built a line-tracing robot whose steering motor came from a dead hard drive, because that was the part I could find. Our university robotics club once shrank to two members; we decided to host a national competition anyway, and we did. I learned that a small team with a clear goal and working hardware can do more than a large one with a plan.

In graduate school I worked on speech recognition. My first six months ended in failure. The engine did not work, and I had been building on assumptions I had never questioned. One afternoon in Seoul, standing in front of an antique shop in Insa-dong, I looked at an empty teacup in the window and understood that I had to start again with nothing in the cup. I threw away the six months of code and began from an empty project. Four months later the engine worked.

Then came embedded systems: software that lives inside hardware, where every instruction costs time and every byte of memory is counted. Embedded work leaves no place for theory to hide. Either the device does what it should, or it does not.

• HDMI
• Hardware design
• Firmware
• Product development
• Architecture

My first professional assignment, in 2004, was firmware for one of the first HDMI 1.0 products. The chipset was new. No one in Korea had used it, and there was no one to ask. I had the datasheet, the board, and three months. That was where I learned to read a system from its documentation and its behavior, and to trust neither until they agreed.

Over the next years I designed a television mainboard by hand, wrote part of a video-processing chip in a hardware description language, and automated silicon validation in software. I learned that hardware, firmware, and software are not three disciplines that happen to meet. They are one product, and a decision in any of them changes the other two.

In New York the products became families of products: switchers, extenders, controllers, and eventually systems that ran over enterprise networks. The object of design changed. I stopped designing boxes and began designing the rules by which many devices, from many makers, should behave together. The most important part of the design was no longer inside any one product. It was between them.

Over two decades I visited more than 130 job sites across North America, in conference rooms, homes, and equipment closets. Products that worked perfectly on a bench failed in the field for reasons no one had drawn on a schematic: a cable, a network setting, a device from another maker. The field taught me humility about the bench.

• Factories
• Production problems
• Mass manufacturing
• Supply chain
• Product delivery

My first assignment after joining the company in New York was not at a workbench. It was in a factory in Malaysia, where a mass-production board failed the moment power was applied. The room was full of smoke and worried people. I remember telling the company’s president, “Boss, please calm down. I will fix this board right here myself.” Over more than a month on that factory floor, I found the design fault and saw the product through to production.

A few months later, in New York, I found a second fault in the same product, inside a board that had already been assembled into finished goods. There was no time to redesign it. I rerouted the circuit by hand with more than forty soldered wires, and then trained the technicians to do the same.

Those weeks changed how I see design. In a lab, a component is a symbol on a schematic. In a factory, it is something that must be bought, delivered, placed, soldered, tested, and shipped, thousands of times, without failing.

The lesson returned years later, at much larger scale, during the global semiconductor shortage. Lead times stretched to a year. Some parts could not be bought at any price. To keep products shipping, I redesigned boards around the parts that existed, and once wrote an emulation of a missing chip inside another one so that the rest of the system would not notice the difference. Every one of those decisions was technical. Every one was also financial.

• ERP
• Inventory
• Procurement
• Logistics
• Supplier relationships
• Business processes
• Department coordination

Becoming chief technology officer did not make me less of an engineer. It widened the system I was responsible for until it included the company’s operation itself.

An ERP transformation was the first lesson. Implementing an enterprise system forces a company to describe itself precisely, and most companies discover that they cannot. Processes that everyone believed existed turned out to be habits, or workarounds, or one person’s memory. The software was the easy part. The hard part was the hand-offs: the order that sales had promised and procurement had never seen, the engineering change that never reached the warehouse.

Then came pandemic-era supply-chain shocks and the corporate workforce restructuring that followed. With fewer people carrying the same products, I took on procurement, contract manufacturing, inventory, logistics, and customer delivery alongside the technology role. I learned to read inventory as cash sitting on a shelf, a supplier relationship as a form of reliability, and a purchasing decision as a commitment the whole company would live with for months.

None of this was a career plan. It was the work that needed doing. But it showed me the company the way I had always seen a circuit: as parts that work only when the connections between them work.

I did not become interested in organizations by studying them. I became interested in organizations after spending decades building systems. Eventually I realized that products, operations, and organizations fail for the same reason: their interfaces.

• Team leadership
• Technology leadership
• Executive accountability
• Decision making
• Trade-offs

I became a leader of engineers the way many engineers do: by being the person people came to when something was broken. Leading more than twenty engineers and fifteen offshore technical partners taught me that a team, like a product, fails at its interfaces. The most expensive problems were rarely a lack of skill. They were two capable groups that did not share a language, or a decision that one group assumed another had made.

As an executive, the trade-offs changed shape. An engineering decision was also a cost decision, a schedule decision, a supplier decision, and a customer decision, all at once. I learned that executive decisions are rarely purely technical, operational, financial, or strategic. They are usually all four, and the job is to see all four before choosing.

I also learned what I will not delegate: the responsibility for the result. A title gives permission to decide. It does not make the decision right. When a board is on fire, or a supplier cannot deliver, or a process breaks between two departments, the leader is the person who owns the outcome and stays calm long enough to fix it.

Looking back, the work divides into stages that look very different from the outside: circuit boards, firmware, products, factories, supply chains, departments, leadership teams. From the inside they were the same problem at different sizes.

Throughout my career, the scale changed. The principles did not.

Products are systems. Teams are systems. Operations are systems. Organizations are systems. Each has parts, connections, and signals, and each fails most often where one part hands something to another.

This is why I distrust explanations that blame a single component, whether that component is a chip, a department, or a person. When a system fails, the useful question is rarely “What broke?” It is “Where did the connection fail, and why did no one see it?” That question has served me on factory floors and in executive meetings alike.

Systems thinking also explains why organizations last. The ones that endure keep what they know in processes and records, not only in people’s memories. They transfer expertise before it leaves. They survive transitions because their connections were designed, not improvised. I have come to see that as the deepest form of engineering there is.

Everything above comes down to a small number of principles. None came from a book. Each came from something I built, broke, fixed, or carried.