The Robot Lawn Mower Lesson: Why Great Leaders Remove Ambiguity

While building Design Right AI, I spent a lot of time writing code for AI workflows, and something clicked that had nothing to do with software.

Programming is unforgiving about ambiguity. A person can nod along to a vague instruction and quietly fill in the gaps with judgment. A computer can't. Every step has to be spelled out, in order, with the edge cases named, or the whole thing stops. You don't get to assume. You get to be explicit.

Somewhere in the middle of that, I found myself imagining what it would take to teach a robot to mow a lawn.

"Go mow the lawn" gets you nowhere. It isn't an instruction; it's a wish. To actually make it happen you have to define all of it: lower the deck, move forward at a steady pace, overlap each pass by a few inches so you don't leave strips, slow down on the turns, empty the bag when it's full, keep the wheels off the flower beds, watch for the sprinkler heads, and return to the garage when the yard is done. Only then does "mow the lawn" mean something a machine can execute.

Here's the part that stuck with me: the task looks simple. It looks simple because a person already carries all of that context in their head. They've mowed a hundred lawns. The overlap, the turns, the flower beds — none of it needs saying, because they already know. The simplicity isn't in the task. It's in the experience the person brings to it.

We hand off the sentence and keep the context

That's exactly what goes wrong when we delegate.

We say "handle the closeout" or "get the site ready" or "take care of the customer," and we assume the person on the other end sees what we see. But we've done the closeout fifty times. We're not handing over the task — we're handing over a sentence, and keeping all the context that makes the sentence mean something.

The other person receives the sentence. They don't receive the fifty times. So they do the reasonable thing: they fill in the gaps with their context, their assumptions, their picture of what "done" looks like. And their picture is almost never identical to ours.

Then the work comes back different from what we imagined, and the easy conclusion is "they dropped the ball." Usually they didn't. They executed faithfully — just against a different set of assumptions than the ones living quietly in our heads.

It's rarely effort. It's the mental model.

I've come to believe that people fail far less often for lack of effort than we give them credit for. Most of the time they're working hard, on the wrong version of the task, because the version in their head and the version in ours were never the same version.

That reframes the whole thing. If someone's output misses, the first question isn't "why didn't they try harder?" It's "what did they think I was asking for — and where did my picture and their picture split?" Nine times out of ten, the gap traces back to something obvious in hindsight that never got said out loud, because to the person handing it off, it was too obvious to say.

The ambiguity we leave in a handoff isn't a small thing. It's usually the whole thing.

The honest caveat: don't hand a master a checklist

I want to be careful here, because this idea gets abused.

The lesson is not "spell out every step for everyone." That's how you insult your best people and bury your good ones in process. Experienced people don't run on step-by-step procedures — they run on principles. Give a seasoned tech "make this drop clean and serviceable" and they'll make a dozen good calls you never had to enumerate, because they understand the why underneath the steps. Hand that same person a rigid checklist and you've slowed them down and told them you don't trust their judgment.

So the real skill of leadership isn't "always add detail." It's knowing when detail helps and when it just gets in the way. New people, unfamiliar tasks, high-stakes handoffs — detail is a gift. Veterans on familiar ground — detail is friction. The art is reading which situation you're in, and matching the handoff to the person and the moment.

The point was never "treat people like machines." It's the opposite: respect that every person is reasoning from their own picture of the job — and take responsibility for making yours visible when it matters.

Two handoffs

Here's the difference in practice.

The ambiguous version: "Can you get the Johnson site ready for Thursday?" The person hears "ready" and does what ready means to them — maybe they stage the gear and confirm access. Thursday comes, and it turns out "ready" in your head also meant the permits were pulled, the customer was briefed on the two-hour power cut, and the ladder truck was booked. None of that happened. Not because anyone slacked — because "ready" was a word doing five jobs, and only you knew all five.

The clear version: "For Thursday at the Johnson site, I need three things confirmed by end of day Tuesday: permits pulled, the customer emailed about the two-hour power cut, and the lift booked. Gear staging can wait until Wednesday. If any of those three hit a snag, tell me Tuesday, not Thursday." Same task. Same person. Wildly different odds of it going right — because the picture is now shared, and the failure points have names.

Notice the second version isn't longer because it's micromanaging. It's longer because it names the three things that were living in your head and nowhere else. That's not control. That's generosity.

Systems beat heroics

Now scale that up from one handoff to a whole company.

Every growing organization hits the same wall. It runs on a few people's judgment — the owner, the lead tech, the person who's been there twelve years and just knows. That works right up until it doesn't, because judgment that lives in one head can only be in one place at a time. You feel it as a bottleneck: everything routes through the same two people, and quality drops the moment they're not in the room.

The organizations I admire get past that wall by doing one unglamorous thing well: they turn hard-won experience into repeatable systems that quietly remove ambiguity. Not rigid checklists for their own sake — shared mental models. The overlap-your-passes, watch-the-flower-beds knowledge, made visible so a good person can make a good call without re-deriving everything from scratch every time.

That's the difference between a good crew and a great one. It usually isn't talent. It's how much of the hard-won judgment has been captured in a form other people can lean on. Great teams run on systems. Struggling ones run on heroics — a handful of people carrying the context in their heads and holding it all together by sheer effort. Heroics don't scale. Systems do.

And the quiet benefit: systems free your best people to do the work only they can do, instead of spending their days answering the same questions and re-explaining the same context. Removing ambiguity isn't bureaucracy. Done right, it's what lets judgment travel.

Where this shows up in our world

I think about this constantly in the low-voltage and security world, because our whole trade is built on judgment that lives in experienced heads — how to lay out coverage, where the runs go, what the code actually requires on this job, which corners you never cut. The people who carry that knowledge are the reason the work is good. And they're a bottleneck the moment the company tries to grow past them.

That's the problem we're working on with Design Right AI: taking the design judgment that lives in seasoned integrators' heads and encoding it into workflows other people can lean on — so the next person doesn't have to re-derive it, and the expert doesn't have to be in every room. It's a real-world application of the same principle, not the point of this piece. The principle is bigger than any tool: make the implicit explicit, so good people can do good work without you standing over their shoulder.

A question, not a conclusion

The robot lawn mower didn't teach me to be more controlling. It taught me the opposite — that most of the friction I'd blamed on people was really ambiguity I'd left in the handoff, and that a huge part of leading well is simply making my own picture visible when it counts, and trusting people with the principles the rest of the time.

I'm still working on it. I get it wrong plenty. So I'll leave this as a question rather than a lesson learned:

What's taught you the most about leadership from an unexpected place?

I'd genuinely like to hear it.

— Dan