When the System Becomes the Work

We thought we had it figured out.

We rolled out a new resourcing system using our project management tool. It was meant to be the source of truth: hours, tasks, timelines, dependencies, level of effort, all mapped out. Forecasts. Allocations. Protections against overbooking. Everything accounted for in one place.

But something was off.

We started noticing that people weren’t focused on the work, they were focused on the system. Time was being spent adjusting tasks, aligning numbers, shifting timelines, and trying to make everything match. The system we built to help us plan was becoming the work itself.

People were frustrated. Managers were spending hours moving things around just to make the data look right. PMs were asking, “What’s real here?” And team members? They were stuck trying to decipher what they were supposed to actually do.

The irony is this all came from a good place. We wanted structure. We wanted accuracy. We wanted to avoid overbooking and burnout. But we crossed a line. Our infrastructure stopped supporting our delivery and started dictating it.

And that’s when it hit us:

The system shouldn’t lead the work. The system should support the work.

So we stepped back. We killed what wasn’t working. We stopped pouring time into maintaining a structure that didn’t reflect reality. We simplified. We rebuilt. We focused on usability, clarity, and real-time alignment over theoretical perfection.

And most importantly, we listened to the people using it.

The lesson? Complexity isn’t always smart. The best systems are the ones people barely notice because they’re working. Because they make it easier to deliver, not harder.

If your team is spending more time updating the system than serving clients, it’s time to pause. Rethink. And maybe start again.

Richard