Eliminate and Automate: Reserve Humans for Critical Thinking
By Darryl Brown
The mantra that shaped a lot of our thinking over the last two years was simple: eliminate, automate, or delegate. In that order.
That order matters. Automating something you don’t need to do is just efficient waste. So before we reached for a tool or built a workflow, we asked why the step existed. What problem was it solving? Was that still the right problem? Was there a simpler version of the solution we hadn’t considered? LEAN manufacturing calls this muda — the elimination of waste before optimizing what remains. We didn’t start with that vocabulary, but we arrived at the same principle.
At some point in the last two years, something shifted in how our team instinctively responds to a repetitive task.
The first question stopped being “who does this?” and became “why are we doing this?”
That’s not a rhetorical question. We ask it genuinely, and we keep asking it, working back through the layers until we reach the root of what a given step is actually trying to accomplish. Sometimes that process reveals something useful: the step exists to solve a problem that no longer exists, or that could be solved more simply, or that we’d assumed needed solving but actually doesn’t. When that happens, the best outcome is that the step disappears entirely. Problem gone. No solution required.
This isn’t a new idea. Sakichi Toyoda built it into the Toyota Production System decades ago — the practice of asking “why” five times to reach the root cause of a problem rather than treating the symptom. We didn’t invent it. We just found that it applied as naturally to software process as it did to a factory floor.
That’s the first move: eliminate. We try to hold every step in our process to a simple test: Does this add value to the outcome, or does it just exist because it always has? Only once we’re satisfied a step genuinely earns its place do we ask the next question: Does a person need to be the one doing it?
For a lot of what we looked at, that questioning process didn’t eliminate the step, but it changed our understanding of it. And that understanding shaped what we built. If you know precisely why something needs to happen, you can design an automation that actually serves that purpose rather than one that mechanizes the existing habit without questioning it.
In the last post I wrote about redesigning our process so that messages and manual handoffs weren’t required to move work forward. Automation was the backbone of those changes. Once you’ve redesigned the process, you start asking: of the steps that remain, which ones actually require a human? The honest answer, more often than I expected, was: not many.
Let me give some concrete examples of what this looks like in practice.
When a developer starts work on a task, their set of changes should be automatically linked to the relevant work item in our project board. When those changes are submitted for peer review, same thing. When the review is approved and the changes are merged into the shared codebase, the work item status should update without anyone deciding to update it. When code reaches production, the board should reflect that immediately.
None of those steps require human judgement. They require information to move from one place to another at the right moment. So we automated them, using a combination of our project management tool, our code repository, and n8n, a workflow automation platform that connects systems together without requiring traditional software development skills to use.
he result is a board that reflects reality. When a developer looks at the board, they’re seeing an accurate picture of where everything stands, because the system is maintaining it.
That matters more than it sounds. A board that’s occasionally out of date is one you stop trusting. And a board you don’t trust is worse than no board at all. The deeper principle I kept coming back to was this: every unnecessary decision point in a process is a tax on attention.
One of the things that made this possible at our scale was n8n. It lowered the cost of building automations considerably — to the point where the people closest to a problem could often build the solution themselves, without needing to queue it as engineering work. That last part is important, and worth a concrete example.
As part of a broader initiative to catch quality issues earlier in our process — something I’ll write about in a later post — we defined a Definition of Ready: a set of criteria every work item must satisfy before it can be assigned to a developer. The question then became how to check work items against that definition without creating a manual review burden. One of our quality engineers took that problem on herself and built an n8n workflow to solve it. The workflow evaluates work items against our Definition of Ready using an AI agent. If a work item passes, it gets tagged “ready.” If it doesn’t pass, it gets tagged “not-ready” and receives an automated comment describing exactly what the AI found missing, with a reference to the person who created it. The entire workflow — including the AI integration — took her approximately one day to build.
The code review notification described in the previous post is another good example of the same principle: the right information reaching the right person automatically, with no human intervention required. Two very different problems, the same underlying approach.
The best automations tend to come from the people who feel the friction most acutely. If building an automation requires submitting a request and waiting for it to be prioritized, most of the smaller but genuinely valuable ones never get built. n8n removed that barrier — anyone on our team can build one, not just engineers. The result was an automation that doesn’t just identify a problem — it closes the loop entirely. No human has to triage, interpret, or forward anything. The right information reaches the right person with the context they need to act. The deeper principle was this: every unnecessary decision point in a process is a tax on attention.
Not every step that looked like a decision actually required one. Is this set of changes linked to the right work item? Has the status been updated since the code was merged? These aren’t interesting problems that deserve a developer’s focus. They’re administrative overhead dressed up as tasks. Add them up across a team of twenty people over the course of a day, and the attention cost is real, not because any single one is significant, but because the cumulative interruption to focused work is.
Our goal was never to automate people out of the process. It was to make sure that when a person’s judgement was genuinely required, they had the headspace to apply it. Skilled engineers should be solving hard problems. Not checking whether a card got moved.
Over time, the list of automated workflows grew, not because we sat down and planned an automation strategy, but because the habit developed. Someone noticed a repetitive manual step, asked whether it needed to be manual, and more often than not, it didn’t. Each automation that worked made the next one easier to justify.
In “The Phoenix Project,” one of the core ideas Gene Kim returns to repeatedly is the cost of unplanned work, or the small interruptions and manual tasks that don’t show up on any plan but quietly consume a significant portion of a team’s capacity. Repetitive manual steps are exactly that. They seem trivial individually. Collectively, they’re a meaningful drag on what a team can accomplish.
Automating is a decision about where skilled people’s attention actually belongs.
As with many of these changes, there is a more subtle positive result that is harder to measure, but real and maybe more important. People get to spend more of their time doing what they want to do instead of managing process. I discuss this in the next post.
There’s a version of this principle that goes further than workflow automation — further than anything a project management integration or an n8n flow can handle. I’ll get to that in a later post about AI. But the foundation is the same idea: if a step in a process is repetitive and predictable enough to automate, take the time to do it.
If work only moves when someone follows up, the system isn’t doing its job.
You can’t design something deliberately without being able to measure it. The next post is about how we approached metrics — what worked, what didn’t, and what we learned about the difference between measuring things and actually changing them.
