Blog >

Sorting the real from the imaginary in tech skill development

Issac Strack

Until recently, I wasn’t too familiar with the classic Hans Christian Andersen tale, The Emperor’s New Clothes. I’d always dismissed it (or rather, the people in the story) as kind of absurd. I didn’t realize until I actually read it that the first person to pretend had a very logical reason for doing so, and once he made that choice, the rest of the plot fell into place like a set of dominoes.

See, there were two con artists who cleverly created the ruse by stating that the emperor’s clothes were made out of material so delicate and refined that if you couldn’t see it, you were either not qualified for your position, or you were a simpleton. So, person after person, not wanting to admit what they couldn’t see or be called a fool, lied until people started to believe that something imaginary was real.

Building skills in your organization is just like The Emperor’s New Clothes. There is a difference—and not a small one—between those with real skill development practices, and those with imaginary skill development who pretend their strategy will lead to real results.

I’ve spent the last three years creating skills strategy plans for companies of all sizes, and I’ve observed distinct differences between organizations that make real progress and those that struggle.

You’ll identify with some of the real practices, and also probably identify with a few of the imaginary ones, which are areas where you and your teams can improve. That’s normal and to be expected.

As you consider these scenarios, take inventory of where you are by grading yourself and your org on each topic. As you take inventory, you’ll see the exact areas where you need to focus, and you’ll be better able to implement initiatives that will move your skills strategy from “imaginary” to “real.”

Lifelong learning

Imaginary = “ I know what is required to do this job effectively and that’s enough.” versus Real = “ There is no ‘good enough’ when it comes to skill development. If employees stop learning, we stop innovating.”

For the above, please remember: A culture of learning is about the overall belief that there is no “good enough” when it comes to skill development. Paul Eldridge at Salesforce has created one of the most comprehensive and thorough cloud skill development strategies I have ever seen. Guess what he’s busy revising at this very moment? Guess what he’ll revise again next month and the month after that? The company’s cloud skills strategy. Technology doesn’t sleep, and neither can your strategy. It’s easier to stay on top of a subject than it is to try and catch up.

Intensity and regularity

The difference is in the intensity and regularity. Do you learn something new every day? Do you or your team watch courses on your commute or during lunch breaks? Your competitors do. I know, because I work with them. And not only that, but they’ve also made learning new skills a habit. We all have priority lists and the list of critical things is short. Companies with truly great cultures put time to learn new skills on the short list. What does that look like? It could include tying manager compensation to “20% time,” or extending timelines on projects to allocate time for learning. A company could also regularly sponsor hackathons, learning lunches or internal conferences.

When it comes to prioritizing skill development, you have to mean it. If leadership takes it seriously, so will your teams.

Imaginary = “Learning programs are a good perk, like rewards and recognition, free lunches or ping pong tables.” versus Real = “Skill development is critical to our daily success and is as important as production time, flow time and team collaboration.”

Flow of learning

There’s a lot to unpack in this one.

Protecting formal skill development time is critical to success.

An organization committed to skill development also recognizes that not all learning happens in such a formal manner. Learning happens in real time when one colleague helps another, or when a developer performs a Google search. On-demand, tribal knowledge, guilds, pair programming—there are a large number of modalities and “quick wins” when it comes to learning, and orgs that recognize and cultivate learning flow stand the highest chance of success.

Imaginary = “We are too busy to prioritize learning time when it comes to other responsibilities.”” versus Real = “Skill development is part of our culture, encouraged by leaders and doesn’t just come from courses or a classroom.”


It’s difficult to accurately measure skill progression. But whether you intend it to or not, the things you measure send a clear message about the things you value. Over the years, I’ve observed that in organizations where it’s all about completion—checking that box at the end of a course—employees aren’t truly invested in developing themselves. This is ineffective. Mature organizations measure skill progress by using assessments and analytics that show growth by an individual over time.

Imaginary = “The best way to measure learning progress is to find out how much time is spent consuming content.” versus Real = “The best way to measure skill progress is to find out if the right skills are being acquired.”

Skills autonomy

Imaginary = “Frameworks are the answer! We need to tell everyone what to learn and how to learn it.” versus Real = “People know what skills they need to develop better than we do. We give them directional guidance and then get out of the way.”

Focusing on time spent learning drives activity; focusing on skill development drives outcomes.

You can’t document a forest fire; it grows and shifts too rapidly.

Sounds obvious, doesn’t it? But how would you describe the impossible pace of technology releases and the ever-growing skills gap that results?

And how do you approach this skills gap?

In an effort to identify skills gaps, some companies try to document every skill, at every role, at every level. They create “skills frameworks” and other documents that are outdated the moment they’re published. On top of that, even though they aren’t trying to, they wind up telling employees with 10 years of expertise in their craft what skills they should be acquiring.

Great companies see technology for the forest fire that it is, and empower their teams to solve this problem. And this is the fundamental principle of Agile: They trade control for results.

This too may sound obvious, but removing the traditional “top-down” control model and replacing it with trust and empowerment is easier said than done. In my experience, companies that do this successfully involve their people in the decision-making, rather than inform them about a skill development framework built by L&D.

Reduced complexity

The key to creating a manageable skills architecture is to make skills modular.

Using org structure to organize skills makes them rigid and complex, because it assigns a skill (Python, for example) to a single role (see table 1.0). But skills don’t belong to roles. They are definitely associated with roles—often many different roles. Organizing skills by org structure creates duplication, overlap and an overly complex hierarchy.

Imaginary = “We map skills and content by role and role level.” versus Real = “We align skills to objectives.”
 table 1.0 :  Organizing skills by org structure creates duplication, overlap and an overly complex hierarchy

The best skills architectures start by aligning skills to objectives via a skills matrix (see table 2.0). No rocket science required! Simply lay your functional areas (roles, teams, areas of responsibility) across the top, lay your major skills areas down the side, and presto: You’ve got a skills matrix.

 table 2.0 :  The best skills architectures start by aligning skills to objectives via a skills matrix.

The visualization seems simple, but it’s important because it allows you to assign skills in a modular way, making it easy to apply them to roles afterward. For example, Python spans multiple functional areas (data, scripting, web development, etc.). The skills matrix captures that, so you only have to build one content track for Python, usable by multiple areas.

The tipping point

Healthy skill development is contagious. And within your organization, 15–20% of your people are early adopters. Great companies know this and strategize to “infect” those adopters with a fantastic and healthy skill development experience. They know that if they do, the rest of the workforce will see it, develop a bit of FOMO, and in no time, your entire org will be looking for skill development opportunities.

Still, 20–30% of your employees will likely account for 80% of your skill development.

Imaginary = “I try to build something that covers everything and everyone.” versus Real = “I understand the principle of the 15% tipping point, when ‘the moment of critical mass, the threshold, the boiling point’ happens (Malcolm Gladwell) and design for early adopters.”

This is a law of nature. Having a “use it or lose it” policy when it comes to learning resources will only hurt your culture in the long run. Activity will decrease and the psychological safety of your entire org will take a hit.

Conversely, companies that allocate learning resources to everyone regardless of usage create a culture of abundance, where innovation can come from anywhere and small bets pay off.

Separation of goals

Successful performance management, career ladders and role levels have specific characteristics:

  •  They must be generic
  •  They must be objective
  •  They can’t change frequently

Successful skill development models also have specific characteristics:

  • They must be specific
  • They must be flexible
  • They have to change frequently

Building an architecture that tries to meet the requirements of both defies logic. Great companies recognize this and separate these initiatives. There is definitely still a relationship (and an important one) but treating them separately via process and architecture is critical to long-term success.

Imaginary =  versus Real =


Developing a real, effective skills strategy and a healthy learning culture is hard.

But getting to something real is worth the effort. The above-mentioned patterns and practices can serve as a starting point to the larger conversations (and work!) that need to happen. I encourage you to take these patterns, add your own and close those skills gaps.

Developers working at computers

Isaac Strack is an author, speaker, technologist and STEM education advocate. He is currently the Head of Professional Services in EMEA, working closely with customers of all sizes to fully leverage the Pluralsight platform in developing and implementing their skill strategies.

Isaac is active in STEM/STEAM activities, regularly contributes to Pluralsight One initiatives, and has made it his personal mission to improve lives through democratizing technology skills.