<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 |
02 December 2020

This article presents important tips to ensure that technical knowledge you share is understood by and has a value for your audience. In part 1, I explored the notion of the mental model and how it helps to better structure and convey the information you want to deliver, and why you should use more than one way to present your subject. In the following, I’ll discuss six more tips as well as common mistakes to avoid.

3. CLEARLY DEFINE YOUR PREREQUISITES

In part 1 of this article, I mentioned that you need to know what your audience knows, so you don’t skip relevant aspects and create learning gaps. Depending on how you deliver the subject, this can be more or less challenging. If you’re in a classroom and directly communicate with your audience, you can continuously get feedback. If you deliver a presentation, the audience has a chance to raise questions. However, if you write a book, you’re completely decoupled from your readers, and direct feedback is no valid option to ensure you describe your subject comprehensibly. Still, it’s always helpful to state as clearly as possible the prerequisites for what you’re teaching from the very beginning.

It has become a common mistake to not properly define the prerequisites and the target audience, though. This happens frequently nowadays, especially with presentations for conferences. I increasingly experience that conference review boards don’t ask for or even don’t allow you enough space to describe the audience you expect. Hence, the title and abstract can be misleading because they’re short pieces of information. The result is that you may either end up with attendees who don’t have the knowledge they need to follow and understand the discussion, thus leading to disappointment. Alternatively, there may be people in your audience who already know what you present, who will be disappointed because they expected to learn something new.

The key to avoiding this problem is to make sure you clearly mention what your presentation is about.

4. AVOID LEARNING GAPS

Starting with the right audience is important, but it’s just as essential to ensure a smooth learning path. When you start, you rely on the prerequisites. Continuing, you need to guarantee that everything you explain builds on information you’ve already provided to your audience.

8-tips-for-sharing-technical-knowledge-part

These figures are an example of a learning gap, which makes the learning process more difficult and sometimes impossible. Imagine that you want to learn how to draw an owl using only this short tutorial.

5. NEVER OVERESTIMATE YOUR AUDIENCE

I’ve often witnessed cases of people delivering knowledge and overestimating their audience, which is one of the most critical mistakes in knowledge sharing. People usually make this mistake for one of the following reasons:

  • They want to prove how much they know – While you’re presenting, the audience trusts you to know the subject. You don’t have to prove you know it. Instead, you should help others understand it, first covering the basics and then progressively detailing the more advanced parts. If you only give “complicated” details, your audience won’t consider you wiser. In fact, you’ll end up with the opposite and not very positive feedback.
  • They try to avoid the “Clearly define your prerequisites” issue discussed above – I’ve seen cases where people leave out details that seem more basic because they think the audience knows them already. While these details may seem natural for you, you should take into consideration that not everyone in your audience understands them. This is the reason why you established your prerequisites; if what you’re teaching is not part of the prerequisites, don’t skip it.


6. USE SPECIFIC EXAMPLES

Go from particular to general. Usually, it’ll be easier for us to understand concrete examples than general ideas. It’s the main reason why people who want to learn object-oriented programming might fail to understand it in the first place or find subjects like “abstract classes” or “interfaces” difficult. To ensure that your audience truly understands what you share, try starting with a particular example and then generalise its usage.

However, it might be a mistake to use large examples. When working with practical programming examples, I recommend that you create apps that need no more than one lesson to implement. I’ve seen courses trying to develop one app throughout multiple or even all the lessons. This approach has the following problems:

  • The audience will need to remember the status from one lesson to another.
  • If an attendee misses a lesson, they’ll find it challenging to understand what comes next.

On the other hand, using small examples can sometimes involve having to re-write things that you’ve discussed already. However, you can make this aspect valuable by using it as a refresher.


7. MAKE THE EXPERIENCE INTERACTIVE

Sometimes you have the opportunity to transform a monologue into a dialogue. For example, for a course or presentation you might consider asking your audience for their opinion or implementing group exercises. Here are a few ideas to keep your audience’s attention:

  • Ask questions to the whole group but be prepared to directly name someone if you don’t get answers at first.
  • Offer your audience simple ways to check their knowledge. You can use an interactive testing platform like Kahoot to make the evaluation more like a game.
  • Assuming you deliver a curriculum that has several sessions, allow someone from the audience to present a refresher of what you’ve done in the previous lessons of the course.
  • Sometimes, it’s a good idea to break up the audience into small groups and give them specific activities to practice applying a certain topic.


8. FEEDBACK IS IMPORTANT

Probably the best tool to learn how to improve is to listen to feedback. While it’s impossible to make everyone happy, asking for feedback can reveal common mistakes you made. When multiple people voice the same opinion, it might be something to consider changing about how you share knowledge.

CONCLUSION

John Nash, one of the greatest Nobel laureates in economics, proved that we achieve the highest value if we collaborate rather than individually tackle a subject. Sharing knowledge in the most understandable manner is one way we can collaborate to raise our value by growing together rather than apart.

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

  • 12 November 2020

    8 Tips for Sharing Technical Knowledge – Part 1

 

Archive

  • 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

OLDER POSTS