When I started at the terminal, I wanted to die.
You’re discharging a tanker at 800 cubic metres an hour. You’re coordinating a team — thankfully, people who run themselves — and underneath all of it runs a river of data you can’t let go of: volumes, times, correction factors, densities, temperatures. One number written down wrong moves tonnes of product in the wrong direction. And at the beginning, I had no idea about any of it.
I came from another world. I’d studied interactive systems; I’d designed websites for an internet agency in Berlin. When I moved into heavy industry — at first only covering sick leave and holidays as a loading master at Shell and Aegean, single, with no idea whether it would last — I arrived knowing nothing about the trade. But I brought a way of working that doesn’t switch off just because you change uniform.
My method has always been the same: watch, learn, copy, endure, and once you can do it in your sleep, try to simplify. You don’t get to simplify from ignorance. You earn that right by first doing it by hand — the whole tedium of it — until you own it. So I spent my first rotations quiet, copying what the others did, enduring.
The nights
Shift work has one thing nobody mentions: it hands you dead hours. Endless nights when sometimes there’s no job on, but the checks still have to be done. One of them was going through the schedule to make sure every piece of information was one hundred per cent correct.
That’s where I started. With homemade improvements: fields that filled in others by default when you entered a value; dropdowns to pick from instead of typing; filters by category. Nothing spectacular. Just removing manual steps, one at a time.
Those same nights were also good for something else: searching the internet. And on one of them I found the formulas for calculating the correction factors in Table 54 for fuel oils.
With it I built a spreadsheet where you entered a tank’s volume and it gave you back the volume corrected to 15 degrees, and the tonnes in air and in vacuum. What until then meant going to a battered book, finding the page, the column, interpolating by hand and writing it down — every time, every tank, every tanker settlement — became typing a number and reading the result.
That is exactly the work I mean when I say monkeywork: tasks you could train a monkey to do, being done by qualified professionals, shift after shift. It wasn’t that it was hard. It was that it was unworthy of the time of someone who knows what they’re doing. And it was also where the errors came from: not from a lack of knowledge, but from repetition and fatigue.
Sharing it was the real leap
Once I’d checked them, I shared them.
I could have kept them. A file like that makes you faster than everyone else, and on shift work that shows. But it made no sense: the tedium wasn’t mine, it was everyone’s. Before long the other supervisors were using them, because they saved all of us the same thing.
That was the moment — without realising it — I stopped being someone with a trick and became someone who builds tools for other people. The difference sounds small. It isn’t. It’s the first time what you build stops serving only you and starts holding up an entire operation.
The blend that went wrong
But before that came a lesson that cost me dearly, and it’s really the most important one in this chapter.
Back then, IFO blends were worked out on spreadsheets that came ready-made. One of them was set up wrong: the fuel percentage was sitting where the gasoil one should have been. I used it. And I gave a ship a blend well off what they had ordered.
You don’t forget that. A customer asks for a product with specific characteristics and you hand them something else — not because you didn’t know how to do it, but because you trusted a cell that was in the wrong place.
The conclusion I drew wasn’t “don’t trust spreadsheets”. It was something far more useful: a tool amplifies whatever you put inside it, for better and for worse. If you automate a calculation, you stop checking it. And if you stop checking it, the day it’s wrong it will be wrong many times over, with total apparent confidence.
From then on I knew how a sheet had to be built: fail-safe. It shouldn’t let you enter what doesn’t belong. It should show what it’s calculating. It should shout when something falls outside range. If the error comes, it should surface before the product does.
When I got to Oryx I also implemented the IFO calculations for bunkering, and over time we adapted far more sophisticated blenders, largely thanks to what other collaborators showed us. But the judgement I built those with didn’t come from a manual. It came from that ship.
Oryx: from templates to a system
I didn’t just bring the formulas to Oryx. I found colleagues who improved them — and that’s another thing I learned there: a tool you share evolves; a tool you keep to yourself dies with you.
Between us we stopped automating just the volume calculation and started working directly from tank levels, so the file returned every measurement at once.
And we went after the next piece of monkeywork: filling in documentation. Templates that poured the data into the documents themselves, instead of typing it again where it already existed.
Then came the files for tracking tanker loadings and discharges. And there I did something — without giving it a name — that would matter years later: systematising data capture so it could be analysed afterwards. Not writing things down to fill a box, but capturing them thinking about what could be known from them later on.
The Access database: the day I stopped building and started designing
The culmination of all that was an Access database.
I didn’t build it. And that sentence, which meant nothing at the time, today explains almost everything I do.
I put in the logic. We poured in much of the spreadsheets I’d been creating for vessel planning, and we added what shift work teaches you the hard way: that every piece of information that reaches you on your shift has to reach the person relieving you just the same. Anything that stays in your head, or your notebook, or an email only you read, disappears at eight in the morning when you go home. Access captured that. It wasn’t a data store: it was the handover.
There, without knowing there was a word for it, I acted as the architect. Someone with more hands than me built it, and my job was deciding what had to exist, what information couldn’t be lost, and how it had to flow. My old passion for programming logic finally found somewhere to live inside a bulk liquids terminal.
When the time came to take it seriously with a software company, I left for Dow. The project went to sleep.
What I didn’t know until much later
Nobody asked me for any of this. It wasn’t part of my job, there was no project, there was no budget. I did it because I couldn’t stand watching repetitive work eat the hours of people who knew how to do difficult things.
I also had no permission to build software, and no IT team waiting for my requests. I had Excel and the nights. So I fought the war with what I had.
What I didn’t know until much later is that in those years, among tanks and battered books, I was already doing the three things that are my trade today: getting rid of the work a monkey could do, building tools fail-safe because a tool amplifies error just as much as success, and making sure that what one shift knows reaches the next one intact.
The weapon was poor. The instinct was the same one that, twenty years later, would run an entire factory of agents.