The refactor trap in the first 100 days

You are working through the 100-day plan. The technology team are keen to refactor, clean up the code and tidy the technical mess. That is where the trouble often starts.

The truth is that they have wanted to do this for a long time. There have always been more pressing priorities. A new owner can feel like the chance to reset that.

The problem is that this can be a Pandora's box in disguise. The scope for refactoring and technical cleanup grows faster than Japanese knotweed. One module pulls in another. A schema change forces a service rewrite. A library upgrade exposes three more. Before long the project is six months old, the timeline has moved six times, and there is no clear end in sight. Meanwhile the real value-creating work, the things that rely on technology to support the investment thesis, sits on ice.

The problem usually starts by asking the wrong question. "What could the technology look like?" Or worse: "How would we build it today?"

Post-acquisition, the better starting point is much simpler. What happens if we do nothing? Which parts of the system genuinely block the plan, and which are simply imperfect? The honest answer is usually that most of the technical mess is tolerable for now, and a smaller subset is actively in the way.

You do not have the luxury of aligning every duck perfectly. Momentum matters, particularly in the first year after a deal. Ask the question. Justify the priorities against the value creation plan, not against an engineering ideal. Timebox the work. Execute. Then ask the question again.

Refactoring is not about building the perfect system. It is about removing just enough friction for the business to move forward.