Engineer to Zero

One idea keeps showing up in how I think about software, data platforms, and internal tools.

Engineer to zero.

What I mean by that is simple: build systems that remove support work instead of quietly creating more of it.

A lot of software looks successful on paper because it launched, automated one painful step, or gave a team a new interface. But if the result is more exceptions, more manual cleanup, more one-off training, or more tickets for the engineering team, then the system is not really done. It may have moved the work, but it did not remove it.

That is the standard I try to design against.

Automation is not enough

A lot of teams say they want automation when what they really want is assistance.

Assistance is helpful. It speeds up a person doing a task.

Automation is stronger. It lets the task happen with less manual effort.

But engineering to zero pushes beyond both. It asks a better question:

How do we design this so the operational burden keeps shrinking over time?

That changes the way you build.

You stop optimizing only for the happy path. You start thinking about edge cases, visibility, retries, governance, validation, ownership, and long-term maintainability. You start asking who will be responsible for this six months from now when the original builder is focused on something else.

That is usually where the real work is.

The hidden cost of half-finished systems

I think a lot of internal software fails in a very specific way.

It works just enough to get adopted, but not enough to reduce the surrounding operational drag.

So the team ends up with:

• a new app to manage
• a new workflow to explain
• a new set of edge cases
• a new place where data can become inconsistent
• a new queue of support work

That is a dangerous zone because it can look like progress while creating new long-term load.

I have seen this in data pipelines, process automation, onboarding workflows, reporting systems, and internal apps. The pattern is almost always the same. The initial problem gets addressed, but the system boundary stays weak. Visibility is incomplete. Exceptions fall back to manual handling. Then the organization quietly hires itself a maintenance tax.

The goal is not zero humans

Engineer to zero does not mean removing humans from every workflow.

It means designing the system so humans spend their time where judgment actually matters.

That usually means:

• less repetitive follow-up
• fewer preventable mistakes
• clearer ownership
• earlier error detection
• better defaults
• safer guardrails

A good system does not eliminate people. It eliminates unnecessary effort.

That distinction matters.

What engineering to zero looks like in practice

For me, the concept usually shows up in five areas.

1. Strong defaults

A lot of operational problems happen because a system makes the easy path ambiguous. Good defaults reduce decision fatigue and reduce bad data.

2. Validation early, not late

If data is wrong, incomplete, or inconsistent, catch it as close to the point of entry as possible. The later you detect a problem, the more expensive it becomes.

3. Visibility built in

If a system matters, it needs observability. You should know what ran, what failed, what changed, what is delayed, and who owns the next action.

4. Fewer hidden handoffs

The more a process depends on tribal knowledge and side-channel communication, the less real automation you have. State should be visible in the system.

5. Reduce exception handling over time

Every system has edge cases. That is normal. The goal is to notice the recurring ones, productize the handling, and shrink the manual path with each iteration.

Internal tools deserve better product thinking

One thing I care about a lot is bringing stronger product thinking into internal tools.

Internal software often gets treated like it only needs to function. I think that is a mistake.

When internal systems are confusing, brittle, or inconsistent, the cost shows up everywhere:

• slower teams
• more support tickets
• more training burden
• worse data quality
• reduced trust in the system

That is why I care about interface clarity, field permissions, workflow state, content structure, and backend-driven rules. Good internal tools do not need to feel flashy, but they do need to feel intentional.

If the system is going to sit in the middle of real operations, it deserves real design.

A good system should get quieter

This is probably my favorite test.

A good system should get quieter over time.

You should see:

• fewer questions
• fewer corrections
• fewer workarounds
• fewer emergency interventions
• fewer places where engineering has to babysit the process

That is the outcome I want.

Not just software that exists. Software that reduces noise.

Final thought

I do not think every project has to start with a giant architecture exercise. Sometimes the right answer is to move quickly, ship a useful version, and learn from the process.

But I do think the end goal should be clear.

Do not just automate the task.

Design the system so the support burden trends toward zero.

That is the kind of software I want to build more of.