An incredibly stylish car passes you on the street. It’s saturated with the latest technology and safety systems that are far more than the current laws require. You can’t believe what you’re seeing, so you check the information about it on the Internet, where it turns out that it has already won more than one race and one of the safety aspects being looked at is large side mirrors while maintaining excellent aerodynamics and drag.
And it is a competition car, damn it!
You want one just like it, or a better one for your business - one that will replace that old grump that customers know well, but which is practically not worth repairing anymore…
Then you find that you have to find a dealer, schedule a test drive, place an order, and wait about 18 months for your first car. In fact, for many companies, it’s infinity. You can’t wait that long, so.
Have the body of your car patched to resemble a modern design. Replacing the engine is too expensive (and time-consuming, by the way - spare parts for your car are already very hard to find, and you have to manufacture the parts yourself), so you abandon it in the first place. You also don’t add new safety systems (electronics and their adaptation to your model are even more expensive).
You know that even though your car will go a little faster (the fastest ever) and more economically (the biggest fuel savings your organization has ever seen), you won’t win any races.
So you come up with another competitive advantage: the surface area of your vehicle’s mirrors is 2x that of your competitors, and you communicate this as even greater safety.
And that you’ll do this by tacking on 7 more mirrors to the 11 you’ve been installing for the past decades? It doesn’t matter, you are again the leader - solely in your eyes.
Sound absurd?
Similar to this metaphor is the technological situation of a company that communicates digital transformation, but doesn’t realistically carry it out due to having a very old technology stack, IT architecture, software full of spaghetti code and technology debt that is no longer controllable, with more and more projects becoming more expensive and more difficult to implement, involving more and more resources and causing more and more errors (also difficult to predict, sometimes more difficult to fix - and there are beginning to be some that are already physically impossible to fix in the current solution) - but the vision of waiting 12-18 months for solutions even much better than the competition is unacceptable.
Could it be more difficult?
Always. For starters, it’s enough that operational and decision-making people (or departments) don’t know the basics of the software development process, don’t have enough digital competence or - let’s take the situation to the absurd - are outright digitally excluded.
Using this very vivid example, I will describe what the hypothetical consequences of the above situation could be, and how important it is that the individual or individuals responsible for digital transformation (and in this series I call it Ops) - have above-standard competence.
A Mirage of Transformation
You wouldn’t let you or your loved ones be operated by someone who has only watched Dr. House, Grey’s Anatomy, Scrubs or even ER, would you?
In most organizations with a software component, fortunately, no one dies (and this is a very important piece of information that, among other things, allows you to distance yourself from your work), but with the knowledge of the software development process is already different.
The larger the organization, the more difficult and demanding knowledge to have - I don’t want to stigmatize anyone here, but only to show that this is not a trivial problem that can be easily fixed.
Maintaining outdated technologies
From time to time in my career, a very typical transformation scenario has emerged, especially in the area of companies with digital products. Established software no longer required a change in technology, but in foundation and architecture to meet the needs of the 21st century.
Most often it was desktop software, although sometimes still supported by systems from the MS-DOS family (yes, not yet Windows), and the customer’s wish was to migrate it to a web application, usually on a cloud environment.
The need for such a transformation is easy to see - something I loved my clients for, because it was interesting to hear what it looked like from their perspective (often even non-technical) to recognize this need.
These were picturesque stories, where helplessness was mixed with real concern for their own company stemming from the realization that something was very much wrong and the product had reached a wall in its development.
When the product is more subtle (e.g., has always been web-based or has always been a mobile app), it is no longer so easy to recognize. Failure to decide to replace it with new, more efficient solutions leads to, among other things, a drop in performance and an increase in vulnerability.
In the most drastic situations, it even becomes difficult or impossible to estimate these indicators - whether in ongoing work or as a result of updating the organization’s software.
The result? Difficulty in adapting to new market trends (too much technological inertia), and thus loss of competitive advantage. Among employees, this can cause an increase in anxiety or stress situations, with frustration at the forefront. There is a rising tide of declining motivation, loss of job satisfaction - and leaving the company (by the best ones) in the end.
Shades of technological debt
The increased cost and difficulty of maintaining and upgrading software is obvious. I am glad that more and more people outside of IT are aware of it. Here I’ll start perversely, because I’ll start with a scenario in which an attempt at real transformation is made.
Courageous organizations sometimes make decisions to create new solutions - ones that are really good, modern, ahead of the competition not by months, but by years. What can go wrong in such a scenario?
Lack of compatibility with existing infrastructure is the first thing that comes to mind. The product is mismatched with the architecture that has been present in the organization for years.
In extreme cases, it may turn out that it wasn’t even tested for it. In the worst: the organization finds this out after it has already been manufactured or purchased (when we are talking about working with a third-party supplier).
This is an often-overlooked aspect even in IT departments, greedy for technical innovations. Dear ones, I’m a nerd too, and I also get yoked by amazing solutions (especially nowadays, when everything is changing and developing so fast), but safety first.
When the topic of infrastructure is behind us, the other aspect that happens to be overlooked is the difficulty of integration with existing software - especially when the transformation is carried out in stages (and that’s exactly what it is most often: in large organizations we can talk about transformation processes lasting as long as 5-10 years) and a transition scenario is needed or the need to support key but very old systems in niche technologies.
The whole aspect of technology debt, when an organization pushes out that the pace of deployment of new products or updates to existing ones is increasing, flows out negatively primarily to the people who produce them - in our examples, primarily IT.
Workload levels increase, operational efficiency decreases. Frequent or constant technical problems (usually coupled with pressure to solve them as quickly as possible) turn the growing stress into cases of job burnout, missed by programmers just as technological debt is missed by non-technical people. Take care of yourself.
What cost optimization?
When it is in the IT area that there is a unit responsible for the cost of technical solutions and their maintenance, it is not yet bad. And if there is? Prejudices can be made just for specialists - a desirable situation.
However, the more the organization grows, the more the competence centers are separated and granulated, which is also a natural process, especially in the model of traditional corporations, i.e. with a strongly hierarchical and strong structure, rather than a flat or cross-area structure (sometimes there is also talk of differences in the project vs. product approach, but this already applies strictly to development, not to the management of the entire organization).
When a financial competence center is separated, such as an expanded accounting department, it is easy to make decisions without considering the context of the organization. What can this result in?
- Investments can be inefficient or misguided
- Operating costs are increasing (and I mean the entire cost of the organization: sometimes operating costs are the infrastructure and software maintenance itself, but this can also well include, for example, logistical elements in the areas of supply chains to the organization as well as to the end customer - examples can be multiplied and there are probably as many as industries)
- Cost reduction programs do not take into account, for example, the company’s strategy only assigns tasks for reduction to each department
- The profitability of the company is falling. The longer such a state persists, the more difficult it is to predict and manage.
Limiting or stopping innovation
Lack of understanding of technology or the basics of IT architecture over time reduces an organization’s ability to create a competitive advantage. Dependence on the widely understood legacy (each company has its own and usually calls this term something different) limits the ability to adapt to market conditions (and these are now changing ever faster).
There are even industries marked by the stigma of low or no innovation, but there the problem is most often even more complex (e.g., resulting from a large physical infrastructure, or the need to maintain processes older than… 100 years - I’ve done such things and it was also fascinating). I, in these texts, pluck the low-hanging fruit and paste on companies that are relatively easy to digitally transform.
Nevertheless, the decline in innovation over time is being noticed by more and more employees. And those who are motivated precisely by the impact of innovation (agility, the opportunity to see the fruits of their labor) - rather than, for example, financial factors - begin to leave.
The whole thing begins to loop and move toward collapse and stopping innovation. In the most difficult moments, when the organization can no longer even afford to transform itself (e.g., its market position is declining), the most common play is with promotions, price reduction vs. competitors’ products, which in turn introduces further risk - the brand becomes price-sensitive, and the pricing strategy lets go of customer value management (its quality and caloricity) in favor of high volumes at all costs.
The Cascade of Consequences
I’ve only listed you four example areas of risk due to the lack of digital competence in the broadest sense (but in the IT/software/architecture area - for simplicity within web and mobile technologies), but there are usually more, although in every company where I diagnosed this (in those most pleasant and sincere relationships - together with the organization) their specifics or proportions were different.
What is worth being sensitive to in your company?
Security issues. In our geopolitical situation and the push into the security/cybersecurity area, we are already talking directly about not only software vulnerabilities and bugs, but active cyber-attacks and difficult protection of customer data (about the organization’s intellectual property, industrial property or other industry-specific areas of secrets I am not even mentioning).
Project risk in the broadest sense. At a very general level, this can be simplified to: the cost of projects increases disproportionately to their complexity, the implementation process lengthens and also becomes unstable, and the percentage of projects/features whose implementation is a failure or whose implementations are canceled before they are released to customers increases.
Difficulties in data management. The more the lack of standardization of data, including processes for its effective storage, management and use, the easier it is to lead to a situation in which the phenomenon of so-called “dirty data” (when we are talking about customer/sales data - in extreme cases in organizations involuntarily and without malice create processes that contaminate this data) grows. And if we are talking about some analytical data, it may turn out that also their analysis is hampered and/or we collect an excess of them “just in case” (no longer just above the needs, but also the perceptual capabilities of your employees).
This, however, sometimes requires just the basics of technical knowledge.
Can a non-technical person notice that something is wrong?
Of course.
Communication problems between teams (especially IT vs. the rest of the organization). Misunderstanding and frustration are on the rise, and mistakes and misunderstandings (not even in projects anymore, but simply in relationships between people) are increasingly due to lack of a common language.
Resistance to change. Digital transformation has to provide benefits. The more difficult situation an organization is in (and the larger it is), the harder it is to justify in the short term (for simplicity: less than 6-12 months) and… the harder it is to understand, especially for non-technical people. Displacement, shifting of responsibility between departments - this is another harbinger of a bad state of the company.
Loss of customer confidence and financial losses. Let’s not kid ourselves, if we’re talking about such a situation, under recovery scenarios we can already see and bankruptcy, and a very large restructuring, and resetting the brand and building it (or a new one) from scratch to maintain liquidity and ensure the prospect of sales increases in the future. By the time you notice these things, it’s most often too late.
Importantly, at least some of the above phenomena can also occur as a result of actual digital transformation, but:
- improperly designed
- improperly implemented
- unsuccessful
- uncompleted.
Ops is a huge responsibility in an organization for the transformation, as they may be the direct implementers of the transformation, but above all they should be the entity responsible for the governance of the entire transition and protecting the organization - even if that means protecting it from itself.