I had never set foot on a refinery when I volunteered for a construction project at Motiva’s PARCEP facility in Port Arthur. By the time we were done, I was the lead engineer for my discipline on that unit.

My job was to ensure that every instrument in that unit was tested, verified, and handed off correctly. We were responsible for thousands of instruments and every one of them had a function, a tolerance, and a failure mode. If a vessel ran too hot, the system automatically brought in cooling water. If a tank level climbed too high, the outlet valve opened. The unit was designed to correct itself, but only if every instrument was calibrated and wired correctly. My job was to make sure it would.

When the metric lied

Partway through testing, I noticed something. Our retest rate was high. We were hitting our quota on paper but a significant portion of the work was being redone. I dug into it and found the root cause. We were testing instruments that mechanical had not yet cleared. The pipes hadn’t been tested, which meant the equipment had to be disconnected, tested, and then reassembled once mechanical was done. We were essentially testing the same instruments twice.

I pulled the schedules for every department that had to complete work before we could test. I built a system that only released instruments for testing once the upstream work was done. Testing was slow at first. Then it picked up. The retest rate dropped. We stopped doing the same work twice and started making real progress. I didn’t know it at the time, but that is exactly how I approach product work today. Before I build anything, I map the workflow. What is the input at each stage, what is the output, what are the constraints, what happens downstream if something goes wrong. The retest problem looked like a testing problem. It wasn’t. It was a sequencing problem that only became visible when I looked at what every other department needed to complete before my team could do its work. I only found it because I was looking at the whole system, not just my piece of it.

Same instinct, different system

I left chemical engineering and moved into data and product work. The problems looked different but the way I approached them didn’t change. Years later I was brought into a conversation about where to integrate an AI solution into a digital review workflow. The manual process was straightforward. Reviewers read descriptions pulled from a random sample, determined whether required questions were answered, and recorded a pass or fail. The team was deep in discussion about how the workflow should be designed. I took a step back.

I started mapping each stage. What was the input, what was the output, what were the constraints at each step, what metrics would tell us whether the outcome we wanted was actually happening. Nobody had thought to track how long each stage took. There was a discussion about the exception workflow, what happens when a reviewer flags something as failing and another reviewer overturns it, and how that should be designed. Both are being addressed in the next iteration, one to improve visibility into where the process slows down, the other to ensure the exception workflow is designed correctly from the start. And it hit me. It was like I threw on my chemical engineering hat once again, trying to solve system problems, just like I had done on the refinery construction project.

With the AI model, we could now automatically target the descriptions most likely to fail, while taking a smaller sample of passes to verify the model was working correctly. The workflow did not change. The system became smarter about where to focus human attention.

What it taught me

Chemical engineering didn’t teach me how to build products. It taught me how to think about systems. What goes in, what comes out, what happens at each stage, what breaks when something upstream fails, and what you need to measure to know whether the outcome you want is actually happening. Studying economics sharpened how I think about tradeoffs, incentives, and user behavior. But the instinct to map a system before touching any individual part of it, that came from the refinery.

If you are a PM, start with the workflow before you touch the solution. Map the inputs and outputs at every stage. Understand the constraints. Think about downstream consequences. Ask what you need to track to know whether the outcome you want is actually happening. The solution is one component in a system. Treat it that way.

Author: Adam Dalal