Dealing with illusions, dream castles and deception in IT

The newly established digitalization department has developed an idea for a new product. Implementing it would digitize the business model and, if it is visible on the market quickly enough, would give the company a real competitive advantage.

Everyone involved in IT realizes that this is the horse to bet on. At the same time, however, IT also has an extraordinarily bad reputation: too slow, too uninspired, too old, too expensive. Attempts have been made to change this, but visible success has been a long time coming, partly because it is still not possible to develop a common and stable understanding of priorities between IT and its internal clients.

The new product is therefore not only an opportunity, but also a risk. If the company fails to position itself credibly as the implementation partner of the future, the management could aim for a scenario of parallel development alongside the existing IT organization, a new structure with the popular epithet “digital”.

In this situation, the idea of a long-serving employee comes at just the right time: the organization's huge legacy stack contains the old application “Muli”, which in principle would represent something similar to the technical core of the new product. The team that has been looking after the application for years senses a breath of fresh air and vehemently supports this perspective. Why not build on this and massively accelerate the time-to-market?

The IT management grasps at this straw. Few things are more convincing than combining the new with the tried and tested and being able to build on a robust foundation. The staff department is also enthusiastic, as the market launch of the new product now appears to be much more manageable than originally thought. The head of IT aggressively claims development sovereignty for himself and the management follows the well thought-out proposal.

Quiet voices of doubt voiced in the corridors of IT are suppressed by obsessive confidence.

A few months later, the confidence is no longer there. With the first adjustments, more and more features of the old application came to light that called into question its suitability for the new product:

• As a previously internal application, it is far removed from modern security standards, which are a prerequisite for web applications. It is light years away from data protection approval.
• The underlying framework will be so outdated by the end of the year that security patches will no longer be delivered.
• The expected multi-client capability is realized by setting up the system multiple times. This is not what we had in mind.
• The monolithic character massively slows down the adaptations. Unknown dependencies and technical debts come to light with every change.
• The level of documentation is abysmal. There is actually only one developer who can claim to have a reasonably complete overview of the applications.

The development team still thinks highly of its own historical work. However, the IT management realizes that they have backed the wrong horse. But it's already in full gallop and nobody is really prepared to take responsibility for tightening the reins ...

And so it goes on and on. First obfuscation is replaced by justification, then blame is apportioned. In the end, the organization is faced with a new decision without a finished product: is it worth throwing more money after the investments already made or do you start all over again?

More common than you think and worse in its effects

I assume that such a scenario, in this or a modified form, sounds familiar to you. This type of deception is not only used in business model development scenarios, but also when competing IT structures are merged. Which stack prevails in the end is then less a technically sound decision, but rather the result of power relations or the sales talents of the stakeholders of the respective applications.

The damage caused correlates with the organization's ability to recognize mistakes and draw consequences from them. The sooner someone has the courage to put a stop to the development and find new approaches, the lower the negative impact.

Unfortunately, however, organizations that are caught up in IT blindness are rarely blessed with such a positive culture in dealing with mistakes. The organizational characteristics that promote these wrong decisions are very close to those that also make concealing mistakes a seemingly successful individual strategy: a lack of openness, a perceived need to set oneself apart and a fear of being set back.

It is therefore likely that once a company has been duped by IT, it will remain true to its decision until the damage takes on painful dimensions.

The technical solution to the problem

If I am faced with the challenge of having to make such a decision in an organization that potentially involves IT dazzle and I am in a leadership role, I generally have two options: Either I guide people to make their own decisions or I refer the decision to myself and, if necessary, my management team.

The former option only has a chance of delivering a sensible result if there are visible opposing poles with regard to the system decision that can come into conflict with each other. This is not the case in the anecdote formulated at the beginning.

If the opposite pole is missing, I expect people to act in a way that requires both a self-confession of limited possibilities and is drastically opposed to their individual interests. This is to be expected under few circumstances at the working level and no one can be blamed for it. At the management level of IT, there is more hope, but this requires the creation of a space on my part within which the uncertainties for IT managers are reduced.

If I have two strong stakeholders for their respective technical solutions, I can at least provide guidance on a methodical level on how to bring about a system decision. However, I must always be aware that evaluation schemes convey a false objectivity because they all too often already incorporate a decision-making tendency. If I am not familiar with the content of the topic to be decided, I can unintentionally favor one system over the other in the assessment by recommending an evaluation scheme.

In both cases, my biggest shortcoming is that I don't know enough about the technology myself to be able to see through Pontemkin villages and bogus arguments. This problem weighs even more heavily on me if I choose the option of making the decision for myself and my team: I am then completely exposed to my less than adept interpretation of the preparatory, naturally tendentious work of the stakeholders for the solution in question. It is questionable whether I would achieve a poorer quality decision by rolling the dice.

The best solution for all scenarios is therefore to seek external help in choosing the right path. I can expect unbiased expertise and genuine reflection on the options for action. But even under these conditions, we must not delude ourselves: One hundred percent protection against a wrong decision will ultimately never succeed.

However, one could be of the opinion that the risk is sufficiently limited by this conscious approach. But this only solves the apparent problem of the current choice of development approach. Potentially major damage becomes less likely if my decision quality has actually increased, but it is not ruled out. In order to minimize the amount of damage if it occurs, I have to meticulously observe the course of the project and react if I notice that the paint applied at the beginning is unexpectedly chipping off somewhere. So the concentration never wanes ...

The cultural solution to the problem

All of this seems time-consuming and unsatisfactory. Guiding employees, external consulting, project controlling, always accompanied by the feeling that not everyone is pulling in the same direction.

It would be much better if I could simply trust the judgment of the employees and if they, detached from their own interests, would exclusively pursue the good of the company. Under these circumstances, we would not see patterns such as those described at the beginning.

It is clear that this ideal can hardly be realized in the problem described. People identify with their work and their results, they are proud of them. It is not easy for anyone to recognize that there may be better approaches than the ones they have worked hard to achieve. Pride in work is an essential aspect of personal motivation to work and identification with the company that gives me the opportunity for individual development.

Political behavior, on the other hand, which is aimed at keeping issues within one's own sphere of action or expanding it in line with an individual interest, is not something you have to put up with. To get a grip on this, the creation of transparency is the appropriate means, because this form of politics can only thrive in the dark.

Truly living transparency in an organization is the result of cultural development. This cannot be triggered and implemented immediately when confronted with the problem described.

However, the following is possible: Push the decision-making process without interfering too much and consciously start the follow-up project, which follows the decision with the system selection, as a prominent proof of concept in an agile way of working with short iterations. Ensure that the team is not only made up of stakeholders of the selected system, but that at least neutral experts are also involved. Create broad awareness of the regular interim status presentations and ensure that critics also take a look at the progress. If the initial decision-making process was distorted by illusions and deception, this will quickly become apparent and the decision can be corrected. Avoid researching the causes of how the misrepresentation may have come about and only look forward in the process.

In addition to minimizing the decision-making effort and achieving an almost risk-free end result, this approach also ensures learning behaviour within the organization, provided that its basic patterns are consistently applied to problem cases of this type. There is a growing awareness that concealment is no longer worthwhile, as it will inevitably be uncovered, even if not punished. The absence of punishment leaves room for the perception of being allowed to make mistakes, which has a positive effect on the organization's willingness to make mistakes. And last but not least: transparency becomes an instrument that is used in a targeted manner to solve challenges and is thus gradually taken for granted.

In this way, the seemingly frustrating handling of illusions, dream castles and deception can ultimately have a positive effect!