What three years of mowing lawns taught me about automation that 25 years in IT didn't

For three years I ran a lawn mowing and gardening business called Mowing Magic. It was just me, a ute, a ride-on, and a push mower. Four days a week on the tools, Fridays for admin, Saturdays for quotes and catch-up.

Before that I spent 25 years in IT. Networks, servers, project management, the whole thing. I could architect a system. I could write process documentation. I understood uptime, redundancy, and disaster recovery.

None of it prepared me for what actually breaks when you’re the one holding the whipper snipper.

The problem was never the grass

The problem was the phone. Always the phone.

When you’re on a zero-turn doing laps of a Dromana acreage, you hear nothing except the engine and the blades. Your phone buzzes in your pocket. You don’t feel it. By the time you kill the engine, check the screen, and call back, the caller has already rung the next name on Google. A $75 regular mow in Mount Martha. Gone. Multiply that by four or five missed calls a day and you’re leaking $300 to $400 in billable work. Every day. Without knowing it.

That’s the first thing IT didn’t teach me. In an office, the phone rings, you answer it. On the tools, the phone is a liability you can’t manage. The gap between “the system should capture this” and “I am physically incapable of capturing this right now” is not a technology problem. It’s a physics problem.

Systems break at the point of human friction

In IT, you design a process and assume it runs. You test it. You document it. You hand it over.

In lawn mowing, your process has to survive a 38-degree Tuesday in Red Hill when the ride-on throws a belt halfway through a job. It has to survive the client who stops you on the way out and adds “just a quick tidy-up of the back bed.” It has to survive the wet week that shuffles every booking into the following fortnight, and the crew member who’s new and doesn’t know the difference between a standard mow and a cleanup.

Every piece of automation I’d designed in IT assumed stable conditions. Defined inputs. Predictable outputs. Real field work has none of that.

The lesson is not that automation is useless. The lesson is that automation only works when you design it for the worst Tuesday, not the best Monday.

The customer doesn’t care about your system

This was the second lesson.

In IT, the user adapts to the tool. They learn the password policy. They log tickets. They follow the workflow because it’s part of the job.

In lawn mowing, the customer doesn’t follow your system. They text instead of using the booking form. They ask for a quote on a job you can’t see, for a property you haven’t measured, while you’re standing in their driveway holding a blower. They change the scope mid-conversation. They pay late and don’t answer your follow-up because you’re a “gardener” and the invoice went to the wrong email.

IT taught me to build systems for compliant users. Mowing taught me that most users are not compliant. They’re busy, distracted, and doing you a favour by giving you work. The system has to meet them where they are, not the other way around.

This is why I stopped believing in “adopt this tool.” A booking platform the customer won’t use is worse than no platform at all. A quote template the team ignores is a lie you tell yourself. The only process that works is the one people actually follow when nobody is watching.

Speed of capture beats quality of data

Third lesson. And the one that took me longest to accept.

In IT, data quality matters. Complete records. Accurate fields. Standardised naming. You spend time getting it right because bad data breaks downstream systems.

In lawn mowing, you don’t have time. You’re scribbling a quote on the back of an invoice pad while the engine is still warm. You’re texting yourself a client’s address at a red light. You’re entering the job into your calendar at 9pm after the kids are in bed, trying to remember whether it was 600 square metres or 800.

The IT instinct is to build a perfect data-entry workflow. The field reality is that any data captured three hours late is wrong data. Better to capture the wrong address in the moment and correct it later than to capture nothing and lose the job entirely.

The automation that actually works in field services is the automation that captures. Voice notes. Photos. A text-to-calendar zap that runs while you’re driving. Crude, fast, barely structured. Then a human tidies it up later. The capture happens at the point of contact. The cleanup happens at the point of least resistance.

This is the opposite of how IT designs systems. It’s also the only way they survive contact with actual work.

What I’d build differently now

If I were running Mowing Magic today, I wouldn’t start with a CRM. I wouldn’t start with job management software. I wouldn’t start with a scheduling platform.

I’d start with a voice agent that answers the phone when I can’t. Not a chatbot. Not a web form. A phone number that talks to a caller, asks the right questions, books the job, and texts me the summary while I’m still on the mower.

That’s $400 a day in recovered calls. Roughly $2,000 a week across a five-day booking window. About $100,000 a year in revenue that currently evaporates into voicemail.

The rest can wait. The quotes, the scheduling, the invoicing, the follow-ups: all of it matters. But none of it matters if you’re not capturing the work in the first place.

The honest takeaway

Twenty-five years in IT taught me how systems should work. Three years mowing lawns taught me how they actually fail. The gap between those two things is where most automation projects die.

If you’re running a field service business on the Peninsula (mowing, gardening, plumbing, electrical, building) and you’re thinking about automation, start with the physics problem. What can’t you do because you’re physically doing something else? Fix that first. Everything downstream gets easier once you’re not losing work at the point of first contact.

Clarity before tools. Boring beats clever. I didn’t learn those in a server room. I learned them on a zero-turn in Dromana, watching another missed call light up a screen I couldn’t reach.

If you want help figuring out where the physics problem is in your business, we do a workflow clarity audit that starts exactly there: one workflow, one bottleneck, one fix.