<img height="1" width="1" style="display:none;" alt="" src="https://px.ads.linkedin.com/collect/?pid=4958233&amp;fmt=gif">
RSS Feed

Leadership | Laurentiu Spilca |
12 November 2020

Helping others upskill has always been something I’ve considered essential. When you know something, you’ll make it ten times more valuable by sharing it with ten people! But sharing knowledge is not easy, especially concerning technical subjects. Do you want to help your community through sharing specific knowledge, but you don’t know where to start? Are you afraid that you won’t do a great job? Have you ever tried to convey a technical subject but failed? In this article, I’ll discuss some important tips you should consider when sharing knowledge and the most common mistakes you need to avoid.


The first thing I’d like to mention is the mental model. The lack of a mental model is one of the most common causes of failure in knowledge sharing. Helping your audience build their mental model consists of defining a clear path to learn the subject you deliver. A mental model is an explanation of someone’s thought process about how something works in the real world. Mental models help to shape behaviour and set an approach to solving problems and doing tasks. It doesn’t matter if you deliver a presentation, a workshop, or write a book or an article – you need to help your audience build their mental model. You can find a detailed description of mental models with additional reading resources here. But what precisely does it mean to create a path for those with whom you share knowledge?

When starting with knowledge sharing, you might be tempted to only tell your audience how that specific subject you describe works. However, you should always tell your audience a few things beyond that. The following aspects are part of the mental model:

  • Why should your audience care about what you deliver, and why should they learn it? Tell your audience why the specific subject is valuable and what they’ll be able to do after mastering it. In order to be motivated to learn something, one must first understand its value.
  • How will you deliver the knowledge? Tell your audience which steps you’ll follow to help them understand the topic. Are you going to tell them a story, discuss a visual, or will you be working on a code example? Your audience needs to know what to expect.
  • If you’ve already mentioned certain aspects that your audience should know, it’s good to remind them that these are a prerequisite, that you’ve discussed the subject before, and where they can find it.
  • If you refer to a subject you won’t detail later in your training or article, offer your audience other resources to learn more about that topic if they wish.

Let’s look at an example to illustrate this: Say you want to teach someone how to declare a variable in Java. First, we’ll consider the case without using a mental model, in which you might say something like this:

“To declare a variable in Java, you first need to know the type of value you’ll assign to the variable. Then you choose a syntactically valid name. The name of the variable follows its type, and the instruction concludes with a semicolon.”

While the above paragraph might look clear if you already know what a variable is and how to declare it, for a beginner, a lot of details are missing:

  • What is a variable? Maybe you’ve discussed it previously, but you should remind your audience about it and tell them where to find that information.
  • Why should your audience know how to declare the variable? What value is gained by spending their time learning this subject, and how will it be useful afterwards?
  • What does “syntactically valid” mean? Have you covered this subject already, or are you going to do so in the next lesson? You should be explicit about terms you’re using and where you’ve covered them.

Additionally, you need to consider the knowledge level of your audience. How much into detail should you go? You don’t want to bore them if they already have a clear idea of what you teach. If your audience knows the general subject, but you wish to introduce something more specific, be clear with your description and get straight to the point. However, assessing if your audience already understands certain topics is always tricky. Suppose you have a group of twenty people. Will they have equal knowledge and understanding of a topic? Most probably not, so you’ll have to find the proper equilibrium, ensuring that everybody learns what you deliver without those with more advanced knowledge getting bored.

Here is an example of how you could present the same topic using a mental model:

Next, we’ll examine how to declare a variable. As we’ve already discussed in the previous lesson, a variable is a place in memory where we store values that we’re going to use. You need to know what variables are and how to define them because in most cases you won’t be able to implement an algorithm if you don’t temporarily store part of the data you process. The easiest way to store this data is by using variables. The first step is to know what kind of value you’ll store in a variable. Say you want to store integer values like 10 or 15. Then your variable type will be ‘int’. You’ll choose the type from those we discussed earlier in this lesson. Then you’ll choose a name for your variable. The variable name needs to follow some syntax rules, which we’ll discuss later in this lesson. The name of the variable follows its type, and the instruction concludes with a semicolon.”

Certainly, the second approach of delivering the same information is longer. Adding the mental model can more than double the content, but it makes the difference between “some understand what you deliver” and “almost everyone understands what you deliver”. Let’s dissect the second approach and discuss why the additions are essential.


Observe that I started with making the audience aware of what comes next. Always refer to what you’re going to teach before actually teaching it.

As we’ve already discussed in the previous lesson

If you use a notion that you discussed before, refer to it again and remind the audience where they’ve learned it. For example:

  • “earlier in this lesson”
  • “in lesson 2”
  • “earlier in this presentation” 
  • “at the beginning of my presentation”
  • “in section 2.2 of this article”
  • “in chapter 2 of this book”

This way, your audience will remember the notion more easily, and you give them the opportunity to take note and review that subject later.

a variable is

Give a short definition to remind your audience about a notion you’ve already discussed.

You need to know what variables are

Give your audience a motivation and clarify the value of learning about that specific subject.

which we’ll discuss later in this lesson

Always let your audience know if you’ll further discuss a notion later. If you only discuss it briefly in your course or presentation, it’s a good practice to share other, more detailed resources on that topic like book titles and chapters as well as links to articles, video tutorials, or presentations.


People delivering knowledge often make the mistake of using only one way to describe a topic. You’ll find this issue in many articles around the web, be it on StackOverflow, Medium, Baeldung, or other well-known sources. The authors offer valuable information, but they cover their subject too quickly and use only one way to present the subject. For many people, especially those with less experience in the field, this approach can impede understanding.

Because people differ in how they absorb information, you should use two or three different ways to ensure comprehension. Some of us learn best when reading or listening to a description of a technical topic, some benefit from a visual presentation, and still others prefer to get an analogy. Here are different ways to present a topic:

  • Written or spoken description – Describe in words the topic the way you understand it.
  • Written or spoken analogy – Give an analogy of the topic, for example, by comparing it with a subject from a non-technical domain. In some cases, you could also tell a joke.
  • Visual representation – Draw a diagram or show a graphic to help your audience understand the subject.
  • Visual analogy – Use a cartoon, picture, or meme and compare it to the technical topic you’re teaching.
  • Examples and exceptions – Tell your audience when it is beneficial to use the approach, technique, or technology you describe, and also tell them when they shouldn’t use it.
  • Story from your own or others’ experience – Stories are great, and you can use them to illustrate the impact of a specific topic. In most cases, we use stories to show the importance of the subject we teach.
  • Source code – Where applicable, you can demonstrate a technical subject by discussing a source code example directly.

In part 2, I will present six more tips for sharing technical knowledge, including the value of examples and feedback as well as the pitfalls of overestimating your audience and how to avoid learning gaps.

Laurentiu Spilca

Development Consultant

Laurentiu is a dedicated development lead and trainer who leads and consults on multiple projects from various locations in Europe. With 10+ years of experience, he believes it’s essential to deliver high-quality software and to share knowledge and help others to upskill. This belief has driven him to design and teach courses on Java technologies. When he isn’t teaching or writing – his new book is Spring Security in Action – Laurentiu enjoys riding his motorbike, playing the guitar and the piano, and exploring new destinations.


From This Author

  • 02 December 2020

    8 Tips for Sharing Technical Knowledge – Part 2



  • 13 November 2023

    Delving Deeper Into Generative AI: Unlocking Benefits and Opportunities

  • 07 November 2023

    Retrieval Augmented Generation: Combining LLMs, Task-chaining and Vector Databases

  • 19 September 2023

    The Rise of Vector Databases

  • 27 July 2023

    Large Language Models Automating the Enterprise – Part 2

  • 20 July 2023

    Large Language Models Automating the Enterprise – Part 1

  • 11 July 2023

    Boost Your Game’s Success with Tools – Part 2

  • 04 July 2023

    Boost Your Game’s Success with Tools – Part 1

  • 01 June 2023

    Challenges for Adopting AI Systems in Software Development

  • 07 March 2023

    Will AI Transform Even The Most Creative Professions?

  • 14 February 2023

    Generative AI: Technology of Tomorrow, Today

  • 25 January 2023

    The Joy and Challenge of being a Video Game Tester

  • 14 November 2022

    Can Software Really Be Green

  • 26 July 2022

    Is Data Mesh Going to Replace Centralised Repositories?

  • 09 June 2022

    A Spatial Analysis of the Covid-19 Infection and Its Determinants

  • 17 May 2022

    An R&D Project on AI in 3D Asset Creation for Games

  • 07 February 2022

    Using Two Cloud Vendors Side by Side – a Survey of Cost and Effort

  • 25 January 2022

    Scalable Microservices Architecture with .NET Made Easy – a Tutorial

  • 04 January 2022

    Create Production-Ready, Automated Deliverables Using a Build Pipeline for Games – Part 2

  • 23 November 2021

    How User Experience Design is Increasing ROI

  • 16 November 2021

    Create Production-Ready, Automated Deliverables Using a Build Pipeline for Games – Part 1

  • 19 October 2021

    A Basic Setup for Mass-Testing a Multiplayer Online Board Game

  • 24 August 2021

    EHR to HL7 FHIR Integration: The Software Developer’s Guide – Part 3

  • 20 July 2021

    EHR to HL7 FHIR Integration: The Software Developer’s Guide – Part 2

  • 29 June 2021

    EHR to HL7 FHIR Integration: The Software Developer’s Guide – Part 1

  • 08 June 2021

    Elasticsearch and Apache Lucene: Fundamentals Behind the Relevance Score

  • 27 May 2021

    Endava at NASA’s 2020 Space Apps Challenge

  • 27 January 2021

    Following the Patterns – The Rise of Neo4j and Graph Databases

  • 12 January 2021

    Data is Everything

  • 05 January 2021

    Distributed Agile – Closing the Gap Between the Product Owner and the Team – Part 3

  • 02 December 2020

    8 Tips for Sharing Technical Knowledge – Part 2

  • 12 November 2020

    8 Tips for Sharing Technical Knowledge – Part 1

  • 30 October 2020

    API Management

  • 22 September 2020

    Distributed Agile – Closing the Gap Between the Product Owner and the Team – Part 2

  • 25 August 2020

    Cloud Maturity Level: IaaS vs PaaS and SaaS – Part 2

  • 18 August 2020

    Cloud Maturity Level: IaaS vs PaaS and SaaS – Part 1

  • 08 July 2020

    A Virtual Hackathon Together with Microsoft

  • 30 June 2020

    Distributed safe PI planning

  • 09 June 2020

    The Twisted Concept of Securing Kubernetes Clusters – Part 2

  • 15 May 2020

    Performance and security testing shifting left

  • 30 April 2020

    AR & ML deployment in the wild – a story about friendly animals

  • 16 April 2020

    Cucumber: Automation Framework or Collaboration Tool?

  • 25 February 2020

    Challenges in creating relevant test data without using personally identifiable information

  • 04 January 2020

    Service Meshes – from Kubernetes service management to universal compute fabric

  • 10 December 2019

    AWS Serverless with Terraform – Best Practices

  • 05 November 2019

    The Twisted Concept of Securing Kubernetes Clusters

  • 01 October 2019

    Cognitive Computing Using Cloud-Based Resources II

  • 17 September 2019

    Cognitive Computing Using Cloud-Based Resources

  • 03 September 2019

    Creating A Visual Culture

  • 20 August 2019

    Extracting Data from Images in Presentations

  • 06 August 2019

    Evaluating the current testing trends

  • 23 July 2019

    11 Things I wish I knew before working with Terraform – part 2

  • 12 July 2019

    The Rising Cost of Poor Software Security

  • 09 July 2019

    Developing your Product Owner mindset

  • 25 June 2019

    11 Things I wish I knew before working with Terraform – part 1

  • 30 May 2019

    Microservices and Serverless Computing

  • 14 May 2019

    Edge Services

  • 30 April 2019

    Kubernetes Design Principles Part 1

  • 09 April 2019

    Keeping Up With The Norm In An Era Of Software Defined Everything

  • 25 February 2019

    Infrastructure as Code with Terraform

  • 11 February 2019

    Distributed Agile – Closing the Gap Between the Product Owner and the Team

  • 28 January 2019

    Internet Scale Architecture