In August 2006, a man named Brian Schlichting — Naveed Kakal's first boss then, his colleague still — made a hiring decision on a hunch. The candidate was a fresh electrical-engineering grad whose main professional credential was managing car washes. Schlichting reasoned, in Kakal's telling, that car washes had "spiritual similarities to laundry controls," and he wasn't wrong: machines, water, valuable things moving through a tunnel on a schedule. Kakal had simply been practicing on cars. The job was on the controls team at ETECH in Minneapolis, relieving a small crew burning out on workload and travel, under a title — "ICS Systems Engineer" — that he suspects was invented the week he was hired. Small shops don't need real title ladders; everyone can see what everyone actually does.
What everyone actually did, in 2006, was keep laundry plants running on the GE automation package: 90-30 PLCs on the floor, Cimplicity HMI screens above them. The villain of this story is not that hardware. It's the licensing model. Cimplicity charged per computer, and a laundry plant is exactly the kind of place that wants a terminal on every post — soil sort, wash aisle, finishing, the manager's office. Every screen was a line item. The floor wanted eyes everywhere; the invoice said pick two.
So in 2007, Larry Erickson — employee number one of this saga, the lgerickson whose name opens the version-control record — started asking a question that was close to heresy in industrial automation at the time: what if the HMI was just a web page? The record shows him finding out alone at first: October 29, 2007, initial import, Rails 1.2.6. SOAP calls poking PLC points. A "main program" that launched when Windows booted. A mid-project upgrade to Rails 2.0 over Christmas. And in the spring, a commit message for the ages: "Weekend of Fail."
Improving the condemned
Here is where the story goes somewhere most engineering careers don't. While Larry chased the new platform, Kakal's job was to keep the old world running — and he did considerably more than that. "I was really improving the old system more than anyone thought was possible," he says, "while it was being decommissioned." He learned the business by learning the tools the company had already agreed to kill, and then pushed those tools past what anyone believed they'd do.
On paper this sounds like effort poured down a drain. It was the opposite, and understanding why is maybe the most transferable thing in this whole story. Every improvement he forced out of the dying GE stack mapped its true limits — not the rumored limits, the real ones. And every real limit became a specification for the successor. The old platform couldn't say what the new one needed to be, but it could say precisely where it hurt. "Where our old tools limited us, we had a new platform ready to carry the conceptual torch," he says, and then, with feeling: "which we hella did."
He calls that stretch the most formative of his career — the era he still reaches for "when thinking about how to do anything conceptually new on an existing domain." Which, two decades later, describing AI-era product work, is more or less his job description.
Click to force
The proof that the torch actually got carried is specific, and it's a good one. On some of the last 90-30 plants, Kakal built a UI trick: click a sensor on the screen and it forces the input in the controller. Suddenly you could run imaginary goods through a real control system with your fingertip — trip a sensor, wait ten seconds, watch the device react. Miss the window a real bag would have hit, and a real alarm fires. The plant, playable. It made testing tactile, and it made commissioning faster, because you could exercise the logic without hanging linen.
That trick became the testing standard for the new platform — "we ran bags around using click-to-force," he says, and the new system supported it from day one. And here the tape delivers a small miracle of corroboration. Kakal told this story from memory, nineteen years out, unprompted and unhedged. His second week ever in the version-control record — r361, March 12, 2009 — reads: "Working on force." The concept crossing from the condemned system into the new one, timestamped, exactly where he said it would be. The interviewer checked. His memory of that era, it turns out, runs sharper than most people's memory of last quarter — which tells you something about how hard those years imprinted. The line runs unbroken from that commit to November 2025, where he's still tuning simulated weights in the same subsystem. One idea, seventeen years of tape, first taught to a machine that was already scheduled to die.
The final 10%
The crossing itself wasn't dramatic. Larry's R&D reached the point where a cutover was real, and closing the distance became Kakal's job: "the final 10% on almost every feature," proof-of-concept to v1. The record shows what that looked like — the repo's activity explodes from 71 revisions in 2008 to 1,191 in 2009, the year he arrives. R&D gets you a demo. The final 10% is where somebody decides a plant can bet a shift on it.
Then came the part you can't simulate. In the fall of 2009, Kakal and Erickson commissioned the new system at Angelica's Los Angeles plant. The first night ran so close to the edge that the two of them slept in their cars. The years around it were, by his cheerful accounting, travel "on a hope and a prayer" that the current technical issue wouldn't detonate mid-project. Two self-taught web developers, no seniors anywhere to ask, a database they were learning in production — "what is an index?" — on Rails 1, a framework the wider internet was still skeptical of, in an era with hardly any Stack Overflow to fall back on. It had existed for about a year.
The failure mode of that education wasn't ignorance; it was mislearning. "We'd often learn the wrong lesson from an experience," he says, "or not understand the root cause until years later." Early on, every behavior in the system was treated as suspect, and days went into tracing code that ended with the debugging koan he still quotes: it did exactly what it was written to do — we just designed it wrong. Features got rewritten fast, sometimes with architectural hacks he freely describes as terrible. None of the projects got hard-abandoned. Almost none of them went to plan either.
Trust, again
What made the difference — and readers of the last case file will feel the rhyme — wasn't technical at all. "Establishing trusting relationships gives you space and time to figure out problems on bespoke systems," he says. "If they trust you, they'll leave you alone to fix it right. If they don't trust you, you'll never have a peaceful project even if everything is going well." In the 2012 Ottawa story, he spent banked trust to survive a catastrophe. In 2009, sleeping in a car outside a Los Angeles laundry, he was still making the first deposits.
Comfort took a year or two after the cutover; the complexity-versus-automation tradeoff didn't resolve cleanly for a while. The moment they knew the bet had paid was procedural, not triumphant: the day they could say, with process in place, here is what a project build looks like — and mean it.
Ask what outsiders get wrong about all this and he goes straight at the modern imagination: people picture migrations as project-management black holes, dozens of meetings confirming that nothing has moved. "We had none of that. We were super lean and had full agency to design the future." The genuinely hard part wasn't Rails and it wasn't the PLCs — it was cultural. Internet connections to the plant computer weren't standard. A system you could update remotely was a strange and mildly alarming idea, and selling it meant chipping away at habits that ran through sales and service, not just engineering. The web part was a bet; the trust part was the work.
The condemned GE stack, for its part, went out with more dignity than most systems get: improved to the end, mined for every concept it could donate, its best trick — click a sensor, force the point, watch the plant respond — still alive in its successor's testing tools seventeen years later. There are worse legacies for a machine. There are worse teachers for an engineer. ❦