A lot of what software teams call "process" isn't there to stop problems. It's there to make sure that when a problem happens, nobody gets blamed.
I'm not against process. A good runbook is worth a lot, and I like a real paper trail. But there's a difference between process that helps and process that only looks like it does, and the two are easy to mix up.
Good process is the residue of understanding. Someone figured out how the thing actually works and where it bites, then wrote it down so the next person doesn't get burned the same way. The steps exist for reasons you can explain. That kind of process is knowledge, compressed. It survives people leaving, and it makes the system safer.
Bad process is the opposite. It's ritual sitting on top of a system nobody really understands anymore. The steps get followed because they've always been followed. Nobody can tell you why step four is there, or what happens if you skip it. This kind of process isn't capturing knowledge. It's hiding the fact that the knowledge is gone, or was never there. And that's the dangerous kind, because it feels like control over something no one in the building can actually explain.
So here's a simple test. Does the process make the bad thing less likely to happen? Or does it just make sure the paperwork is in order when it does? The first is engineering. The second is ceremony.
We drift toward ceremony because it's visible. You can hold up a checklist and look responsible. You can't hold up the outage that never happened because someone finally understood the code. Prevention is invisible. Paperwork isn't.
The hard part is that the people who build all this are usually the good ones, the careful people who stay late and want to do right by the team, which is what makes it so awkward to tell them their careful work isn't actually protecting anything. You're not arguing with someone lazy. You're arguing with someone whose effort points at the wrong wall.
So I don't call it theater out loud. I ask one question: what problem does this prevent? If there's a clear answer, keep it. Often the honest answer is "it makes us feel like we did our job." Feeling safe is not the same as being safe.
Sometimes the answer is real. The team can't catch the problem on its own, and the process is the only thing between you and a mess. Fine. Add it. Just build it so it can go away once someone actually understands the system. Good process earns its retirement. Bad process sticks around because no one's left who knows what it was guarding.
So my advice is simple. If something only produces paperwork, get rid of it. Drop the meeting that exists for its own sake. Delete the Jira automation nobody actually needs. Then watch what happens.
Usually, nothing breaks. And that tells you everything.