> The software was designed following best practices. It is stable, people iterate quick. You can take your time to think about the best solution. Except that

> The software was designed following best practices. It is stable, people iterate quick. You can take your time to think about the best solution. Except that the messy project you were working on before sounded like a one man project. And at every new change request you delivered, working by yourself, a pretty big chunk of value. Now, in the nicely engineered project, you work in a team. The team is iterating in sprints that require a number of developers two or more weeks of work to deliver the tiniest feature. Yes, iteration is quick, but it doesn't really deliver much value. Every time the new CEO requests something even slightly different from the exact functionality that was developed so far, the project architect's answer is that this will not fit in the current set of features, and it might be possible, if ever, after another series of sprints that will take multiple months to complete. And the funny thing is that, while in your one man project you were considered a lone cowboy working on a relatively simple system, the architect of the current project (that delivers more or less the same functionalities but requires 5 or 6 times the time and resources to maintain) is considered a demi-god "because the project is so complex". Because of course the CEO measures the complexity of the project not but what it delivers, but by the amount of resources consumed by it. And while the CEO of the previous company was annoyed when a new feature required more than a week to implement all by yourself, now whenever the new architect says "we need more resources for that", this actually increases his power and consideration in the company, as it is taken as a sign of the complexity of the project.