Why More Data Doesn’t Mean Better Decisions

The factory that stayed slow

Electric motors arrived in factories in the 1880s. They were clearly superior to steam engines. Factory owners bought them immediately.

And then nothing happened. Productivity barely changed for 40 years.

The economic historian Paul David documented this in a now-famous paper for the American Economic Review. The pattern he found was striking: factory owners took the electric motor and bolted it into the same spot where the steam engine had been — one big power source driving a central shaft, belts and pulleys distributing energy across the building. The layout, the organisation of work, the flow of materials — none of it changed. They replaced the power source but kept the architecture.

The real gains came in the 1920s, when engineers realised electric motors could be small. You could put one on every machine. You could rearrange the factory floor around the flow of work rather than around proximity to a central shaft. US manufacturing productivity growth surged from roughly 1.5% per year to over 5% — a 3.4x acceleration. Not because the motors got better, but because the architecture of work changed to match what the technology could do.

David’s point was not really about motors. It was about a pattern: when a powerful new technology is inserted into an unchanged workflow, the gains are negligible. The gains come when you redesign the workflow around what the technology makes possible.

I think about this pattern constantly. Because our industry is living it right now.

(Paul David, “The Dynamo and the Computer: An Historical Perspective on the Modern Productivity Paradox,” American Economic Review, 1990. For the full arc, David Nye’s Electrifying America (MIT Press, 1990) covers the factory transition in detail.)

Five dashboards and a WhatsApp group

Over the past decade, turf management has acquired an extraordinary amount of technology. Weather stations. Soil moisture sensors. GPS fleet tracking. Nutrition planning tools. Disease risk models. Irrigation controllers. Growth tracking via clipping yields or GDD models.

Each arrived with its own dashboard, its own login, its own data format. Each was bolted onto the existing way of working. The daily routine stayed the same — walk the course, check the weather, decide what to do based on experience — but now there were more screens to look at first.

This is the electric motor bolted into the steam-era factory. The power source has changed but the architecture of decision-making has not. Information still flows through one person’s head. Cross-referencing still happens manually, if it happens at all.

Adding another sensor, another app, another dashboard to this arrangement does not make decisions better. It makes the morning longer.

Bolting new capability onto unchanged workflows produces minor speedups — slightly better-informed versions of the same decisions made the same way. Redesigning the workflow itself — building a different architecture — produces fundamentally different capabilities. Not the same work done faster. Different work made possible.

What architecture actually means

Architecture is an intimidating word. It does not need to be.

Think of it this way. You have five filing cabinets in five different rooms — weather, soil, spray logs, nutrition, equipment. Each is well-organised. But if you want to answer “did last week’s fertiliser application, combined with the warm spell and the moisture levels, increase disease risk on the greens?” — you need to walk to four rooms, pull four sets of files, and work out the answer yourself.

Architecture means putting all five cabinets in one room with a librarian who understands how they relate to each other. The data does not change. But the ability to cross-reference, to spot patterns, to answer compound questions — that changes fundamentally.

In practical terms, data architecture for a turf operation means three things:

• All operational data flows into a common structure, regardless of where it was generated
• Relationships between data types are defined (soil moisture relates to irrigation scheduling, GDD relates to nutrition timing, weather conditions relate to disease risk)
• The system can reason across those relationships, not just store them side by side

This is the difference between having data and having intelligence. And it maps onto three stages that describe where most operations sit today and where they are heading.

Stage 1: Disconnected

This is where the vast majority of turf operations are in 2026, and there is no shame in it. The tools were not designed to talk to each other. Nobody was offered a connected alternative.

What this looks like at 6am: you check the weather app. You check the soil probe app. You open the spreadsheet on your phone (or you don’t, because it is not formatted for mobile). You remember what you sprayed last week. You estimate GDD accumulation based on experience. You make a decision.

The decision is often than not good. Experienced operators make excellent decisions in disconnected environments — they have built internal models over years of observation. The problem is not the quality of the decision. It is the cost of producing it. The time spent cross-referencing. The mental load of holding six data sources in your head before the team arrives. The signals you miss not because you lack the knowledge, but because you were busy.

The critical limitation at Stage 1 is not data quality. It is that the operator is doing the integration work that the system should be doing — and that work consumes the time and headspace that should go toward the decisions only they can make. You know the fusarium risk is rising because you checked the forecast, remembered last year’s outbreak timing, and glanced at the soil probe. But you did that work in your head, between the car park and the maintenance shed, while also thinking about the mowing rota and the tournament on Saturday.

Stage 2: Connected

At Stage 2, data flows between systems. The weather data, soil data, spray records, nutrition inputs, and growth tracking feed into a common environment where they can be viewed together and cross-referenced.

This sounds simple. It is structurally significant.

When GDD accumulation is tracked alongside the nutrition programme, you can see whether the fertiliser application aligned with the growth window or missed it. When disease risk models pull from actual site weather data rather than a regional forecast, the risk assessment reflects your microclimate, not a 30km average. When spray logs are timestamped against weather conditions, you can audit whether applications happened in the right window — and whether they worked.

What this looks like at 6am: you open one system. You see that overnight temperatures dropped to 3C, that soil moisture on the greens is at 28%, that GDD accumulation has crossed the threshold you set for your next fertiliser application, and that the 10-day disease risk model shows elevated fusarium pressure starting Thursday. The spray log shows your last preventive application was 12 days ago.

You are making the same decisions. But the preparation that used to take 20 minutes of cross-referencing across five systems now takes 90 seconds of reading. More importantly, the cross-references that you might have missed — because you were busy, because you forgot to check the soil probe, because the spreadsheet was on the office computer — are now visible by default.

The shift from Stage 1 to Stage 2 is not about better data. It is about freeing the operator from the manual work of integration so they can focus on what they are actually good at.

Stage 3: Intelligent

Stage 3 is where the system stops being a filing cabinet — even a well-organised one — and starts reasoning.

At Stage 2, the system shows you that GDD has crossed your nutrition threshold. At Stage 3, it tells you: “GDD crossed the threshold this morning, but soil moisture is low and there is no rain forecast for five days. Applying granular fertiliser now risks burn. Consider delaying 48 hours or switching to a foliar application.”

At Stage 2, you see that disease pressure is rising. At Stage 3, the system has already checked your spray log, compared conditions to historical patterns on your site, and told you: “Conditions are tracking similarly to the third week of October 2025, when fusarium appeared on greens 6, 11, and 14. Your last application was 12 days ago. You are approaching the end of the protective window.”

This is not automation. The operator still decides. But the system has done the preparation work that used to depend entirely on memory and experience — across every data point, every historical record, every weather model, simultaneously.

What this looks like at 6am: you arrive and the system has already prepared a briefing based on the thresholds you set, the priorities you defined, and the management plan you built for the season. Here is what changed overnight. Here is what it means against your plan. Here are the three things that need your attention based on your own criteria. The rest is on track.

The experienced greenkeeper still knows more than the system about the subtleties of their site — the green that always drains slowly, the microclimate behind the clubhouse. But they are no longer spending that expertise on the manual work of data integration. Their knowledge goes where it is actually irreplaceable: judgement, priorities, and the thousand small decisions that make a great course.

The cockpit, not the pilot

Formula 1 went through this exact transition. In the 1980s, a race strategist made pit stop decisions based on a stopwatch, a pit board, and the driver’s voice over the radio. The data existed in fragments — the driver felt the tyres, the mechanic heard the engine, the strategist watched the gap. Nobody had a connected view.

Today, 300 sensors on each car generate over a million data points per second. Teams run over a thousand race simulations per weekend. The difference is not that they added sensors. It is that they redesigned the decision architecture around integrated, real-time data.

But the driver still drives. The car still needs to be felt. The instinct that separates a good lap from a great one has not been replaced — it has been amplified. The driver is not competing against the telemetry. The telemetry is giving the driver more of the picture, faster, so the decisions that only a human can make happen with better context.

That is the shift. Not replacing expertise. Amplifying it by removing the data work that sits between what you know and what you do.

Where this is heading

The destination is not a system that replaces the operator. It is a system that accompanies them — a copilot that is present through the season, that builds context over time, that understands the difference between March on your site and March on a site 200 kilometres away.

When decisions are made inside a connected system, they leave a trace. The fertiliser application that was delayed because soil moisture was low — that decision is recorded, along with the conditions that prompted it and the outcome that followed. Over time, the system learns. Not from a textbook — from your turf, your climate, your management decisions. Every season makes the next one sharper.

The factories that eventually thrived were not the ones that bought the best motors. They were the ones that rethought how work was organised. The technology mattered — but the architecture mattered more.

For turf management, the equivalent question is not “which sensor should I buy next?” It is: “when information arrives on my site — from a weather station, a soil probe, a spray record, a growth measurement — where does it go, and what happens to it?”

The technology to answer that question well exists today. The question, as it was with the electric motor, is whether we are willing to rethink the architecture around it.