In 2017, I gave a technical presentation about using UiPath Studio for automated testing. I was working in QA, years before I moved into presales.
The invitation came from someone who had helped me get my first job in QA. He was working at iQuest by then.
I hadn't spoken in front of that kind of audience before. I had given internal QA training to newer colleagues, so explaining technical work to other people was familiar. Doing it outside that setting was new.
I made slides and rehearsed. I enjoyed the experience, and I'd do it again. Looking back, the part I'd spend more time practising is the delivery: intonation and articulation.
The recording below is in Romanian. It gives me a way to look at what I actually did, beyond what I remember nine years later.
What I wanted to show
Our team had started using UiPath Studio for automated testing. It was an RPA platform, and I wanted to show that we could use it for tests too. I included a comparison with Selenium to explain the idea.
I don't remember how I chose the particular example. I do remember what I wanted to demonstrate: something we had begun doing in our work, using the platform for a purpose beyond its original focus.
That context matters when watching the recording. This was a QA engineer explaining an approach in 2017. The product details belong to that period. What interests me now is how I explained them to people who hadn't been working alongside me.
Using familiar concepts to explain an unfamiliar tool
In the talk, I refer to Selenium and concepts such as waits, exceptions and selectors while explaining how the activities work in Studio. Those references give someone with testing experience a place to start.
A new interface already gives people plenty to take in. If they recognise the problem being solved, they have less to work out at once. They can connect the unfamiliar activity to something they understand, instead of trying to remember every new name on the screen.
That is a useful check when preparing a technical presentation: what can the audience already recognise in the thing you're explaining? It might be a concept from another tool, or simply a task they have done themselves. You still need to explain the differences; a comparison only gets you started.
Later, I also make a distinction between being able to build something without writing code and benefiting from technical knowledge. Those are different claims. Removing some code from the process doesn't remove the need to understand what you're asking the software to do.
Giving people time to follow the demo
Before running the demo, I explain the sequence people are about to see. I then use slower debug execution so the steps can be followed. I also explain that I'm running a single input row to avoid a long demonstration.
Slowing the execution down costs time, but it makes the individual actions easier to see. Limiting the amount of data keeps the audience from sitting through repeated work once the sequence is clear.
The viewer needs enough time to understand each step, without having to watch it happen over and over. A fast run may finish successfully while leaving someone unsure what just happened.
The demo starts around minute 24, if you want to see that part of the recording.
What I'd practise more today
I'd spend more rehearsal time on how the explanation sounds. Knowing the subject gives you the words; it doesn't automatically make them easy to follow when spoken. Intonation helps make the point of a sentence clear. Articulation helps people hear the words without having to work them out from context.
For someone preparing a talk, that deserves time alongside the slides and the software. Say the explanation aloud. Listen for where an important point gets lost in the delivery, even though it looks perfectly clear on the slide.
I now work in presales, where explaining technical work is part of the job. In 2017, I was doing it as a QA engineer who had been invited to share something. I enjoyed it then, and speaking more clearly is still something I want to get better at.