I had been at Apple four months when they sent me to a factory in China, and I thought I knew what I was going for. Electronics. Pick-and-place machines. Testers. The drama, I assumed, would be electrical. The drama turned out to be a mop. Specifically: whether an operator could bring a mop into a cleanroom, how the mop got in, where it had been before it got in, and who had written any of that down. Nobody had. That was the trip.
I came home with three lessons and one line. The lessons: a Systems EE's real job happens on the line, not on the schematic; you have to know exactly what you want and then be a pain about getting it; and nothing, at this company, gets done on a hunch. The line is the title. After the three lessons there is a section about the email I wrote every night, which is where I found out what I actually think about the place. First, the boring facts, and a note on what isn't here.
- what
- an early build at a contract manufacturer's factory, two weeks on the floor
- when
- August 21 to September 6, 2026 · four months into the job
- where
- a factory outside Shanghai · the hotel and the shuttle are in the other post
- who
- my team, our in-region engineers, and the factory's engineers · one senior engineer I'll call Wen
- what's not here
- what we were building, who built it, and any photo of the line. The lessons are mine; the product isn't.
- the other post
- the personal half, the tunnel and the agoraphobia, is here
## 1. Walk the line
Here is what I thought a Systems EE was, four months in: my job at Tesla with a nicer badge. Design the board. Own the schematic, argue about parts, get it through bring-up, hand it off. I now think the schematic is the easiest thing we do. The job is taking everything the research teams at Apple have figured out, putting it on a page, and then making that page buildable, which means making sure that a few hundred people you've never met, working in a language you don't speak, can make ten thousand of it without any one of them having a bad Tuesday. The first part takes a month. The second part is the career.
I learned this by spending my first week following Wen around. Sixteen years at Apple, fluent in Mandarin, knew the game inside and out, and for reasons I still consider luck he let me shadow him, take notes, and write the nightly build report. Here's what he did all week: he ignored the electronics. The functional testers, the thing I had flown there to care about, got maybe an hour of his time. The rest of it he spent walking the line, watching operators' hands, pointing at things. When he really needed a point made he'd bark it in Mandarin, and with enough context I could follow: that carrier, that flip, why is she touching that twice. The factory staff, who were new to each other and barely keeping the place running, did not always love him for it.
Then the mop. Wen found an operator in the cleanroom with a mop that had, visibly, been somewhere else first. He took a picture. He brought it to the biggest cross-functional meeting of the day, in front of everyone, and then he followed up every single day until two things existed that hadn't: a written procedure for how cleaning materials come in and out of the room, and a way to match the next unexplained speck of foreign debris against mop fibre, using its FTIR catalogue. A mop is not an electrical problem. It is exactly the kind of thing I would have walked past. I think that is the whole point of him.
I've been chipping away at a master's in industrial engineering for years, slowly, and until this trip the lean vocabulary was vocabulary: gemba, value stream, takt, 5S, poka-yoke. Watching Wen, it all clicked at once, and what made it click was that he had never been taught any of it. He just lived it. In the other post I quoted Chrissy Meyer telling The Amp Hour that glue machines were the bane of her existence. Ours were tapes and carriers: how many different carriers one small thing could ride in, how many times a human hand touched it, how many flips it took to get both sides through the machines. We spent whole afternoons on that. It was the best part of the day.
Somewhere in that week I wrote down the line I keep coming back to. I thought I'd borrowed it from a podcast. I can't find it, so it might be mine:
> A factory is a place where about a million actions happen every day, and pretty much every one of them has to be directionally correct for the thing rolling off the end of the line to work.
You can't watch a million actions. So the job is to make each one as simple as it can be and to write every one of them down, because an action nobody has described is an action that will, eventually, be done wrong. Murphy isn't a pessimist at that scale, he's a statistician. It is also, I think, the real meaning of the story everyone at Apple tells about Steve Jobs's father and painting the back of the fence. I used to hear that as a story about craftsmanship. On the line it reads as arithmetic: the details you skip are the ones that ship.
## 2. Know what you want, then be a pain about it
The second thing about Wen was that he could see the factory he wanted. Not roughly. Exactly: where the unit should be at nine in the morning, which station should have caught which failure, what the operator's hands should be doing. He had spent two and a half weeks there before I arrived, and he was still following up on things he'd asked for in week one, and he expected an answer. He hounded people. The internet keeps trying to name this trait, high agency, conviction, founder mode, and none of the names are as good as watching it. What it looked like from behind him was simple and very hard: decide precisely what done looks like, then refuse to let anyone, including yourself, stop short of it.
Part of how he did it was volume, and this is the part I'm still working out. Our in-region engineers and the factory's engineers would go at each other in a way I'd never seen at work. We asked for this by today and it isn't done, what is wrong with you, at full volume, and then, in the next breath, laughing together about something else. I grew up in a house where I can count on one hand the times anyone raised their voice. I am conflict-averse to the bone. So I watched this with something close to alarm until one of the in-region engineers, who is a mother, gave me the frame: they were tiger-parenting the factory. Be hard on it now, while there are ten units on the line, so that nobody has to be in agony later when there are ten thousand and the same mistake is holding up a batch. And the factory, as far as I could tell, took it as care.
Here is my honest problem with that. I don't think I get to do it. Not because it's wrong, but because I'm a white guy from Newfoundland who doesn't speak the language, and the same words out of my mouth wouldn't land as tiger-parenting, they'd land as a foreigner shouting. And I also don't get to go easy, because going easy on a factory is how you end up with a dirty mop in a 1k cleanroom. The best I've come up with is a middle: cold, blunt, specific, written down, and relentless about the follow-up. Wen without the volume. I tested it once on this trip, in a lab, on one supervisor, and it worked. October is whether it works on a line.
The lab was where I got to try the other half, the vision half. Technically I'm the test lead for this module, which means I own the testers on the line and the procedures for what happens to a unit after it fails one and gets pulled off. The failure-analysis lab was a room full of new-grad EEs and three supervisors, all hired by the factory, and I spent my first afternoons just sitting in it. Gemba, if you like. What I saw was this: to get any data out of a failed unit they were hand-reworking a connector with a pitch measured in microns, hanging bench equipment off it, and poking registers one at a time through a third-party probe. Hours per unit. We had shipped them a proper debug board that should have plugged straight in. Why weren't they using it?
Software. The debug board talked to the chips on the module through a bridge chip with a thousand-page datasheet, and the software that came with it let you read and write that chip's registers and nothing else. Twenty reads and writes to get one number you cared about, if you'd configured it right, which took most of a morning. The lab EEs agreed with me: the software was ass. So I said I could make this one click. Hook up the flex, pick a test, click, get the data back. One of the in-region engineers, the same one with the tiger-parent frame, rolled her eyes. Have you seen the register map?
It took a few days, and I wasted one of them, out of pride, trying to reverse engineer how the board talked before I did the obvious thing and asked the team that built it. By the morning the next batch of failed units came back from the line, the test they'd failed was reproducible in one click, with the numbers. I told her at triage. Eye-roll again. Then I went to the lab, which had no Wi-Fi, so I'm sitting there on my phone's hotspot next to a supervisor who is elbow-deep in a rework, and I tapped him on the shoulder and showed him the data coming back, clean, at the precision the bench gear had been fighting for. He lit up. For a week I had been the foreigner typing in the corner of their lab, and that was the moment I stopped being one. He wanted it on his own laptop, and he fixed the Python environment himself to get it there, which taught me a separate and painful lesson about software portability.
I want to be careful about the moral, because the easy one is wrong. The easy moral is San Francisco beats we've-always- done-it-this-way. But Wen is the least San Francisco person I have ever met and he is the best I've seen at this. The real moral is that I did the same thing he did, at a smaller scale. On the first afternoon in that lab I could see what failure analysis should look like: a unit comes off the line, plugs into the debug board, and gives up its data in a minute instead of an afternoon of rework. Then I spent days writing code toward that picture, past an eye-roll at triage, past a lab that didn't know why I was there, past my own detour into reverse engineering, and I didn't stop until a supervisor had it running on his own machine. A precise picture of the room working, and no willingness to leave until it did. The tool was mine. The method was his.
## 3. Nothing on a hunch
The third lesson is the one I have the least standing to preach. When a test starts failing on a line, everybody says the same sentence: I think we should calibrate the fixture.It is the manufacturing equivalent of turning it off and on again. On this build one of our impedance tests drifted, the whole distribution shifted up, and the answer was not the fixture. Someone had added grounded metal near the probe head, and it was enough to move every reading. We found that out by walking onto the line, pulling the pogo pins off, and measuring. Not by reasoning about it in a conference room. The data was sitting there the whole time; it just wasn't in the room.
I thought Tesla was a data-driven company. It is, by most standards. But looking back now, I can see how much we did at risk, on a hunch, on the strength of a senior engineer being pretty sure, and it worked out almost every time. Apple does not do that. Any change to the process needs testing, and not a little: enough samples to be sure you aren't aliasing. I think there are two unglamorous reasons Apple can afford this and Tesla mostly couldn't. The boards are cheap, so a hundred samples is nothing. And the teams are deep, so handing someone a new recipe and saying "chase this for a week" costs nobody their real job. Under those conditions, nothing on a hunch is not a personality trait. It is just the cheaper option.
The honest limit: sometimes I thought it went too far. There were things the whole room was sure about, and they wanted the data anyway, and at Tesla the room's confidence would have been enough. But here is the thing I have to admit about my own confidence. I don't have any yet. I am too new to have good suspicions, and the couple of times I thought I did, I was wrong. So for now the data isn't a philosophy for me. It's the only tool I actually own.
So it makes sense that the part of the trip that surprised me most, given I went as an electrical engineer, was how much of it was statistics. Statistical process control, setting test limits at six or nine sigma, Cpk, why a bimodal distribution is a confession, why you compare the same test across builds and across testers at different points in the process before you believe it. I start a graduate statistics course for engineering managers in two weeks, and for the first time I know exactly what I want out of it. One more note for the nerds: a language model (an internal one, before anyone panics) turned out to be very good at the data farming, the Cpk, the charts, the outlier and multimodality hunts, and I recommend it without reservation.
- Everything in the flow is "at risk" until it passes a tester. You place testers, AOI and AXI through the process so that when something goes wrong you can tell where, not just that.
- Package strain moves a bandgap reference. It's the piezojunction effect: stress shifts the base-emitter voltages the reference is built from, and plastic packaging alone can move one by millivolts. At Tesla we only cared about strain when chips popped off the board.
- Reflow sets a solder joint's microstructure and heat coarsens it for the rest of its life, which is why time above liquidus is a reliability number and why factories run their ovens as cool as they can get away with.
- Hot-bar temperature has to match the flex laminate: a higher-temperature solder wants a polyimide flex, and LCP only gets you so far.
- Failure analysis is a catalogue, and knowing which tool to reach for is the craft: cross-section (done by hand, which shocked me), CT, FTIR, EDS, and the AOI/AXI images you already paid for. EAG's technique index is the best map of it I've found.
- Incoming and outgoing inspection, die handling and tape choices, and gauge R&R. I have a list.
## The build report
Every night I wrote the build report, the email to Cupertino about the day. It taught me one thing about time, one about what people read first, and one about culture. The first is that Cupertino is always behind. Our team was half a day behind the line, because the line moved while we were in meetings. By the time we'd caught up at the twice-daily cross-functional and written it down and Cupertino had woken up and read it and decided something, they were a day and a half behind. Which is an argument, if you needed one, for lesson one: the decision belongs to whoever is standing on the line.
The second is what goes at the top. Material flow. Senior people want to see that units are moving and nothing is stuck: the batch names, where each one is, what it's going through. Then the day's failures, which scale directly into parts per million. Then the notes. I put a fun photo at the bottom every day and people mentioned it when I got home, which I choose to take as praise.
The culture thing: they asked me to stop putting emojis in it. It was a tell for something I noticed everywhere on the trip, including shuttle rides with no small talk in them. Apple takes itself extremely seriously. Earnestness reads as weakness; goofiness reads as not understanding the stakes. I don't love it. I also can't argue with the hardware it ships. And I can't rule out that some of what I read as culture is class. Everyone on that trip had a master's or a PhD from a school you've heard of. I have a bachelor's from a Canadian school you haven't, from a half Irish Catholic, half Anglican working family in Newfoundland that shaped how hard I work, and that is the only thing that has ever gotten me hired.
Here's what the no-name school bought me. I got a lot wrong on this trip. I asked Wen things and was wrong. I asked questions in the big meeting and was wrong. I thought I had let go of the pride that minds that, and then it cost me a day in the lab. But I want to learn more than I want to look smart, and what surprised me is how often the dumb question paid out for someone else. In our Systems EE breakouts I'd ask one and someone five years in would go, "huh, yeah, why do we do it that way?" or "huh, what does that acronym actually stand for?" The dumb question is a service. It is also the only version of Wen's barking I'm allowed.
## October
I go back in October, to a different, much more mature factory where a lot less goes wrong, and I plan to spend it doing what Wen did: ignoring the electronics, watching hands, and taking notes on what a line looks like when it's dialed in. Then, on the next build, back to a line that isn't, with a better picture of what I'm trying to make it into.
Because that is the gap, when I'm honest about it. Wen could see the factory he wanted. I can't yet, not exactly, not operator by operator. What I have instead are the two things I own: the data, because I have no hunches yet, and the dumb question, because it is the only bark I'm allowed. Wen saw a mop. I would have walked past it. A million actions a day, every one of them directionally correct, and October is for finding out what else I walk past.