How I Reduced Daily Manual Operational Work by 90%
Case Study
Technical Systems Modernisation
How I reduced daily manual operational work by 90% and redesigned a legacy scientific data pipeline to remove future development bottlenecks.
The Results
90%
reduction in daily manual operational work
4.5 hours
of senior staff time released each day
6 projects
cleared from the development backlog
10%
improvement in meeting the 18-hour delivery target
The Problem
Too much senior time was being spent on routine checking
01
The pipeline used a cautious fail-safe process. When a float encountered an issue — including temporary problems such as database or network errors — it could be removed from automated processing and queued for manual review.
Senior staff were spending at least five hours every day checking these cases, even though many could safely have been retried automatically during the next processing cycle.
Every new data format created another development project
02
As new float types were introduced, each variation required its own decoder to be written and maintained within an already complex legacy MATLAB codebase.
Six decoder projects were already waiting in the development backlog, with further float types expected.
The immediate problem was workload. The longer-term problem was that the architecture itself was continuing to create more work.
The Approach
A complete rewrite of a functioning near-real-time operational system would have introduced unnecessary risk.
Instead, I focused on the two specific bottlenecks.
I led a focused three-day optimisation of the system’s triage process.
Day 1 — Understand the failures
I reviewed where processing was stopping and grouped the causes into meaningful categories, including temporary system errors, incomplete data and genuine data corruption.
Day 2 — Change how different problems were handled
Serious errors continued to be flagged for manual review.
Lower-risk warning cases were instead paused and automatically returned to the next scheduled processing cycle.
I also automated the daily diagnostic reporting.
Day 3 — Test before deployment
The revised logic was tested against representative scenarios across the different error categories before being introduced into the live system.
Reduce unnecessary manual intervention
01
Remove the development bottleneck
02
The second problem needed a different solution.
Rather than continuing to write custom decoding logic for every new float type, I designed a reusable decoder controlled through configuration files.
The unique variables for a new float could be defined in configuration and recorded in the database without changing the central decoding code each time.
That turned introducing a new float type from a bespoke software-development project into a repeatable configuration process.
The goal wasn’t to rebuild the system. It was to remove the parts that were creating unnecessary work.
The Results
Daily manual intervention fell from approximately five hours to 30 minutes, releasing at least 4.5 hours of senior staff capacity every day.
Less Manual Triage
The proportion of float profiles meeting the project’s 18-hour international delivery target improved by 10%, with some weekend and bank-holiday data reaching downstream users substantially earlier than before.
Faster data delivery
The configuration-driven approach allowed the six pending decoder projects to be delivered while removing the need for future float types to require the same bespoke decoder-development process.
Six Projects Cleared
Moving routine updates into configuration files, alongside clearer automated diagnostics, meant more of the day-to-day system management and float onboarding could be handled by the wider team without relying exclusively on senior developers.
Less Reliance On Senior Developers
What This Project Demonstrates
The technology in this project was specialised, but the underlying problem is common.
Legacy systems often accumulate manual checks, individual workarounds and development processes that made sense when they were introduced but gradually become expensive to maintain.
Sometimes the most useful change is to identify where the system is creating unnecessary work, fix that part carefully and leave everything else alone.
The answer is not always a rebuild.
That is the kind of problem I enjoy working on: understanding what is really causing the friction, finding the smallest useful intervention and making the system easier for the people who depend on it.
HAVE A SYSTEM THAT IS HARDER TO RUN THAN IT SHOULD BE?
You do not necessarily need to replace it.
If manual checks, workarounds or development bottlenecks are taking up too much of your team’s time, I can help you work out where the real friction sits and which changes are worth making.
ABOUT ARGO
Argo is an international programme using thousands of autonomous profiling floats to collect ocean observations used in climate research, ocean monitoring and forecasting.
The floats typically profile the upper 2,000 metres of the ocean, collecting measurements including temperature and salinity, with newer float types also supporting biogeochemical observations.