The Competence Problem in Modern Tech Training

The Competence Problem in Modern Tech Training

by Nato Riley

What if vendor-focused training makes users less competent?

What if I told you that many vendor trainings unintentionally make their userbases less competent?

What if operating systems were built around competence more than brand loyalty?

For that matter, what if hardware was able to help train and learn alongside its user?

To clarify, I'm talking not talking about all vendor training. This topic is focused on trainings from vendors that lock the user's skillset. Vendors are able to choose whether or not to create vendor-locked training models.

As an educator I think a lot about what helps learners become more competent.

Vendor lock-in vs real-world skill

One of the most challenging things I've ran into in the field when training enterprise teams is that a developer with a vendor-locked skillset tends to struggle to keep up with a top performer with an agnostic skillset.

For example, a cloud engineer who is task-oriented and has a skillset that's vendor-locked with a single platform like AWS might often think that to use another cloud platform such as Azure they must go learn something entirely new.

On the other hand, a goal-oriented cloud engineer who knows Azure, but understands the underlying similarities between Azure, AWS, GCP, and other cloud platforms even self-hosted technologies  will often have superior performance in the real world with technical tasks.

For years, I wondered if the issue was that the training formats were creating challenges in with talent being able to perform necessary engineering tasks for technical jobs.

Competence of the Creators

What would often confuse me is some of the most "technical" minds came from non-technical backgrounds such as journalism, psychology, marketing, and many often didn't have degrees.

If the right opportunity comes up, these types tend to take on any form of learning opportunity that excites them, and they often don't worry about the cost of education if they decide there is a form of learning that excites them.

For this type of thinker, knowledge is a thing to play with, and learning more means more to play with.

Observations of the Critics

On the other hand, I would see other personalities get hired who would constantly keep trying to get a new certification or a new degree, and while the other type of enterprise worker I mentioned above likes to learn, these thinkers instead tend to get locked into a vicious cycle of learning without applying the knowledge.

They don't treat knowledge as a thing to play with; rather it is a thing to theorize around and critique.

On one end, creators will take observations from critics and then go on to create new ideas to explore. The actions of creators create tangible real world results to critique.

What's rare is the skill achieve both the perspectives of the creator and the critic.

AI and the rise of competence as currency

Before AI, we called this a "Jack of all trades" or a "master of none."

Now that AI can cover so much depth when it comes to engineering, it's changing how talent works in technical industries.

It's becoming more valuable for human workers to do what humans do best, such as innovate and drive creativity.

Mundane, monotonous tasks that take us away from our humanity can now be taken over by AI, allowing a jack of all trades to be able to manage the bigger picture when it comes to building new technologies.

The new roles: artisan and architect

Human curated configurations and data sets can be configured with what's called retrieval augmented generation (RAG).

It's worth researching what RAG is for those new to the concept; at a high level it, allows you to manage the data an AI model uses to carry out its tasks and responses.

AI is terrible at innovating, but it's incredibly good at following human-curated templates leading to the prevalence of engineering becoming more of a process of "curating" pieces of code and organizing them into files for RAG.

Pieces of data broken up can be organized as "artifacts"; it's also worth researching more about artifacts and what they are if this is a new concept.

If a competent developer does manual work, then takes pieces of the code from their manual work to hand to an AI companion, the AI  even with hallucination is at the minimum as accurate as a human being who risks human error.

The difference is the AI doesn't burn out when tasked with brutally mundane tasks.

If one important engineering role is to curate different types of artifacts to hand to AI engines, then the other important engineering role is to maintain the agentic pipeline and the engine itself.

This means engineering effectively with AI requires two roles:

  • An artisan of artifacts who builds and curates small pieces of code to be used as RAG (usually based on tasks that were originally manual tasks)
  • An architect of the agentic engine (grows more capable as it learns from competent operators)

Those who are productive in the modern era are extremely productive, making the disparity between top performers and everyone else more extreme in technical spaces than seen historically.

Competence as the ultimate differentiator

This brings us back to competence. In the 21st century, competence is becoming a currency of its own due to the value that comes from AI amplifying whatever knowledge someone possesses.

With AI, more knowledge with applied experience means the benefits of learning are far more noticeable than ever before when it comes to tasks where AI is a clear game changer.

That being said, not all tasks benefit from AI.

The value of competence is someone with more experience also knows how to better gauge if a task might benefit from AI or if it might just be better to manually take it on.

Building technology that trains competence

So for our trainings at Cloud Underground, we decided to build a technology that doesn't require vendor training.

However, it does require competence meaning you must exercise:

  1. Critical thinking
  2. First principles thinking
  3. The endurance to finish what you start

A mentor of mine used to always say, "How you do anything is how you do everything."

If you are competent with AWS, you are competent with Azure.

The Cloud Jam Gauntlet

I created a gauntlet that is harder to complete than it is to use AWS or Azure, it also takes quite a large time commitment to complete.

If you start my gauntlet it's okay to not complete the journey, it's not going to be for everyone.

If you are the one to start the Cloud Jam Gauntlet and finish what you start you, will find that you will be incredibly competent with similar technologies that use servers.

Technologies you’ll gain competence with

Examples of technologies that use servers you will have increased competence with through completing the trials in the Gauntlet:

  • Cloud servers (AWS, Azure, GCP, etc.)
  • Containers (Docker, Kubernetes, etc.)
  • Virtual machines (VMWare, KVM, etc.)
  • Anything that is a binary system

If you can follow a technical guide, you can follow vendor documentation.

If you can come up with your own ideas, you can be the vendor who creates documentation for others to follow.

A new standard for learning through doing

Cloud Jam Gauntlet uses a special agnostic kernel that works with most operating systems (compatibility is expanding).

The challenges do not require you to have Underground Nexus experience or skills; however, it absolutely requires critical thinking skills, creativity and first principles thinking (the art of thinking for yourself).

It doesn't matter if you are an engineer, an artist, a journalist it doesn't matter what your background is.

Either you are competent or you aren't.

Just because you don't complete the Gauntlet it doesn't mean you aren't competent; this is an experience that isn't for everyone.

I dare you to try learning from the challenge.

Why we built the Super Root kernel

I'll be talking more about the architecture of my new technology soon; for this blog, I wanted to outline important context that drives decisions like why I made a Super Root sovereign kernel technology my team and I created together.

Check out the Cloud Jam Gauntlet to learn more about our technologies and put your technical innovation skills to the test.

Back to blog

Forge your path with Cloud Jam Gauntlet

The Cloud Jam Gauntlet is your guided initiation into sovereign systems. You will build your own cloud environment, test its resilience, and learn how to manage intelligent infrastructure with purpose and control.

Start Building Today