Worlds apart

How IT and the rest of the world drift apart

Uwe Friedrichsen

9 minute read

Steam locomotive (seen in Hungarian Railway Museum, Budapest)

Worlds apart

A few days ago, I saw the following job advertisement creating a lot of mockery in the Internet:

A job ad requiring at least 12 years of experience with administration of Kubernetes, a tool that was initially released 6 years ago

While I perfectly understand why it received so many ironic comments, I think it goes deeper. Pondering the paradox of the job ad for a moment, I thought that it actually points out some much more fundamental problems. Thus, I decided to spontaneously interrupt my “Simplify!” blog series and insert this post.

Speed of technology adoption in IT

The first important thing to note is the increased speed of technology adoption that has become normal in IT. We do not only face a technology explosion in the recent years, i.e., a multiplication of tools and technology options available 1. We also adopt them at a much faster pace than we did in the past.

About 10 years ago you could still be quite sure that any new technology that hit an IT operations department of an enterprise, was at least 10 years old. Younger technologies usually were considered too immature for enterprise usage.

In the recent years this changed. Especially the rise and adoption of container technologies with Docker and Kubernetes occurred at an unprecedented speed. Instead of 10+ years, it just took 2-3 years from the initial release to widespread enterprise adoption.

You could argue that containers were an exception because they solved several long-time problems that troubled development departments as well as operations departments:

Containers basically right-shifted the separation between applications and the OS. Before containers, the OS contained lots of infrastructure components that applications needed to run: libc, JDKs, application servers, Python, PHP or other language runtime installations, just to name a few.

It was always a negotiation mess between development and operations:

  • Development departments were limited in their projects to solutions that were backed by infrastructure components on the OS level that the operations departments needed to provide.
  • Operations departments on the other hand could only update their OS and infrastructure components after every application maintained by the development departments supported the new infrastructure component versions.

Everybody hated this dependency mess that impeded both of them.

So yes, of course neither development nor operations needed to think for a long time if they wanted to go for containers:

  • All infrastructure dependencies of the application are bundled together with the application in the container, i.e., no dependencies to components that need to be provided on the OS level. Development departments can move at their pace without having to wait for operations.
  • And on the OS level, the container scheduler restricts itself to the job, an OS did in its beginnings: Managing access to resources like compute, storage and network. As a result, operations departments can move at their pace without having to wait for development.

The whole dependency mess was blown away with a single new technology.

Still, while this for sure was part of the initially unexpected fast adoption rate of containers, I do not think they were a rare exception.

Also NoSQL databases, a technology wave emerging before the container wave, were adopted a lot faster than prior technologies. And looking at newer waves like, e.g., serverless, consisting of FaaS and managed services, we can see that those technologies are adopted at a similar fast pace as containers.

So, I think we observe a shift in technology adoption. The timespan between genesis of a new technology and its adoption became shorter. Even enterprises understood that they need to adopt technologies at a faster pace today if they do not want to loose touch with the IT evolution and the new options it provides on a business level.

Additionally, many of the new technologies that are adopted at a faster pace also support moving faster with IT. This creates better options to respond to markets that have become more dynamic with appropriate post-industrial means in IT – always keeping in mind that IT, not only due to the digital transformation has taken a much more critical role within a company than it had in the past.

Summing up:

Technology adoption has become a lot faster in the recent years.

IT detached from the rest of the world

The second thing we can observe from the job ad is that the world outside IT has a hard time understanding what is going on in IT. In the worst case people outside IT are completely detached from what is going on on IT, maintaining their image of IT they have created many years ago.

The job ad pretty much sums up this effect: The HR department who created that job ad most likely did it according to their long-standing rules, probably stating something like: Junior role: 2+ years of experience with the respective core technologies, normal role requires 5+ years and senior role 12+ years. That would be a typical schema we have seen for many years in job ads.

We could now have long discussions how sensible it is in general to require 12+ years experience with a technology for a senior role. I mean, expecting someone to have 12 years of deep expertise in a single technology at the same time means that any person satisfying this requirement usually is detached from other developments in IT for at least 10 years. You are calling for a one-track specialist.

Thus, personally I think that such a requirement is highly questionable regarding any job in IT – not only today, it also was in the past.

Nevertheless, this is not the point. The key point is that while it was possible to expect such a long-time experience from an IT applicant in the past, today in most places it simply does not make any sense anymore.

Let us just look at same popular technologies of 2020: 12 years of experience in Docker? Kubernetes? AWS anything beyond S3, EC2 and SQS? Angular? React? Kotlin? Swift? Apache Kafka? Spring Boot? And so on.

For most of the tools and technologies that define the standard stacks of 2020, even requiring 6 years of experience often does not make any sense because they exist only for a few years.

Yet, most of the people outside IT have not realized that shift inside IT (not to mention many other shifts that I do not discuss here). For them IT still is the old, slow cost center, just being expensive while impeding business progress. 2

Summing up:

The world outside IT is not aware of the changes that happened inside IT.

And now?

The question is: What can we learn from the job ad? … well, after (justifiably) making a bit of fun of it … ;)

Probably we could start quite a lot of discussions. But I do not want to take it too far. Still, I think we can derive a few insights:

  1. We need to prepare for shorter adoption cycles – This also means that we need to learn new tools and technologies more often than we needed to in the past. A side effect of this is that we need to learn to balance picking up new technologies and acquiring deep expertise. I know, this probably sounds like a quite unpleasant trade-off and admittedly I do not have an easy answer to it. But I think, fact is that we need to deal with this up-to-date vs. deep knowledge trade-off.
  2. We should avoid to jump on each bandwagon – It is important to understand that the previous recommendation does not mean that we should pick up every novelty we see. In IT, we are surrounded by a whole industry that tries to create new hypes every single day to maximize their revenue. Often, it is hard to resist all those intended distractions and separate the wheat from the chaff. While it is important to understand some of the new technologies at least a bit, others can be ignored safely. We need to stay critical about all the silver bullet merchants and try to understand on our own if the new technology really creates relevant new options or not.
  3. We need to Help people outside IT to understand IT – If people outside IT do not understand what is going on inside IT, misconceptions and irritations arise. Most of them are not as funny as the job ad that was the trigger for this post. Even the job ad has the potential to create lots of harm and frustration if the responsible HR people decide to insist in the 12 years of experience. Therefore it is more important that ever not to deride people who do not understand today’s realities of IT, but help them to understand. Try to see IT with their eyes: For most people outside IT, IT is a closed book written in a very strange language. Helping them to understand IT at least a bit will prevent us from a lot of harm and frustration that will hit us otherwise.

Summing up

These were some thoughts I had when reading the impossible to satisfy job ad from the beginning, requiring the applicants to have at least 12 years of experience with a tool that only exists for 6 years.

What I read from that job ad after smiling about it was twofold:

  • The technology adoption rate in IT became a lot shorter in the recent years.
  • People outside IT do not understand how much IT changed in the recent years.

There is a lot of upheaval going on in IT these days and it is not yet clear where it will end. But no matter if we like it or not, we need to deal with it in a constructive way. Making some fun of such a job ad is fine, but after that, I think we need to go beyond it.

Otherwise the things the ad just uncovered will shape us. But at least I want to shape and not get shaped. 3

I hope the post gave you a few ideas to ponder. Nonetheless, it is also perfectly fine to revisit the ad and give it another smiling shake of your head … ;)


  1. I will write about this phenomenon in more detail in one of the next “Simplify!” posts where I discuss accidental complexity on the technology level. ↩︎

  2. To be fair: Some IT departments still behave exactly this way. ↩︎

  3. I know that the latter cannot be avoided completely. Still, I think it makes a big difference if you try to actively shape your surroundings or if you only respond to the forces that work on you. ↩︎