a-c-LKwn7PJp_-E-unsplash

A Spring Reset

This time of year always makes me want to clean things up a bit—not just closets or inboxes, but the way things function. Spring is a good reminder that not everything needs to be kept just because it once worked.

I see this a lot with systems.

Processes get built with the best intentions… and then slowly become frustrating, inconsistent, or quietly ignored. Not because people don’t care, but because the system was designed for a version of reality that doesn’t actually exist.

One pattern I come back to often:
If a system only works when everyone does exactly what they’re supposed to do, every time… It’s probably not going to work.

We build systems based on how we hope people will behave.

We assume someone will remember to send the update.
We assume a client will read the full email.
We assume a task will get passed along without friction.

And when it doesn’t happen, it’s easy to think something is broken in the people. But more often than not, it’s just the design.

The same thing shows up in automation.

Automated responses can be incredibly helpful. They create consistency and take pressure off. But they work best when they support real interaction, not replace it. Too much automation, and things feel cold or disconnected. Too little, and everything depends on memory and follow-up. The balance is where things start to feel natural.

The same goes for delegation. Handing something off only works when the flow of information is just as clear as the task itself. If a system depends on someone remembering to send things over, it will eventually stall. But when information is captured as part of the process (shared spaces, simple handoffs, clear rhythms), it starts to run without friction.

If you’re doing any kind of spring reset, it might be worth asking:

What only works when everything goes perfectly?
Where am I relying on memory instead of structure?
What feels harder than it should?

Those are the places worth adjusting.