By the time the new CTO came in, things didn't feel uncertain anymore. They felt settled, just not in the direction I had been working toward. Up to that point, most of the problems I had been dealing with were structural. Misalignment, lack of process, decisions that didn't quite connect to how the system actually worked. But they were still internal problems, things that, at least in theory, could be corrected if the right decisions were made. That changed when leadership shifted.

The introduction of a new CTO was positioned as a step forward. More direction, more alignment, more structure. On paper, that should have helped. In reality, it introduced another layer between the people building the system and the decisions shaping it, and almost immediately, the gap widened. There was a stronger push toward AI initiatives, new processes, and new ways of estimating and delivering work. None of that was inherently a problem. The issue was how it was done. Decisions were made quickly, often without input from the people closest to the system, and without much regard for what was already working.

One of the clearest examples was the shift in how work was estimated. The team had been using effort-based story points for years, a system that supported relative sizing, forecasting, and velocity tracking. That was replaced with a time-based model where one story point equaled one day.

On paper, it sounded simple. In practice, it broke the system. It removed the ability to measure complexity, invalidated historical sprint data, and made velocity tracking unreliable. I raised those concerns clearly and publicly, explaining exactly what would happen if we made that change.

Nothing changed.

That pattern kept repeating. Working systems in the conversion project were questioned or ignored in favor of older implementations. At that point, it became clear the issue wasn't progress or capability. It was direction.

The same thing happened with releases. A structured process had been in place, one that ensured proper QA validation before anything reached staging or production, and it had worked consistently. Then releases started going out without that structure. Without proper QA validation. Without the same visibility. Sometimes without the people responsible even being notified. When things broke, I was still expected to step in and fix them. The process was gone, but the responsibility wasn't. That's when it stopped feeling like misalignment and started feeling like a pattern.

At the same time, smaller things kept adding up. Tickets without clear scope turning into disputes after delivery. Public corrections over decisions that had already been explained and justified. Conversations happening after decisions were made instead of before. Individually, none of those moments were enough to define the situation. Together, they painted a clear picture.

I wasn't being asked to build something better anymore. I was being asked to maintain alignment with decisions I didn't agree with, in a system that wasn't moving in a direction I could support. That was the point where the question changed. It stopped being how do I fix this, and became should I still be here.

I had already done the part that was supposed to matter. I built the system. I explained the problems. I documented the risks. At that point, there wasn't anything left to clarify. I didn't make that decision quickly. I took the time to write everything out, not as complaints, but as documentation. Architecture, timelines, process issues, patterns. I wanted to be clear about what I had done, what I had seen, and why I believed the situation wasn't sustainable. That became the basis for a conversation with leadership. I wasn't asking for anything unreasonable. I wasn't trying to force change. I was asking for a path forward that made sense, either through real alignment or a clean transition.

The response I got was simple. A layoff would be the best option.

And that was it. There was no argument, no pushback, no attempt to convince me to stay or to revisit the direction of the project. Just an agreement that it made sense to part ways. In a strange way, that made the decision easier, because it confirmed what I had already started to accept. The gap wasn't going to close.

From there, everything became about leaving the right way. I proposed a final date, gave time for handoff, and made sure anything I was responsible for could be transitioned cleanly. I confirmed details around final pay, wrapped up conversations, and stayed present through the end. There was no reason to leave on bad terms. I had done the work. I had communicated clearly. I had tried to move things in the right direction. And when it became clear that the direction wasn't going to change, I chose to step away instead of fighting it.

That was the part that mattered. Not leaving because things were hard, but leaving because they weren't going to get better in a way that aligned with how I worked or what I was trying to build. Looking back, I don't see it as a failure. I see it as a boundary. There's a difference between working through problems and working in a system that isn't willing to solve them. I had spent enough time trying to do both to know which one I was dealing with.

So I stepped away. Not burned out. Not angry. Just done.

And for the first time in a while, that felt like progress.