Office Hours

Reflecting back on the various roles I have had in a Data Science team, it has occurred to me that I am one of the few people who is often asked to present.
From a whole host of meeting invites, to slides in various Teams channels and countless versions of presentations on my laptop, I realised that I had presented more than 120 versions of 18 projects over the last six years – that’s roughly one presentation every three weeks! Through this, I can safely say that I have sat through and given presentations that did not land well with various audiences.
One would argue that this many Presentations were unnecessary for technically apt stakeholders in a data literate organisation, but these individuals are few and far between where I work.

Many of my presentations have been time-consuming and cumbersome to prepare, but they have been invaluable in my attempt to become a better Data Science communicator. Regardless, I am thankful of my introspective moments which have led to confidence in my content and communication skills.
To date, being a keynote speaker and attending a panel at Financial Times Energy Summit on ML in the energy industry has been a highlight. Whilst I have so much more to learn, I now know that I can drive an engaging conversation with those who are listening.
So, here are six points that I think are valuable and some resources I have used when considering presenting my projects.
1. Create a narrative
Regardless of the project you are presenting, whether it is explorative, a production ready solution or research, a narrative is necessary to coherently articulate the progress made. Whilst there are many approaches to this, there are two crucial components which are a must.
Context
Most of the time, our projects won’t make sense when they land in front of us. We have to painstakingly construct models, insights and outcomes from mediocre data. To make sense we dissect and explore parts of data over and over to find meaning within the bigger picture. Essentially, we become scientists.
Fortunately for our audience, we are in a position to frame our data within a bigger picture and to become the story-teller. We can include history, similar trends and approaches others may have taken. We can use visualisations from our explorative stages to describe potential challenges, silver linings and our inspirations.
Whether you present to very specific teams or bigger, diverse groups, a tailored presentation with more relevant facts and background is beneficial. I tend to structure my slides following a fairly high-level narrative and draw attention to the detailed slides when necessary. Doing this allows the audience to remain focused on the challenge and the solution, whilst I help them appreciate the progress I have made.
Timeline
It is important to stick to a clear and organised timeline (preferably linear) – Data Science stories shouldn’t feel like a Christopher Nolan film.
I have often seen presentations start instantly with an outcome and solution. Whilst these are impactful, they also lead to a lot of "what does that mean?" moments, which can potentially alienate your audience.
A strong start is essentially your background and the context you provide. A valuable middle section would include a concise explanation of your method, findings, insights and necessary information to help the audience understand what was done. At the end, you should wrap up with model outcomes, potential improvements, use and challenges with data, strategies to production and wider impact if the project was to continue.
If you are able to, make room for questions. This gives the audience the opportunity to ‘dive deeper’ into the content and anything they have become particularly interested with.
2. Don’t make the audience listen and read.
Put yourself in the shoes of a stakeholder sitting through a ML slide deck, trying to listen to an expert, read their blurb on the slide and understand the value their work has on a business domain. This is a lot to juggle.

Instead, limit the amount of text to few bullet points and statements per slide to avoid cramming text. There are number of steps you can take to make concise and clear points, articulated well by Guy Kawasaki – 10/20/30 rule which provides an excellent template for pitching. Though it doesn’t translate directly for ML presentations, much of it is applicable.
3. Visualisations are important. If you are making charts, use the right visual tools.
This is probably the most important point for me, however, it is also the hardest to achieve. These principles may be easy to discuss but are much harder to execute, consistently.
TL;DR on visualuations –
- Charts with rulers help us interpret them more accurately and reduce our perceptive bias.
- Don’t use charts of they are not getting the point across easily.
- Pick or make a consistent colour palette for presentations by adjusting contrast and brightness to highlight what is important without removing what is not.
Visualisations are not just for aesthetics. In fact, they serve a higher purpose in helping our brains process pattern recognition more easily, as they point a magnifying glass on what is already there within the context of the larger data set.

In 1869, French civil engineer Charles Minard visualised the movement of Napoleon’s Russian campaign in 1812. Whilst it is difficult to construct such charts even now, it is a stunningly simple chart that articulates six variables in one 2D plot! (temperature, troop count, travelled distance, direction of travel, lat/long and location relative to specific dates). It literally tells the sad story of conquest through data.
Organise your insights to not just show data, but also to read easily. Two basic yet reoccurring themes I’ve spotted in presentations are: a lack of comparative measures and the right use of colour.
Rulers and scales
I feel that some background is necessary to explain why our visual prowess often fails.
Human brains are tuned to spot differences in similar things, but only if they are noticeably different from another. We easily misinterpret or underestimate certain data points in large charts (bar or line) if there are no common ways to spot differences across multiple items.
This is probably a trivial explanation, but the relationship between actual difference vs perceived or subjective difference is stated in Webber’s Law.
In addition, Steven’s Power Law worsens this variance to our perceptive bias as each person has a unique scaling system, one that is non-linear across length, area and volume.

For example, when any two people estimate the difference between two bars in a bar graph (i.e. the ratio), they would come up with different estimates. Whilst this might be incredibly small in most circumstances, comparing multiple bars in unstructured graphs results in a compounded effect. This holds true for length, area, volume, brightness, sound intensity (loudness) and weight.
To fix this, we can use periodic rulers (or a common edge as rulers), as they provide the best comparative tool in charts. This is invaluable in establishing a baseline to compare two or more items.
Whilst this fix seems very trivial, it is something we often forget to consider. These errors are most prominent in stacked and area charts as it is much harder to use rulers. Therefore, I avoid using these and stick to simpler charts.

Contrast
Use of colour, specifically the difference in contrast, is critical in drawing attention. We usually include colour to differentiate between multiple variables, using a variation of sequential, diverging and qualitative colour palettes that are used in charts produced by Python and R.
It is important to question what is relevant to show, one variable vs all or multiple variables. The former is easier to interpret, requires little variation of colour therefore can make impactful distinctions with just two contrasts. The latter is ideal in articulating variation and complexity in variables, describing faceted problems and insights. The less variables the better. If you really want to go the extra mile, group them by importance and relevancy to the audience.
There’s a detailed post on the science of how we recognise patterns and interpret them – I highly recommend it!
4. Make it your own, be passionate.
The majority of our projects could eventually drain the enthusiasm out of us. No matter how much time we spend data cleansing and passionately optimising, ultimately all stakeholders care about the purpose and outcome of our code. It is not interesting in the grand scheme of things, at least for the non-technical audience who can fund further work.

I had to remind myself to focus on what is relevant, what made the frustrating challenges interesting to solve and what interesting things I had learnt along the way.
I incorporated different graphs to increase engagement during presentations, included long term goals of production models, strategised ways to gain additional benefits with other projects and even spent time finding well organised templates with animations.
At worst, your enthusiasm and genuine interest will get your stakeholders and audience excited for you, you learn something interesting from the experience and move on. At best, they will support you, spread your word and rally the right people to take the right decisions with you.
5. Interact with your audience.
Interaction at a start of a presentation can ground your audience and focus them on what you want to draw their attention to. This hold particularly true if they have had to sit through multiple presentations before you are up! An interesting fact about the project, an intriguing statistic, a "show of hands…" question are great ways of interacting with your audience.
In general, you can also use this opportunity to understand the level of prior knowledge they have and the level of complexity they are comfortable with.
Of course, they could lie or be disengaged, but by interacting with them, the audience has a chance to build trust and break any awkward barriers when it comes to asking the presenter questions.
6. Help the audience understand the success criteria and model evaluations.
If someone is new to our world, then measuring progress with terms like accuracy, precision/recall and AUC might make things more confusing.
Be very specific about how you are evaluating the performance of a model. Make time to recap or provide the audience cliff notes on how to interpret the results. If it is AUC, explain why you would use this method, the results and what it means for the project. Always link back to the bigger picture and the value it offers.
If the results aren’t promising, or you believe that more effort is necessary to improve, be transparent and justify a potential approach. Same applies if it is a dead-end and you’ve exhausted all paths.

We don’t always get time to build great presentations. It is difficult to find time to really work on your slides, to create a narrative and make great visualisations in between engineering tasks. The effort is worth it!
Simple and compelling Storytelling helped few product owners and regulars become more interested in our projects. They made an effort to grasp basic concepts. Our stand-ups and sprint planning sessions had more abstract thinking involved and were able to mitigate for stakeholder budgeting, better control deadlines and they made room for us to try things.
I want to believe that these are habits that we learn and develop over time to be better communicators. I also hope the teams we work for gain more appreciation and invest time for communication. I was lucky to have an open-minded team.
Thank you for reading, for any suggestions please leave a comment below!