I have always believed part of my job is to make parts of my job unnecessary.

Automate the repetitive work. Fix the friction. Teach someone else what I know. Build systems that do not depend on me.

Then move on to the next important problem.

That mindset has shaped much of what I have been working on lately, and Labor Day seemed like a fitting time to think about why.

Labor Day grew out of the labor movement of the late 1800s, when workers pushed for better conditions, shorter hours, and greater recognition of the value of their work. The first Labor Day celebration took place in New York City in 1882, and it became a federal holiday in 1894.

More than 130 years later, the nature of work has changed dramatically.

The questions around work have not.

When technology makes us more productive, should the goal always be to produce more? Or should progress also mean spending less time on work that no longer requires us?

Removing the Work That Gets in the Way

Much of my recent work has focused on that question.

Through my AI Flywheel series, I have been exploring how AI agents can take on more of the implementation process while people continue to provide direction, review, and judgment.

I have also been building CopyGitHubRepo, which automates repetitive work around repository snapshots, migrations, releases, and GitHub Pages.

And I continue to think about the ongoing effort required to keep platforms such as .NET current as new versions arrive and older ones reach end of support.

These may look like different problems, but they share an underlying idea:

If a machine can reliably do the work, why are we still asking a person to do it?

Software development has always moved in this direction.

Higher-level languages replaced lower-level programming. Frameworks reduced boilerplate. Build systems automated compilation. CI/CD automated testing and deployment. Containers standardized environments.

AI agents are pushing that boundary further.

The work does not simply disappear.

It moves.

Developers spend less time performing mechanical tasks and more time deciding what to build, evaluating tradeoffs, reviewing results, solving difficult problems, and taking responsibility for what reaches production.

Fill the Potholes

I use another analogy frequently in my career.

Imagine driving the same road to work every day. A section is filled with potholes. Traffic slows down. Your commute gets longer. Everyone knows the problem exists, but nobody is fixing it.

Technically, repairing the road is not your job.

But the potholes are still affecting you.

At some point, my instinct is to get some gravel and fill the holes.

That does not mean ignoring responsibilities or organizational boundaries. It means recognizing that sometimes important problems sit between those boundaries.

I tend to look for those problems.

Where are people repeatedly losing time?

What process creates unnecessary friction?

What knowledge depends on one person?

What are we doing manually simply because nobody has stopped to improve it?

Those are often some of the most valuable problems to solve.

Replace Yourself

The same philosophy applies to leadership.

I am always trying to replace myself.

If I am responsible for something important, I want someone else capable of taking it over. I want the knowledge shared, the process understood, and the system able to operate without depending on me.

That creates room for me to move on to the next important problem.

I think automation is another version of the same idea.

A team should not manually repeat deployment steps that a pipeline can perform safely.

An engineer should not spend hours on a repository operation if CopyGitHubRepo can do it consistently.

And developers increasingly may not need to personally write every line of implementation code for a well-defined task.

Replacing yourself in a task does not make you less valuable.

It creates capacity.

Productivity Should Create Capacity

This is where conversations about productivity can go wrong.

When technology saves someone an hour, the immediate question is often how to turn that hour into more output.

I think there is a better question:

What can that person do now that they could not do before?

Maybe they can solve a harder problem.

Improve a system that everyone has learned to tolerate.

Mentor someone.

Learn something new.

Think more carefully about an architectural decision.

Or simply avoid spending another hour doing something a machine could have handled.

That is what connects much of what I have been working on lately: automation, CopyGitHubRepo, and the AI Flywheel.

They all lead back to the same question:

What work no longer requires a person?

Labor Day seems like a good time to remember that the answer should not simply result in higher expectations for how much work people produce.

Progress can also mean removing the potholes, replacing ourselves in work that no longer needs us, and creating room to move on to something more valuable.

Sometimes progress is measured by how much unnecessary work we leave behind.