From Sliced Bread to Patent - second-hand-tigers/badocter-career-learnings GitHub Wiki

Learning Hub › Career Learnings Directory › Dr. Docter's Career Learnings › The Renaissance Engineer › Mentoring Integration with Stage Development

From "Sliced Bread" to Patent

The Mentoring Integration with Stage Development page tells a condensed version of this story under the internal codename we used for years: "Sliced Bread." I don't need to protect that codename anymore. The technology matured far enough that it was eventually issued as a real U.S. patent under its actual name, with a dozen people's names on it — which means the fuller version of this story gets to end with all of them properly credited, not hidden behind initials. This is that fuller version.

The Blind Spot I Didn't Know I Had

JD mentored me on this technology — a Real Time Optimization (RTO) solution-analysis tool — while I was a junior engineer on his team at ExxonMobil Research & Engineering, doing remote support work for several manufacturing sites (see the "Global Network Action Team Lead - RTO Solution Analysis" line on my Antwerp entry — this is that same technology area). I helped JD test it, but I genuinely couldn't see a real use case for it. For about six years I'd been doing remote support for sites that only ever called me for one reason: the application had crashed, and they needed it running again. Nobody ever called with a question the analysis tool would have actually helped answer.

That pattern of calls left me with a completely reasonable, completely wrong impression: that keeping the application running was the business need, full stop. I had six years of consistent data telling me so. This is exactly the trap described elsewhere on this wiki as "what you see is all there is" — I wasn't ignoring evidence of a deeper need, there simply wasn't any evidence of it reaching me from where I sat.

Landing in Antwerp Without an Answer

Then I took a multi-year assignment to Antwerp as the on-site RTO Engineer, and the blind spot became visible within days of arriving — because relocation breaks plateaus whether you're ready for it or not. Two separate business teams came at me almost immediately, demanding an explanation for why the RTO application was pushing operations in a direction they didn't agree with.

It turned out the senior engineer I'd replaced had simply told them not to worry about it — the model took everything into account. He was senior and respected enough that they hadn't pushed back. I was new, early-career, and the nominal subject matter expert all at once, and they weren't the least bit afraid to press me for a real answer.

So I tried to give them one the honest way: I ran case studies on the RTO model by hand. Each one took a full day or more to trace a single historical run down to root cause. The application reran every three hours. By the time I had an answer, the business situation had already moved on to the next case, and what they actually needed was an explanation for that one, not yesterday's. I felt the full weight of not being able to do a job I'd expected to be straightforward — I'd been remotely supporting sites just like this one for almost six years, and it had never looked this hard from a distance.

Calling JD

That was the moment the business case JD had never been able to prove suddenly became obvious to me, because I was the one standing in the gap it would have filled. I called him, explained the urgency, and described exactly where I thought his tool could fit.

There was one problem: JD's tool took up to an hour to run. That's manageable if someone's manually kicking it off when they remember to, but useless against a three-hour operating cadence unless it's automatic. So we pulled in one of the developers of the RTO software itself (JC) and a system engineer (JV), built the automation hooks to trigger the analysis immediately after every case ran, and had it deployed online in under a week.

What Automation Actually Delivered

Getting an analysis report within an hour of every online case — sometimes within minutes — was genuinely game-changing. We could finally give the business teams a real-time explanation instead of yesterday's stale one. But the bigger surprise was what the tool surfaced once it was running continuously: long-unidentified modeling bugs that had been quietly corrupting the solution the whole time. The model was not, in fact, taking everything into account, whatever my predecessor had told the business teams. It took the automated analysis running case after case, in near real time, to prove that.

From One Site to a Company-Wide Push

JD and I presented these findings at the in-company Advanced Control Application and Real Time Optimization (ACAP-RTO) annual meeting. The response was unanimous: deploy this as fast as possible, everywhere it applied.

Fawley: The Peer Assist That Became a Plant Assignment

At the following year's annual meeting, a representative from the Fawley refinery pulled me aside in a hallway to describe similar difficulties they were having with their own analysis, and asked whether I could come do a three-day peer assist — a cold-eyes review. During that review, the tool helped me narrow down about three pages' worth of modeling issues that needed fixing. A couple of months later, I was offered a full plant assignment at Fawley to implement the improvement plan. (This is the Fawley RTO Engineer role already on the Career Timeline.) If you can find three pages of problems in three days, you can imagine how many more show up once you're actually living with the model for months — and it took a lot longer than I expected to get everything working. By the time the revamp was done, the technology was working stunningly — and that's the point in my career where the global community started treating me as the go-to expert: the person every site called when their analysis started looking squirrelly.

All the way through this, I kept working with JD and a growing list of others to keep advancing what the tool could do.

Where It Ended Up: A Patent

That continued work eventually became U.S. Patent 10,353,353 B2, "Hydrocarbon Processing Analysis" (full patent record), assigned to ExxonMobil Technology and Engineering Co. Twelve inventors are listed on it. None of us got there alone, and this is exactly the kind of credit that's easy to let get flattened into "I have a patent" — see Credit Other Contributors — so here's the full list:

Alison Cozad
William A. Docter
Joseph W. Evans
Narendranath Y. Gaitonde
John M. Righi
John D. Terry (JD in the above sections)
Kenneth H. Tyner
David S. Bergeson
Henry F. Demena
Katherine L. Weiger
Douglas B. Doughty
Anthony M. Ciravolo

This is the patent already listed among the Contributions I Am Most Proud Of on the bio page — that line has always pointed here, now there's a "here" to point to.

Worth saying plainly: JC and JV, who built the automation hooks that made the whole thing viable on a three-hour cadence in the first place, aren't on this list. Their work was essential to getting the technology into real use — it just wasn't new intellectual property in the patent sense, which is a different bar than "contributed something that mattered." Both kinds of contribution matter to a story like this one, and only one of them shows up on a patent.

How This Connects

This one story ends up touching almost every idea already on this wiki, which is part of why it's worth telling in full instead of just as a mentoring footnote:

"What you see is all there is" — six years of remote-support data gave me total confidence in a wrong conclusion, and I didn't know it was wrong until my vantage point physically changed.
Relocations break plateaus — the Antwerp move is the plateau-breaker in this story, not a coincidence alongside it.
Where Programs of Change Fail — the deployment only spread company-wide after a genuine sense of urgency (two business teams, demanding answers I couldn't give fast enough) existed to justify it. Kotter's point about urgency preceding the plan shows up here in the wild, not just as a citation.
Mentoring runs both directions — JD had the technical depth and years of context; I had the site-level visibility and urgency he couldn't see from Central Engineering. Neither of us gets to the patent alone.
Credit other contributors — twelve names on the patent, not one. In project closeout decks, put an Acknowledgements slide in it that lists everyone who contributed to the team's success, regardless of how large or small a part they played. It is appreciated and goes a long way toward building trust and interest in working with you in the future.

License: © 2026 William Docter. This work is licensed under a Creative Commons Attribution 4.0 International License (CC BY 4.0). You may copy, redistribute, remix, and build upon this material, including for commercial purposes, provided you give appropriate credit to William Docter and indicate if changes were made. The Second-Hand Tigers logo is not covered by this license. All rights in it are reserved.