Why does changing the IT leader lead to an internal crisis in the business?

Changing the IT leader in a company is often seen as an opportunity for a fresh start. But in practice, this “reset” turns into a systemic wipe, and along with the new position come a new philosophy, tools, approaches, and, most often, an internal conviction that “everything done before me was wrong.” Why does this keep happening? And how can we learn to ensure continuity in IT rather than revolutions? Let’s figure it out.

Laura Salamat, certified IT architect, CDTO at NNEF

In my practice over the past few years, I have repeatedly encountered situations where a change in IT leadership resulted not in a new direction for development, but in a complete restart “from scratch.” Instead of analyzing, refining, and strengthening already working solutions, everything is reconsidered. Architecture and decision-making are deemed unsuccessful, the team is considered insufficiently flexible, and even processes that have been digitized are labeled outdated.

This approach is perceived as a “fresh start,” but in reality, it often leads to the loss of valuable expertise, erosion of trust, and increased internal tension between IT and the business. Of course, there are situations where the system truly requires a radical overhaul, but such cases are now more the exception.

The “new broom” syndrome or the habit of starting everything from scratch. The desire of a new IT leader to quickly demonstrate results is understandable and logical, especially in the public sector, where the emphasis is often placed on “quick wins and results.” However, the problem begins when decisions are made not based on studying the current state, but from a position of opposition, akin to “everything was wrong before, now we will do it right.” On the surface, this sounds like a strategy, but in practice, it is more often a wipe. The team does not understand why their efforts are ignored, the business loses its anchor in IT, and ultimately, the leader themselves faces resistance that they themselves provoked.

What the business loses

The most critical aspect of this entire story is the loss of context. What seems inefficient from the outside often has justifications, compromises, and business realities that the new team has not yet encountered. Without understanding these factors, any new solution is viewed as a risk of repeating the same mistakes. Add to this the demotivation of key specialists, delayed deadlines, and “repackaging” the same solutions under different names. The losses in such cases are not only technical and cultural but also directly impact the budget.

Why this happens

International practice confirms that this is not a scenario unique to our country. According to Gallup, managers experience the highest levels of stress and burnout during periods of organizational change. McKinsey highlights that less than 40% of IT leadership changes occur effectively; in other cases, there are setbacks, strategic uncertainty, and reduced productivity.

In our context, the situation is exacerbated by the lack of a culture of transferring decisions. Documentation is often simply non-existent and is perceived as the norm. A new IT leader finds themselves in a position where it is easier to tear everything down than to restore the logic and sequence of already made decisions.

What to do about it

Instead of constant resets, mature teams can implement the following practices.

1. Systematic transfer of architectural decisions in the form of living documentation and meetings.

2. A phase of “understanding” rather than “breaking,” so the new IT leader must observe, listen, and be present on production sites for at least 30-60 days.

In practice, this means not just an adaptation period, but conscious observation and study of current processes, architectural decisions, and the logic of existing initiatives.

During the first 60-90 days, the task of the new IT leader is not to generate proposals for “quick results,” but to delve into the context, listen to the team, participate in working groups and retrospectives, to understand which solutions truly require changes and which require development.

3. Formalization of continuity or “handover” should be part of the management culture, not an exception.

4. Support for the key team or mandatory preservation of memory, decision logic, and trust within the collective.

IT always implies sustainable development, not quick restarts. A strong IT leader knows how to distinguish where restructuring is needed and where strengthening is required. If a company is forced to start from scratch every time the IT leader changes, the problem is not with the people, but with the lack of a systematic approach to memory, processes, and responsibility.

Starting from scratch every time is less about strategy; it is a signal that the system is not learning and not working.