The intersection of technology and leadership

Category: Conferences (page 1 of 7)

Three tips to become a public speaker

I am grateful that I have had a chance to do a lot of public speaking. Speaking at conferences and user groups has many benefits: You meet new people, you are introduced to different ideas, you often get to visit new places, and share your own ideas and experiences. I am particularly thankful for many wonderful memories where people have come up to me, sometimes years later, to mention they saw a talk of mine and thanked me for sharing my knowledge and experiences.

Over the years, I have also helped many people with their own personal journey of speaking at conferences or events. I found myself repeating several tips that, in this blog, I want to share with you.

1. You have something to say

People early on in their speaking journey often throw this statement up as their first mental hurdle:

“I have nothing to say”

What’s fascinating about this statement is the assumption that everyone has heard and learned everything there is in our industry. Considering that the technology industry is constantly evolving with its tools, platforms, languages and practices, there will always be someone who hasn’t been exposed to some idea or some experience. Everyday there are more and more people coming into technology, each with a different background, and there will be something they have not read, listened to, or learned yet.

You have an opportunity to share your own lessons learned. You do not need to be the expert, and you do not need to be a person who has invented an idea to share your own knowledge. We all stand on the shoulders of giants, and as long as you attribute other people’s ideas, you should not worry about this.

For ideas for talk topics, consider:

  • What problem did you solve in own environment, that others might learn from?
  • Have you applied a certain technique/approach in a context where it is not so usual?
  • In learning a new tool, framework or practice, what lessons and traps did you discover along the way?
  • With a repeated experience, or practice, have you uncovered some general principles that work for you?
  • Is there something that you found difficult to find information on the Internet? If you can’t find it, it’s likely that others cannot as well.

As I wrote in a previous post about preparing a proposal for a conference, experience is super valuable and attached to a relevant topic, or a slightly different spin about a technique or tool, you can offer others a different perspective, and insight.

Everyone has something interesting to say. Find a friend, a coach, or a mentor to bounce ideas off and see if there is an interesting experience you can share.

2. Start off small

I don’t know anyone who started their public speaking career by launching into a keynote, or presenting at one of the largest or most popular conferences in their industry. Agile software development teaches us to start small, gather feedback and learn to adapt and refine your talk.

Practice makes perfect – An age-old maxim.

I recommend first-time speakers start small, and practice giving their talks to groups as depicted in the below diagrams.

A lunch and learn (sometimes called brown bag) tend to be one of the smallest and safest places to practice your talk. Often held at a lunch-time, a lunch and learn talk often doesn’t require as much polish or preparation as other types of talks. You also have the benefit of knowing some of people who might attend, giving you a chance to get objective feedback to help you improve. Pro-tip: Ask some people attending in advance if they can give you feedback, so they can give you more specific and concrete observations as feedback.

As you gather feedback from a lunch and learn, you might then look to find a relevant user group to host your talk. A user group tends to be more formal than a lunch and learn, but are still often informal groups where you can test your talk for flow, and even discuss the talk with people who hang-around after a conference. This is a super-valuable source of seeing if you communicated your ideas successfully.

Rather than targeting a large conference, look for a smaller conference (<300 people) to submit your talk to. A smaller conference might have trouble attracting more well-known speakers, and give you less competition in submitting and getting accepted. See my tips for submitting a proposal here. You may be happy keeping to smaller conferences as you build up experience and confidence in presenting your topic. Smaller conferences offer you a number of experiences: Stepping on stage without being overwhelmed by a faceless crowd, or feeling like you can chat to people in between sessions rather than at a convention of 800+ people.

Once you master these smaller conferences, you might start to get invites or be accepted into a larger conference. These conferences are often multi-stage, or multi-day conferences which tests your ability to really perform on stage and appeal to a much broader group.

Finally, and it’s definitely not necessarily for everyone, you may even get an invite to keynote a conference. I am a big believer that keynotes are slightly different from your average conference talk. I see these as talks that should be inspirational, introduce a different idea to an audience and have a different feeling compared to other talks at the same conference. A really good keynote should be difficult to pull off, because it draws upon both your speaking experience and skills but also challenges the audience with a different perspective.

3. Discover your own style

Like many activities, public speaking draws upon many different skills and experiences. Everyone has a different approach to composing and telling their presentations, and it is this variety which keeps conferences stimulating. Over time, with more practice, you will discover your own style that resonates with your audience.

In the meantime, I recommend the following books to help you prepare:

  • Presentation Zen (Reynolds) – Written by the person who worked alongside Steve Jobs for his famous apple keynotes and provides plenty of advice for composing and designing the presentation.
  • slide:ology (Duarte) – Another great book that explores the difference of presenting information via slide decks versus other forms of documentation as well as many recommendations about effective techniques.
  • Presentation Patterns (Ford, McCullough, Schutta) – The authors of this book are well-seasoned technical conference speakers and they draw upon the ideas of patterns and anti-patterns to describe and catalogue common advice and pitfalls for the first-time conference speaker.

As you build your experience with public speaking, and you really listen to your audience and feedback, you will discover your own style that works for you, and audiences will appreciate your authenticity.


Developing public speaking skills takes time and effort, but if you follow these the three tips above, you’ve got a good chance at starting on the right track.

Conference Tips: Submitting a Talk Proposal

I have been keynoting and speaking at conferences for more than ten years. I also contribute to a number of conferences as a reviewer, giving my thoughts to conference committees on evaluating potential talks/workshops. In this post, I want to share a number of attributes I look for, when reviewing a conference submission. It may help you as a person who wants to submit an idea to a conference. I won’t promise that your talk will be accepted if you follow these tips, but I do hope you end up with a better chance.

Conference talk preparation

Make it relevant to the conference

Some people use a scattershot approach – preparing a single talk that they send to all types of conferences. As a reviewer, it’s relatively east to spot these ones. At an agile-themed conference, there’s a loose tie to a talk titled, “Introduction to Kubernetes.” At a developer-focused conference, there’s a loose tie to talk on “Optimising flow with Kanban” unless there’s an agile twist to the conference. Talks with loose-ties will perform poorly against well-targeted talks that are very relevant to the conference theme and audience.

Consider who the conference attendees are and what themes/tracks the conference has to see if you can make the content more relevant.

Use the Goldilocks rule for talk descriptions

A talk can be too abstract when it tries to put in too many buzzwords without adding any practical information. Want to talk about microservices, docker, or continuous delivery? Great, but let us know how your talk is different and useful. A talk can also be too specific with a very narrow lesson or target audience. Great that you want to talk about how you managed to optimise the smallest possible CSS, using X tool! Is it relevant to a conference focused on software architecture?

Follow Goldilocks and make sure that your talk abstract is just right by considering how your description gives some weight and more meat to your talk. Conceptual talks with examples are a good start. A super narrow topic can be fine as long as it really unique or interesting for potential attendees.

Bonus tip: One sentence talk abstracts are normally too short.

Make your talk title and description match

I don’t claim to have the best talk titles, but I really make sure that the talk descriptions builds on what is eluded to in the talk title. I have see too many submissions where people have a catchy title, and then the description doesn’t match the topic at all. It sometimes seems like two completely unrelated topics and I give the submission a low rating because it’s hard to predict what it will actually deliver.

Define concrete learning points

Although some talks are intended to be inspirational, many talks are there to help others learn about a particular circumstance. You will attract the right participants, and help committees select your topic if you can explain what you hope audience members will learn. I look for three to five key points in a 50-60 minute talk that make your talk stand out from others. The more concrete (and relevant) these learning points are to the audience/conference, the better.

Avoid the sales pitch

Unless you are at a vendor conference, I favour talks that are not overly product focused. This becomes more difficult when the field is highly aligned to a specific topic or technology. Amazingly I have seen many talk submissions made, as if the marketing department of some mega-corporate technology vendor (wonder who that could be, cough cough) made it on behalf of someone else. Please provide something useful, rather than words that don’t add substance.

Draw on real world experiences

People love hearing stories about problems and solutions for technology conferences, and real world experiences or case studies can be really strong vehicles for demonstrating lessons learned. Distilling case studies into higher level conceptual, design or architectural learnings rate highly (assuming it is relevant to the audience).

Use your editing tools

Although I don’t expect all submissions to come from people where English is the first language, please make sure you run your submissions through some sort of spellcheck or grammar check. It’s very painful as reviewers if every third word has a typo and we can’t understand every sentence. If we can’t understand them, chances the conference attendees will not be able to understand them too!

These basic tools are built into almost all text editing program, so please use them.


Having a conference talk accepted isn’t really a mysterious process. There are certainly things that make the life of a selection committee or reviewer much easier if you follow the tips I provide above. Although these tips don’t guarantee your proposal will be accepted, following these will make sure that they don’t automatically get rejected.

Good luck!

We can do better

I’m proud that many people are actively addresing diversity issues. Research shows that diversity leads to better problem solving and often, more creative solutions. Unfortunately the results of history lead us to where we are today, but we can always do better. I’m proud to be part of ThoughtWorks, where we are also trying to do our part to address diversity issues, and our work was recently recognised as a great company for Women in Tech. And yes, I do realise that diversity goes beyond just gender diversity.

As a fairly regular conference speaker this year, I have been disappointed by some of the actions of both conference organisers and speakers that have been, in my opinion, rather unhelpful.

At a conference speaker’s dinner earlier in the year, the topic of diversity came up where someone calculated that only 4 out of almost 60 speakers were women. I was truly disappointed when one of the conference organisers responded with, “That’s just the industry ratio isn’t it? It’s just too hard to find women speakers.” Of course not all conference organisers have this attitude, such as The Lead Dev conference which ended up with 50% women:men speaker ratio or like Flowcon which achieved a >40% ratio women:men as well. Jez Humble writes about his experiences achieving this goal (recommended reading for conference organisers).

At another conference, I saw a slide tweeted from a talk that looked like this below (Note: I’ve found the original and applied my own label to the slide)

Bad slide of stereotypes

My first thoughts went something like: “Why do all the developers look like men and why do all the testers look like women?” I was glad to see some other tweets mention this, which I’m hoping that the speaker saw.

We all have responsibilities when we speak

I believe that if you hold talks at a conference, you have a responsibility to stop reinforcing stereotypes, and start doing something, even if it’s a little thing like removing gendered stereotypes. Be aware of the imagery that you use, and avoid words that might reinforce minority groups feeling even more like a minority in tech. If you don’t know where to start, think about taking some training about what the key issues are.

What you can do if you’re a speaker

As a speaker you can:

  • Review your slides for stereotypes and see if you can use alternative imagery to get your message across.
  • Find someone who can give you feedback on words you say (I am still trying to train myself out of using the “guys” word when I mean people and everyone).
  • Give your time (mentoring, advice and encouragement) to people who stand out as different so they can act like role models in the future.
  • Give feedback to conferences and other speakers when you see something that’s inappropriate. More likely than not, people are more unaware of what other message people might see/hear, and a good presenter will care about getting their real message across more effectively.

What to do if you’re a conference organiser

I’ve seen many great practices that conferences use to support diversity. These include:

One thing that I have yet to experience, but would like as a speaker is a review service where I could send some version of slides/notes (there is always tweaking) and get some feedback about whether the imagery/words or message I intend to use might make the minorities feel even more like a minority.

SATURN 2016, San Diego

I first heard of SATURN via social media through Michael Keeling, an IBM employee who spoke at XP2009 many years ago. Sam Newman spoke last year about Microservices. Although the conference has a Call For Papers (CFP) each year, they also had a small number of invited speakers and Michael organised for me to go along to talk about Evolutionary Architecture.

SATURN is a conference organised by the SEI (Software Engineering Institute). SEI are probably most well known for CMM, although there is now another institute responsible for it. The conference has been running since 2005 and has a long history of focusing on architectural concerns.

Architecting the Unknown

Architecting the Unknown keynote by Grady Booch (@Grady_Booch)

What I really liked about the conference

I believe that one of SATURN’s greatest strengths is a focus on architectural thinking, through the application of the latest tools. Unlike some other conferences, I felt like the programme tried to assemble a good collection of experience reports and presentations that emphasised the architectural principles, rather than focusing on the current tools.

Although this may be less popular for people wanting to learn how to use a specific tool, I feel this emphasis is much more valuable and the lessons longer lasting.

What I also really enjoyed about the conference was the relatively small size which was just over 200 participants from various parts of the world. Having a good location, and small size allowed for some better quality conversations both with other speakers and attendees. One good example of the conference facilitating this, was an office hours session for attendees to easily ask questions of speakers. I shared by office hours with Eoin Woods (author of Software Systems Architecture) and Grady Booch (IBM Fellow, One of the Three Amigos who were best known for developing the Unified Modeling Language).

SATURN 2016 Conference Dinner

Conference dinner at a baseball game for SATURN 2016

Another example to reinforce that was connecting with Len Bass (one of the authors of Software Architecture in Practice) at the conference dinner (at a baseball game).

Other observations

During the conference I spoke with many people carrying various Architect titles. Interestingly many came from many larger organisations and government agencies, which shouldn’t have been any surprise given the history of the conference. I remember meeting and speaking with one particular Enterprise Architect (EA), who seemed to be one of the most pragmatic EAs I’d met, who was trying at all costs to stop his board randomly signing large contracts with product vendors like Oracle and IBM without the proper diligence about understanding what they were actually building.

At the same time, I met a number of architects struggling to help their organisations see the value of architecture and the role of the architect.

My talk

I spoke after Booch’s initial keynote, “Architecting for the Unknown” which lead really well onto the topic I was speaking on, “Evolutionary Architecture“. I had a packed room as was a topic that resonated with people. At one point the conference organised brought more chairs into the room and there was still only standing room for the 90 minute talk! I had some great questions and conversations throughout and found out later that I won the award for the best conference talk in the “Architecture in Practice” category!

Evolutionary Architecture Talk

SATURN Evolutionary Architecture talk audience

I’d definitely recommend attending SATURN if you’re interested in focused on building architectural thinking and an opportunity to connect with architects across the industry. The size is great for conversations, sharing experiences and with next year’s scheduled for Colorado will be really interesting too.

Final thanks

I’d like to thank the organising group calling out Michele Falce (Technical Event Coordinator), Bill Pollak (General Chair), Jørn Ølmheim and Amine Chigani (Technial Co-Chairs) who did a great job putting together a fantastic conference, John Klein for hosting Office Hours, and Michael Keeling for organising an invite for me.

Championing P3 on a panel at DevTalks Bucharest

On Thursday I was presenting at DevTalks Bucharest, a 550+ developer conference with four different stages. I shared the panel with a Sabin Popa (Cloud Strategy Leader at IBM) and there was supposed to be another panelist but they had withdrawn. The topic of the panel was, “Innovation and data privacy – Keeping innovation alive in Cloud!” We first presented a bit about ourselves and our companies, where I was talking about our three pillars: Sustainable Business (P1), Software Excellence (P2), and Social Justice (P3).

Image courtesy of

Image courtesy of Phillipp Krenn (@xeraa)

I talked a lot about observations we see around the world with our clients – these stories really resonated with people, particularly because:

  • It is based in reality (and not just sales demonstrations or fancy presentations)
  • People are genuinely interested in what other people are doing around the world.

During the panel, I talked about the responsibilities that we have as developers for privacy, and the responsibilities that we have as educated citizens to get this on the agenda of our parliaments. I touched upon the idea of Datensparsamkeit and that we can use our knowledge to start raising awareness among our friends and families.

Although not meaning to, I found that I probably spent a lot of time talking on the panel – but mostly because both the moderator and the other panelist wanted to keep asking questions of me. I had suggested that Sabin also give his own thoughts about what they could be done about data privacy.

When we touched the topic of innovation in the cloud, the topic of certification came up – something that didn’t really surprise me. One statement was that all platforms would be certified in the future (for security) and that would be considered one form of innovation. Although useful, I challenged the position, talking about how certification gives false confidence – particularly in services and products where people are involved. I think certification is definitely useful for testing mechanical parts, for testing platforms and products that never change – but software is soft. It constantly involves and once a platform is certified, doesn’t mean it will continue to pass the same tests. I see a lot of companies sell certification as an easy answer and I believe it gives companies a false sense of confidence.

An interesting question posed to the panel is what would we do if we are asked by our company to do something that is borderline unethical but not doing the task puts our job at risk and the mention that there are many more people to do our role. This, for me, was an easy answer. I talked about our responsibility of being digitally-educated and responsible citizens of the world and talked about the bravery and confidence of people like Snowden. I challenged everyone we should think through the consequences of mindlessly doing tasks that we don’t believe in and not think about just the consequences of the job right now, but question the consequences for our family, friends and the world we are creating for future generations.

Thoughts on OOP2015

I spent the first half of last week in Munich, where I was speaking at OOP Conference 2015. I missed last year when Martin Fowler was a keynote but had presented both in 2013 and 2012.

The conference still seems to attract more seasoned people like architects and decision makers and I am still constantly surprised at the number of suits I see for a technical conference – I do not know if that is more of a German culture difference as well. I felt like there were significantly more German-speaking sessions than English ones, and I sat in a number of them when I expanded my vocabulary.

I was only there for three of the five days of the conference, and was lucky enough to be invited and attend a special dinner on Monday evening where Dr Reinhold Ewald (a former German astronaut) gave a presentation about what it was like being an astronaut, what they do in space and some of the interesting challenges.

I saw a number of the keynotes and talks which I’ll briefly summarise here:

  • Challenges and Opportunities for the Internet of Things (IoT) by Dr Annabel Nickels – A relatively introductory session on what the Internet of Things actually means. The talk explained the IoT well, why it’s not possible and what people are experimenting with. It was clear that security and privacy aspects had not advanced and that there was still a lot of work to go, as there were lots of questions from the audience, but no clear answers in this space – more “it’s something we’re looking into”-sort of answers
  • Coding Culture by Sven Peters – Sven is an entertaining, engaging and obviously well-practiced presenter who knows how to engage with the audience with pictures and stories. His talk focused on coding culture – but more particularly the coding culture of Atlassian, the company Sven works for. An entertaining talk about how they work inside the company, but was not particularly surprising for me since I know already a lot about that company.
  • Aktives Warten für Architekten by Stefan Toth (Actively Waiting for Architecture) – A nice introduction to the Last Responsible Moment or what is more popular in the Agile community these days, Real Options.
  • Ökonomie und Architektur als effektives Duo by Gernot Starke, Michael Mahlberg (Economics and Architecture as an effective pair) – From my understanding, the talk focused on bringing the idea of calculating ROI on an architectural front. The pair spent a lot of ideas introducing financial terms and then a number of spreadsheets with a lot of numbers. Although well-intentioned, I wasn’t sure about the “calculations” they made since a lot of it was based on estimates of “man-days” needed and “man-days” spent/saved – it all looks very good when calculated out, but they didn’t really spent much time eliciting how they get estimates. They spent a lot of time introducing Aim42 which I wasn’t familiar but will now look into.

I ran two talks that had both good attendance and great feedback (like the one below):

OOP2015 - Best Talk

The fist was “The Geek’s Guide to Leading Teams” where I focused on exploring the responsibilities and remits of what a Tech Lead does and how it’s quite different from being a developer.

The second was “Architecting for Continuous Delivery” which focused on the principles and considerations for when people build systems with Continuous Delivery in mind.

I had a great time visiting the conference and had an interesting time expanding my German vocabulary as I tried to explain what I and what my company do in German – something I didn’t really do a lot of when I was living in Berlin.

Booklist from the Retrospective Facilitators Gathering 2014

The Retrospective Facilitators’ Gathering is the only conference I planend on attending in 2014. Like many conferences, I end up with many books to read, and thought it’d be worth sharing the list I accumulated here:

Implementing Continuous Delivery Workshop Prework

At XP2013, Christian Trabold and I will be giving a tutorial on Implementing Continuous Delivery. In order to prepare for the workshop we ask you to bring a computer and do the following before the workshop:

  1. Install VirtualBox (
  2. Install Vagrant with minimum of v1.2.1 (
  3. Ensure that you have at least 2.5GB of free space on your hard disk
  4. Ensure that your USB port is working so that we can provide the image via a portable Hard Drive/Stick.
  5. Make sure you don’t use local ports like 8080 and 8153 (We need these ports for accessing the apps on the VirtualMachine)

Feedback for Conference Presenters

After presenting at the recent Quarterly Technology Briefing in London, Manchester and Hamburg I had a very good question from one of my colleagues about what feedback I found most valuable.

Our feedback forms were quite short with two quantitative questions (out of a 1-5 scale), and three or four free text questions. Although the quantitative questions gave me a good indication of general feedback from the audience, it is not specific enough for me to really understand what things to do more of, or things to do less of. It reminds me of a traffic light system some conferences used (red, yellow, green) for evaluating conference presenters. Fun, quick, but entirely useless to know why people put numbers down.

Although the free text answers to feedback forms take more time to read, the feedback is much more helpful, particularly around getting an understanding of where expectations for a session matched or didn’t match, and useful suggestions or ideas to focus more on. I can take this feedback and actually do something about it for a different presentation.

For conference organisers, or if you’re putting feedback forms together for your own workshop, please don’t leave feedback as a binary, or based solely on numbers. Although there are advantages to getting quicker to an evaluation, you don’t really know why people rated something well or not well. Ask open ended questions and provide these to speakers unedited and raw.

I think if conferences really wanted speakers to get better as well, I think having some peer presenters sit in a session and provide targeted feedback would be even better. I could imagine something like this could focus solely on the mechanics and/or execution of the presentation and give timely, helpful feedback to improve the session and the presenter.

Agile Testing Days Summary

My last speaking conference for the year was the Agile Testing Days held in Potsdam on the outskirts of Berlin. In terms of conference history, this was its fourth year of running and attracts a lot of the big names in agile testing circles, as one would expect from the name. For me, as a test-infected developer , I found it fascinating to see what concerns the testing audience and I felt many common themes around whether or not testing was important, the difference between an agile tester and a normal tester, and of course a focus on collaboration and working iwth other roles.

They had three keynotes a day, a pretty overwhelming number considering that there were multiple tracks and sessions. I don’t think I would do much justice trying to summarise them all but I’ll share a number of highlights that I took away. Jurgen Appelo spoke about the stories behind his books. He’s an entertaining speaker, very well prepared and I feel very in agreement with his “all models are broken but some are useful” approach to collecting different software methodologies and giving a go at lots of different things. Just as the community is continuing to expand beyond just software development, his focus is also pointing upwards into the upper hierarchies of management – to those with the money, budget and decisioning making authority. He’s invented something he’s calling the “management workout” although I shudder at this after seeing it associated (read: abused) by a very hierarchical organisation very much into command and control. Ask me about it one day if you see me in person.

I also appreciated Gojko’s keynote presentation challenging existing thoughts on collecting information, metrics and that all we are doing is improving the process of software development, not necessarily the product. His argument feels very similar to the lean start up movement that why bother putting quality around features we aren’t even sure are useful by anyone, or not validated. He quoted a number of clients he’s seen who throw away automated testing suite in favour of measuring impact on business metrics and trends – using that to work out regressions. It’s an interesting approach that requires a) businesses to actually identify their real business metrics (very rare in my opinion) and b) link features to these metrics and c) measure them very carefully for changes. I guess this also goes along with his new book on Impact Mapping to work out where to put the effort.

He also criticised the testing quadrants, argued that we’re collecting the wrong data, points out that exploratory testing is still testing the process (not the product) and that most organisations are missing feedback once they go live. He also came up with his own adaptation on the Maslo’s hierarchy of needs in terms of software. It starts off with building deployable/functional software, then it should meet performance/security needs, then be usable, followed by useful and then followed by successful. He also recommended a book new to me, called “The Learning Alliance: Systems Thinking in Human Resource Development”

I ran my session, TDDing Javascript Front Ends shortly after a BDD session that complemented the idea very well. The previous session focused on why/what and not the how, where mine was a good depth into how you do it from a hands on practitioner point of view. I had a number of good questions and people after the talk that gave me some great feedback and encouraged me to do more. The only shame was that the session was limited to 45minutes and the tutorial that I run with is normally achievable. I look forward to people taking the online tutorial (found here) and then passing in even more feedback.

Older posts

© 2018 patkua@work

Theme by Anders NorenUp ↑