It got worse before it got better. That was the point.

In HBS's Principles of Leadership, there's a simple matrix that reorganized how I think about change. Two axes: what you do (the wrong thing or the right thing) and how well you do it (well or poorly). The trap is the top-left box. Most of us are doing the wrong thing, but doing it really well. We're fluent in it. And to get to the goal, the right thing done well, you can't jump straight across. You first drop into doing the right thing poorly. That downward slide is discomfort and resistance, and what gets you through it isn't instruction, it's psychological support. Only then do you climb from poorly to well, and that second leg is learning, which needs the opposite: concrete, instrumental guidance. Worse before better isn't one move. It's two, and each one needs something different from you.

I lived the whole curve at Hubtel.

Pre-Covid, we thought we had a solid payment processing system. We called our APIs robust. We were doing the wrong thing well. Then a large, high-traffic client came on, others trooped in behind them, and the volume exposed everything our "robust" system couldn't do. The backlash was brutal. Our CEO made the hard call: don't patch it, rebuild it.

I wasn't Head of Engineering then, but I had enough voice to push for the architecture I believed in. We built a demo of a Kafka producer/consumer pattern and showed it to our already-frustrated CEO. He lit up and gave the nod. I also pushed us onto proper build and release pipelines, and some of those Azure DevOps templates are still in use today, which still makes me smile.

Then we slid into the valley: the right thing, done badly. We were redesigning over a few intense weeks, and in the middle of it we started getting hit with DDoS attacks. Long nights in the office arguing architecture, system design through to software design, the whole DevOps cycle. Our infra lead at the time, now our Head of Infrastructure, was in the trenches for every hour of it. And the new system, for a while, made things harder. Tiny changes drew huge backlash. Case-sensitivity on an API field. Date formats in callback payloads parsed wrong on the client's end. We made one Kafka payload attribute nullable and broke a whole chain of downstream consumers. The technical debt of moving fast in a new direction was enormous. If you only watched the performance graph in those weeks, you'd have called the rebuild a mistake.

What carried us through that slope wasn't a better manual. It was the psychological support the matrix names: a team holding each other's morale, a client who stayed patient with our scaling (I think our settlement model, money in their account the next hour, made the growing pains worth it for them), and a CEO who didn't reverse his decision when it got ugly. Then came the second leg, the climb, where instrumental guidance took over: the architecture calls, the standards, the templates, the hard technical conversations that turned poorly into well. We did the cutover after a lot of trial and error. The storms abated. Today that system processes millions in volume and value.

The debt we took on bought things that never show up on a graph: real standardization, a team that argued hard and stayed friends, the muscle to disagree about systems without it getting personal. You don't earn those on the way up. You earn them in the valley.