Years of acquisitions had left every port in the operation running differently. Different SSID names. Different VLANs. Different POS configurations. Different hardware layouts. No two ports worked the same way, no two vessels were configured identically, and the operational consequence was that every support call started from a blank page. New hires relearned the environment at whatever location they landed in. Troubleshooting playbooks existed for individual sites, which meant they did not exist for the operation.
I led a 30-person global team through a comprehensive standardization of all 167 vessels and 83 offices. The lesson I keep coming back to is the title of this post: standardization is a leadership problem, not a technical one.
The technical part is the easy part
Deciding the right VLAN structure takes a week. Defining firewall rules takes a few days. Choosing a standard rack layout, an SSID naming convention, and an access point configuration is a series of decisions any competent infrastructure team can make. The technical work is bounded, finite, and largely solved.
Getting 30 people across multiple time zones to execute that standard consistently, on 167 vessels and 83 offices, with different working styles, different levels of experience, and different local conditions, is unbounded. That is the leadership work. And the leadership work is where most standardization efforts fail.
Start from a blueprint that already works
I did not build the global standard from a blank page. I used the NYC Ferry standardization as the baseline. That project had already proven the methodology: create a physical and configuration standard, train the team hands-on, break into groups to scale, and maintain QA throughout.
From that starting point, I expanded the scope. Network configurations. Rack layouts. Firewall rules. Access points. SSID naming. VLAN structures. Toast POS systems across the dining division. Vendor WiFi. Connectivity architecture. Every system, every configuration, every location brought into alignment under a single documented standard.
The principle is one I would tell anyone facing this kind of work: you do not invent a global standard. You take a working local standard and extend it. The methodology is the thing being scaled, not the configuration.
The playbook is the product
The most valuable output of the standardization effort was not the configurations. It was the playbook. I wrote a documented standard for every new vessel and office build, covering exact configurations, hardware placement, security practices, and connectivity requirements.
That playbook is the blueprint for everything that comes next. When the company acquires a new operation or launches a new vessel, the team does not figure it out on the fly. They follow the standard. The same standard that runs on every other vessel and in every other office in the fleet.
This is what standardization actually delivers. It makes growth predictable instead of chaotic.
People execute standards, documents do not
A standard that lives in a document nobody reads is not a standard. It is a suggestion. The difference between the two is leadership.
Getting 30 people to execute consistently requires a few things that have nothing to do with technology. Clear expectations. Visible accountability. A QA process that catches drift before it becomes the new normal. And a leader who has done the work themselves, so the team knows the standard is not theoretical.
I worked on the first vessels and offices personally. Not because I had to. When the person who wrote the standard is also the person installing the first rack, it sends a message: this matters, and I am not asking you to do anything I have not done myself.
What scaled was the methodology, not the complexity
Any technician can now walk into any port or board any vessel and know exactly what they are looking at. Ticket resolution is faster because troubleshooting follows one process instead of dozens. New sites and vessels onboard against a proven standard instead of being figured out on the fly.
The team's capability scaled because the complexity did not scale with it. Adding the next 10 vessels does not require 10 new configuration designs. It requires following the one that already works. That is the leverage point. Standardization is what lets a 30-person team support 167 vessels and 83 offices without the support burden growing linearly with the footprint.
The real lesson
If your standardization effort is struggling, the problem is probably not your choice of firewall rules or VLAN structure. It is probably one of these: unclear expectations, no accountability for drift, no QA process, or a standard written by someone who has never installed it themselves.
Fix the leadership problem and the technical execution follows. I have seen it work at 38 vessels and at 167. The scale changes. The principle does not.
Adam Cooper is a Technical Director writing about distributed IT operations, maritime technology, and AI in production environments. Connect on LinkedIn or get in touch.