Don’t Automate Useless Processes. Remove Them.

The industry says “automate everything”, I say: if it’s worthless today, remove it. We saved hours and stopped demotivating people in the process.

“Who is the audience for this internal document?” A team member asked me recently.

I paused. I thought about it. And then it was actually quite hard to realize, and even harder to admit, that the audience didn’t exist anymore.

He was absolutely right to challenge it. We were creating these documents simply out of habit.

The document in question was an internal technical changelog for each app developed as part of a project. In the past, project managers used them alongside completed tasks, to compose human-readable release notes for clients. But that process doesn’t happen anymore. And for developers, maintaining it is completely useless - Git history already tells the whole story. If someone really needs to know what changed, they can look at the commits.

We were writing for ghosts.

From that day on, we stopped doing it company-wide. Just like that, we saved hours of unnecessary monkey work that brought zero added value to anyone.

And that was just the beginning; below, I’m sharing 5 more I’m cutting.

The Automation Trap

This moment forced me to sit down and analyze my entire workflow in depth. I started looking for steps that I strictly maintain just because I’m used to them, rather than because they are actually necessary.

The tech industry’s default answer to tedious processes is always to automate them.

I disagree. If a step in a workflow doesn’t add value to the final result today, I won't automate it. I am cutting it out immediately.

Most repetitive steps in our work are just leftovers from problems we no longer have.

Here is what I am pushing not to do on the projects I lead, and a few “mandatory” processes we ended up shrinking or removing completely:

1. The Major Release Ceremony

Before, we had a massive ceremony around major version releases. It caused huge operational overhead. Worse, it actively demotivated team members.

Developers who wanted to make important updates to our internal libraries, even if they were breaking changes, were discouraged because the release process was such a massive pain.

We shrunk the process. We don’t need

• master-v1, master-v2, … protected branches
• complicated CI/CD
• :dev-1x, :dev-2x tagged Docker images

For that one person who, during a statistically rare occurrence, needs to backport something or develop on an older version, it will take them 15 minutes to sort it out themselves. That is vastly better than forcing the entire team to invest 5–10 minutes into release ceremonies for each library on each project.

Contributions have already doubled, and the velocity of new version releases has skyrocketed.

2. The Triple-Documentation Trap

We used to document the versions of running project services in three different places within our project management and issue tracking system. When I asked myself, “For whom?” the answer was ridiculous.

It was for a rare edge case that happens now, maybe once a year (it happened more often in the past). If we didn’t have the documentation, it would take a manager and a developer a maximum of 15-30 minutes to figure it out.

Why were we causing weekly overhead to solve a 15-minute annual problem? We stopped, with no negative consequences, and just saved time.

3. Requiring Full Code Reviews for Every Tiny Change

This made sense in early startups to catch big mistakes. But with automated tests, linters, and CI/CD pipelines, it’s complete overkill for

• non-breaking tweaks
• one-line fixes
• low-risk changes

GitLab merge request UI with required approvals (source: GitLab documentation)

Teams end up waiting days for approvals on trivial stuff. It kills momentum and makes developers second-guess simple fixes. We are shipping faster, and devs are more motivated to fix or improve small things.

4. The “Just in Case” Architecture

Setting up Kubernetes clusters and complex microservices for a simple CRUD application with 50 internal users, just because “we might need to scale to a million users one day.”

That is causing massive operational overhead today for a future that doesn’t exist yet.

I’m keeping it a monolith until it hurts.

5. Writing Thick, Upfront Specifications

We used to spend weeks crafting thick requirements documents for small- to medium-sized projects.

• screen-by-screen flows
• edge cases
• exact data formats

All for features everyone knew would evolve quickly once real users or feedback came in.

In practice, the first sprint or two revealed

• Our assumptions were wrong
• priorities shifted
• Half the spec became an obsolete paperweight.

This habit came from old waterfall fears or client pressure for “certainty.” But in iterative development, it just creates

• false security
• wastes time
• makes the team feel like they are building a ghost document rather than solving real problems.

Shrinking the Habitual

This mindset naturally bled into my personal life, too. I started challenging the small things I do just out of habit.

Do I really need to double-lock the house when I’m just walking a few hundred meters down the street for a few minutes? Do I really need to store that item perfectly in the closet when I’m taking it out 5 times a day? Do I really need all of these newsletters I’m subscribed to? Am I actually reading them, or do I just get nervous when they arrive because I leave them unread, keeping them “in queue” for a week? Do I need all of those subscriptions I pay for? Do I really have enough time to invest in them?

No. Absolutely not. My life got significantly less stressful just because of this realization.

It sounds silly, but there is a serious underlying point here.

There are things everyone is doing purely because “they have to be done.” On their own, each of these tasks causes just a tiny bit of friction. But over the long term, these micro-frustrations stack up. People start feeling

• demotivated
• frustrated
• nervous
• stressed
• or even aggressive when dealing with them.

You aren’t burning out your team with the hard engineering problems. You are burning them out with the useless rituals.

These habitual tasks are the most important candidates for the chopping block. You either change them drastically, or you cut them off completely.

My Advice

Simplicity is a highly underrated aspect of software engineering and life in general. My goal for 2026 is to make it a core focus.

Block out a week or two this year. Use this time strictly to revise the ritual, repetitive things you and your team are doing. Honestly, determine whether they are still relevant and needed today.

You will be surprised by how many of them are not.