Technical learning

The ability to actively engage with and master new technologies, tools, and technical knowledge to remain effective, adaptable, and forward-thinking. Technical learning requires curiosity, openness to experimentation, resilience in the face of complexity, and a proactive approach to continuous development.

“Education is the passport to the future, for tomorrow belongs to those who prepare for it today.” Malcolm X

Why technical learning matters

Technical learning matters because the tools and platforms a leader’s team depends on keep changing whether or not the leader keeps pace with them, and a leader who falls behind doesn’t just lose personal capability, they lose the ability to make good judgment calls about the technology decisions in front of them. A leader who has never actually used the systems their team relies on is negotiating from a position of theory rather than experience, and that gap is usually visible to the team long before the leader notices it themselves.

Without ongoing technical learning, a leader’s authority on technical matters steadily narrows to whatever they learned early in their career, even as the actual work moves well past it, and delegating the gap away doesn’t fully close it, since some decisions still require enough first-hand understanding to ask the right questions. Leaders who keep learning stay credible not because they know more than their specialists, but because they know enough to tell good technical judgment from confident-sounding technical judgment.

“The illiterate of the 21st century will not be those who cannot read and write, but those who cannot learn, unlearn, and relearn.” Alvin Toffler

What good and bad technical learning looks like

What bad looks like	What good looks like
Treats technical learning as something to schedule only once a specific tool is urgently needed.	Treats technical learning as an ongoing baseline practice, so a foundation already exists by the time a tool becomes urgent.
Judges their own technical competence by how confidently they can talk about a tool.	Judges their own competence by whether they can actually operate the tool unassisted, since explaining and doing aren’t the same fluency.
Avoids trying a new tool in front of others, for fear of looking incompetent while still learning.	Learns visibly in front of the team, modelling that competence is built openly, not expected to already be there.
Relies entirely on the team’s technical experts to translate new tools, without building any independent understanding.	Builds enough independent understanding to ask sharp questions and sanity-check what the experts say, without needing full expertise.
Treats every new technology with equal urgency, chasing whatever is newest regardless of relevance.	Filters which emerging technologies are genuinely relevant to their context before investing serious time in them.
Delegates technology decisions entirely to specialists, without understanding enough to weigh the trade-offs personally.	Understands enough of the underlying trade-offs to participate meaningfully in the decision, while still relying on specialists for depth.
Treats a failed attempt to learn a new tool as evidence they’re “not technical.”	Treats a failed attempt as expected friction, and adjusts their approach rather than drawing conclusions about their own aptitude.
Learns a tool once and assumes that knowledge stays current indefinitely.	Periodically checks whether their technical knowledge has aged, since tools and best practices keep evolving after the initial learning is done.

“The best way to predict the future is to invent it.” Alan Kay

Barriers to technical learning

Over-reliance on outdated knowledge: Expertise built years ago can feel just as solid today as it did when it was current, even after the tools and best practices underneath it have moved on. What actually signals the erosion isn’t a single dramatic failure, but solutions that used to work simply taking longer, or landing less well, than they once did.

Lack of exposure: Without regular hands-on contact with newer tools, a leader’s mental picture of what’s possible stays anchored to whatever was current the last time they looked closely. That gap widens without any single alarming moment marking it, since nothing about a busy schedule announces that the picture in your head is now several product cycles behind.

Inexperience: Without a base layer of technical vocabulary and concepts to build on, every new tool has to be understood from first principles rather than by analogy to something already familiar. This makes the learning curve genuinely steeper for some leaders than others, not because they’re less capable, but because they’re starting further back.

Lack of interest in technology: When technical detail simply doesn’t hold a leader’s interest, the learning that does happen tends to stay surface-level, enough to get by, not enough to build real fluency. The disinterest is rarely stated outright, it just shows up as technical development perpetually losing out to more engaging priorities.

Fear of technology: For some leaders, an unfamiliar interface triggers a genuine, if low-grade, anxiety about looking incompetent or breaking something, and that discomfort is enough to shut down exploration before it starts. The irony is that avoiding the tool to protect a sense of competence is exactly what prevents the competence from ever developing.

Resistance to change: Tools a leader has used for years accumulate a kind of comfort that has little to do with how well they still perform, and giving them up can feel like a loss even when the replacement is objectively better. Few leaders would admit to simple sentiment here, so the attachment tends to get defended as a practical preference instead.

Time management challenges: Technical learning rarely has a hard deadline attached to it, which makes it the easiest thing to postpone whenever something more urgent competes for the same hour. The cost of that postponement is invisible in the short term and only becomes obvious once a real gap in capability is exposed under pressure.

Intimidation by complexity: A genuinely complex new system can look, from the outside, like a single impossibly steep climb, when it’s actually a series of much smaller steps that only look continuous from a distance. Avoidance sets in not because the material is unlearnable, but because it was never broken down into a version small enough to start.

Delayed adoption: Waiting until a tool has become the obvious, safe, default choice feels like prudence, but it also means arriving at the same capability everyone else already has, exactly when it stops being an advantage. The early period when a tool is still unproven is precisely when learning it fastest actually pays off most.

Inability to leverage others: Asking a more technical team member for help can feel like an admission that undermines a leader’s authority, even though the opposite is usually true. The leaders who ask directly and often tend to build both their own skill and their team’s respect faster than those who try to work it out alone rather than ask.

“For the things we have to learn before we can do them, we learn by doing them.” Aristotle

Enablers of technical learning

Find a mentor or tutor: Seek out someone highly skilled in the technical area you’re exploring. Most experts enjoy sharing their knowledge and can provide informal guidance or structured tutoring.

Engage a specialist: Consider hiring an external consultant for one-on-one sessions. This tailored approach helps you focus on key areas and addresses specific challenges quickly.

Adopt an expert’s mindset: Observe how tech experts approach problems. Focus on recognising patterns, categorising information, and asking the right questions.

Join professional associations: Connect with like-minded professionals through workshops, conferences, and online communities built specifically around your technical area. These groups often surface a shift in the field weeks or months before it shows up in mainstream coverage, simply because the people closest to the change are the ones talking about it first.

Read foundational texts: Identify definitive books or journals in your area of interest. Subscribing to reputable industry publications keeps you informed on emerging trends.

Take a formal course: Structured learning through online platforms or universities provides a clearer path than self-directed study alone, along with hands-on practice and access to instructors who’ve already anticipated where learners typically get stuck. The structure matters less for the credential than for simply removing the burden of deciding what to learn next.

Experiment and explore: Dive into new technologies as they emerge. Be the first to test them, allowing yourself to make mistakes as a core part of the learning process.

Build technology into daily life: Integrate new tools and platforms into your everyday routine, and set aside unstructured time to explore outside your immediate field. Broad, low-stakes exposure builds comfort and occasionally surfaces connections a narrower, purely job-focused search would miss.

Teach what you learn: Organise a study group or workshop. Teaching others forces you to understand the subject deeply while fostering a culture of shared growth.

Seek structured feedback on your work: Once you’ve applied a new tool or technique, ask someone more experienced to review what you actually produced, not just how you felt about learning it. Real feedback on the output tells you whether you’ve genuinely built the skill or just built confidence.

“If you are not willing to learn, no one can help you. If you are determined to learn, no one can stop you.” Zig Ziglar

Reflection questions for technical learning

How comfortable are you asking for guidance from a technical expert within your own team? What’s stopping you if the honest answer is “not very”? Who on your team would you least expect to ask, and what would happen if you did?

How can you balance your day-to-day workload with the time required for formal technical development? What’s currently getting priority over this that, honestly, shouldn’t be? If technical learning had to happen this week, what would you actually cut to make room for it?

What specific industry journals or digital resources could you follow to ensure your knowledge doesn’t become stagnant? When did you last actually read one, rather than just subscribe to it? How would you notice if your understanding of your field had gone out of date without any clear signal telling you so?

When was the last time you experimented with a tool that made you feel like a genuine beginner? How did that discomfort compare to what you expected going in? What would it take to seek that feeling out more deliberately, rather than avoiding it?

Which everyday tasks could be improved or automated if you adopted a new piece of software or hardware? What’s stopped you from making that change so far, time, unfamiliarity, or something else? Who on your team has probably already solved this and never mentioned it?

What technical challenges are you currently facing that could be resolved faster with outside expertise? What’s held you back from bringing someone in, cost, pride, or simply not having considered it? What would you need to see to justify that investment?

How are you using your personal technology habits to support your professional technical fluency? Is there a tool you already use comfortably at home that you’ve never tried applying at work? Where does the line between “personal” and “professional” technology actually help or limit you?

Could you lead a session teaching a new tool to reinforce your own understanding of it? What topic would expose the biggest gap between what you think you know and what you could actually explain? What’s stopped you from offering to teach this already?

How can you break down a complex technical problem into smaller, less intimidating parts? What’s the smallest possible version of the problem you could tackle first? Where has breaking something down this way worked for you before?

Do you allow yourself guilt-free time to explore emerging technologies that aren’t yet part of your official role? What would you explore first if no one was going to ask what it was for? What’s the cost of never giving yourself that time at all?

“One learns from books and example only that certain things can be done. Actual learning requires that you do those things.” Frank Herbert

Micro practices for technical learning

1. Use the new tool for something trivial first: Before applying a new tool to something that matters, use it once on a low-stakes task purely to get the feel of it. The goal isn’t output, it’s removing the unfamiliarity before the stakes are real.

2. Ask the newest person on your team to show you something: Find one thing a more junior or more technical colleague does with a tool that you don’t know how to do, and ask them to walk you through it directly. This does more for both your skill and your relationship with them than a formal course often does.

3. Timebox exploration weekly: Put a recurring, protected hour in your calendar for pure technical exploration, with no deliverable attached. Treating it as a real appointment rather than a “someday” intention is usually the only thing that makes it actually happen.

4. Rebuild something you already use: Pick a tool or process you already rely on and try to understand, or even briefly rebuild, a simplified version of how it actually works underneath. Understanding the mechanism behind a familiar tool often transfers to picking up an unfamiliar one faster.

5. Say “I don’t know how to do that yet” out loud: In the next meeting where a technical topic comes up, practise naming the specific gap plainly instead of nodding along. It opens the door for someone to actually teach you, which silent nodding never does.

6. Review your output, not just your learning: After applying something newly learned, have someone more experienced check the actual result, not just ask how the learning process felt. What you produced is a more honest measure of what you’ve actually built than how confident you feel afterward.

“An investment in knowledge pays the best interest.” Benjamin Franklin

Explore related leadership resources

To further develop this capability, examine how it intersects with other core leadership dimensions across the libraries:

Leadership library:

• Experimenting: Take a hands-on approach to new tools, using structured trials to understand their potential and limitations within your workflow.
• Questions (Asking good): Sharpen your technical discovery by asking the right “how” and “why” questions to bridge the gap between high-level concepts and practical application.
• Feedback Responding: Use data and peer input to iterate on your technical processes, ensuring you are applying new knowledge effectively and accurately.
• Perseverance: Maintain the steady focus required to push through the “steep” part of the learning curve when mastering complex new systems or software.

Supporting libraries

• Conscious unlearning (Agility): Proactively let go of outdated technical habits or legacy methodologies to make mental space for more efficient, modern solutions.
• Curiosity drive (Agility): Fuel your technical growth by staying intrinsically motivated to explore emerging trends and the “next big thing” in your industry.
• Intellectual humility (Agility): Openly acknowledge what you don’t yet know, creating a receptive state of mind that accelerates the acquisition of new technical expertise.

Continue exploring: Return to the Leadership Library to view the full directory of competencies and resources.