Don T Let Pigeon Drive Bus

So You Keep Getting Your Work Run By Things That Shouldn't Be Driving

I've been running into this pattern long enough that I just stop surprised when I see it. Someone builds a system, writes a pipeline, or sets up an automated workflow, and somewhere in there they hand the steering wheel to something that was never meant to handle it. I call this Don T Let Pigeon Drive Bus because honestly that's what it feels like watching a bird try to merge onto a highway. The pigeon isn't malicious. It's just not built for the road. Here's the basic idea in plain terms: identify the component in your system that's being asked to do work outside its competence range and remove it from that responsibility. That's it. No poetry. In practice, this usually shows up in three places. First, you have automation scripts that were written for simple cases and then left to handle increasingly complex input without any guard rails. Second, you have human operators doing tasks that should be semi-automated but aren't because someone never built the automation. Third, and this one bites people the most, you have AI models or simple programs making decisions that require domain knowledge they simply don't possess.

The pigeon drive bus problem isn't about intelligence. It's about fit. A pigeon can fly fine. Just not behind the wheel of a bus. Same thing here. A tool or process that works perfectly for task A can wreck task B if you don't recognize the boundary between them.

How To Actually Implement This In Your Workflow

I want to walk through how I do this now, not some theoretical framework. The first thing I do is map every step in a process and label what type of work each step actually requires. I break it down into three buckets: rule-based work, judgment work, and creative or exploratory work. Rule-based work goes to scripts, macros, or automation tools. Things like file renaming, data format conversion, batch email sending, or schedule management. If the path from input to output is always the same, automate it. Judgment work stays with humans or at minimum goes to systems that can escalate to humans. Decisions that involve tradeoffs, context you can't easily encode, or consequences that vary based on situational factors. This is where most people go wrong. They try to automate judgment calls because they think it will save time. It doesn't. It just makes the mistakes louder.

Creative or exploratory work gets a different treatment entirely. You don't automate discovery. You set up scaffolding around it. You create templates, research frameworks, and review processes, but you don't hand the actual exploration to a machine or a script. Once I've categorized the steps, I look for the mismatch. That's the pigeon at the wheel. The step that's sitting in the wrong bucket. I then either move it to the right bucket, remove it from the automated flow, or redesign it so the tool being used only handles the part it's actually good at.

A Real Example From One Of My Projects

Last year I was working on a content distribution pipeline. We had a script that would take an article, run it through a few formatting checks, and then push it out to three different platforms. The script worked fine for standard posts. The problem came when we started running experimental content. Longer pieces, pieces with embedded data visualizations, pieces that had footnotes or citations in non-standard formats. The script kept mangling these. Not breaking in a dramatic way. Just quietly introducing errors that were hard to catch until after publication. A footnote number would shift. A chart caption would get cut off mid-sentence. The script was doing exactly what it was programmed to do, but it was being asked to handle things outside its programming. The fix wasn't to make the script smarter. That would have been expensive and probably still unreliable. The fix was to add a gate. Any piece that matched certain complexity markers got routed to a human reviewer before it hit the publishing step. The gate itself was simple: if the document contained more than fifty references, or if it had any embedded objects beyond standard images, it triggered the manual review path. Simple condition, maybe ten lines of code, and it eliminated about ninety percent of the post-publication errors we were seeing.

The pigeon didn't get a better driving suit. We just took the keys away from it and put them on a hook by the door.

Advanced Nuances Beginners Miss

There are a few things that aren't obvious when you first encounter this problem. One of them is that the pigeon often looks like it's working. The automation succeeds most of the time. The errors are rare and scattered. This creates a false sense of security. People keep the pigeon at the wheel because clearly it's handling the job well enough. Until one day it doesn't and you've lost hours trying to figure out why. Another thing people miss is that sometimes the pigeon isn't a tool. Sometimes the pigeon is a person doing work they're not qualified for because you structured their role that way. I've seen junior staff members end up making architecture decisions because no one explicitly said they couldn't. The org chart looked fine on paper. In practice, the wrong person was driving. A third nuance is that removing the pigeon from the wheel doesn't mean removing it from the system entirely. The pigeon might be great at something else. In the content pipeline example, the script was still useful. It just needed to be scoped to the tasks it could actually handle reliably and handed off the rest at the gate.

When This Approach Won't Save You

I need to be honest about where this breaks down. If your entire workflow is fundamentally poorly designed, separating pigeon work from human work won't fix the underlying rot. You'll just have a cleaner version of a broken process. The categorization method assumes you have a process worth saving. If you don't, you should probably just rebuild it. Another limitation is that the gate approach I described adds a manual step. That means slower throughput. In some environments, speed matters more than correctness. If you're running a high-volume operation where a two percent error rate is acceptable and manual review would cut your output in half, you might decide to accept the pigeon's mistakes and compensate elsewhere. That's a real tradeoff and it depends on your specific constraints. If you find yourself in a situation where the pigeon truly is the only option, the alternative is usually to invest in a system that can actually handle the full scope. That could mean a proper content management system, a dedicated automation platform, or in some cases just hiring someone who knows what they're doing. None of those are cheap. But neither is shipping broken content at scale.

Practical Steps You Can Take This Week

Pick one process you run regularly. I'd suggest something that runs at least twice a week so you'll notice the difference quickly. Write down every step. Label each step as rule-based, judgment-based, or exploratory. Look for the mismatches. Pick the worst one and fix it. Don't try to fix everything at once. I used to get overwhelmed by this. There are always five pigeons driving buses in any system I touch. Fixing them all simultaneously is a recipe for burnout and incomplete work. Pick one. Get it right. Then move to the next one. The whole point of Don T Let Pigeon Drive Bus is just this: match the driver to the vehicle. It sounds obvious when you say it out loud. The hard part is actually doing it when the pigeon has been driving for months and everyone has gotten used to the bumps.