What I walked into
E-commerce at Maersk was still an acquisition business. The pieces worked, but they were not designed as one system. Capability was local, largely US, and too slow for a world that measures parcel platforms in milliseconds. Every new customer felt like a project, not a product.
Implementation for a new customer took three to six months. Almost everything was customized. Even when the next client asked for the same thing, there was no standard integration path to reuse. Teams re-solved the same problems because nothing in the infrastructure made repetition cheap.
The diagnosis
The constraint was not effort. It was architecture and operating model. If every client sat on a one-off workflow, we would never get faster, never go global, and never attach new capabilities without another six-month program. The work was to decide what had to be platform, what could stay configurable, and then lead the people who could actually build that distinction.
I treated speed as a product requirement, not a later optimization. Global was the same: if the stack only worked in one geography, every “international” deal would become another custom build. The standard we had to match was already set by the rest of the industry — millisecond-class systems, not batch-era logistics software.
The architecture bet
We did not throw the old system away. We took what was true in it, then redesigned the connections so the platform could talk to itself at the speed the market required, and so new capabilities could be attached without a rewrite.
Sortation, routing, label generation, and tracking updates were rebuilt as systems you could plug in, not as one-off features buried in a customer implementation. That is the difference between a project shop and a platform: the second client should inherit the first client’s work.
Once those primitives were stable, we could offer higher-order capabilities on top — things customers actually sell with, such as marketing — without inventing a new backbone each time. Advanced product sits on a fast, shared core, or it never ships twice.
How the work got done
Transformation of this kind is a sequence, not a slogan. I set the target (global, fast enough, attachable), drew the architectural line (reuse over customization), and then ran a multi-disciplinary build with product, engineering, and operations so the team could execute against that line every week.
Changing the infrastructure and the scale of the platform meant repetitive work could be done once. Standard integration workflows replaced “start from zero.” The same pattern that used to take a quarter of custom labor became something we could turn again for the next customer.
What this was for
The point was not a prettier diagram. It was to make Maersk’s e-commerce stack behave like a global product: fast enough to compete, coherent enough to extend, and operationally boring in the places that should be boring — so people and capital could go to the next capability instead of the last integration.
Numbers and roles are on the resume. This page is the reasoning.