Skip directly to search

Skip directly to content

 

8 Tips for Sharing Technical Knowledge – Part 2

 
 

Software Engineering | 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.

Figure 1

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.

 

Related Articles

  • 27 January 2021

    Following the Patterns – The Rise of Neo4j and Graph Databases

  • 02 December 2020

    8 Tips for Sharing Technical Knowledge – Part 2

  • 12 November 2020

    8 Tips for Sharing Technical Knowledge – Part 1

  • 08 July 2020

    A Virtual Hackathon Together with Microsoft

  • 30 June 2020

    Distributed SAFe PI Planning

 

From This Author

  • 12 November 2020

    8 Tips for Sharing Technical Knowledge – Part 1

Most Popular Articles

Following the Patterns – The Rise of Neo4j and Graph Databases
 

Insights Through Data | Calin Constantinov | 27 January 2021

Following the Patterns – The Rise of Neo4j and Graph Databases

Data is Everything
 

Insights Through Data | Adina Gabriela Stavar | 12 January 2021

Data is Everything

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

Agile | Thomas Behrens | 05 January 2021

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

8 Tips for Sharing Technical Knowledge – Part 2
 

Software Engineering | Laurentiu Spilca | 02 December 2020

8 Tips for Sharing Technical Knowledge – Part 2

8 Tips for Sharing Technical Knowledge – Part 1
 

Software Engineering | Laurentiu Spilca | 12 November 2020

8 Tips for Sharing Technical Knowledge – Part 1

API Management
 

Architecture | Gareth Badenhorst | 30 October 2020

API Management

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

Agile | Thomas Behrens | 22 September 2020

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

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

Architecture | Radu Vunvulea | 25 August 2020

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

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

Architecture | Radu Vunvulea | 18 August 2020

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

 

Archive

  • 27 January 2021

    Following the Patterns – The Rise of Neo4j and Graph Databases

  • 12 January 2021

    Data is Everything

  • 05 January 2021

    Closing-the-gap-between-the-product-owner-and-the-team-part-3

We are listening

How would you rate your experience with Endava so far?

We would appreciate talking to you about your feedback. Could you share with us your contact details?