10 practical lessons on crew adoption, from the captains and fleet managers who have done it
I spend a lot of my time talking to fleet managers and captains, and the question that comes up most often isn’t whether a new system works, but whether the crew will actually use it.
People assume seafarers resist technology, but they mostly don’t. In their study on the human element in maritime digitalisation, Inmarsat and Thetius described the relationship between crews and emerging technology as broadly positive. So if openness is high, what decides adoption on the bridge, in an industry that’s still a little late to it?
Having spent years at sea myself as a submarine captain, I know bridge teams are careful about what they let onto the watch. It all comes down to one thing: trust. I’ve seen crews leave a good system switched off because no one gave them a reason to rely on it, and I’ve seen doubtful crews come around fast when the rollout was handled well.
Here’s what I’d focus on:
1. Anchor the tech in existing seamanship.

Onboard training session on a vessel, supporting crew adoption of Orca AI
during live operations
By the first watch, the crew should be able to say how the system fits the way they already navigate. Name the one job it does first, and don’t promise everything. What crews want are operating terms: when to act on a prompt, when to ignore one, who to call when it behaves strangely. Seamanship comes first; the technology sits around it. I learned to navigate long before any of this existed, and so did most of the officers now using it, which is why a new tool has to fit the way they already work instead of asking them to start over.
2. Be clear: it informs, the crew decides.
This is the one I care about most. The system is a second set of eyes – it helps inform the decision with data; it does not make the decision. The Master remains responsible for safe navigation, and the Officer of the Watch remains responsible for the watch. Say that plainly, and keep saying it, so no one feels a piece of software has taken the call out of their hands. And honestly, until software can take the call, all of us will be retired!
3. Name the fear before installation.
The first thing a bridge team wonders about a new system is simple: is this here to help us, or to catch us out? Leave it unspoken and it becomes the story the crew tells itself. Answer it out loud in the first briefing, before the equipment goes in, and put the answer in writing so it holds up on the first hard watch.
4. Let the crew shape the setup.

Working with the crew to find the best position for the Orca AI screen, making sure it fits naturally into their daily bridge operations.
A lot of adoption rides on small things: where the screen sits, which is probably the most important part of installation if you want real usage and engagement, how bright it runs at night, and how alerts behave before they lead to alert fatigue and become background noise you eventually deactivate or ignore. Ask the first crew what feels awkward in the opening week, then go back to them with what you changed. Feedback that disappears ashore teaches the crew to stop giving it.
5. Aim for an early, visible win.
Trust moves fastest the first time the system shows a crew something they’d have missed. Pick a first use case that pays off in the opening voyages: a target held in fog, a contact the radar lost, a reporting step that gets shorter. Keep the first voyage narrow and let that result do the persuading.
6. Expect overrides, and welcome them.
Anyone who’s stood a watch knows the pull to trust your own eyes over an instrument. A crew that trusts a system also has to feel free to overrule it, and to know that reflects well on them. When an officer goes against a prompt, ask what they saw and learn from it. A bridge where overrides never happen worries me more than one where they happen often.
7. Remove a burden when you add a tool.
Every new system competes for the bridge team’s attention. Crews take to a tool that makes the watch easier and resent one that just piles on work. So take something away at the same time: a duplicate spreadsheet, a manual report, a routine call for context the office can now see itself.
8. Make the data pathway transparent.
Crews stop trusting a system the moment the data feels like it’s moving behind their backs. The rule I’d hold to is simple: whatever the office can see, the bridge can see, and nothing comes down from shore without the context behind it. No black box, and responsibility stays with people on both ends.
9. Make honest feedback a badge of honor.
The rollouts that last are the ones where honesty carries no penalty. A master who says a tool is getting in the way should feel as free to say it as one who praises it. Treat that candor as a sign the process is working, and show the fleet what good looks like.
10. Give the rollout champions on ship and shore.
A rollout that lands as an order from the office tends to stall. People on board are already carrying a full workload. Put a name to it on each side instead: someone on board the crew respects, and someone ashore with the authority to change settings and actually answer the vessel.
The bridge has always run on trust, long before any of these systems arrived: between the ship and the office, and between a master and the call he makes at three in the morning. New technology has to earn its way into that. It earns it by being useful and by respecting the people who use it. Get that right and the system becomes part of the watch. Get it wrong and you’ve bought a tool that sits dark on the bridge. The fleets that scale this are the ones that put as much work into the people and the trust as into the technology.