Avenga’s response to the war on Ukraine: Business Continuity and Humanitarian Aid
Director of Avenga Labs
Table of content
I use this term very often in my articles and discussions with my colleagues and clients. This is a force to be reckoned with because it is shaping our technology landscape, digitalization opportunities, and risks, whether we like it or not, so let’s face it head-on.
The times we live in are called by many names and one of them is the attention economy. In order to sell a product or a service, a piece of our attention is needed. We are constantly distracted by advertisements, banners, sponsored content, and even unwanted text messages and robocalls.
The same attention-grabbing techniques apply to solution architects, developers, and well, basically all the IT roles. It does not matter which different sources of technology or sector news they follow or which conferences they attend, or even how often they discuss things with their colleagues.
This constant flood of information (and misinformation) creates a phenomenon known as the Fear Of Missing Out (FOMO). Many people are anxious about working in an old-fashioned way or using not-so-hot technologies, tools, and platforms. We think “Am I the only one left who uses this technology?” “Is everyone else moving elsewhere?” “Am I lagging behind?”
This has both individual aspects (attractiveness in the labor market) and company-wide aspects (are we still technologically relevant?).
Let’s talk about the good, bad, and ugly sides of FOMO in IT.
Software and IT are fashion businesses. Something that is not easy to admit at first, but with some experience and wave after wave of new fashions, styles, and changes in the popularity of technologies, we come face to face with this understanding.
Non-tech people, even those formally from the IT sector, often quote the pros of each new thing in IT. For example, non-relational databases, AI saving the world, blockchain as the new future, etc. This one-sided version of reality is often emphasized by technology vendors showing the benefits of each new thing.
What is good about this is the ability to get the attention of many players so they at least take a look at the new trend, pattern, or technology and analyze its usefulness for local needs, and its impact on today and tomorrow. This is what my group, Avenga Labs, is doing for its clients and for Avenga. Nobody likes missing opportunities and being behind their competitors.
Technology responding to business is one way, a traditional one.
Another is the opposite approach, which means trying to find the right fit for the new incoming technologies into today’s and future business opportunities.
FOMO is also a great motivation for all the tech people to learn new skills, try new things, and be more open to even changing their job profiles. I remember the times when mobile applications were all the rage (the early 2010s) and everybody wanted to at least try Android SDK and create simple mobile applications. Only a few remained loyal to the new trend and were willing to switch their primary line of jobs, but it definitely helped with the acceleration of a big mobile revolution back then.
In the case of companies moving slower (followers, late adopters majority), FOMO is the key reason to amplify their cloud transformation efforts, catching up with modern Customer Experience services, data strategies, Machine Learning efforts, API management, DevOps, DevSecOps, NoOps and so much more.
Focus and motivation are the most important factors that help teams to achieve maximum efficiency.
FOMO very often acts, not as a motivator for finding the best solution for the problem, but for finding a problem for the new hot solution (technology, pattern, tool) and then pushing it into the project, in order to fill another slot on a resume while having some fun at the expense of project delivery velocity, and attention to the business and non-functional requirements.
Losing focus on the actual requirements is a very common problem nowadays, because the individual goals of the team members are not in line with the goals of the project too often.
FOMO is also an important factor in people changing companies or looking for a new project, where they will be able to catch up to everything in order to reduce their technological anxiety.
They are usually promised that they will have time to catch up on the latest trends, but the project pressure often makes this impossible and it is often easier to change jobs than find time to learn new skills.
Another huge problem is what the technology giants are doing to the minds and souls of tech people, by using their brands to promote solutions and technologies which are of much less relevance to enterprise applications. In my discussions with different architecture teams, everybody recognizes it as a problem, saying “we are not Netflix/Google/Facebook . . .”.
Very often business users, in their own version of FOMO, are pushing technologies and IT has a hard time explaining why not, what risks are involved, and what the consequences will be for IT and business performance.
It’s also FOMO that may be a strong force behind shadow IT when people decide to buy SaaS services to work in a more modern way.
Technology FOMO, when not tamed down by technology leaders or product owners, because they are using a naive agile approach to “let the team decide” and not challenging those ideas at all, can turn successful projects into an unmanageable mess and can even end up in project cancellation. The same FOMO reason that made the team try new things, may be the same reason why they will abandon the project because the experimental technology or pattern did not eventually work. The living organism of the project and IT solution may simply not survive a series of FOMO-inspired experiments.
So, the worst-case scenario is not “just” not delivering on time, but is creating a solution that will be doomed to failure even before the first production release.
Technology governance is often lacking… courage to even start a discussion before it’s too late to reverse changes or analyze the alternatives.
FOMO is inevitable, but the question is to what extent is it allowed to influence critical project decisions and how much are the stakeholders willing to pay for the lesser focus on their goals?
First of all, the energy can be used to train the teams and let them educate themselves in interesting new technologies, which will increase the motivation and capabilities of the IT organization. There’s always something that we’d like to learn if we had some more time. I am one of the lucky ones who does this as their primary line of work, both internally and externally with clients.
The new stuff should be verified in Proof Of Concept activities and separated from regular work. The results should always assess the real benefits versus the cost of adopting the new shiny tech, its expected lifetime, and the popularity of it as well. Doing it half-time and after-hours is not an effective way to truly assess the potential and risks related to a new technology.
It’s also important to be prepared for the negative outcomes of those experiments. Avoiding using the wrong solution is a big time and money saver, and the technologies are never as shiny, easy to use, error-free, and … useful as advertised. The question is often not if it works, but is it better than what I use now and will it be better for the future. What are the pros and cons, and what will the probable adoption look like?
It’s also very important to share the results, presentations, code, and whitepapers with the local tech community, so that people, who literally have one hour to spare, can at least be aware of what this new hot trend and technology are about.
From my experience, it may lower the FOMO, but it also encourages a few to learn and further investigate the given technology.
It’s important not to miss new opportunities, but also to be careful not to create internal technology fragmentation on the project/portfolio/company level, at least without clear and undoubtable benefits.
Modern agile techniques, such as Architecture Decision Records (ADRs), are helpful tools to organize discussions around technology and solutions choices.
Evolutionary architecture is a great strategy choice to upgrade technologies and patterns, both in the new and existing software solution, while tracking the consequences of each choice by using fitness functions. Adaptable architectures are also reducing technical debt and FOMO at the same time. And, you can start to embrace evolutionary architectures at any time, if you haven’t done so before.
Safe choices of mainstream technologies in their latest versions, plus regular updates during the lifecycle of digital products, are probably the easiest way to find a balance between the FOMO needs of the teams and the predictability of the digital efforts.
The technology life cycles are shorter than ever, but usually, companies don’t switch from fundamental Java/C#/Python to something else because of boredom.
However, add to it another Labs / R&D stream for experimentation and the workplace can still be very attractive to luring in new talent and modern technology.
Functional requirements usually overshadow non-functional ones. So NFRs and their implementations are too often neglected or even skipped.
Then, someone invents nonexisting problems that are motivated by their latest discovery of a new trend or technology and they push this trend/technology in order to solve the non-existing problems, which really create multiple other problems.
The right definition, conversation, and awareness of priorities are really important to avoid FOMO-related problems and also to embrace FOMO-inspired solutions for the actual important problems in the particular solution.
Cooling down curiosity and experimentation to an absolute zero degree is a fast track to become technologically irrelevant in the modern dynamic market.
On the other hand, extreme anxiety about shiny new things without relation to value-added and proper risk management is a recipe for another kind of disaster.
The best way is … the hardest one, because it means dynamic balancing between the adoption of the new trends and solutions, and not being stuck in the IT past.
There are safe choices and the dialog is the key to selling a little less adventurous technology choices to the teams while dedicating time for training and POCs with the latest technologies. Asking “Why? What for? What if we don’t?” is a great way to show the real reason and motives behind different ideas. They all may seem great at first, but the questions do help. I encourage you to ask yourselves these questions and ask your teams.
FOMO is one of the frequent, albeit “implicit” topics nowadays. With its different consequences and manageability challenges, the Fear of Missing Out is one of the strongest human emotions, after all. Let’s turn its undoubted energy into a maximum value.