Why a “Broken” System Might Be Exactly What You Need

I used to think a “good” system was one you didn’t have to touch again. You build it, document it, roll it out… and then move on. When something broke, my first assumption was that I hadn’t thought hard enough the first time. We wait to build something until we’ve thought it all the way through. We hold off until we have more clarity, more time, more certainty. We tell ourselves we don’t want to waste energy creating something that might not work.

So instead… we keep everything in our heads.

And the irony is, the thing we’re trying to avoid - inefficiency, confusion, rework - is exactly what happens when no system exists at all. Over time, I’ve come to believe something that feels counterintuitive: failed systems are not a sign of poor leadership. They’re often the first sign of good leadership.

What I’ve learned instead is that a system that fails is often the most useful one you’ll ever build.

A few years ago, I was responsible for pulling together recurring narrative reports for students. Same questions every two weeks. Same themes, more or less. To make it easier, I built what I thought was a very smart system: a detailed Word template with prompts, examples, and guidance embedded directly into the document. The idea was simple - everyone would respond in one place, and at the end of the quarter I’d compile everything into the final report.

On paper, it was clean. In reality, it was a mess.

People saved multiple versions. Some edited over the prompts. Others emailed their responses instead. By the end of the quarter, I had half-complete documents, inconsistent language, and no easy way to track themes across quarters. The system technically existed, but it created more work than it solved.

That system failed. Fully.

But here’s the thing: building the wrong system taught me exactly what the right one needed to be. I learned that the problem wasn’t people “not following the process.” The problem was that the process didn’t match how people actually worked. What I really needed wasn’t a perfect template, it was a way to capture responses over time, track patterns, and reduce the end-of-quarter scramble.

So I scrapped it and tried again. This time, I moved to a simple form and spreadsheet that logged responses as they came in. It wasn’t fancy. It wasn’t perfect. But it worked better immediately. And then, over time, it got better because I kept adjusting it based on what broke next.

That experience completely changed how I think about systems.

A system doesn’t have to be perfect to be valuable. It just has to exist long enough to teach you something. You don’t learn what you need by thinking harder at the beginning; you learn by watching where things fall apart. And most of the time, those failures aren’t signs you did something wrong. They’re data.

I see so many leaders delay building systems because they don’t want to get it wrong. Because they’re already stretched thin. Because fixing something later feels like more work than just “doing it manually for now.” I get it. But the cost of waiting is usually higher than the cost of adjusting.

You don’t need the perfect system. You need a starting point. Something you can revisit. Something that can evolve. Something that gives you information instead of draining your energy.

Because the system that doesn’t quite work yet is often the one that finally shows you what will.