My parents came to the United States for my graduation ceremony and stayed to travel a bit. For me, that also meant my first real stretch of time off since I started working. This post is mostly about a few work lessons that surfaced during that pause.

A quick bit of context for anyone wondering why the ceremony is only happening now. In a typical US PhD commencement, hooding—your advisor placing the academic hood on you—happens once a year. I defended at the end of April last year, which meant I missed last year’s ceremony, so I went back to Ann Arbor this year for hooding.

I started my job on May 12 last year. This break runs through May 13, so before I left I had already worked my last day of the year that started when I joined on May 12 (no small satisfaction).

I was not planning to write any of this, but I could not sleep, so here we are.

Before I left, a senior colleague in my group asked whether I had been working for about a year and a half. I said I still had roughly two weeks to go. The look on his face was priceless—and fair enough. When I first joined, I had no real idea what I would end up doing. Since then I have touched four chiplets, plus a pile of other things. In hindsight, it has been a wild ride.

Working near Jim is its own kind of experience. I have not spent much time with him one on one, but his style and philosophy show up everywhere in how the company runs. What follows is mostly my own thinking.

From here on, nothing to do with the trip or the ceremony—just work thoughts that have been rattling around in my head.

Notes from work

The hardest part of chips is management

People often ask what has stuck with me most since leaving school. My answer: management and leadership are wildly underrated. Everyone agrees that architecture, power, performance, interconnect, packaging, software, and so on are hard. They are—but most of that can still be attacked as a stack of technical problems. The hardest part is getting your chip to actually tape out, ramp, and behave for real customers. Anyone who has done this work knows how much weight sits in that sentence: threading the full flow is enormously complex. You need people on architecture and modeling, you need vendors and suppliers, and inside the company you need arch, SoC, IP design, physical design, verification, systems, software, product, and more to stay aligned. Every handoff can hide a long tail of issues. If you also have to stick to schedule, the tradeoffs among performance, schedule, and cost never stop moving. Almost any step can become the bottleneck—which means the real difficulty is often how you manage the whole messy process. When I say management here, I do not mean only the people manager on an org chart. Who owns priorities, who is the named interface for each thread, which escalation path fires when something slips, and whether recurring meetings still earn their calendar time—all of that counts. A common failure mode is simple: architecture interfaces are still moving while implementation windows are already frozen, and teams end up patching around avoidable misalignment. Good management really is the foundation. How to do it well is homework for another day; maybe I will write up some of what I have learned later.

Closing the product loop

As above: semiconductor cycles are long. Someone can finish a project and move on, and their piece may not reach a user for another year or two. If feedback gathered by customer-facing teams does not find its way back to the teams upstream, the same mistakes get repeated over and over again. Beyond “someone should tell the architects,” postmortems, cross-team reviews, and searchable design notes are often the smallest set of habits that keep lessons from evaporating. The missing piece is usually explicit ownership and trigger conditions: for example, who convenes a cross-team review within two weeks after a P0 customer incident. Hardware simply is not as short-cycle as software; feedback arrives late by nature. Closing the loop under those constraints is harder, not easier.

Using AI

Last year I was still coding the old-fashioned way; at today’s model pricing and my current usage, burning on the order of a hundred dollars in tokens in a day is no longer surprising. Wild. Using AI well is less about tools than about a change in mindset: from “first I understand the thing, plan how to do it, then execute” to “what does done look like, what information do I need, how do I know it worked, and how do I consolidate the method so I can reuse it.” That shift is often the hardest part. It also does not mean every step should be delegated to AI; high-risk calls, cross-team commitments, and final sign-off still need clear human ownership.

Generality wins

Jim said something along these lines recently (not a verbatim quote—paraphrased from memory): everyone talks about specialized hardware, but models move fast enough that anyone betting the farm on narrow specialization ought to be nervous. In the history of products shipped at real scale, designs that are over-customized rarely win. Everyone thinks they know where LLMs and AI are headed, yet even small architectural changes inside a model can have meaningful implications for hardware—not to mention multimodal systems and the diversity of models and data later on. So what people need is not necessarily a faster inference chip, a faster training chip, or a faster agent chip. They need a better AI computer. I mean computer. Plenty of people know how to design silicon or write software without really understanding how a computer works. We need a better computer. It is a system problem.

Time to catch a flight. That is enough for tonight.

If I get a chance later, I want to write a follow-up focused on practical management and feedback-loop mechanics.